emacs-devel
[Top][All Lists]
Advanced

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

Re: forward-comment and syntax-ppss


From: Alan Mackenzie
Subject: Re: forward-comment and syntax-ppss
Date: Fri, 9 Dec 2016 23:09:05 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Clément.

On Fri, Dec 09, 2016 at 05:33:09PM -0500, Clément Pit--Claudel wrote:
> On 2016-12-09 13:47, Stefan Monnier wrote:
> >> There is nothing in the notion of narrowing which suggests that it
> >> should change the syntactic context of any text - if a certain
> >> buffer position is inside a string, it is inside the string; it
> >> doesn't suddenly become outside the string by virtue of where the
> >> buffer is narrowed.  Were that not the case, the notion "inside a
> >> string" would become meaningless.

> > Let's take sm-c-mode as an example: it marks CPP preprocessor
> > elements as being comments.  Yet, it also wants to know if there are
> > strings inside that "comment", so it narrows to the "comment" and
> > then parses the result as a chunk of C code.

> > Other examples come from the context of
> > multiple-major-modes-in-a-buffer.

> I'm not directly involved in this discussion, but thanks to both of you
> for these explanations.  I didn't clearly understand the distinction at
> hand up to this point.

> Alan, is it valid to say that you view narrowing as a convenient
> editing feature that lets you restrict operations to a subsection of
> the buffer?  Something like a "window" over the buffer (or maybe
> "stencil" would be a better term?), which doesn't change any of
> semantic meaning, but just conveniently restricts motion?  In that
> sense, your vision of narrowing is similar to my applying two overlays
> to make the beginning of the buffer invisible up to a point, and the
> end of the buffer invisible starting from a point, right?

Yes, I think that's a very good summary.

> Stefan, am I correct in thinking that the narrowing that you mention
> above is of a different nature, in the sense that if I narrow a buffer
> to the range a…b it's just as if I had copied that portion of the
> buffer to a totally separate, disconnected buffer (possibly running a
> different mode), and the text would get copied back into the original
> buffer when I widen?

I'm not Stefan, but that's pretty much my understanding of his
understanding.

> Maybe the solution is to just give these two things a different name?
> It seems that in the first case we're narrowing to a region without
> forgetting about the context — let's call this "context-aware
> narrowing", or "focusing".  In the second case we're narrowing to a
> region and forgetting about the context entirely — let's call this
> "context-oblivious narrowing", or "sub-buffer editing".

No, I don't think this is right.  The narrowing itself is simply
narrowing.  It's what you do on the narrowed buffer that makes the
difference.  In @dfn{ACM-narrowed-processing), the parse state of a
position would be determined by (parse-partial-sexp 1 POS).  In
@dfn{SM-narrowed-processing} it would be determined by
(parse-partial-sexp (point-min) POS).

I think the main conceptual mistake people are making at the moment is
attributing to the act of narrowing, differences in attitude to the
processing done on narrowed buffers.

> Context-aware narrowing allows one to work on just one function easily;
> Context-oblivious narrowing makes things like
> http://demonastery.org/2013/04/emacs-narrow-to-region-indirect/
> possible.

> Cheers,
> Clément.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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