Bill Wohler <[EMAIL PROTECTED]> writes:
> Bill Wohler <[EMAIL PROTECTED]> writes:
>
>> Stefan Monnier <[EMAIL PROTECTED]> writes:
>>
Make a buffer with this content:
>>>
In-reply-to: "foo bar" of Fri, 15 Jul 2005 20:31:33 EDT
>>>
(2 lines only)
Then
M-x mh-le
I'd be happy if instead of just clearing out inhibit-quit it would cause the
C-g to call the debugger.
That sounds like a good idea. Would you like to try it and see how it
works for you?
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gn
> We could conceivably bring it back in this modified form.
> But I think it calls for some care. Simply clearing out inhibit-quit
> is likely to leave something broken. Emacs should display a message
> warning the user that that is the case.
I'd be happy if instead of just clearing out inhibit-
If two C-g are separated by 2 seconds or more and the first is not processed
by the time we see the second, then we can assume that Emacs is
non-responsive and that inhibit-quit should probably be ignored.
This sounds much like the emergency escape feature. That is disabled
on window
> The most common such problem by far is when a regexp hits a pathological
> exponential-matching behavior. I wish we'd fix that one instead.
> It would be good to fix that, but how? It is a consequence of the
> algorithm, and even recognizing these cases would seem to be a hard
> proble
The most common such problem by far is when a regexp hits a pathological
exponential-matching behavior. I wish we'd fix that one instead.
It would be good to fix that, but how? It is a consequence of the
algorithm, and even recognizing these cases would seem to be a hard
problem.
Al
Bill Wohler <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>
>>> Make a buffer with this content:
>>
>>> In-reply-to: "foo bar" of Fri, 15 Jul 2005 20:31:33 EDT
>>>
>>
>>> (2 lines only)
>>> Then
>>> M-x mh-letter-mode
>>> M-x font-lock-fontify-buffer
>>
>>> You
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> Make a buffer with this content:
>
>> In-reply-to: "foo bar" of Fri, 15 Jul 2005 20:31:33 EDT
>>
>
>> (2 lines only)
>> Then
>> M-x mh-letter-mode
>> M-x font-lock-fontify-buffer
>
>> You get:
>> font-lock-default-fontify-region: Wrong type ar
> As you can see, this function sometimes returns non-nil (i.e. it says it's
> found a match) but with no begin/end of match 0.
> Is that incorrect? If so, why did it appear to work ok before?
> Maybe the criterion for a bad match has to be written differently
> to accord with the practi
As you can see, this function sometimes returns non-nil (i.e. it says it's
found a match) but with no begin/end of match 0.
Is that incorrect? If so, why did it appear to work ok before?
Maybe the criterion for a bad match has to be written differently
to accord with the practical rules
> Make a buffer with this content:
> In-reply-to: "foo bar" of Fri, 15 Jul 2005 20:31:33 EDT
>
> (2 lines only)
> Then
> M-x mh-letter-mode
> M-x font-lock-fontify-buffer
> You get:
> font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil
This is introduced by m
In the current CVS version as of today:
GNU Emacs 22.0.50.8 (i686-pc-linux-gnu, X toolkit) of 2005-07-15
Make a buffer with this content:
In-reply-to: "foo bar" of Fri, 15 Jul 2005 20:31:33 EDT
(2 lines only)
Then
M-x mh-letter-mode
M-x font-lock-fontify-buffer
You get:
font-lock-de
12 matches
Mail list logo
