bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#18826: 24.3.94; c++-mode bad indentation after programmatic insert w


From: Alan Mackenzie
Subject: bug#18826: 24.3.94; c++-mode bad indentation after programmatic insert with locally changed syntax table
Date: Mon, 27 Oct 2014 08:53:28 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hello, Dmitry.

On Mon, Oct 27, 2014 at 08:06:46AM +0700, Dmitry Gutov wrote:
> On 10/27/2014 12:38 AM, Alan Mackenzie wrote:

> > They're not syntax-table text properties, so the setting of them doesn't
> > belong in syntax-propertize.

> Well, they are used to set syntax information, so syntax-propertize is a 
> much better place for them, conceptually, than font-lock.

They (that is, the c-is-sws and c-in-sws properties) mark syntactic
whitespace.  They're set during calls to c-forward-syntactic-ws and
c-backward-syntactic-ws, which are used all over the place, just as much
in the indentation engine, and the commands, as in font lock.  They're
intended to mark CPP structures and, especially, massive comments, such
as are frequently found at the beginning of source files.  They're
intended to speed up the skipping of WS.

> > Maybe it will, maybe it won't.  `syntax-propertize' has the disadvantage
> > of inefficiency; at any buffer change, all syntax-table text properties
> > after the position of the change are effectively wiped out, even where
> > (as is usual) this isn't necessary.

> If it's a actually a problem, maybe you need to be able to use a custom 
> invalidation strategy. Aside from the strategy itself, this shouldn't be 
> too hard to implement.

It's already implemented and running.  :-)  The syntax-table properties
in the vicinity of a buffer change are removed and re-applied with tender
loving care.

[ ... ]

> >> Hmm. My current workaround is to use a temporary syntax table that
> >> inherits from c++-mode-syntax-table (but has angle brackets in the
> >> 'paren' class). Sounds like it might also create a conflict, if maybe a
> >> more subtle one.

> > Any reason you don't use the current syntax table as the base to add the
> > descriptors for < and > to rather than creating a new, blank one?  You
> > could use `copy-syntax-table'.

> Is that much different from what I described above? I do

>    (with-syntax-table (make-syntax-table (syntax-table)
>      ...)

No it's not.  Apologies.  I hadn't read your email properly.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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