Bug 224626 - emacs 22: dead keys don't work
Summary: emacs 22: dead keys don't work
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: rawhide
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Chip Coldwell
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-01-26 19:08 UTC by Ville Skyttä
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 22.0.93-6.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-02-13 15:55:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ville Skyttä 2007-01-26 19:08:45 UTC
With 22.0.93-4 locally built from devel on FC6 i386, dead keys don't work.  Any
attempt to type them results in no characters appearing in the buffer and eg.
"<dead-tilde> is undefined" error appearing in the minibuffer.

This is under KDE, Finnish keyboard layout, LANG=en_US.UTF-8, XMODIFIERS=@im=none

Changing LANG or XMODIFIERS (including unsetting the latter) has no effect, so
it's probably a different issue than bug 217189

Comment 1 Chip Coldwell 2007-01-26 20:25:52 UTC
(In reply to comment #0)
> With 22.0.93-4 locally built from devel on FC6 i386, dead keys don't work.  Any
> attempt to type them results in no characters appearing in the buffer and eg.
> "<dead-tilde> is undefined" error appearing in the minibuffer.

Does "C-x 8 ~ n" work?

Chip


Comment 2 Chip Coldwell 2007-01-26 21:27:27 UTC
(In reply to comment #0)
> 
> This is under KDE, Finnish keyboard layout, LANG=en_US.UTF-8

Actually, that strikes me as a somewhat strange combination: Finnish keyboard
with LANG=en_US.UTF-8.  But maybe it can still be made to work.

My guess is that the value of the variable "keyboard-coding-system" will be nil.
 Please verify that for me.

If it is, then try "C-x RET k" which will prompt you for a new
keyboard-coding-system (or if you reach the value of keyboard-coding-system via
"C-h v" you'll be given the opportunity to customize this variable).  Try
setting it to the value "mule-utf-8" and see if that brings back the dead keys.

Thanks,

Chip




XMODIFIERS=@im=none
> 
> Changing LANG or XMODIFIERS (including unsetting the latter) has no effect, so
> it's probably a different issue than bug 217189



Comment 3 Ville Skyttä 2007-01-26 21:55:11 UTC
(In reply to comment #1)

> Does "C-x 8 ~ n" work?

Yes.  Actually, immediately after typing "C-x 8" I see "Loading
iso-transl...done." in the minibuffer, and after that all dead keys suddenly
start working!

> Actually, that strikes me as a somewhat strange combination: Finnish keyboard
> with LANG=en_US.UTF-8.  But maybe it can still be made to work.

Hopefully, that's how I like it and is more or less what I've successfully used
for 10 or so years (sans UTF-8 for some of that period obviously).  I think I
could go for LANG=en_FI.UTF-8 but for some reason that sounds like asking for
trouble to me ;)
 
> My guess is that the value of the variable "keyboard-coding-system" will be
> nil.  Please verify that for me.

Verified, it's nil.  But changing it to mule-utf-8 doesn't seem to make any
difference wrt. dead keys.


Comment 4 Chip Coldwell 2007-01-26 23:17:52 UTC
(In reply to comment #3)
> (In reply to comment #1)
> 
> > Does "C-x 8 ~ n" work?
> 
> Yes.  Actually, immediately after typing "C-x 8" I see "Loading
> iso-transl...done." in the minibuffer, and after that all dead keys suddenly
> start working!

If you put

(require 'iso-transl)

in your .emacs file, does that also work?

Chip


Comment 5 Ville Skyttä 2007-01-26 23:30:40 UTC
Yep, that works.

Actually there seem to be a few dead keys that still don't work which used to
work in Emacs 21.4 and do also work in XEmacs and other apps (such as
<dead-cedilla>, ie. "¸") but the current situation is a big improvement.

Comment 6 Alexandre Oliva 2007-01-27 03:31:26 UTC
I use a BR-ABNT2 keyboard with en_US.UTF-8.  When I start rawhide
emacs-22.0.93-3.fc7, keyboard-coding-system is mule-utf-8, but dead keys don't
work just the same.  C-x 8 loads iso-transl and then it starts working.  loading
iso-transl in .emacs works around the bug as well.

Comment 7 Chip Coldwell 2007-01-31 15:39:32 UTC
(In reply to comment #3)

> > My guess is that the value of the variable "keyboard-coding-system" will be
> > nil.  Please verify that for me.
> 
> Verified, it's nil.  But changing it to mule-utf-8 doesn't seem to make any
> difference wrt. dead keys.

Could you try one other thing?  Instead of (require 'iso-transl) in your .emacs,
could you run 

(progn
         (set-default-coding-systems 'utf-8)
         (set-terminal-coding-system 'utf-8)
         (set-keyboard-coding-system 'utf-8))

and report if dead keys work?

Thanks,

Chip


Comment 8 Alexandre Oliva 2007-01-31 16:34:12 UTC
FWIW, I didn't need any of these with my own build of the Emacs 22.0.90 test
release.  Now, even with iso-transl, I experience regressions.  I can't enter
character ´ (acute accent) any more.  In gtk and other emacsen, I can do this by
typing dead_acute twice.  Other pairs of dead keys, that used to generate the
corresponding character, now replace the effects of the previous dead key (i.e.,
double or triple dead_acute is the same as dead_acute, even in terms of error
messages, and dead_acute dead_tilde is the same as dead_tilde)

Note that ´ (acute accent) is not the same as ' (apostrophe).  The latter is
generated with dead_acute blank.  For most other dead accents in a US keyboard
configured for intl mode (or a BR-ABNT keyboard, for that matter), the accent is
present in ASCII, so doubling the dead key or following it by a blank has the
same effect.  The other exception is dead_umlaut, that when doubled should
generate the umlaut itself, but when followed by blank generates ".


Comment 9 Chip Coldwell 2007-01-31 16:58:52 UTC
(In reply to comment #8)
> FWIW, I didn't need any of these with my own build of the Emacs 22.0.90 test
> release.

Do you know if the problem started between 22.0.90 and 22.0.91?  All the pretest
releases are available here:

 ftp://alpha.gnu.org/gnu/emacs/pretest/

Chip


Comment 10 Ville Skyttä 2007-01-31 17:22:26 UTC
(In reply to comment #7)
> Instead of (require 'iso-transl) in your .emacs, could you run 
> 
> (progn
>          (set-default-coding-systems 'utf-8)
>          (set-terminal-coding-system 'utf-8)
>          (set-keyboard-coding-system 'utf-8))
> 
> and report if dead keys work?

Tried, does not help.

Comment 11 Alexandre Oliva 2007-02-13 04:42:22 UTC
I've just built emacs-22.0.93 on FC6/x86_64, out of the pretest tarball, without
any arguments to configure other than --prefix, and it doesn't display this
problem.  So it's something specific to the Fedora build.  According to rpm -i
emacs-22.0.93-5.fc7.src.rpm, I'm not missing any of the -devel packages.

Comment 12 Alexandre Oliva 2007-02-13 05:07:59 UTC
The problem is caused by the --without-xim configure flag.  Take it out and
everything works properly again.  Unless you're an unhappy user of the
C-SPC-stealing iiimf, that is :-/

Since there are other ways to bring C-SPC back that are under the user's
control, I'd rather this option be removed from the Fedora build.

Comment 13 Chip Coldwell 2007-02-13 15:55:08 UTC
(In reply to comment #12)
> The problem is caused by the --without-xim configure flag.  Take it out and
> everything works properly again.  Unless you're an unhappy user of the
> C-SPC-stealing iiimf, that is :-/
> 
> Since there are other ways to bring C-SPC back that are under the user's
> control, I'd rather this option be removed from the Fedora build.

OK, done.  We'll wait for the C-SPC bugzillas to roll in now.

Chip



Comment 14 Ville Skyttä 2007-02-13 20:59:52 UTC
Confirmed, dead keys work again without iso-transl in 22.0.93-6.*.  Thanks.

Just a minor observation; I seem to have been miscredited for the --without-xim
change in %changelog, the credit for that finding belongs to Alexandre, not me.

Comment 15 Chip Coldwell 2007-02-13 21:58:01 UTC
(In reply to comment #14)
> 
> Just a minor observation; I seem to have been miscredited for the --without-xim
> change in %changelog, the credit for that finding belongs to Alexandre, not me.

I'll fix that in the next update.  I hope Alexandre can forgive me if I don't
bump the EVR again just to fix the changelog.

Chip



Note You need to log in before you can comment on or make changes to this bug.