all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 36136@debbugs.gnu.org
Subject: bug#36136: [PATCH]: Re: bug#36136: syntax-ppss fails to invalidate its cache on changes to syntax-table text properties
Date: Wed, 12 Jun 2019 10:15:03 +0000	[thread overview]
Message-ID: <20190612101503.GA4587@ACM> (raw)
In-Reply-To: <jwvblz3us6n.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Wed, Jun 12, 2019 at 04:37:25 -0400, Stefan Monnier wrote:
> > The following patch is simpler than my first proposal, following
> > feedback from Eli.  It works for me.

> > Stefan, could you look at this, please?

> Here I am.

Hello!

> > * src/textprop.c (syntax-propertize--done): New buffer local variable.
> > (set_properties, add_properties, remove_properties): when a syntax-table text
> > property is being changed, reduce syntax-propertize--done to the buffer
> > position.

> Hmm... I'm not too fond of adding ad-hoc support for specific
> text-properties in (set_properties, add_properties, remove_properties).

Neither am I, particularly.  But the whole point of syntax-ppss, surely,
is that it should work automatically, without users having to call
syntax-ppss-flush-cache all the time.

The root of the problem is that inhibit-modification-hooks is too blunt
a tool.  Setting it prevents running functions we want to run, just as
much as ones we don't.

I've just had another idea: we introduce a new property called something
like dont-inhibit.   When a function in before/after-change-functions
has this property, it would run, regardless of
inhibit-modification-hooks.  Or possibly, we could introduce new hooks
no-inhibit-before/after-change-functions.

What do you think?

> > * lisp/emacs-lisp/syntax.el (syntax-ppss--trim-cache): New function extracted
> > from syntax-ppss-flush-cache.
> > (syntax-ppss-flush-cache): Now only modifies syntax-propertize--done and
> > syntax-ppss--done.
> > (syntax-ppss): Calls syntax-ppss--trim-cache and sets syntax-propertize--done.

> This part looks OK.

> I'm not sure if making the cache-flushing more lazy will be a win
> overall: it speeds up buffer modifications at the cost of slowing down
> syntax-ppss.

It will probably not make a great deal of difference either way.  Buffer
changes are frequent in Emacs, and so are calls to syntax-ppss in many
major modes.

> To get back to the original problem:

> > This is because the invalidation function, syntax-ppss-flush-cache is
> > invoked only as a before-change function, but typical (?all)
> > syntax-table property changes happen when before-change-functions
> > is inactive.

> That's why it doesn't have "--" in its name: if you don't want to use
> syntax-propertize then you'll probably have to call that function
> by hand.  I consider it as perfectly acceptable.

Well, for CC Mode I'm going to have to do that anyway, since Emacs-26.x
and earlier are already out there and aren't going to change.  This is
going to be tedious and error prone.

But for the future, it would be nice if syntax-ppss could take note of
all buffer changes, rather than just some of them.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2019-06-12 10:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-08 13:17 bug#36136: syntax-ppss fails to invalidate its cache on changes to syntax-table text properties Alan Mackenzie
2019-06-08 20:36 ` bug#36136: [PATCH]: " Alan Mackenzie
2019-06-09  5:56   ` Eli Zaretskii
2019-06-09 14:52     ` Alan Mackenzie
2019-06-09 18:39 ` Alan Mackenzie
2019-06-12  8:37   ` Stefan Monnier
2019-06-12 10:15     ` Alan Mackenzie [this message]
2019-06-12 10:54       ` Stefan Monnier
2019-06-13 12:21         ` Alan Mackenzie
2019-06-13 21:31           ` Stefan Monnier
     [not found] ` <handler.36136.B.155999987226722.ack@debbugs.gnu.org>
2019-08-24 19:35   ` bug#36136: Acknowledgement (syntax-ppss fails to invalidate its cache on changes to syntax-table text properties) Alan Mackenzie

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

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

  git send-email \
    --in-reply-to=20190612101503.GA4587@ACM \
    --to=acm@muc.de \
    --cc=36136@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.