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: emacs-devel@gnu.org
Subject: Re: New hook before-region-change-functions wanted
Date: Sun, 10 Sep 2017 18:53:53 +0000	[thread overview]
Message-ID: <20170910185353.GE3588@ACM> (raw)
In-Reply-To: <jwvwp58f13p.fsf-monnier+gmane.emacs.devel@gnu.org>

Hello, Stefan.

On Sat, Sep 09, 2017 at 09:44:20 -0400, Stefan Monnier wrote:
> > The reason I want it is as part of the solution to bug #22983
> > (syntax-ppss returns wrong result).  I envisage two (or possibly more)
> > mutually independent caches, and a switch being made to the appropriate
> > cache when the region is changed.  This switch would be made inside a
> > function on before-change-region-functions.

> Regarding a hook placed on narrow-to-region (from where I stand, `widen`
> is just a special call to narrow-to-region):
> - As discussed in the past, narrow-to-region needs to be
>   extended/adjusted/complemented with some way to distinguish "hard
>   narrowing" (as is used in Info-mode, and might be used in cases of
>   multiple-major-modes) from "soft narrowing", so there's a risk such
>   changes would impact the desired behavior of this hook.
> - syntax-ppss doesn't need this hook, and even if it were added it
>   probably wouldn't benefit from it: you can just as easily change
>   syntax-ppss to compare (point-min) with its last value in order to
>   detect calls to narrow-to-region.  There are minor advantages to using
>   your hooks, but there are also similarly minor advantages to
>   performing the detection dynamically in syntax-ppss, and I think
>   overall neither approach would be noticeably better than the other.

OK, first of all, I've given up the hook proposal after strong
objections from Richard.

`widen' is physically a separate function from `narrow-to-region'.

As I see it, there is no such thing as "hard" or "soft" narrowing.
There's just narrowing which is completely defined as it always has
been.  I'm in favour of it staying that way, having proposed alternative
measures for multiple major modes.

> > While it is true that this hook is not absolutely necessary, in that the
> > cache switch could be made by the first call to syntax-ppss after the
> > region change, it makes the cache switch clean.  In particular, the
> > cache will always be in synch with the region, and any functions which
> > examine the cache at an arbitrary time (for example, jit-lock
> > functions), will get the right cache.

> AFAIK noone ever looks at syntax-ppss's cache except for syntax-ppss.
> jit-lock definitely doesn't.

Sorry, yes, I got a little confused.  font-lock.el calls syntax-ppss,
and I think I was worried that it might do so between a change in
restriction and the syntax-ppss cache's getting changed.  Or something
like that.  Nothing to worry about.

Incidentally, I've now posted a patch for bug #22983.  I'm interested in
what you think of it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2017-09-10 18:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-08 14:46 New hook before-region-change-functions wanted Alan Mackenzie
2017-09-08 15:07 ` John Wiegley
2017-09-08 15:10 ` Eli Zaretskii
2017-09-08 15:12   ` Alan Mackenzie
2017-09-08 20:47 ` Dmitry Gutov
2017-09-09 13:46   ` Stefan Monnier
2017-09-08 22:22 ` Richard Stallman
2017-09-09  8:33   ` Alan Mackenzie
2017-09-10  2:44     ` Richard Stallman
2017-09-10  7:37       ` Alan Mackenzie
2017-09-11  1:17         ` Richard Stallman
2017-09-11 16:45           ` Alan Mackenzie
2017-09-12 15:46       ` Andreas Röhler
2017-09-09 13:44 ` Stefan Monnier
2017-09-10 18:53   ` Alan Mackenzie [this message]
2017-09-10 22:21     ` Stefan Monnier
2017-09-10 23:02       ` Drew Adams

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=20170910185353.GE3588@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@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.