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

[Alan Mackenzie]

Hello, Dmitry.

In article <mailman.12024.1414247237.1147.bug-gnu-emacs@gnu.org> you wrote:
> I think the following should be harmless. Why does it result in broken
> indentation?

Why do you think it should be harmless?

> 1. Open in c++-mode buffer with following contents:

> int main(int argc, char** argv) {
>  fgets(0, 1, 2);
> }

> 2. Add an empty line after the semicolon, move cursor there, and
> evaluate this:

> (with-syntax-table (make-char-table 'syntax-table nil)
>  (modify-syntax-entry ?\( "(")
>  (modify-syntax-entry ?\) ")")
>  (modify-syntax-entry ?< "(")
>  (modify-syntax-entry ?> ")")
>  (insert "fgets(0, 1, 2)"))

> 3. Press `;', see the indentation of the current line change, and
> include (erroneously) two extra spaces:

> int main(int argc, char** argv) {
>  fgets(0, 1, 2);
>    fgets(0, 1, 2);
> }

If you go to the semicolon at the end of line 2 and do C-u C-x = you'll
see that that character has these text-properties:
  c-in-sws             t
  c-is-sws             t
  fontified            t
.  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.

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?

> Originally: https://github.com/company-mode/company-mode/issues/212

> In GNU Emacs 24.3.94.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
> of 2014-10-06 on axl
> Repository revision: 117555 sdl.web@gmail.com-20141005005838-oyl694hqhu2d3632
> Windowing system distributor `The X.Org Foundation', version 11.0.11501000
> System Description:     Ubuntu 14.04.1 LTS

-- 
Alan Mackenzie (Nuremberg, Germany).