In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] writes:
So while performing some conversion, the pre/post-conversion hook (which is
utf-8-pre-write-conversion in this case) caused a GC to happen, which in
turn caused a message to be displayed (I have garbage-collection-messages
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages
Stefan Monnier [EMAIL PROTECTED] (SM) wrote:
SM I've finally had time to take a look at it on my Mac OS X system and I can
SM indeed reproduce it. The patch below seems to fix it, but it's maybe a bit
SM naive, I don't know.
SM Does someone see something wrong with such a patch?
It does solve
Symptoms:
file-name-shadow-mode doesn't recognize URLs, i.e. when I enter an URL
(using ffap) via C-x C-f, parts of the URL (// or ~) will be given
file-name-shadow-properties. Example:
1. start emacs -q --no-site-file
2. M-x file-name-shadow-mode
3. M-x ffap-bindings
4. C-x C-f and enter a URL,
Title: Message
After
starting Emacs -Qand turning
debug-on-error on I open 2 files, selectediff-merge-buffers and type n.That results in the
trace below.
This must be very recent because
on
GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600) of
2005-07-07 on LD1
this works fine (exceptthe help
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
When using emacs -nw and ido-mode, the cursor keys UP and DOWN
don't work as expected in the ido minibuffer. They seem to be
interpreted as sending M-O A and M-O B (in the shell, they send
^[[A and ^[[B).
#3 0x000e624c in show_help_echo (help=1868850540, window=3313665,
object=3313665, pos=0, ok_to_overwrite_keystroke_echo=0)
at /vol/freeware/cvs/emacs/head/emacs/src/keyboard.c:2303
Can you investigate what happened in that frame?
What was the immediate cause of the crash?
Emacs falls into infinite loop with:
1. emacs -Q -D
2. Evalulate the following expression in *scratch*.
(progn
(goto-char (point-min))
(insert (string-to-multibyte \200))
(goto-char (point-min))
(recenter))
Debugger says
ido-mode defines [(meta ?O)] to be 'ido-next-work-file for the
ido-mode-map. Removing that definition fixes the problem. It seems
this interferes with the key substitution process.
Indeed, the escape-sequence processing used on ttys (via function-key-map)
which maps ESC O A and ESC O B to `up'
