GNU bug report logs - #18826
24.3.94; c++-mode bad indentation after programmatic insert with locally changed syntax table

Previous Next

Packages: emacs, cc-mode;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Sat, 25 Oct 2014 14:27:02 UTC

Severity: normal

Found in version 24.3.94

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


Message #40 received at 18826 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 18826 <at> debbugs.gnu.org
Subject: Re: bug#18826: 24.3.94; c++-mode bad indentation after programmatic
 insert	with	locally	changed syntax table
Date: Mon, 27 Oct 2014 08:06:46 +0700
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.

> 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.

>> In that sense, the `sit-for' suggestion is not future-proof. So I'll try
>> only changing the syntax table around specific functions that don't
>> modify the buffer text, but just move point, since that was the actual goal.
>
> Might it be possible that you could get mixed up with less-than and
> greater-than (or even shift-right) operators?  If so, be careful!

Thanks, but there are no "less-than" in a function signature.

>>> In the medium future (several weeks away), I'm hoping to fix CC Mode so
>>> that the text properties are applied to < ... > on an after-change
>>> function rather than at redisplay.
>
> ...., a change to use syntax-propertize needs the above change to happen
> first.

Not sure why, but ok.

>> 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)
    ...)




This bug report was last modified 10 years and 289 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.