Kenichi Handa skrev:
In article [EMAIL PROTECTED], Jan D. [EMAIL PROTECTED] writes:
I've checked in a fix that changes UTF8_STRING to STRING if the data
doesn't look like UTF8. However, this might give errors too. The only
way to be sure to copy raw binary data correctly is by adding a
Kenichi Handa [EMAIL PROTECTED] writes:
Peter Dyballa [EMAIL PROTECTED] writes:
Launched with -Q
unify-8859-on-decoding-mode is nil
unify-8859-on-encoding-mode is t
I start i-search in an Unicode encoded buffer (*Help*). In an ISO
8859-1 encoded buffer ä and Ä are found, also
In article [EMAIL PROTECTED], Jan Djärv [EMAIL PROTECTED] writes:
AFAIK, only when TEXT is requested, an selection owner can
choose the returning type from STRING, COMPOUND_TEXT, or
UTF8_STRING. When UTF8_STRING is requested, we should
return it or return nothing.
And, if Emacs owns
Increment of the counter is suspended during the file dialog/menu
operation. And after the operation, the timer fires multiple times
continuously until the counter catches up the value that it would be
if no file dialog/menu were activated.
Weird. Suppose
My description above is about the count-up example in Simon's message.
You can observe a similar behavior using the example and M-! sleep 5
RET
I see, delayed window autoselection turns itself off in that case.
Anyway, does it make sense that a timer fires more frequently than
prescribed by
What did you think of treating the scroll-bars in the same way? (That
is,
suspend autoselection if scrolling.)
I could write
((or (menu-or-popup-active-p)
(not (coordinates-in-window-p
(cons mouse-x-position mouse-y-position) window)))
Funnily enough, weird was the exact word I used in an email too. But then
I thought buffering up the timers to run later might be the most logical
thing to do, in the circumstances. Maybe it makes more sense than not
running the timers at all. After all, as I'm sure the documentation aught
I've checked in a fix that changes UTF8_STRING to STRING if the data
doesn't look like UTF8. However, this might give errors too. The only
way to be sure to copy raw binary data correctly is by adding a new type
(like application-specific/octet-stream). But if we do that, nobody
will be
In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] writes:
AFAIK, only when TEXT is requested, an selection owner can
choose the returning type from STRING, COMPOUND_TEXT, or
UTF8_STRING. When UTF8_STRING is requested, we should
return it or return nothing.
Also IIRC a
You learn something every day. At least, I do about Emacs.
`timer-max-repeats' is the maximum number of times to repeat a timer,
if real time jumps. Hence, there is an upper bound on the number of
times such timer run.
I think the Elisp manual should mention two things: (1) That a timer can
I was thinking that it would also simplify mouse-autoselect-window-cancel,
to avoid the tests specific to scrolling, but now I see maybe that's not the
case.
The test in `mouse-autoselect-window-cancel' serves to avoid that the
pre-command hook cancels autoselection while scrolling. I could
Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use
to keep track of valid unicode chars that have no corresponding character in
emacs-mule. So the presence of eight-bit-* chars does not imply that the
utf-8 encoded form of the text will contain an invalid utf-8 byte
It currently does word-granularity, and does it very well. Character
granularity would probably be too much work compared to what it would
provide.
Actually, smerge-mode (take a look at smerge-refine) does
character-granularity and it wasn't more work (quite the opposite,
actually).
It
This isn't so much a bug, per se, as it is missing functionality. It
would be
convenient to be able to run emacs from the command line, as well as
emacsclient. However, the actual binaries are not on the path
(obviously) and
when I place a symlink to them in ~/bin and invoke them from there
Stefan Monnier skrev:
Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use
to keep track of valid unicode chars that have no corresponding character in
emacs-mule. So the presence of eight-bit-* chars does not imply that the
utf-8 encoded form of the text will contain
On Mon, 03/06/2006 07:58 +, Kenichi Handa wrote:
Hi,
This might be a bug.
During the last step of installation, ``make install prefix=/tmp/E/emacs
gives error:
/tmp/E/emacs/share/emacs/23.0.0/leim: No such file or directory
``make install will run without error.
--
Leon
GNU
A while ago, I proposed to change isearch so that it
translates characters by translation-table-for-input to
solve such a problem, but there raised an objection that
read-char should do that translation. RMS asked to check if
such a change to read-char is surely safe or not,
In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] writes:
I think we can't know what should be done, so we should strive for
simplicity and try to avoid losing information. I.e. just return the
unibyte string as-is.
Even if it doesn't conform to ICCCM? I'll attach the
relevant
There's a lot of report from chinese Emacs community that Emacs conflicts
with gnome-settings-daemon.
`C-SPC' is widely accepted as the hot-key to activate XIM input method
such as SCIM or fcitx in chinese linux community. But when
gnome-settings-daemon is running, `C-SPC' is swallowed by emacs
In article [EMAIL PROTECTED], Leon [EMAIL PROTECTED] writes:
On Mon, 03/06/2006 07:58 +, Kenichi Handa wrote:
Hi,
This might be a bug.
During the last step of installation, ``make install prefix=/tmp/E/emacs
gives error:
/tmp/E/emacs/share/emacs/23.0.0/leim: No such file or directory
Stefan Monnier [EMAIL PROTECTED] writes:
It'd probably be best to layer the diffs: first do a word-granularity diff
and then do a char-granularity diff within words.
That's my opinion too.
But maybe that'd be too slow.
This is why I was proposing just looking at the beginning and end of
21 matches
Mail list logo
