[Top][All Lists]

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

Re: CC Mode and electric-pair "problem".

From: João Távora
Subject: Re: CC Mode and electric-pair "problem".
Date: Sun, 01 Jul 2018 12:22:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Alan Mackenzie <address@hidden> writes:

>> Could you please recap what problem(s) you are trying to fix with
> Sorry.  That's just the way things go, sometimes.

I'm not sure how far into "final allegations" we are, but below is my

> electric-pair-mode from functioning correctly.  João and I have discussed
> at length ways of fixing this.

... in particular, a few weeks ago I provided, in electric-pair-mode,
means for CC mode to declare that it has this particular behaviour.

Though I'm still waiting for Alan's comments on this, I'd say the
electric-pair-mode test failure is effectively fixed if Alan aggrees to
use that customization point.

But, in my view, electric-pair-mode was just the canary in the mine:
after Alan's changes much more basic things such as C-M-* sexp
navigation stop working like they did.  I am actually more worried about

To recap, I like that Alan's change in syntactically incorrect code is
better "50% of the time":

   char *c="an incomplete string
   int a = 0;

by not fontifying "int a" as a string, does indeed exhibit some
intelligence.  But this doesn't (where it previously did):

  int main () {
    int a = 0;
    char *c = "here's me editing a
    return 0;

If this switch was all, I wouldn't mind at all.  Unfortunately it comes
with a very big trade-off: the underlying syntactic changes break
e.g. C-M-u C-M-SPC inside the multi-line string being edited (which is
precisely something I could use to fix the string).

I just noticed that in 26.1 indentation of the "puts(c)" wasn't affected
by the temporary editing of the string.  Now it is, so another downside,


reply via email to

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