On Fri, Jun 01 2007, Richard Stallman wrote:
> What version are you running?
> If it is from CVS, is it the trunk or which branch?
It was the trunk (tough not fully up-to-date) as written in my
original mail (or isn't 22.1.50.n unique to the trunk?):
| Note that my Emacs is not current, but from
On Fri, Jun 01 2007, YAMAMOTO Mitsuharu wrote:
>> I think it crashed while creating the new frame; I don't recall
>> seeing the frame appear, but I'm not absolutely sure.
I think Emacs was creating a frame while/before my crash as well.
> I think this is due to string data relocation caused by E
Richard Stallman <[EMAIL PROTECTED]> writes:
> > Font-lock-keywords can not be set any more in the local variables
> > section of a file. Use font-lock-defaults instead.
>
> I find the change in behavior sufficiently mysterious that I'm
> not even sure this characterization is
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
>> On Fri, 01 Jun 2007 10:05:41 +0900, YAMAMOTO Mitsuharu <[EMAIL
>> PROTECTED]> said:
>
>> I think this is due to string data relocation caused by ENCODE_UTF_8
>> in x_set_name_internal (GTK+ only).
>
> GCPRO was missing in the previous patc
> Font-lock-keywords can not be set any more in the local variables
> section of a file. Use font-lock-defaults instead.
I find the change in behavior sufficiently mysterious that I'm not even sure
this characterization is correct.
We want to give users a simple and clear rec
What version are you running?
If it is from CVS, is it the trunk or which branch?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I suggest not patching Emacs 22.1 at this time.
Ok, I won't.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
> On Fri, 01 Jun 2007 10:05:41 +0900, YAMAMOTO Mitsuharu <[EMAIL
> PROTECTED]> said:
> I think this is due to string data relocation caused by ENCODE_UTF_8
> in x_set_name_internal (GTK+ only).
GCPRO was missing in the previous patch. Below is a revised one.
Richard Stallman <[EMAIL PROTECTED]> writes:
> I think it should instead say something like:
>
> `fontified'
>This property says whether the text is ready for display. If nil,
>Emacs's redisplay routine will call the `fontification-function' (which
>see) to prepare
> On Fri, 01 Jun 2007 00:35:33 +0200, [EMAIL PROTECTED] (Kim F. Storm) said:
> I had a crash yesterday with the emacs 22 branch (not fully
> up-to-date, but close):
> GNU Emacs 22.0.990.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of
> 2007-05-23 on kfs-lx
> It is built on an up-to-date Debia
Chong Yidong <[EMAIL PROTECTED]> writes:
> Reiner Steib <[EMAIL PROTECTED]> writes:
>
>> report-emacs-bug wrote:
>>
>>> Please describe exactly what actions triggered the bug
>>> and the precise symptoms of the bug:
>>
>> My Emacs session which has been already running for several days
>> (noteboo
I think it should instead say something like:
`fontified'
This property says whether the text is ready for display. If nil,
Emacs's redisplay routine will call the `fontification-function' (which
see) to prepare this part of the buffer before it is displayed.
Reiner Steib <[EMAIL PROTECTED]> writes:
> report-emacs-bug wrote:
>
>> Please describe exactly what actions triggered the bug
>> and the precise symptoms of the bug:
>
> My Emacs session which has been already running for several days
> (notebook with suspend to disk) crashed. I don't recall whi
report-emacs-bug wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
My Emacs session which has been already running for several days
(notebook with suspend to disk) crashed. I don't recall which command
triggered the bug.
> If Emacs crashed, a
martin rudalics <[EMAIL PROTECTED]> writes:
>> (set (make-local-variable 'font-lock-keywords)
>> ! (font-lock-eval-keywords (or keywords font-lock-keywords)))
>
> Wouldn't this mean that old keywords survive a major-mode change?
> What about the companions in `font-lock-defaults'? I
>>> I had this in my local variables section:
>>
>>> mode: font-lock
>>> font-lock-keywords: ("^\\S-.*:$")
>>
>>> which worked in Emacs 21, but does not work any more in Emacs 22. I
>>> solved the problem by writing instead:
>>
>>> mode: font-lock
>>> font-lock-defaults: (("^\\S-.*:$"))
>>
>>
>> +("\\(\\)'" (1 (sh-font-lock-backslash-quote)))
> Then we might do
>> +("\\(\\)" (1 (sh-font-lock-backslash)))
> as well.
Except that \' is much less common then \, so the first incurs the
additional cost of sh-font-lock-backslash-quote much less often.
Stefan
__
>> (set (make-local-variable 'font-lock-keywords)
>> ! (font-lock-eval-keywords (or keywords font-lock-keywords)))
> Wouldn't this mean that old keywords survive a major-mode change?
> What about the companions in `font-lock-defaults'? In general I
> think all those should survive iff they
> Only thing I say, if it is left as it is, maybe it should be mentioned
> in the NEWS with something like:
> Font-lock-keywords can not be set any more in the local variables
> section of a file. Use font-lock-defaults instead.
I find the change in behavior sufficiently mysterious that I'm
Richard Stallman <[EMAIL PROTECTED]> writes:
> Should this fix be installed in Emacs 22.1?
> Or is it safer for us to leave that bug unfixed?
I suggest not patching Emacs 22.1 at this time.
First, this only affects setting font-lock-keywords in local
variables, which is an advanced user activity
In lisp-mode the indentation of the following expression is wrong:
(foo
:bar :a12
:sie sume )
If I press TAB at the beginning of the last line I get:
(foo
:bar :a12
:sie sume )
I think this is wrong, the indentation should be as the first example.
This was not the behaviour in emacs 21,
>> I had this in my local variables section:
>
>> mode: font-lock
>> font-lock-keywords: ("^\\S-.*:$")
>
>> which worked in Emacs 21, but does not work any more in Emacs 22. I
>> solved the problem by writing instead:
>
>> mode: font-lock
>> font-lock-defaults: (("^\\S-.*:$"))
>
>I must say th
>Should this fix be installed in Emacs 22.1?
>Or is it safer for us to leave that bug unfixed?
I have no idea of the reasons or the implications of this change, nor if
the correct behaviour was the previous or the current one.
Only thing I say, if it is left as it is, maybe it should be mentioned
> +("\\(\\)'" (1 (sh-font-lock-backslash-quote)))
Then we might do
> +("\\(\\)" (1 (sh-font-lock-backslash)))
as well.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-
> (set (make-local-variable 'font-lock-keywords)
> ! (font-lock-eval-keywords (or keywords font-lock-keywords)))
Wouldn't this mean that old keywords survive a major-mode change?
What about the companions in `font-lock-defaults'? In general I
think all those should survive iff they h
25 matches
Mail list logo
