Font-lock in COMINT modes

unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed

* Font-lock in COMINT modes
@ 2006-12-07  0:57 JD Smith
  2006-12-07 16:38 ` JD Smith
  2006-12-07 18:00 ` JD Smith
  0 siblings, 2 replies; 14+ messages in thread
From: JD Smith @ 2006-12-07  0:57 UTC (permalink / raw)



In Emacs 22, my idlwave-shell mode font-lock fontifies
comments/strings/etc. without having been asked to. This can be
problematic if you miss a closing quote, and all subsequent text gets
string fontification.  In Emacs 21, the only fontification was comint
coloring the prompt blue.

I don't mind the fontification so much (in fact I like it), it's just
that missing string quotes allow it to run away, latching onto parts
of the subsequent input and output in a way that's hard to cancel.
Perhaps there is an easy way to inhibit scanning through the prompt?

JD

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-07  0:57 Font-lock in COMINT modes JD Smith
@ 2006-12-07 16:38 ` JD Smith
  2006-12-07 18:00 ` JD Smith
  1 sibling, 0 replies; 14+ messages in thread
From: JD Smith @ 2006-12-07 16:38 UTC (permalink / raw)


On Wed, 06 Dec 2006 17:57:36 -0700, JD Smith wrote:

> 
> In Emacs 22, my idlwave-shell mode font-lock fontifies
> comments/strings/etc. without having been asked to. This can be
> problematic if you miss a closing quote, and all subsequent text gets
> string fontification.  In Emacs 21, the only fontification was comint
> coloring the prompt blue.
> 
> I don't mind the fontification so much (in fact I like it), it's just
> that missing string quotes allow it to run away, latching onto parts
> of the subsequent input and output in a way that's hard to cancel.
> Perhaps there is an easy way to inhibit scanning through the prompt?

