On 7/8/06, Nicolas FRANCOIS <[EMAIL PROTECTED]> wrote:
Maybe it's a problem with keymap installed directly in the kernel, or in
the console file... I just want to test every possible solution.
I think this has more to do with X and emacs than the kernel. I'm
pretty confident that the compose input methods for emacs have nothing
to do with the kernel or the linux console.
I've upgraded my LFS to a recent version (6.1.1 SVN, in fact). I used to
work on a 6.0 (also SVN), and the keyboard worked just fine. I have the
SAME versions of Xorg (6.9.0), Emacs (21.4.1), the same configuration
files (xorg.conf, .emacs...), but the behaviour of the Alt-Gr key has
changed.
Before that, it behaved as a classic deadkey, and I could call one of my
emacs macros : "C-c AltGr ^" produced the sequence "^{}" and placed the
cursor between the two braces (one of my macros, not a miracle ;-)
Now, when I press the Alt-Gr key, Emacs blinks. I can still insert a "^"
character with AltGr-9, but Emacs blinks on the Altgr key, and the
previous sequence ends badly after the Altgr keypress, not calling the
right macro.
I don't know if this will help, but I came across this Debian commit
against emacs-21.4a (same as in BLFS book).
http://lists.alioth.debian.org/pipermail/pkg-emacs-commits/2005-August/000068.html
Try the patch at the bottom that just switches the order of two
#includes in src/xterm.h. If that doesn't work, I would try building
emacs from CVS.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
