> No, I can't. But shouldn't we avoid such an incompatible
> change at this stage?
Can be. But since it's about a year now since we called a freeze and I see
no sign of getting to the pretest stage, I figure I don't understand enough
what "feature freeze" means: I just propose changes and I'll let someone
else decide whether they should be installed.
I think it's The Right Way to solve the problem, so that's what I use in my
local code, but if someone wants to write a "quick&safe" fix instead and use
that instead I see no problem with it. I'm still interested to know whether
I'm right or not in thinking that my fix is The Right Way.
>> Hypothetical examples aren't too interesting since we can also
>> concoct such examples where the current "translate in
>> self-insert-command" can be made to fail.
> I didn't know that self-insert-command also uses
> translation-table-for-input. I have thought that the
> variable is for an input method as in this docstring:
> Char table for translating self-inserting characters.
> This is applied to the result of input methods, not their input. See also
> `keyboard-translate-table'.
> Anyway, could you show me such an example?
Let's see:
(insert (with-current-buffer foo
(buffer-substring (point)
(progn
(call-interactively 'self-insert-command)
(point)))))
Yes, it's silly,
Stefan
_______________________________________________
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