A strange side note.  In attempting to find out why strings and
comments are being fontified in my comint shell, despite the fact
that:

 font-lock-defaults is a variable defined in `font-core.el'. 
 Its value is (nil)

 Local in buffer *idl*; global value is nil

I attempted to instrument `font-lock-default-fontify-region'.  Edebug
couldn't do so, giving this error:

 Debugger entered--Lisp error: (invalid-read-syntax "Expected lambda
 expression")

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-07  0:57 Font-lock in COMINT modes JD Smith
  2006-12-07 16:38 ` JD Smith
@ 2006-12-07 18:00 ` JD Smith
  2006-12-09  1:26   ` Richard Stallman
  1 sibling, 1 reply; 14+ messages in thread
From: JD Smith @ 2006-12-07 18:00 UTC (permalink / raw)



Here is the change which altered the default behavior in comint modes. 

----------------------------
revision 1.348
date: 2006-09-28 19:09:19 +0000;  author: rms;  state: Exp;  lines: +4 -1
(comint-mode): Bind font-lock-defaults non-nil.
----------------------------

If font-lock-defaults is left nil instead of being explicitly set to
'(nil) as it now is, keywords-only is implicitly true, and strings and
comments are not fontified by default.  With this change, strings and
comments are fontified by default in all comint modes (unless they set
font-lock-defaults on their own).

This patch would restore the earlier behavior.  Since I'm uncertain
whether '(nil) was intended to nullify keywords-only, I'm not sure if the
patch is appropriate (i.e. is '(nil t) practically any different from nil).

*** comint.el	28 Nov 2006 11:25:56 -0700	1.350
--- comint.el	07 Dec 2006 10:54:48 -0700	
***************
*** 653,659 ****
    (make-local-variable 'comint-accum-marker)
    (setq comint-accum-marker (make-marker))
    (make-local-variable 'font-lock-defaults)
!   (setq font-lock-defaults '(nil))
    (add-hook 'change-major-mode-hook 'font-lock-defontify nil t)
    ;; This behavior is not useful in comint buffers, and is annoying
    (set (make-local-variable 'next-line-add-newlines) nil))
--- 653,659 ----
    (make-local-variable 'comint-accum-marker)
    (setq comint-accum-marker (make-marker))
    (make-local-variable 'font-lock-defaults)
!   (setq font-lock-defaults '(nil t))
    (add-hook 'change-major-mode-hook 'font-lock-defontify nil t)
    ;; This behavior is not useful in comint buffers, and is annoying
    (set (make-local-variable 'next-line-add-newlines) nil))

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-07 18:00 ` JD Smith
@ 2006-12-09  1:26   ` Richard Stallman
  2006-12-09  2:15     ` JD Smith
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Stallman @ 2006-12-09  1:26 UTC (permalink / raw)
  Cc: emacs-devel

    Here is the change which altered the default behavior in comint modes. 

    ----------------------------
    revision 1.348
    date: 2006-09-28 19:09:19 +0000;  author: rms;  state: Exp;  lines: +4 -1
    (comint-mode): Bind font-lock-defaults non-nil.
    ----------------------------

I'm sure I did this to fix a bug, but I can't find any discussion
about it.  Maybe it was so facemenu-enable-faces-p would return nil.

As far as I can see, if font-lock-defaults is nil, that is equivalent
to (nil).  How do you conclude that nil would be equivalent to (nil t)?

But that is a side issue.  If the value (nil t) is better, we can
switch to it.  Do people agree it is better?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-09  1:26   ` Richard Stallman
@ 2006-12-09  2:15     ` JD Smith
  2006-12-09  4:02       ` Stefan Monnier
  2006-12-09 18:25       ` Richard Stallman
  0 siblings, 2 replies; 14+ messages in thread
From: JD Smith @ 2006-12-09  2:15 UTC (permalink / raw)

On Fri, 08 Dec 2006 20:26:27 -0500, Richard Stallman wrote:

>     Here is the change which altered the default behavior in comint modes.
> 
>     ----------------------------
>     revision 1.348
>     date: 2006-09-28 19:09:19 +0000;  author: rms;  state: Exp;  lines: +4
>     -1 (comint-mode): Bind font-lock-defaults non-nil.
>     ----------------------------
> 
> I'm sure I did this to fix a bug, but I can't find any discussion about
> it.  Maybe it was so facemenu-enable-faces-p would return nil.
> 
> As far as I can see, if font-lock-defaults is nil, that is equivalent to
> (nil).  How do you conclude that nil would be equivalent to (nil t)?

nil and '(nil) are not equivalent, in that the former implicitly
causes only keywords to be fontified, and the latter causes
font-lock-keywords-only to be set locally to nil (since it is a list
without a 2nd entry), which allows string and comments to be
fontified.

This is a telling comment from font-core.el:

  ;; Only do hard work if the mode has specified stuff in
  ;; `font-lock-defaults'.

All the defaults, like keyword-only, are recovered from the
font-lock-defaults list *only* if it is non-nil (e.g. '(nil)).  I
haven't understood how a purely nil font-lock-defaults implicitly
prevents string+comment fontification independent of the keywords-only
setting, but it does.

'(nil t) explicitly sets keywords-only to t, restoring the behavior.
What I don't know is whether nil and '(nil t) differ in other ways.
They clearly exercise different code paths.

JD

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-09  2:15     ` JD Smith
@ 2006-12-09  4:02       ` Stefan Monnier
  2006-12-11 16:22         ` JD Smith
  2006-12-09 18:25       ` Richard Stallman
  1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2006-12-09  4:02 UTC (permalink / raw)
  Cc: emacs-devel

> I haven't understood how a purely nil font-lock-defaults implicitly
> prevents string+comment fontification independent of the keywords-only
> setting, but it does.

Because if it's nil font-lock-mode-internal is not activated at all.
AFAIK nil and (nil t) are equivalent (i.e. don't highlight anything), except
that (nil t) takes a lot more CPU to do nothing (it runs all the
font-lock-foo-function hooks, enables jit-lock so as to do nothing
just-in-time rather than eagerly, checks where nothing needs to be done,
rounds up to a whole number of lines the region upon which inaction is
requested, checks if there's a multiline entity and extends the region even
more, so that nothing is done in a multiline awaer way, ...).

        Stefan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-09  4:02       ` Stefan Monnier
@ 2006-12-11 16:22         ` JD Smith
  2006-12-12 14:29           ` Richard Stallman
  0 siblings, 1 reply; 14+ messages in thread
From: JD Smith @ 2006-12-11 16:22 UTC (permalink / raw)


On Fri, 08 Dec 2006 23:02:29 -0500, Stefan Monnier wrote:

>> I haven't understood how a purely nil font-lock-defaults implicitly
>> prevents string+comment fontification independent of the keywords-only
>> setting, but it does.
> 
> Because if it's nil font-lock-mode-internal is not activated at all. AFAIK
> nil and (nil t) are equivalent (i.e. don't highlight anything), except
> that (nil t) takes a lot more CPU to do nothing (it runs all the
> font-lock-foo-function hooks, enables jit-lock so as to do nothing
> just-in-time rather than eagerly, checks where nothing needs to be done,
> rounds up to a whole number of lines the region upon which inaction is
> requested, checks if there's a multiline entity and extends the region
> even more, so that nothing is done in a multiline awaer way, ...).

Classic ;).

My presumption is that '(nil) and nil must differ in some other
way (aside from the unintended side effect of changing the default
non-keyword fontification), since the original change from Sept.
explicitly bound f-l-defaults non-nil, which by inference suggests nil and
'(nil t) would exhibit this same difference, whatever it is.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-11 16:22         ` JD Smith
@ 2006-12-12 14:29           ` Richard Stallman
       [not found]             ` <87vekaf780.fsf@stupidchicken.com>
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Stallman @ 2006-12-12 14:29 UTC (permalink / raw)
  Cc: emacs-devel

    My presumption is that '(nil) and nil must differ in some other
    way (aside from the unintended side effect of changing the default
    non-keyword fontification), since the original change from Sept.
    explicitly bound f-l-defaults non-nil, which by inference suggests nil and
    '(nil t) would exhibit this same difference, whatever it is.

It affects facemenu.  I am pretty sure that was my motive
for making the change.

However, if it also makes things a lot slower, that is not good.
Has some font lock expert verified that this is really happening?

If so, we should set up a way to turn off facemenu for faces while not
turning on the Font Lock mechanism unnecessarily.

One way is for Font Lock to notice the value (nil t)
specially and not turn on the mechanism.

Another way is to have another variable to disable the faces menu
with.  That way is very safe.

^ permalink raw reply	[flat|nested] 14+ messages in thread

[parent not found: <87vekaf780.fsf@stupidchicken.com>]

* Re: Font-lock in COMINT modes
       [not found]             ` <87vekaf780.fsf@stupidchicken.com>
@ 2006-12-18 16:00               ` Richard Stallman
  2006-12-18 16:36                 ` Chong Yidong
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Stallman @ 2006-12-18 16:00 UTC (permalink / raw)
  Cc: emacs-devel

I listed in FOR-RELEASE that this case is slow:

    You must have gotten that impression from Stefan's 12/08 message:

      if [font-lock-defaults ] is nil font-lock-mode-internal is not
      activated at all.  AFAIK nil and (nil t) are equivalent (i.e. don't
      highlight anything), except that (nil t) takes a lot more CPU to do
      nothing (it runs all the font-lock-foo-function hooks, enables
      jit-lock so as to do nothing just-in-time rather than eagerly,
      checks where nothing needs to be done, rounds up to a whole number
      of lines the region upon which inaction is requested, checks if
      there's a multiline entity and extends the region even more, so that
      nothing is done in a multiline way, ...).

    Even though it is true that font lock jumps through more hoops with
    (nil t), there is no evidence that this slowdown affects the user.


Could you check and see?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-18 16:00               ` Richard Stallman
@ 2006-12-18 16:36                 ` Chong Yidong
  2006-12-18 20:38                   ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: Chong Yidong @ 2006-12-18 16:36 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman <rms@gnu.org> writes:

> I listed in FOR-RELEASE that this case is slow:
>
>     You must have gotten that impression from Stefan's 12/08 message:
>
>       if [font-lock-defaults ] is nil font-lock-mode-internal is not
>       activated at all.  AFAIK nil and (nil t) are equivalent (i.e. don't
>       highlight anything), except that (nil t) takes a lot more CPU to do
>       nothing (it runs all the font-lock-foo-function hooks, enables
>       jit-lock so as to do nothing just-in-time rather than eagerly,
>       checks where nothing needs to be done, rounds up to a whole number
>       of lines the region upon which inaction is requested, checks if
>       there's a multiline entity and extends the region even more, so that
>       nothing is done in a multiline way, ...).
>
>     Even though it is true that font lock jumps through more hoops with
>     (nil t), there is no evidence that this slowdown affects the user.
>
>
> Could you check and see?

I haven't been able to observe any slowdown when font-lock-defaults is
(nil t).  Not surprising, since I don't notice any slowdown when
font-lock-defaults is (something t), i.e. normal font-lock situations!

Maybe someone running on a 486 can observe a difference, who knows.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-18 16:36                 ` Chong Yidong
@ 2006-12-18 20:38                   ` Stefan Monnier
  2006-12-20 13:00                     ` Richard Stallman
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2006-12-18 20:38 UTC (permalink / raw)
  Cc: rms, emacs-devel

>> I listed in FOR-RELEASE that this case is slow:
>> 
>> You must have gotten that impression from Stefan's 12/08 message:
>> 
>> if [font-lock-defaults ] is nil font-lock-mode-internal is not
>> activated at all.  AFAIK nil and (nil t) are equivalent (i.e. don't
>> highlight anything), except that (nil t) takes a lot more CPU to do
>> nothing (it runs all the font-lock-foo-function hooks, enables
>> jit-lock so as to do nothing just-in-time rather than eagerly,
>> checks where nothing needs to be done, rounds up to a whole number
>> of lines the region upon which inaction is requested, checks if
>> there's a multiline entity and extends the region even more, so that
>> nothing is done in a multiline way, ...).
>> 
>> Even though it is true that font lock jumps through more hoops with
>> (nil t), there is no evidence that this slowdown affects the user.
>> 
>> 
>> Could you check and see?

> I haven't been able to observe any slowdown when font-lock-defaults is
> (nil t).  Not surprising, since I don't notice any slowdown when
> font-lock-defaults is (something t), i.e. normal font-lock situations!

> Maybe someone running on a 486 can observe a difference, who knows.

Indeed, the "slowdown" should be completely and absolutely neligible, even
on a 16MHz 386sx.


        Stefan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-18 20:38                   ` Stefan Monnier
@ 2006-12-20 13:00                     ` Richard Stallman
  2006-12-20 22:06                       ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Stallman @ 2006-12-20 13:00 UTC (permalink / raw)
  Cc: cyd, emacs-devel

    Indeed, the "slowdown" should be completely and absolutely neligible, even
    on a 16MHz 386sx.

I believe you, but if it isn't noticeable, I wish you had not
presented it as a problem before.  I believed you then, too.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-20 13:00                     ` Richard Stallman
@ 2006-12-20 22:06                       ` Stefan Monnier
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2006-12-20 22:06 UTC (permalink / raw)
  Cc: cyd, emacs-devel

>     Indeed, the "slowdown" should be completely and absolutely neligible, even
>     on a 16MHz 386sx.

> I believe you, but if it isn't noticeable, I wish you had not
> presented it as a problem before.  I believed you then, too.

Sorry, I (obviously) didn't mean to present it as a problem. I was just in
a lighthearted mood when I wrote it,


        Stefan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Font-lock in COMINT modes
  2006-12-09  2:15     ` JD Smith
  2006-12-09  4:02       ` Stefan Monnier
@ 2006-12-09 18:25       ` Richard Stallman
  1 sibling, 0 replies; 14+ messages in thread
From: Richard Stallman @ 2006-12-09 18:25 UTC (permalink / raw)
  Cc: emacs-devel

    This is a telling comment from font-core.el:

      ;; Only do hard work if the mode has specified stuff in
      ;; `font-lock-defaults'.

That conditional must be the reason for this difference in behavior.

Can someone please document what it means for `font-lock-defaults'
to be nil?  Including the effect on facemenu?

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2006-12-20 22:06 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-07  0:57 Font-lock in COMINT modes JD Smith
2006-12-07 16:38 ` JD Smith
2006-12-07 18:00 ` JD Smith
2006-12-09  1:26   ` Richard Stallman
2006-12-09  2:15     ` JD Smith
2006-12-09  4:02       ` Stefan Monnier
2006-12-11 16:22         ` JD Smith
2006-12-12 14:29           ` Richard Stallman
     [not found]             ` <87vekaf780.fsf@stupidchicken.com>
2006-12-18 16:00               ` Richard Stallman
2006-12-18 16:36                 ` Chong Yidong
2006-12-18 20:38                   ` Stefan Monnier
2006-12-20 13:00                     ` Richard Stallman
2006-12-20 22:06                       ` Stefan Monnier
2006-12-09 18:25       ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).