Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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


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.