- Original Message -
From: "Stefan Monnier" <[EMAIL PROTECTED]>
> > IIRC, you were the one to propose _not_ following a link in a
> > non-selected window, and I initially said it made sense (so I
> > implemented it unconditionally).
>
> I meant "frame", sorry.
Am I seriously misunderstan
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> If you don't cancel the timer, it will expire at the wrong moment
> (counted since the time it was set by whatever previous activation).
Thanks, I see how it is implemented now. I thought of a rather different
model.
And m
I am not versed enough in the matter, but since signals restore the
setting of interrupt_input_blocked, those would appear to be bugs.
What do you mean by "signals"?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/
/* Unblock input if we enter with input blocked. This may happen if
redisplay traps e.g. during tool-bar update with input blocked. */
while (INPUT_BLOCKED_P)
UNBLOCK_INPUT;
return Fthrow (Qtop_level, Qnil);
}
This approach of unblocking input appears
When tex-mode.el from current CVS is compiled, it produces the
following warning:
In tex-mode:
tex-mode.el:818:8:Warning: function `tex-mode' defined multiple times in
this
file
Is this okay?
It is expected. I find this somewhat ugly but I don't know
a good wa
BLOCK_INPUT;
...
record_unwind_protect()
...
UNBLOCK_INPUT;
unbind_to();
I think that code is correct.
Neither record_unwind_protect nor unbind_to does anything to
interrupt_input_blocked. If there is no abnormal control transfer,
unbind_to will run the
I got rid of the confusing double-levels of hiding,
and the double magic button, by redefining `face'
in terms of `editable-field'. I also put in a "sample"
to show what the chosen face looks like.
It works except for one thing: when I set a different face name,
the sample does not update. How c
Do `emacs -Q', turn on global-font-lock-mode, and visit a long file --
say, `.emacs'. Now go back to the `*scratch*' buffer and evaluate the
following:
(defun check-buffer ()
(if (not (eq (current-buffer) my-buffer))
(message "Foo: %s" (buffer-name (current-buffer)
(setq my-buffer (cu
I am trying to understand the implementation around hourglass cursors. When
I look through eval.c, fns.c, keyboard.c, lread.c and minibuf.c I see in
many places something like:
#ifdef HAVE_X_WINDOWS
if (display_hourglass_p)
cancel_hourglass ();
#endif
Is this really correct?
Richard Stallman <[EMAIL PROTECTED]> writes:
> It works except for one thing: when I set a different face name,
> the sample does not update. How can I make it update?
I don't have time to find out.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
ht
"Chong Yidong" <[EMAIL PROTECTED]> writes:
> Do `emacs -Q', turn on global-font-lock-mode, and visit a long file --
> say, `.emacs'. Now go back to the `*scratch*' buffer and evaluate the
> following:
>
> (defun check-buffer ()
> (if (not (eq (current-buffer) my-buffer))
> (message "Foo: %
Richard Stallman <[EMAIL PROTECTED]> writes:
> I am not versed enough in the matter, but since signals restore the
> setting of interrupt_input_blocked, those would appear to be bugs.
>
> What do you mean by "signals"?
I am confusing unwind-protect with catch/throw. Sorry for that.
--
Richard Stallman <[EMAIL PROTECTED]> writes:
> /* Unblock input if we enter with input blocked. This may happen if
>redisplay traps e.g. during tool-bar update with input blocked. */
> while (INPUT_BLOCKED_P)
> UNBLOCK_INPUT;
>
> return Fthrow (Qtop_level, Qnil);
Also with regard to the other report you answered (where I was wrong):
I might well be mistaken. I am just trying to get a hold of why Emacs
keeps crashing on me. It appears, anyway, that something seriously
elusive is going on here. I'll probably have to implement some kind
of trace buffering f
Hello,
I'm trying to gather data for a bug report on random segfaults I have
with emacs.
I run emacs under gdb as explained in etc/DEBUG.
Now I enter gdb whenever I press c-g, which is unexpected and
inconvenient.
Is there some other way to handle this?
To clarify further: winding up in gd
"Jan D." <[EMAIL PROTECTED]> writes:
Also with regard to the other report you answered (where I was
wrong):
I might well be mistaken. I am just trying to get a hold of why
Emacs
keeps crashing on me. It appears, anyway, that something seriously
elusive is going on here. I'll probably have to i
"Jan D." <[EMAIL PROTECTED]> writes:
>> Also with regard to the other report you answered (where I was wrong):
>> I might well be mistaken. I am just trying to get a hold of why Emacs
>> keeps crashing on me. It appears, anyway, that something seriously
>> elusive is going on here. I'll probabl
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Date: Sun, 27 Feb 2005 18:57:08 +0100
>
> I am trying to understand the implementation around hourglass cursors. When
> I look through eval.c, fns.c, keyboard.c, lread.c and minibuf.c I see in
> many places something like:
>
> #ifdef HAVE_X_WIND
Can anyone think
> of a non-obsolete use for keyboard-translate-table, to put in
> the example?
It's used in normal-erase-is-backspace-mode (when running on a tty).
Could you write an example based on normal-erase-is-backspace-mode?
It's also used for flow-ctrl.el, which is
I tried graphviz-dot-mode.el on OSX with the external Graphviz Viewer
and it worked very nice. I didn't know about the dot language before.
But now I think I will used it further. Personally, I mean this new
language and this new mode fits very well into Emacs philosophy.
That is u
FOR-RELEASE does not mention this. In any case, shouldn't it be done
*before*
the Emacs manual is proofread, otherwise new errors will creep in.
I did go through and update the Lisp manual fully.
However, that was about a year ago, after which things stalled
because I could not convince p
EDITED, shown value does not take effect until you set or save it.
That is good.
SET for current session only.
That is good.
UNCUSTOMIZABLE, you should not see this.
How about
NO CUSTOMIZATION DATA; you should not see this.
___
Emac
>> > IIRC, you were the one to propose _not_ following a link in a
>> > non-selected window, and I initially said it made sense (so I
>> > implemented it unconditionally).
>>
>> I meant "frame", sorry.
> Am I seriously misunderstanding something? Is not the Emacs window focus
> what a user is int
"Jan D." <[EMAIL PROTECTED]> writes:
>> "Jan D." <[EMAIL PROTECTED]> writes:
>>
>>> If you configured with GTK, there is a possibility that multiple
>>> threads are updating interrupt_input_block. I've tried to handle that
>>> situation, but bugs may of course still remain.
>>
>> How did you try
Richard Stallman wrote:
UNCUSTOMIZABLE, you should not see this.
How about
NO CUSTOMIZATION DATA; you should not see this.
I installed the latter. It really does not matter that much, since
those variables really should not find their way into Custom buffers.
Sincerely,
Luc.
> elusive is going on here. I'll probably have to implement some kind
> of trace buffering for interrupt_input_block in order to get a hold of
> what is happening here.
If for some reason you think the problems you're experience have something
to do with interrupt_input_block, maybe you should tr
Stefan Monnier <[EMAIL PROTECTED]> writes:
> Of course maybe he really meant "window", but that seems rather unlikely
> to me. This said, I agree that I'd have expected the window-manager to take
> care of such things (basically the window-manager shouldn't pass on
> a mouse-1 click to the applic
David Kastrup <[EMAIL PROTECTED]> writes:
> This sounds like normally only the main thread should ever be touching
> interrupt_input_blocked, unless we have a bug. Correct? So we need
> not think about how to synchronize accesses to the variable, but
> rather make sure that no thread except the
Werner LEMBERG <[EMAIL PROTECTED]> writes:
> [CVS 2005-Feb-09]
>
> Please call base64-decode-region on this mail snippet:
>
>
> SGVsbG8sDQogICBJIHdhbnQgdG8gYW5kIEdCMjMxMiB0byBhIGZvbnQgZmlsZSAuQnV0IEl0IGNh
> biBiZSB1c2VkIGJ5IHRoZSBmcmVldHlwZSAuSXQgcmV0dXJuIG1lIGEgNiB3aGVuIEkgdXNlIFNl
> bGVjdF9DaGFy
> From: Joakim Verona <[EMAIL PROTECTED]>
> Date: Sun, 27 Feb 2005 21:27:15 +0100
>
> Now I enter gdb whenever I press c-g, which is unexpected and
> inconvenient.
>
> Is there some other way to handle this?
Start GDB from the Emacs's src directory. There's a .gdbinit file
there that takes ca
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> elusive is going on here. I'll probably have to implement some kind
>> of trace buffering for interrupt_input_block in order to get a hold of
>> what is happening here.
>
> If for some reason you think the problems you're experience have something
> t
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>
> Start GDB from the Emacs's src directory. There's a .gdbinit file
> there that takes care of this problem. (The etc/DEBUG file actually
> tells you that as its first advice.)
As far as I can determine, my gdb instance is running with this
.gdbini
> Can you give a full procedure starting with emacs -Q that exhibits
> the error.
Execute this in a fresh buffer:
(setq buffer-display-table (make-display-table))
then copy
SGVsbG8sDQogICBJIHdhbnQgdG8gYW5kIEdCMjMxMiB0byBhIGZvbnQgZmlsZSAuQnV0IEl0IGNh
biBiZSB1c2VkIGJ5IHRoZSBmcmVldHlwZSAuSXQgcmV
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Werner LEMBERG <[EMAIL PROTECTED]> writes:
>
>> [CVS 2005-Feb-09]
>>
>> Please call base64-decode-region on this mail snippet:
>>
>>
>> SGVsbG8sDQogICBJIHdhbnQgdG8gYW5kIEdCMjMxMiB0byBhIGZvbnQgZmlsZSAuQnV0IEl0IGNh
>> biBiZSB1c2VkIGJ5IHRoZSBmcmVldHlwZSAuSXQ
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Werner LEMBERG <[EMAIL PROTECTED]> writes:
>
>> [CVS 2005-Feb-09]
>>
>> Please call base64-decode-region on this mail snippet:
>>
>>
>> SGVsbG8sDQogICBJIHdhbnQgdG8gYW5kIEdCMjMxMiB0byBhIGZvbnQgZmlsZSAuQnV0IEl0IGNh
>> biBiZSB1c2VkIGJ5IHRoZSBmcmVldHlwZSAuSXQ
- Original Message -
From: "Eli Zaretskii" <[EMAIL PROTECTED]>
> > From: "Lennart Borgman" <[EMAIL PROTECTED]>
> > I am trying to understand the implementation around hourglass cursors.
When
> > I look through eval.c, fns.c, keyboard.c, lread.c and minibuf.c I see in
> > many places someth
Dear Friend,
I am Mr.Leu Shan,we are a group of business men who deal on import
andexport raw materials into canada,america and europe. We are searching
for representatives who can help us establish a medium of getting to
ourcostumers in the canada,america and europe as well as making paym
> The original message said:
>
>However I might just want to select that window to resize it
>
> so AFAICT this whole thread has been about a confusion between "click
> mouse-1 to follow link" and "click mouse-1 to give focus to a *frame*".
>
> Of course maybe he really meant "window
> Instead of arguing about general policies, which it is very unlikely
> we will change, would you like to check a few files of the Lisp
> manual?
I don't think it would very fruitful for me to check the lisp manual as I am
not an expert in these matters. However, I have provided documentation
Lute Kamstra <[EMAIL PROTECTED]> writes:
[...]
> A second problem I encountered is with debugger-jump. It is currently
> not documented in the lisp manual so I'm trying to figure out what it
> does. From what I understand, it is intended to work just like
> debugger-continue with the difference
> > Start GDB from the Emacs's src directory. There's a .gdbinit file
> > there that takes care of this problem. (The etc/DEBUG file actually
> > tells you that as its first advice.)
>
>
> As far as I can determine, my gdb instance is running with this
> .gdbinit.
>
> Heres gdb:s star
> From: "Lennart Borgman" <[EMAIL PROTECTED]>
> Cc:
> Date: Mon, 28 Feb 2005 01:20:35 +0100
>
> There is clearly something I do not understand here.
Perhaps you are not the only one ;-)
> However I can
> not see how hourglass support can be implemented at all if those places
> where you hide or
This sounds like normally only the main thread should ever be touching
interrupt_input_blocked, unless we have a bug. Correct? So we need
not think about how to synchronize accesses to the variable, but
rather make sure that no thread except the main thread will ever run
code touching it. Corre
In article <[EMAIL PROTECTED]>, "Chong Yidong" <[EMAIL PROTECTED]> writes:
> "Benjamin Riefenstahl" <[EMAIL PROTECTED]> wrote:
>> Grep is our friend ;-). The coding-system (and its CCL programs) is
>> created in lisp/international/ccl.el using (define-ccl-program ...).
>> The parameter BUFFER_
44 matches
Mail list logo
