From: Richard Stallman <[EMAIL PROTECTED]>
Date: Sat, 09 Apr 2005 21:55:23 -0400
Although someone else said he could not reproduce this,
it could be that sometimes W2 is null. Your change can't
hurt anything. So I installed it.
thank you.
i have not investigated further, but any
On 4/10/05, Jan D. <[EMAIL PROTECTED]> wrote:
> Yes,and for Lesstif/Motif. There has been bug reports on this
> approach. The main confusion seems to be that when a small buffer is
> used (like the three initial lines in the *scratch* buffer), the
> scrollbar thumb does not extend to the bottom,
Richard Stallman said:
> It seems that only the last overlay survives.
>
> That seems to be what the code was designed to do.
>
> As for what the code SHOULD be trying to do, I am not really
> certain. I never use that feature,
I was used to the old behavior showing all the "wrong"
whitespace
Eli Zaretskii wrote:
Except in Emacs compiled with --without-x and on MSDOS. So please
let's not preload tooltip in those cases.
Actually, the reason I thought it had to be preloaded was because of
confusion with some prior similar cases. The only drawback of not
preloading it is that we
> I don't like preloading xt-mouse, since most users don't want it.
> Could you make lisp/term/xterm.el load it instead?
Problem is, xterm.el is loaded after .emacs, so doing it in xterm.el makes
it difficult for users to turn it off.
Stefan
> confusion with some prior similar cases. The only drawback of not
> preloading it is that we need to duplicate the same code in the
> defcustom and in startup.el and make sure that the two stay exactly in
> sync.
There are other ways to avoid this duplication. See patch below.
Stefan
> Is GC the only reason to avoid Feval inside XTread_socket?
> If so, is it possible to use code conversion together with
> inhibit_garbage_collection?
Jan D. explained the problem, and I will just note that compiling
with -DSYNC_INPUT should lift that restriction (because it causes
XTread_socket
Stefan Monnier wrote:
There are other ways to avoid this duplication. See patch below.
Stefan
--- startup.el 08 avr 2005 10:38:07 -0400 1.344
+++ startup.el 10 avr 2005 10:35:33 -0400
@@ -737,7 +737,8 @@
emacs-quick-startup
Otherwise Custom might get confused if something "simplifies" the
non-nil value to `t', as I believe `define-minor-mode' does. On the
other hand, it is clearly documented that any non-nil value of the
variable indicates an enabled mode.
Yes, any non-nil value *in the variable* sho
> > confusion with some prior similar cases. The only drawback of not
> > preloading it is that we need to duplicate the same code in the
> > defcustom and in startup.el and make sure that the two stay exactly in
> > sync.
>
> There are other ways to avoid this duplication. See patch below.
Richard Stallman <[EMAIL PROTECTED]> writes:
> Although someone else said he could not reproduce this,
> it could be that sometimes W2 is null. Your change can't hurt
> anything. So I installed it.
I could reproduce the crash and the patch fixes it for me.
Lute.
_
Nick Roberts wrote:
I don't know how to access the standard value (:init-value?), what
would happen if its not set, etc, but if its a sensible idea, I
could look at it.
The standard value is the _unevaluated_ expression given as value in
the defcustom. In the case of define-minor-mode,
$B"#"#"#!V(B1$B1_!WJ,L5NA%]%$%s%HB#Dh%-%c%s%Z!<%se$2$^$9!*(B
$B"!(B1$B1_L5NA%]%$%s%H$H?7$7$$=P2q$$(BGET$B!*"*"*"*(B
http://awg.qsv20.com/?springm
$B!zL5NA$GAjEvM7$Y$^$9$N$G@'Hs$*;n$72<$5$$$M"v(B
$B!z;HMQ$7$F$_$F!V$3$l$O!*!W$H;W$C$FD:$$$?J}$N$_!VM-NA!W$X$*?J$_2<$5$$!#(B
_
$BB>$N%5%$%H$H$N0c$$$rBN83$7$F2<$5$$!*(B
$B(Bhttp://www.getluck.net/
$B4JC1A`:n$G4JC1EPO?!*(B
$B!!??7u$J=P2q$$$O$3$3$+$i(B
$B!!(B $B=i$a$F$NJ}$OL5NA%(%s%H%j!<$+$i$I$&$>(B
$B(Bhttp://www.getluck.net/
$B"(GIhttp://lists.gnu
I have been trying Font Lock mode, which I never used to use before.
I notice that when stealth fontification is occurring, Emacs spends
about 1/3 of its time GCing. The frequent GCs make for annoying
latency when I type another command.
Could someone investigate why so much consing goes on durin
Please do preload tooltip, except in the two conditions that Eli
identified. Since it will nearly always be used, it's good to have
it preloaded.
However, xt-mouse should never be preloaded.
Please go ahead and adapt your change to that decision, and install it.
___
Problem is, xterm.el is loaded after .emacs, so doing it in xterm.el makes
it difficult for users to turn it off.
In that case, I agree let's handle it Luc's way.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/l
Jan D. explained the problem, and I will just note that compiling
with -DSYNC_INPUT should lift that restriction (because it causes
XTread_socket to not be run from the signal handler any more).
Do you recall what the disadvantages of -DSYNC_INPUT were?
I think one disadvantage may hav
Thanks. I've just encountered a situation that I'd like to use
code conversion, which may call Feval, inside XTread_socket.
XTread_socket runs in a signal handler. I don't think Emacs can
recover from a Lisp error occurrinmg in the signal handler.
I think there are many other potential c
Yes,and for Lesstif/Motif. There has been bug reports on this
approach. The main confusion seems to be that when a small buffer is
used (like the three initial lines in the *scratch* buffer), the
scrollbar thumb does not extend to the bottom, since we have added the
fictit
I was used to the old behavior showing all the "wrong"
whitespaces not just the last one.
Now I understand what you want it to do.
Does this replacement function make it work right?
(defun whitespace-highlight-the-space (b e)
"Highlight the current line, unhighlighting a previously jump
Richard Stallman wrote:
However, 0 as argument to the minor mode function is supposed to turn
the mode off. Could you verify that still works right afetr your
change? If it doesn't, another change in another place is probably
needed.
Yes, I checked that it still works correctly afte
In article <[EMAIL PROTECTED]>, Shixin Zeng <[EMAIL PROTECTED]> writes:
> On my system, when locale is set to zh_CN.UTF8, XIM input
> methods(SCIM/fcitx) can't be launched.
> If I set the locale to zh_CN.GBK, both emacs and XIM input methods work
> fine.
> for other apps, XIM input methods work
> Jan D. explained the problem, and I will just note that compiling
> with -DSYNC_INPUT should lift that restriction (because it causes
> XTread_socket to not be run from the signal handler any more).
> Do you recall what the disadvantages of -DSYNC_INPUT were?
> I think one disadvanta
> I have been trying Font Lock mode, which I never used to use before.
> I notice that when stealth fontification is occurring, Emacs spends
> about 1/3 of its time GCing. The frequent GCs make for annoying
> latency when I type another command.
I haven't looked at the consing behavior, but I'll
Kenichi Handa wrote:
Sorry for the late response on this matter, but I can't
reproduce it, i.e. I can use input methods via SCIM in both
locales zh_CN.UTF8 and zh_CN.GBK in both emacs22 and emacs23
(both CVS latest).
What I tried is this:
% scim -d
% LANG=zh_CN.GBK [EMAIL PROTECTED] emacs
% LANG=zh
In article <[EMAIL PROTECTED]>, Shixin Zeng <[EMAIL PROTECTED]> writes:
> Kenichi Handa wrote:
>> Sorry for the late response on this matter, but I can't
>> reproduce it, i.e. I can use input methods via SCIM in both
>> locales zh_CN.UTF8 and zh_CN.GBK in both emacs22 and emacs23
>> (both CVS late
Richard Stallman said:
> Now I understand what you want it to do.
> Does this replacement function make it work right?
Yes it does work correct now.
Thank you.
--
Stephan Stahl
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mail
28 matches
Mail list logo