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

[Alan Mackenzie]

Hello, Dmitry.

In article <mailman.12048.1414277182.1147.bug-gnu-emacs@gnu.org> you wrote:
> On 10/26/2014 02:34 AM, Alan Mackenzie wrote:

>> Why do you think it should be harmless?

> Because the syntax table change is temporary and its effect should be 
> limited to my code?

It's no so limited.  The before-change-functions and after-change-functions
hooks will be run with that syntax table active.  This is not good.

>> .  The c-in-sws and c-is-sws indicate that the semicolon has been
>> recognised and marked as syntactic whitespace.  The second line thus gets
>> parsed as "statement-cont", i.e. a continued statement, so it gets
>> indented an extra level.

> Yes, I see that. But how does this happen?

Somewhere in a before- or after-change-functions, c-backward-sws is being
called, to go backward over syntactic whitespace.  Somehow it gets
horribly confused, because the syntax table isn't correct.  I don't think
the exact details matter too much here.

>> If you cripple C++ Mode by substituting a wrong syntax table, you
>> shouldn't be too surprised when things go "wrong".  This seems like one of
>> these "well, don't do that, then" bugs.

>> Question: why do you want to play around with the syntax table in this
>> manner?  What are you trying to achieve?

> I'm using a different syntax table for sexp movement, where it's 
> necessary for both parens and angle brackets to have paren syntax class. 
> In the actual code I modify the text after it's inserted, and 
> `backward-sexp' is used two times to find necessary search bounds.

OK.  Can I suggest an alternative?  In C++ (and Java) Modes, the template
(generic) delimiters are marked with syntax-table text properties.
Unfortunately, at the moment this is done as part of font-locking, so
isn't done until you display.  However, if you put "(sit-for 0)" into
your code after inserting "< ... >", this will cause a redisplay,
allowing subsequent code to use the text properties, and a backward-sexp
will then work.

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.

> https://github.com/company-mode/company-mode/blob/42012730da15ffaef7c61722475040babed15332/company-template.el#L155-L173

-- Alan Mackenzie (Nuremberg, Germany).