On 01/02/09 01:24, Sven Joachim wrote:
It does happen with emacs -q (on my system emacs -> emacs21).
I think you mean "it does _not_ happen" here?
Correct.
It also does not happen if I comment out the line noted in step #1
above from my regular .emacs.
Good to know. As this line is bad, do you agree that we can close this
bug as a cockpit error?
The original reasoning was to make Meta-H give help rather than
Control-H. The context in my .emacs is:
(global-set-key "\M-h" 'help-command)
(setq help-char "\M-h")
(global-set-key "\C-h" 'delete-backward-char)
... which I originally put in a dozen years ago, under Emacs 19. I don't
recall doing it (obviously), but even my teenage self wouldn't have done
it by trial and error; the config would have been based on documentation
somewhere.
It does what I wanted: make Meta-H be the help character and Control-H
be backspace. And there aren't any error messages when .emacs is read.
Strangely, this now still seems to be true if I comment out the setq line.
The only reason I hesitate about closing the bug is that the error
message is so far removed from the source of the problem and so opaque.
Ideally the setq line should fail, though I don't know how hard that is
to implement in elisp. I would never connect the string "\350" (which
shows up to me as a lowercase e with an accent above it) to the sequence
"\M-h", and nothing about the error message or the context seemed to
have anything to do with the help character.
IOW, I'd say there's a usability bug here due to the violation of the
principle of least surprise.
Also, do you see this with emacs22 as well?
>>
I haven't tried emacs22. I tend to resist Emacs version upgrades
because the changelogs are so massive and it takes a while to read
them and figure out what's going to affect me. However, I can install
it and try if needed.
Perhaps it helps you reconsidering this decision if I tell you that we
currently have 83 bugs in emacs21 that are tagged "fixed-upstream",
meaning that they are not present in emacs22ยน. Also, emacs21 isn't
really supported anymore.
You do have some good points there. ;) It's not really a decision, more
laziness. I will prioritize it higher.
Thanks again for solving this problem!
Reid
--
http://blog.reidster.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org