In article [EMAIL PROTECTED], Richard Stallman [EMAIL PROTECTED] writes:
I don't think it is unreasonable for single-key-description to use the
same description for these many thousands of characters especially if
they are not produced directly by any keyboard in common use.
If
Richard Stallman wrote:
Shouldn't the `single-key-description of a Chinese etc. character simply be
that Chinese character in a string?
In an ideal world, that would be ok, but most people's terminals probably
can't display the Chinese character, so they will see just a box.
Such
[EMAIL PROTECTED] (Kim F. Storm) writes:
Er, well Richard said to wait until after the release, but ...
Yes, I did.
Ouch!
Er, so given that the current code is wrong, what shall we do? Revert
to Richard's code until the release?
-Miles
--
Love is a snowmobile racing across the
My question is this: Why do these keys have as their binding
`self-insert-command'?
Because that is the binding for all characters of that group.
That sounds like because that's the way it is. Care to elaborate? The
question is not how it is done, but why it is done that way.
Er, yes. I already wrote what I see - descriptions such as this:
Character set Big5 (Level-1) A141-C67F
I'm picking up the keys by mapping over the keymaps
accessible from the
global-map (in emacs -q, for example). There are tons of such
keys for which
Drew Adams wrote:
So what? Binding thousands of characters is something computers are good at.
Binding thousands of characters is a waste of memory and time.
Or are you saying that that would affect performance in an unacceptable way?
If so, what's special about `self-insert-command' -
The problem's behavior looks like every other application receive input
from the XIM server, but Emacs receive keyboard input directly, the XIM
is bypassed.
keyboard -- XIM -- application
keyboard -- Emacs
Are you saying that XIM can't ever work with Emacs?
That
Here's a patch. I've left the indendation as it was to make the patch
shorter, but the function will need reindenting. I removed a seemingly
unneeded call to save-match-data():
The reason for the call to `save-match-data' is so that
(save-excursion
Reiner Steib schrieb:
On Thu, Sep 20 2006, Andreas Roehler wrote:
Little correction, concerning last mail to Reiner Steib:
Phenomen is gone if I
- mark and delete a portion from the beginning of the buffer
- mark and delete a portion from the end of the buffer
- save and reopen;
also -
I'm not sure this is right, because windows-1252 covers basically all bytes,
so there's no way to find out that a file is not in windows-1252.
As Latin-1 (still) has a higher priority than windows-1252 (at least
that's my understanding), windows-1252 will not be used unless there a
bytes
Richard Stallman [EMAIL PROTECTED] writes:
[...]
Are you saying that XIM can't ever work with Emacs?
Yes, that's what I mean.
That might be ok, since Emacs has its own input methods. But it would
be good to offer the possibility of using Emacs with XIM. And I thought
that this DID work.
Kenichi Handa wrote:
But, it seems that we need similay additions to the other
lang. env. Do you have any suggestions?
Here is a list from codepage.el that shows which language groups each
Windows codepage is used for and which standard charset contains the
same characters.
Where it says
So what? Binding thousands of characters is something
computers are good at.
Binding thousands of characters is a waste of memory and time.
Only if the result is not needed. Perhaps it's not. Anyway, you seem to
suggest that it's a performance issue - see next.
Or are you
My question is this: Why do these keys have as their binding
`self-insert-command'?
Because that is the binding for all characters of that group.
That sounds like because that's the way it is. Care to
elaborate? The question is not how it is done, but why it is
Am 22.09.2006 um 13:27 schrieb Miles Bader:
Peter Dyballa [EMAIL PROTECTED] writes:
There is also the option to change the 'base' of the character code
notation from 8 to 16
This feature is supported; see the variable `read-quoted-char-radix'.
Right, it works a bit, i.e. in the ASCII
On 9/23/06, Peter Dyballa [EMAIL PROTECTED] wrote:
The improvement is that I can find via an Unicode value an ISO
Latin encoded character – is this an improvement?
It's what you asked for -- that input codes use some well-known
encoding rather than the unfamiliar emacs codes.
The file code
Drew Adams wrote:
I'll take your word for it; I know nothing abou this. I thought Handa was
saying that an integer event indicated such an invalid key. If not, then I
guess one is reduced to parsing the `single-key-description' - that's what I
do currently.
You are confusing events with
Except for these invalid keys, you can use `read-kbd-macro' and call
`self-insert-command' on a key from `map-keymaps' to insert it (after
setting `last-command-char').
The fact that it works in most other cases is just accidental.
I see no relation between self-insert-command and the
If I do C-h c followed by C-mouse-2 and select Remove text properties,
the minibuffer just displays:
Describe key (or click or menu item): C-down mouse-2 rm
I then have to click mouse-1 to change it, when the message:
C-down-mouse-2 ra at that spot runs the command facemenu-remove-all
appears
I agree that one-shot timers are generally better. But when I tried to
implement a one-shot timer for delayed autoselection, it occasionally
didn't trigger for some reason. Maybe I should give it another try.
Please do give it another try, because if reactivations get lost
(other
Many keys will fail to display on various terminals, and that can't be
avoided. However, when key-description returns something that won't
display properly on certain terminals, it means that help displays
such as that of C-h b are not meaningful either. That is
Because doing so binds every character within that character group to
self-insert-command without having to bind several thousand characters
individually.
So what? Binding thousands of characters is something computers are good at.
Or are you saying that that would
Whether this is a serious enough problem to consider adding a patch this
latein the release cycle to consider, I don't know. [I think the
default value of read-quoted-char-charset would probably have to remain
nil though...]
Could you give a self-contained explanation of why you
In article [EMAIL PROTECTED], Richard Stallman [EMAIL PROTECTED] writes:
Both 20864 and 20992 are generic characters, i.e. not an
acutual character but a code representing a group of
characters (a charset or a row of characters). For
instance, (insert 20864) signals an
Richard Stallman [EMAIL PROTECTED] writes:
Could you give a self-contained explanation of why you propose this to
be added now?
I don't really care one way or another, but Peter (Dyballa) suggests
that it would be more user-friendly if non-ASCII characters
entered/searched-for via C-q code used
25 matches
Mail list logo
