unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: New optimisations for long raw strings in C++ Mode.
Date: Wed, 10 Aug 2022 17:32:46 +0000	[thread overview]
Message-ID: <YvPrvna9FdJoCt10@ACM> (raw)
In-Reply-To: <83a68cqbm0.fsf@gnu.org>

Hello, Eli.

On Wed, Aug 10, 2022 at 19:58:31 +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 Aug 2022 16:50:43 +0000
> > Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > On Wed, Aug 10, 2022 at 19:35:58 +0300, Eli Zaretskii wrote:
> > > > Date: Wed, 10 Aug 2022 16:23:27 +0000
> > > > Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org
> > > > From: Alan Mackenzie <acm@muc.de>

> > > > CC Mode has not been doing anything wrong in accessing the buffers it
> > > > controls.  The idea that one should access only the characters in the
> > > > (BEG END) supplied by fontification_functions (and jit-lock) is false.
> > > > It has no basis in rationality.  And in fact, standard font-locking
> > > > itself accesses (via syntax-ppss) all character positions from BOB to
> > > > BEG.

> > > You seem to disagree with a major idea of the design of the Emacs
> > > display engine.

> > I don't think I do.  I think you mean the idea of lazy fontification,
> > though you haven't been specific.

> No, I mean the idea that redisplay processes only a small amount of
> buffer text around the window.

I don't think such an idea is coherent, due to the lack of precision of
the word "processes".  I understand that redisplay _fontifies_ only a
small amount of buffer text.  However, it can get better results if it is
free to _look_ at text anywhere in the buffer.

You seem to be conflating "fontifying" with "looking at".  I don't think
that's helpful.

> > This fontification is all about fontifying restricted areas of the
> > buffer.  There is no principle that one shouldn't look at distant
> > portions of the buffer as need be, to facilitate the fontification of
> > the restricted area.

> You are contradicting yourself.

I can't see any contradiction in what I wrote there.

> > This is absolutely necessary correctly to fontify (long) strings and
> > comments, for example.

> Only if you assume the most simplistic processing.

If you open a file in its middle (e.g., by desktop), and there's an open
block comment there, you've got to look arbitrarily far back to detect
that state.  In practice parse-partial-sexp from point-min will be used,
likely with cacheing of whatever sort.

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2022-08-10 17:32 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-06 21:29 New optimisations for long raw strings in C++ Mode Alan Mackenzie
2022-08-07 12:49 ` Lars Ingebrigtsen
2022-08-07 13:25   ` Alan Mackenzie
2022-08-07 13:34     ` Lars Ingebrigtsen
2022-08-07 14:40       ` Alan Mackenzie
2022-08-07 14:41         ` Lars Ingebrigtsen
2022-08-07 14:54         ` Lars Ingebrigtsen
2022-08-07 16:13           ` Alan Mackenzie
2022-08-07 16:17             ` Eli Zaretskii
2022-08-09 11:00               ` Alan Mackenzie
2022-08-09 15:35                 ` Lars Ingebrigtsen
2022-08-09 15:38                   ` Lars Ingebrigtsen
2022-08-09 16:05                     ` Alan Mackenzie
2022-08-09 16:34                       ` Eli Zaretskii
2022-08-09 20:39                         ` Gregory Heytings
2022-08-09 21:43                           ` Alan Mackenzie
2022-08-09 23:05                             ` Stefan Monnier
2022-08-10  2:43                               ` Eli Zaretskii
2022-08-10  7:42                             ` Gregory Heytings
2022-08-10 13:28                             ` Eli Zaretskii
2022-08-10 16:23                               ` Alan Mackenzie
2022-08-10 16:35                                 ` Eli Zaretskii
2022-08-10 16:50                                   ` Alan Mackenzie
2022-08-10 16:58                                     ` Eli Zaretskii
2022-08-10 17:32                                       ` Alan Mackenzie [this message]
2022-08-10 17:41                                         ` Eli Zaretskii
2022-08-10 22:31                                           ` Stefan Monnier
2022-08-11  6:21                                             ` Eli Zaretskii
2022-08-11  7:37                                               ` Stefan Monnier
2022-08-11  6:27                                             ` Immanuel Litzroth
2022-08-11 16:54                                           ` Alan Mackenzie
2022-08-11 17:15                                             ` Eli Zaretskii
2022-08-12 13:05                                           ` Lynn Winebarger
2022-08-12 13:18                                             ` Eli Zaretskii
2022-08-11 15:47                                         ` Yuri Khan
2022-08-11 16:04                                           ` Eli Zaretskii
2022-08-10 17:19                                 ` Gregory Heytings
2022-08-10 17:21                                   ` Eli Zaretskii
2022-08-10 19:45                                   ` Alan Mackenzie
2022-08-14 20:15                                     ` Alan Mackenzie
2022-08-15  8:00                                       ` Gregory Heytings
2022-08-10 13:25                     ` Eli Zaretskii
2022-08-12 12:44                       ` Lars Ingebrigtsen
2022-08-12 12:52                         ` Eli Zaretskii
2022-08-07 15:00         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YvPrvna9FdJoCt10@ACM \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=gregory@heytings.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).