In article <[EMAIL PROTECTED]>, Luc Teirlinck <[EMAIL PROTECTED]> writes:
> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant. If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicod
> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant. If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicode and hence with Emacs 23. (Unless I misunderstood.)
Indeed,
St
There is something that has not been pointed out in the summary Handa
gave, but which I believe may be relevant. If I understood correctly,
the problem in question will automatically completely disappear with
Unicode and hence with Emacs 23. (Unless I misunderstood.)
Sincerely,
Luc.
_
Stefan's proposal is to translate a character by
translation-table-for-input in read_char (). This is a
generic solution, but it makes read_char () return different
character depending on the buffer-file-coding-system of the
current buffer, which may or may not cause anther pro
We (me and Stefan) has already shown opinions and solutions
to the problem. Richard, could you please decide what to
do?
I have not been reading these messages, because they were numerous and
long. Now that there are two proposals, would you please show me the
two proposals, each des
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> The very right way is to shift to emacs-unicode. As long as
>> we have multiple character codes for characters that user
>> don't want to distinguish, any fix is just a dirty work
>> around.
> I'm not sure about "w
Hello!
I am not sure whether I understood the discussion, but wasn't it about
whether it's worth to correct the i-search code or better do it in the
Unicode version of Emacs? So I better should keep the patches Stefan
Monnier sent me and not update from CVS that often?
--
Greetings
Pete
"They
I didn't know that self-insert-cmmand also uses
translation-table-for-input. I have thought that the
variable is for an input method as in this docstring:
Perhaps the first step is to come up with a clearer statement of what
its job should be. From that, we should be able to decide e
> The very right way is to shift to emacs-unicode. As long as
> we have multiple character codes for characters that user
> don't want to distinguish, any fix is just a dirty work
> around.
I'm not sure about "workaround" but it'll only ever be a heuristic.
> Your patch may fix not only the curr
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> 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 do
> 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 l
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>>> Hmm... indeed the translation-table-for-input is not used for X11 keys.
>>> Now that I look at it a bit more, I think the patch below would make sense.
>>> What do other people think?
>> That doesn't work in some c
>> Hmm... indeed the translation-table-for-input is not used for X11 keys.
>> Now that I look at it a bit more, I think the patch below would make sense.
>> What do other people think?
> That doesn't work in some case. The value of
> translation-table-for-input can be different in each buffer
> (
In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
> Hmm... indeed the translation-table-for-input is not used for X11 keys.
> Now that I look at it a bit more, I think the patch below would make sense.
> What do other people think?
That doesn't work in some case. The val
Am 14.04.2005 um 16:31 schrieb Stefan Monnier:
Any objection/adjustment?
In X11 in an ISO 8859-1 buffer it works to i-search (and find) for
Ã,Ã,Ã,Ã,à ... but: in an ISO 8859-2 buffer it fails to find  (degree).
The original  is:
character: Â (04260, 2224, 0x8b0, U+00B0)
charset: latin-iso
15 matches
Mail list logo
