emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cc-mode fontification feels random


From: Stefan Monnier
Subject: Re: cc-mode fontification feels random
Date: Tue, 08 Jun 2021 11:16:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> > Unless `open-paren-in-column-0-is-defun-start' is non-nil.
>> We can use hacks like this one, indeed, but it's not in fashion
>> nowadays.
> Yes, we prefer waiting forever for Emacs to respond to a TAB or RET,

I'd be interested to hear about the cases where you think the time to
reply to RET or TAB would be sped up by
`open-paren-in-column-0-is-defun-start`.

The case I know of where it would make a significant difference in
practice are things like:
- open a large file in a mode that uses a heavy
  `syntax-propertize-function`, such as perl-mode, and jump to the end.
- turn off font-lock-mode, do the same as above (which should be
  quick this time around), and then hit TAB (at which point you should
  see the same delay as you saw above).

So, yes, there is a performance price to pay, but in return you get
simpler ELisp code (because you don't need to implement the hacks), and
a more reliable behavior.

> and are okay with "random" fontification which triggered this thread.
> The price of fashion, I guess.

I think you're confused:
- the "random" fontification in this thread is in CC-mode, which does
  not use the approach I described (and used in syntax-propertize).
  E.g. Alan mentioned that the problematic behavior of CC-mode's
  highlighting can depend on the order in which the chunks are
  fontified, and `syntax-propertize` specifically aims to avoid
  such order-dependency [ And please don't get me wrong:
  an approach like that of `syntax-propertize` wouldn't solve the
  problematic fontification, but it would (mis)fonftify the same way
  every time.  ]
- it's with `open-paren-in-column-0-is-defun-start` that we had
  occasional/random misfontification, and it's indeed to get rid of
  those that we finally changed its default value.

The performance cost is real, but AFAIK this cost gives *less random*
behavior contrary to what you state.  The whole point of the design of
`syntax-propertize` is to try and make it eas(y|ier) to get
correct&reliable behavior (at the cost of sometimes sub-optimal
performance).

AFAIK one of the reasons why Alan doesn't want to use an approach like
that of syntax-propertize in CC-mode is because his guts tell him that
it would be too inefficient for C++.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]