Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

classic Classic list List threaded Threaded
81 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

João Távora

On Tue, Jul 2, 2019 at 5:04 PM Alan Mackenzie <[hidden email]> wrote:

> > [did you mean to copy [hidden email], or [hidden email]?
> > I'm assuming the latter and correcting]
> No, it's a bug, therefore I submitted a bug report.

You should use the X-Debbugs-CC feature then (and why not continue
in the existing bug 36423?)

Anyway, I insist this matter be brought to emacs-devel because it's a
followup to a discussion that started there but never reached a
suitable conclusion. For that reason, and because I provide a 
workaround for the bug  at the end of  this message, I'm cross-posting
this one mail to both the bug list and emacs-devel.

> > The arguments _against_ NL-terminated strings is that they (1) break
> > longstanding features such as sexp-based navigation (e.g. `up-list`
> > and friends) for modes such say, `js-mode` and (2) break features
> > that expect this to work, most notably electric-pair-mode.
>
> This isn't true. 

What "isn't true"? Have those features broken or not? They worked
before the fe06f643b commit and don't work after the commit. It
sounds quite unrefutable to me.

> If those other feature no longer work with an up to
> date Emacs, they should be fixed.

I've stated this repeatedly in the life of this discussion: it's not just about
electric-pair-mode. If you try to M-x up-list from a multi-line string in
emacs 26.1 it works just as well in js-mode and c++-mode.  In emacs
master it does not in c++-mode. Same with forward-sexp on the starting
delimiter, etc.

> The fontification that CC Mode does is natural and helpful, and users
> haven't complained about it (except when there've been bugs). 

Yes, users haven't complained except when users have complained.

> There have
> certainly been no complaints about using font-lock-warning-face for the
> invalid string delimiters, and font-lock-string-face for valid ones.

That's because providing this annotation is perfectly fine.  The problem
is providing it _at the expense of other features_. And _that's_ what
they've complained about: an average user has no obvious way of
telling that the particular implementation of the red annotation thingy
is guilty of breaking his C-M-u or his electric-pair-mode.

He/she might even judge the latter more vital than said red thingy
, an annotation which he/she will get by other means if using
very popular packages such as flycheck, or flymake, or eglot, or
lsp-mode, etc. These normally call the compiler directly on the
source code and highlight those and many other errors.

On the other hand, if what you want is the red annotation, are you
absolutely sure there isn't a better way to get it? And if you are,
are you also absolutely sure you need to put it in the code and
and not provide an easy way to turn it off?

> For this, I think we would both rather that you amend elec-pair.el rather
> than me.

I'll be "mulling this over". There are potentially many other points of
breakage that would need such an indirection, and doing that to serve
just a particular cc-mode quirk doesn't sound priority to me.

In the meantime, let others chime in.

Also, in the meantime, for a user that is bothered by this bug,
I'd recomend to put something like this in his/her .emacs file:

  (defun c-unescaped-nls-in-string-p (&optional quote-pos) t)

I had something more elaborate in my setup but just this
seems to fix it in my testing.

There is a also a very promising variable, c-multiline-string-start-char,
that I think would be a good candidate for customizing this, but I
haven't messed with it enough. Just setting it from .emacs doesn't
do the trick. Perhaps in a mode hook?

--
João Távora
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Alan Mackenzie
Hello, João.

On Tue, Jul 02, 2019 at 18:22:34 +0100, João Távora wrote:
> On Tue, Jul 2, 2019 at 5:04 PM Alan Mackenzie <[hidden email]> wrote:

> > > [did you mean to copy [hidden email], or [hidden email]?
> > > I'm assuming the latter and correcting]
> > No, it's a bug, therefore I submitted a bug report.

> You should use the X-Debbugs-CC feature then (and why not continue
> in the existing bug 36423?)

I didn't know about the former, and as for the bug, it is a different
bug with differenct causes from #36423.

> Anyway, I insist this matter be brought to emacs-devel because it's a
> followup to a discussion that started there but never reached a
> suitable conclusion. For that reason, and because I provide a
> workaround for the bug  at the end of  this message, I'm cross-posting
> this one mail to both the bug list and emacs-devel.

> > > The arguments _against_ NL-terminated strings is that they (1) break
> > > longstanding features such as sexp-based navigation (e.g. `up-list`
> > > and friends) for modes such say, `js-mode` and (2) break features
> > > that expect this to work, most notably electric-pair-mode.

> > This isn't true.

> What "isn't true"? Have those features broken or not?

They may well be broken.  CC Mode hasn't broken them.  They made invalid
assumptions, which turned out to be unjustified.

> They worked before the fe06f643b commit and don't work after the
> commit. It sounds quite unrefutable to me.

I don't know what you're talking about.

> > If those other feature no longer work with an up to date Emacs, they
> > should be fixed.

> I've stated this repeatedly in the life of this discussion: it's not
> just about electric-pair-mode. If you try to M-x up-list from a
> multi-line string in emacs 26.1 it works just as well in js-mode and
> c++-mode.  In emacs master it does not in c++-mode. Same with
> forward-sexp on the starting delimiter, etc.

I've just tried these in a multiline string in C++ Mode.  Both up-list
and forward-sexp work just fine.  I don't know what you're doing.

> > The fontification that CC Mode does is natural and helpful, and users
> > haven't complained about it (except when there've been bugs).

> Yes, users haven't complained except when users have complained.

> > There have certainly been no complaints about using
> > font-lock-warning-face for the invalid string delimiters, and
> > font-lock-string-face for valid ones.

> That's because providing this annotation is perfectly fine.  The problem
> is providing it _at the expense of other features_.

If other features are broken (and your list of other broken features, so
far, is empty), they should be fixed.

> And _that's_ what they've complained about: an average user has no
> obvious way of telling that the particular implementation of the red
> annotation thingy is guilty of breaking his C-M-u or his
> electric-pair-mode.

That's groundless disparagement.  C-M-u works, and electric-pair-mode is
broken because it's broken.  In one place it's using scan-sexps to move
forward over whitespace, totally oblivious to the possibility of
syntax-table text properties (which have been in use since Emacs-21).
That's broken code.

> He/she might even judge the latter more vital than said red thingy
> , an annotation which he/she will get by other means if using
> very popular packages such as flycheck, or flymake, or eglot, or
> lsp-mode, etc. These normally call the compiler directly on the
> source code and highlight those and many other errors.

Irrelevant.

> On the other hand, if what you want is the red annotation, are you
> absolutely sure there isn't a better way to get it?

No, I'm not.  That's why I invited you to come up with a better way, if
you can.

> And if you are, are you also absolutely sure you need to put it in the
> code and and not provide an easy way to turn it off?

It's a core feature of the mode, not an option.

> > For this, I think we would both rather that you amend elec-pair.el rather
> > than me.

> I'll be "mulling this over". There are potentially many other points
> of breakage

"Potentially" many?  So far, there is precisely one, in
electric-pair--unbalanced-strings-p.  I thought I was doing you a favour
by diagnosing the trouble.  If I'd known I'd get the reaction from you
I've just got, I wouldn't have bothered.

> that would need such an indirection, and doing that to serve just a
> particular cc-mode quirk doesn't sound priority to me.

No, you'd be cleaning up your code, to conform with the reality that in
2019 major modes use syntax-table text properties.  Features from CC
Mode have a habit of migrating to the Emacs core.

> In the meantime, let others chime in.

> Also, in the meantime, for a user that is bothered by this bug,
> I'd recomend to put something like this in his/her .emacs file:

>   (defun c-unescaped-nls-in-string-p (&optional quote-pos) t)

It's free software, but that's a stupid thing to do.

> I had something more elaborate in my setup but just this
> seems to fix it in my testing.

> There is a also a very promising variable, c-multiline-string-start-char,
> that I think would be a good candidate for customizing this, ....

It is not a customisation variable.  It is a language definition
variable.

> .... but I haven't messed with it enough. Just setting it from .emacs
> doesn't do the trick. Perhaps in a mode hook?

Or, alternatively, actually fix the problems which have been festering
for years or decades, and are just now revealing themselves.  Thus far,
there's exactly one such problem in electric-pair--unbalanced-strings-p.

> --
> João Távora

--
Alan Mackenzie (Nuremberg, Germany).

Reply | Threaded
Open this post in threaded view
|

Re: bug#36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Stefan Monnier
>> And if you are, are you also absolutely sure you need to put it in the
>> code and and not provide an easy way to turn it off?
> It's a core feature of the mode, not an option.

I don't understand this statement.
How could handling of incorrect code be part of "the core feature" of
the mode?  I understand you consider this to be a useful feature, and
even though I don't find it of value I'm sure some other users may like
it, but .... "core feature"?


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

João Távora
In reply to this post by Alan Mackenzie
On Tue, Jul 2, 2019 at 7:28 PM Alan Mackenzie <[hidden email]> wrote:
> Hello, João.

> I didn't know about the former, and as for the bug, it is a different
> bug with differenct causes from #36423.

If you say so... I stopped cross-posting, you probably should, too.

> > > This isn't true.
>
> > What "isn't true"? Have those features broken or not?
>
> They may well be broken.  CC Mode hasn't broken them.  They made invalid
> assumptions, which turned out to be unjustified.

C-M-u (up-list) made an invalid assumption?

> > They worked before the fe06f643b commit and don't work after the
> > commit. It sounds quite unrefutable to me.
>
> I don't know what you're talking about.
> I've just tried these in a multiline string in C++ Mode.  Both up-list
> and forward-sexp work just fine.  I don't know what you're doing.

Start emacs -Q, open a buffer with a double quote followed by some
newlines and then another another double quote.  Now put the buffer in
C++ mode and type C-M-u from between the quotes.  Instead of up-listing
to the first quote, you get an error.  Now but point on the starting
quote and try C-M-f.  Again, error. But only in Emacs 27/cc-mode,
probably starting from fe06f64b (that's a git commit hash).

Now repeat this experiment. Let me make a little ASCII table:

                     WORKS    DOESN'T

emacs 27/c++mode                X
emacs 26.1/c++-mode   X
emacs 27/js-mode      X
emacs 27/ruby-mode    X
emacs 27/(many)       X

Do you know what I'm talking about now?

Now, you might not care for this consistency, but I personally did.

I've always had my methods of navigating code with unterminated strings,
with _or without_ electric-pair mode and your cc-mode changes broke
this workflow.

> > lsp-mode, etc. These normally call the compiler directly on the
> > source code and highlight those and many other errors.
>
> Irrelevant.
>
> > On the other hand, if what you want is the red annotation, are you
> > absolutely sure there isn't a better way to get it?
>
> No, I'm not.  That's why I invited you to come up with a better way, if
> you can.

I gave your one exactly one paragraph ago, which you called dismissed as
"irrelevant". *shrug*.

> > I'll be "mulling this over". There are potentially many other points
> > of breakage
> "Potentially" many?  So far, there is precisely one, in
> electric-pair--unbalanced-strings-p.

What about d37d30cef5bbbdf8d17315835126d76d4681b22a? Is that the same
problem?  Maybe, I don't know.  Certainly the broken C-M-u and C-M-f,
aren't the same problem.

> No, you'd be cleaning up your code, to conform with the reality that in
> 2019 major modes use syntax-table text properties.  Features from CC
> Mode have a habit of migrating to the Emacs core.

It's not "my" code and I won't be bullied into making changes I don't
agree with.  Things worked fine until you added a feature in June 2018
that broke them.  You refuse to even let the user disable that feature
or consider alternatives.  That's simply not reasonable to me.

> > Also, in the meantime, for a user that is bothered by this bug,
> > I'd recomend to put something like this in his/her .emacs file:
>
> >   (defun c-unescaped-nls-in-string-p (&optional quote-pos) t)
>
> It's free software, but that's a stupid thing to do.

I'd ask you to actually give an argument instead of an insult, but I've
been on this hamster wheel before, so never mind.  It works quite well.

--
João Távora
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Alan Mackenzie
Hello, João.

On Wed, Jul 03, 2019 at 10:28:11 +0100, João Távora wrote:
> On Tue, Jul 2, 2019 at 7:28 PM Alan Mackenzie <[hidden email]> wrote:

> > I didn't know about the former, and as for the bug, it is a different
> > bug with differenct causes from #36423.

> If you say so... I stopped cross-posting, you probably should, too.

You've hijacked this bug report for your own purposes.  That is not a
gentlemanly thing to do.  Why could you not have started your own
thread?

Are you going to attend to bug #36474, which was the proper topic of
this thread?  Or would you like me to?

> > > > This isn't true.

> > > What "isn't true"? Have those features broken or not?

> > They may well be broken.  CC Mode hasn't broken them.  They made
> > invalid assumptions, which turned out to be unjustified.

> C-M-u (up-list) made an invalid assumption?

No.  You made an invalid assumption in trying to use it.

> > > They worked before the fe06f643b commit and don't work after the
> > > commit. It sounds quite unrefutable to me.

> > I don't know what you're talking about.
> > I've just tried these in a multiline string in C++ Mode.  Both up-list
> > and forward-sexp work just fine.  I don't know what you're doing.

> Start emacs -Q, open a buffer with a double quote followed by some
> newlines and then another another double quote.  Now put the buffer in
> C++ mode and type C-M-u from between the quotes.

Ah, I see.  You said you'd done this from a multiline string.  What you
have constructed is not a multiline string, it is two invalid string
delimiters unconnected with eachother with extraneous matter between
them.

> Instead of up-listing to the first quote, you get an error.  Now put
> point on the starting quote and try C-M-f.  Again, error.

It works for me.  It moves to the end of the initial invalid string.

> But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's
> a git commit hash).

I'm fully aware it's a git commit hash.  Funnily enough, I don't
memorise such hashes, so if you wish to draw my attention to some
commit, please have the decency to give me its date, and the summary
line of its commit message, instead of expecting me to do your work to
make your point.

> Now repeat this experiment. Let me make a little ASCII table:

>                      WORKS    DOESN'T

> emacs 27/c++mode                X
> emacs 26.1/c++-mode   X
> emacs 27/js-mode      X
> emacs 27/ruby-mode    X
> emacs 27/(many)       X

> Do you know what I'm talking about now?

Yes, I do.  Now try the following.  In your C++ buffer, make a comment,
and put an open parenthesis inside it.  After the comment put a matching
close paren.  From the opening paren try C-M-f.  Guess what?  You get an
error, just like you do in your case with the broken strings.

> Now, you might not care for this consistency, but I personally did.

CC Mode has always put a strong emphasis on correctness and accuracy.
You're complaining that a dubious trick borne of incorrectness no longer
works.  I don't think you have a strong position to complain.

> I've always had my methods of navigating code with unterminated strings,
> with _or without_ electric-pair mode and your cc-mode changes broke
> this workflow.

I think, perhaps, you encounter such broken strings extremely rarely,
and you're making a big song and dance over a relatively minor matter.

> > > lsp-mode, etc. These normally call the compiler directly on the
> > > source code and highlight those and many other errors.

> > Irrelevant.

> > > On the other hand, if what you want is the red annotation, are you
> > > absolutely sure there isn't a better way to get it?

> > No, I'm not.  That's why I invited you to come up with a better way, if
> > you can.

> I gave your one exactly one paragraph ago, which you called dismissed as
> "irrelevant". *shrug*.

*shrug* as much as you like.  You know full well what I meant when I
asked you to suggest an alternative.  So please stop being so damned
evasive and answer the point: can you suggest some other mechanism by
which CC Mode can create the required font-locking?  If you can, and
it's workable, we all win.

> > > I'll be "mulling this over". There are potentially many other points
> > > of breakage
> > "Potentially" many?  So far, there is precisely one, in
> > electric-pair--unbalanced-strings-p.

> What about d37d30cef5bbbdf8d17315835126d76d4681b22a? Is that the same
> problem?  Maybe, I don't know.  Certainly the broken C-M-u and C-M-f,
> aren't the same problem.

C-M-u and C-M-f aren't broken.  You just have unreasonable expectations
of them.

> > No, you'd be cleaning up your code, to conform with the reality that in
> > 2019 major modes use syntax-table text properties.  Features from CC
> > Mode have a habit of migrating to the Emacs core.

> It's not "my" code and I won't be bullied into making changes I don't
> agree with.

If anybody's the bully around here, it's not me.  I found a minor bug in
electric-pair-mode, diagnosed it, and reported it.  Then I found myself
engulfed in your immoderate tirade, trying to bully me into a major
restructuring of CC Mode so as to suit your somewhat unreasonable
wishes.

As far as I can make out, you are the maintainer of electric-pair-mode,
and you seem to be refusing to fix a bug, not even a difficult bug.  Are
you going to fix bug #36474 or not?

> Things worked fine until you added a feature in June 2018 that broke
> them.  You refuse to even let the user disable that feature or
> consider alternatives.  That's simply not reasonable to me.

Like you declining even to look at bug #36474?  Correctness in CC Mode
is not an optional feature - it goes to the heart of the mode.

> > > Also, in the meantime, for a user that is bothered by this bug,
> > > I'd recomend to put something like this in his/her .emacs file:

> > >   (defun c-unescaped-nls-in-string-p (&optional quote-pos) t)

> > It's free software, but that's a stupid thing to do.

> I'd ask you to actually give an argument instead of an insult, but I've
> been on this hamster wheel before, so never mind.  It works quite well.

Making random changes to the innards of a program tends to break things.
Will that do you instead?

> --
> João Távora

--
Alan Mackenzie (Nuremberg, Germany).

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Dmitry Gutov
On 03.07.2019 13:58, Alan Mackenzie wrote:
>> But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's
>> a git commit hash).
> I'm fully aware it's a git commit hash.  Funnily enough, I don't
> memorise such hashes, so if you wish to draw my attention to some
> commit, please have the decency to give me its date, and the summary
> line of its commit message, instead of expecting me to do your work to
> make your point.

The rest of the discussion aside, IMO it's a very strange reply. Though
I might be biased, given that a lot of my software-related discussions
are on platforms that linkify commit hashes.

Even so, is calling 'git show fe06f64b' too hard to do?

I would print its output on this occasion here, but in this case Git
says it's 'ambiguous'. So maybe Joao should elaborate.

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

João Távora
In reply to this post by Alan Mackenzie
On Wed, Jul 3, 2019 at 11:58 AM Alan Mackenzie <[hidden email]> wrote:

> I'm fully aware it's a git commit hash.  Funnily enough, I don't
> memorise such hashes, so if you wish to draw my attention to some
> commit, please have the decency to give me its date,

Look I'm not being indecent, Alan. Stop this. just `git show fe06f64b`,
and move on.

> You're complaining that a dubious trick borne of incorrectness no longer
> works.  

Why are you dictating what I can and can't use that to select
the region between the two quotes? I write my text, fill the pargaph,
select it with C-M-u C-M-SPC (nicely chained "u" and SPC) and then
I C-S-% to put in the backslahes. You may well consider it a "trick"
and "dubious" and "stupid", but it's the way I work.

Anyway, tell me, out of curiosity, how do you do it? How do you create

"this \
text, \
for \
example"

?

> I think, perhaps, you encounter such broken strings extremely rarely,
> and you're making a big song and dance over a relatively minor matter.

No, it's pretty routine, really.  Help blurbs in c++ and multi-line shell
commands in Makefiles, from the top of my head.  C-M-stuff is so
second nature in Emacs I don't even think when I'm using it, I just
expect it to work. I have user commands that use the underlying
functions, too.  By the way C-M-u is backward-up-list, not up-list
as I stated earlier (but both are broken, I think).

> can you suggest some other mechanism by
> which CC Mode can create the required font-locking?  If you can, and
> it's workable, we all win.

No, I can't, but I've asked others to chime in. I would personally do it
(in fact I already do do it) via flymake-mode. If you don't like that, sorry.

> C-M-u and C-M-f aren't broken.  You just have unreasonable expectations
> of them.

If you call unreasonable expectations gained from many years of using
Emacs in a variety of modes, including, up to very recently, cc-mode,
then clearly there's little point in proceeding this argument.

> > > No, you'd be cleaning up your code, to conform with the reality that in
> > > 2019 major modes use syntax-table text properties.  Features from CC
> > > Mode have a habit of migrating to the Emacs core.
> > It's not "my" code and I won't be bullied into making changes I don't
> > agree with.
> If anybody's the bully around here, it's not me.  I found a minor bug in
> electric-pair-mode, diagnosed it, and reported it.

You believe this is a bug in e-p-m. It's certainly your right to believe
that. I believe it's a bug in cc-mode. Do I have that right, too? Good.
Shall I open a bug report to joust with it, or is saying so enough?
I'd much rather the conflicting feature be disabled or made optional
in cc-mode, so that not only e-p-m starts working but also C-M-u,
C-M-f, etc. If don't agree, find a small enough solution that fixes
e-p-m, propose it here,  then find a consensus that overrides my
opinion, it happens all the time, won't hold it against you or
anyone else, good luck.

--
João Távora
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Alan Mackenzie
In reply to this post by Dmitry Gutov
Hello, Dmitry.

On Wed, Jul 03, 2019 at 16:07:59 +0300, Dmitry Gutov wrote:
> On 03.07.2019 13:58, Alan Mackenzie wrote:
> >> But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's
> >> a git commit hash).
> > I'm fully aware it's a git commit hash.  Funnily enough, I don't
> > memorise such hashes, so if you wish to draw my attention to some
> > commit, please have the decency to give me its date, and the summary
> > line of its commit message, instead of expecting me to do your work to
> > make your point.

> The rest of the discussion aside, IMO it's a very strange reply. Though
> I might be biased, given that a lot of my software-related discussions
> are on platforms that linkify commit hashes.

> Even so, is calling 'git show fe06f64b' too hard to do?

Yes.  As you'll have noticed, this is an adversarial debate rather than
a constructive cooperation, and expecting me to put in unnecessary work
in order to assist my opponent in making a point against me is not
reasonable.

Surely it is a matter of plain ettiquette: for the writer to put in that
little extra bit of work himself, rather than forcing his readers to do
it.  When writing, I always do this myself.

Besides, other people will read this post, and they'll have to remain
mystified, or put in the work themselves.  Giving a cryptic, rather than
a meaningful, reference thus costs more time than it saves.

Besides[2], the next time we move to a new VCS, the reference will
become totally meaningless.

> I would print its output on this occasion here, but in this case Git
> says it's 'ambiguous'. So maybe Joao should elaborate.

--
Alan Mackenzie (Nuremberg, Germany).

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Eli Zaretskii
In reply to this post by Dmitry Gutov
> From: Dmitry Gutov <[hidden email]>
> Date: Wed, 3 Jul 2019 16:07:59 +0300
> Cc: emacs-devel <[hidden email]>
>
> On 03.07.2019 13:58, Alan Mackenzie wrote:
> >> But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's
> >> a git commit hash).
> > I'm fully aware it's a git commit hash.  Funnily enough, I don't
> > memorise such hashes, so if you wish to draw my attention to some
> > commit, please have the decency to give me its date, and the summary
> > line of its commit message, instead of expecting me to do your work to
> > make your point.
>
> The rest of the discussion aside, IMO it's a very strange reply.

I agree.  Calling a reference to a commit SHA "indecent" (not in so
many words, but it's clearly hinted upon) is harsh and unfair, because
I cannot imagine any ill will behind such a reference.  Let's please
not use such harsh talk in our discussions.

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

João Távora
In reply to this post by Dmitry Gutov

On Wed, Jul 3, 2019 at 2:08 PM Dmitry Gutov <[hidden email]> wrote:
On 03.07.2019 13:58, Alan Mackenzie wrote:
>> But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's
>> a git commit hash).
> I'm fully aware it's a git commit hash.  Funnily enough, I don't
> memorise such hashes, so if you wish to draw my attention to some
> commit, please have the decency to give me its date, and the summary
> line of its commit message, instead of expecting me to do your work to
> make your point.

The rest of the discussion aside, IMO it's a very strange reply. Though
I might be biased, given that a lot of my software-related discussions
are on platforms that linkify commit hashes.

Even so, is calling 'git show fe06f64b' too hard to do?

I would print its output on this occasion here, but in this case Git
says it's 'ambiguous'. So maybe Joao should elaborate.

I'm sorry it's fe06f643b2808b198bb58bda04a8c863e55a2a56, the
3 got lost in translation.

BTW I believe this is the commit that broke things, but it might have been
around this time.

commit fe06f643b2808b198bb58bda04a8c863e55a2a56
Author: Alan Mackenzie <[hidden email]>
Date:   Fri Jun 8 16:42:18 2018 +0000

    CC Mode: Fontify unbalanced quotes in unconstrained multiline strings, etc.
   
    ("Unconstrained" meaning that every string is multiline, without needing such
    special marking as used by Pike Mode.)
   
    * lisp/progmodes/cc-mode.el (c-pps-to-string-delim): Don't process the char
    before BOB.
    (c-multiline-string-check-final-quote): New function.
    (c-bc-changed-stringiness): New variable.
    (c-before-change-check-unbalanced-strings): Add handling for unconstrained
    multiline strings.
    (c-after-change-re-mark-unbalanced-strings): Add handling for unconstrained
    multiline strings.  Handle escaped double quotes more accurately.





--
João Távora
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Dmitry Gutov
In reply to this post by Alan Mackenzie
On 03.07.2019 16:32, Alan Mackenzie wrote:

> Yes.  As you'll have noticed, this is an adversarial debate rather than
> a constructive cooperation, and expecting me to put in unnecessary work
> in order to assist my opponent in making a point against me is not
> reasonable.

IME even the adversarial debates, when treated as such, tend to waste
extra time from all parties involved. You might remember a few of those.

> Surely it is a matter of plain ettiquette: for the writer to put in that
> little extra bit of work himself, rather than forcing his readers to do
> it.  When writing, I always do this myself.

I don't think so. It seems much easier to call 'git show' than to
manually format a reference in the format that you requested. Some email
clients might even do that automatically.

I wouldn't want to see this written into the general rules of
discussions on this mailing list.

> Besides[2], the next time we move to a new VCS, the reference will
> become totally meaningless.

I'm not buying this, sorry. Anybody doing software archaeology in the
year 2040 would probably be able to dig out a Git repository of Emacs as
well.

And anyway, it seems like Git is here to stay. By the time we migrate
off it, it's most likely we've moved away from mailing lists as the
discussion medium.

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Eli Zaretskii
In reply to this post by Alan Mackenzie
> Date: Wed, 3 Jul 2019 13:32:17 +0000
> From: Alan Mackenzie <[hidden email]>
> Cc: João Távora <[hidden email]>,
>  emacs-devel <[hidden email]>
>
> > Even so, is calling 'git show fe06f64b' too hard to do?
>
> Yes.  As you'll have noticed, this is an adversarial debate rather than
> a constructive cooperation

It is only an adversarial debate if you two make it so.  I suggest to
respond as if you don't perceive the adversarial aspects, and expect
the other side to do the same.

> Surely it is a matter of plain ettiquette

It is not.  Showing Git SHA is perfectly okay, at least in this list.

> Besides, other people will read this post, and they'll have to remain
> mystified, or put in the work themselves.  Giving a cryptic, rather than
> a meaningful, reference thus costs more time than it saves.

That ship has sailed when we switched to Git.  It is not wise, to say
the least, to impregnate this discussion, which is already loaded with
emotions, with yet another emotional reaction against something that
no one can do anything about.

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Stefan Monnier
In reply to this post by Alan Mackenzie
> I think, perhaps, you encounter such broken strings extremely rarely,
> and you're making a big song and dance over a relatively minor matter.

This argument cuts both ways.


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Stefan Monnier
In reply to this post by Alan Mackenzie
> evasive and answer the point: can you suggest some other mechanism by
> which CC Mode can create the required font-locking?

Should be pretty easy: add a rule to font-lock-keywords (i.e. no change
in syntax-tables) matching a double quote and which then checks with
syntax-ppss if it's an opening or closing quote and whether the matching
matching quote is on the same line or not (and applies a warning face
accordingly).


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Kévin Le Gouguec
In reply to this post by João Távora
João Távora <[hidden email]> writes:

>> can you suggest some other mechanism by
>> which CC Mode can create the required font-locking?  If you can, and
>> it's workable, we all win.
>
> No, I can't, but I've asked others to chime in. I would personally do it
> (in fact I already do do it) via flymake-mode.

To expand on that a bit…

AFAICT from its documentation, flymake aims to be "a universal
on-the-fly syntax checker for GNU Emacs".  It is distributed as a core
Emacs library, and as an ELPA package requiring Emacs 26.1.

Looking at this situation from afar[1], invalid-syntax highlighting
sounds exactly like the kind of feature that could be implemented as a
flymake backend[2].

(
    Although I guess the question then moves to "How would the
    *backend* implement this feature?" to which I have no answer,
    knowing nothing of either flymake's API or CC mode's
    invalid-syntax detection process.  Abstractly, I guess that would
    imply

    - lifting some fontification code off CC mode since I assume the
      flymake frontend would handle the presentation,

    - keeping the invalid-syntax detection code,

    - marshalling the information it gathers into flymake
      "diagnostics".
)

From this excerpt of the discussion of bug#36474[3]:

Alan Mackenzie <[hidden email]> writes:

>> 4. Someone reinvents electric-pair-mode in cc-model.el.
>> Let's not do this.
>
> No, let's not do that!  :-)

… I understand that it is a shared principle that there is no
intrinsic value to CC mode implementing features that another library
already provides[4], as that complicates maintenance.


Anyway, this was my very abstract reading of the situation; if I knew
the actual code better, I could probably come up with a truckload of
reasons why *as things stand now*, tearing the highlighting feature
apart and banging on it until it fits flymake's API is not the path of
least resistance.

Therefore, feel free to disregard.


[1] "Long-time-user-long-time-lurker-no-contribution-to-speak-of"-kind
    of afar.

[2] Quoting (flymake) Backend functions:

    >    A backend’s responsibility is to diagnose the contents of a
    > buffer for problems, registering the problem’s positions, type,
    > and summary description.  This information is collected in the
    > form of diagnostic objects created by the function
    > ‘flymake-make-diagnostic’ (*note Flymake utility functions), and
    > then handed over to Flymake, which proceeds to annotate the
    > buffer.

[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36474#8

[4] Although in this particular case, CC mode strives to support Emacs ≥
    24.5, so depending on flymake would limit the feature to Emacs ≥
    26.1.


Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Alan Mackenzie
In reply to this post by Eli Zaretskii
Hello, Eli.

On Wed, Jul 03, 2019 at 18:58:39 +0300, Eli Zaretskii wrote:
> > Date: Wed, 3 Jul 2019 13:32:17 +0000
> > From: Alan Mackenzie <[hidden email]>
> > Cc: João Távora <[hidden email]>,
> >  emacs-devel <[hidden email]>

> > > Even so, is calling 'git show fe06f64b' too hard to do?

> > Yes.  As you'll have noticed, this is an adversarial debate rather than
> > a constructive cooperation

> It is only an adversarial debate if you two make it so.  I suggest to
> respond as if you don't perceive the adversarial aspects, and expect
> the other side to do the same.

I've been trying that.  It's not been working well.

> > Surely it is a matter of plain ettiquette

> It is not.  Showing Git SHA is perfectly okay, at least in this list.

> > Besides, other people will read this post, and they'll have to remain
> > mystified, or put in the work themselves.  Giving a cryptic, rather than
> > a meaningful, reference thus costs more time than it saves.

> That ship has sailed when we switched to Git.  It is not wise, to say
> the least, to impregnate this discussion, which is already loaded with
> emotions, with yet another emotional reaction against something that
> no one can do anything about.

That is not true.  A policy decision could be taken now to apply to
future commit references.  I can understand you not wanting to lay down
such a policy, however.

I will continue to supply information such as date and commit message
whenever I refer to a git commit, out of courtesy  and consideration for
the people who will read my post.  They will then immediately know what
I'm talking about, and have enough details to decide whether to look up
the commit in git.

Conversely, I will feel free to ignore a bare git commit hash, for
example when I'm tired, or feeling harrassed, or the tone of the post
containing it is unfriendly, or, quite bluntly, when I just can't be
bothered.

--
Alan Mackenzie (Nuremberg, Germany).

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

João Távora
In reply to this post by Kévin Le Gouguec
On Wed, Jul 3, 2019 at 7:25 PM Kévin Le Gouguec <[hidden email]> wrote:

> Looking at this situation from afar[1], invalid-syntax highlighting
> sounds exactly like the kind of feature that could be implemented as a
> flymake backend[2].

If you're not connecting these particular dots, I wrote Flymake (or
rather, I rewrote it) recently, so that's why I'm partial to it.  But
there is also another very good and popular solution, Flycheck, which
does basically the same thing (but is not bundled with Emacs).

Anyway, if you open an Emacs C source and type M-x flymake-mode you
should already get the full syntax validation of the buffer as performed
by the compiler.  In other projects, it's easy to setup (see the
docstring for the flymake-cc-command variable).

>     - lifting some fontification code off CC mode since I assume the
>       flymake frontend would handle the presentation,
> ...
> apart and banging on it until it fits flymake's API is not the path of
> least resistance.

It's not trivial to write a Flymake backend, but it's not hard either.
I wrote documentation for that in the manual and in docstrings. For this
, you don't need to lift any code off CC-mode (or any other mode) if it
follows basic assumptions.  I hacked up a (very lightly tested) backend
that will diagnose unterminated multi-line strings in most modes.
This includes cc-derived modes if you monkey-patch them with

   (defun c-unescaped-nls-in-string-p (&optional quote-pos) t)
   
...or if you find some other way to disable the problematic feature.
Here is the code.

(cl-defun flymake-check-unterminated-strings
    (report-fn &key changes-start changes-end &allow-other-keys)
  "Flymake backend for checking unterminated strings in c-like modes"
  (save-excursion
    (cl-loop with collected = (list)
             with start = (or changes-start (point-min))
             with start-ppss = (syntax-ppss)
             with end = (or changes-end (point-max))
             initially (goto-char start)
             (when (nth 3 start-ppss)
               (goto-char (setq start (nth 8 start-ppss)))
               (setq start-ppss (syntax-ppss)))
             for ppss = start-ppss then (syntax-ppss)
             for next = (if (and (nth 3 ppss)
                                 (nth 8 ppss))
                            (let* ((lep (line-end-position))
                                   (probe (char-before lep))
                                   (string-end (ignore-errors
                                                 (1+ (scan-sexps (nth 8 ppss) 1)))))
                              (setq end (or string-end (point-max)))
                              (cond
                                ((eq probe ?\\) (1+ lep))
                                ((and (not (= lep (point))) (eq probe ?\"))
                                 (and string-end
                                      (1+ string-end)))
                                (t (push (flymake-make-diagnostic
                                          (current-buffer) (point)
                                          (1+ lep) :error "unterminated string")
                                         collected)
                                   (and string-end (1+ string-end)))))
                          (1+ (point)))
             while (and next
                        (<= next end))
             do (goto-char next)
             finally (funcall report-fn
                              collected
                              :region (cons start end))
             (cl-return collected))))
             
You can try it with

  (add-hook 'flymake-diagnostic-functions #'flymake-check-unterminated-strings nil t)

You might have to turn flymake off and on again.  You also need a very
recent Flymake (version 1.0.8 should be in GNU ELPA shortly).

--
João Távora
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Richard Stallman
In reply to this post by Alan Mackenzie
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes.  As you'll have noticed, this is an adversarial debate rather than
  > a constructive cooperation,

If that's really the case, how can we change the discussion into
constructive cooperation?  The purpose of this discussion is to
improve Emacs.  When we disagree about how to do that, can we
keep in mind that we are all on the same side?

--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)



Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Eli Zaretskii
In reply to this post by Alan Mackenzie
> Date: Wed, 3 Jul 2019 20:54:57 +0000
> Cc: [hidden email], [hidden email], [hidden email]
> From: Alan Mackenzie <[hidden email]>
>
> > > Yes.  As you'll have noticed, this is an adversarial debate rather than
> > > a constructive cooperation
>
> > It is only an adversarial debate if you two make it so.  I suggest to
> > respond as if you don't perceive the adversarial aspects, and expect
> > the other side to do the same.
>
> I've been trying that.  It's not been working well.

Nevertheless, I urge you to keep doing that.

> > > Besides, other people will read this post, and they'll have to remain
> > > mystified, or put in the work themselves.  Giving a cryptic, rather than
> > > a meaningful, reference thus costs more time than it saves.
>
> > That ship has sailed when we switched to Git.  It is not wise, to say
> > the least, to impregnate this discussion, which is already loaded with
> > emotions, with yet another emotional reaction against something that
> > no one can do anything about.
>
> That is not true.  A policy decision could be taken now to apply to
> future commit references.  I can understand you not wanting to lay down
> such a policy, however.

We actually have such a policy, but it isn't working, and I don't
think it will ever do.

> Conversely, I will feel free to ignore a bare git commit hash, for
> example when I'm tired, or feeling harrassed, or the tone of the post
> containing it is unfriendly, or, quite bluntly, when I just can't be
> bothered.

I advise against that.

Reply | Threaded
Open this post in threaded view
|

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode

Kévin Le Gouguec
In reply to this post by João Távora
João Távora <[hidden email]> writes:

> If you're not connecting these particular dots, I wrote Flymake (or
> rather, I rewrote it) recently, so that's why I'm partial to it.  But
> there is also another very good and popular solution, Flycheck, which
> does basically the same thing (but is not bundled with Emacs).

(Yup, the dots were connected.  I know about Flycheck and I did notice
you picking up Flymake recently, for which I am quite grateful!)

The main reason *I* am partial to Flymake, as a user (and in the context
of this feature of CC mode), is because it is bundled with Emacs (has
been for 15 years).  This means I can think of incorrect-code
highlighting as a "core feature", as Alan called it (though it's core as
in "part of the Emacs core", not necessarily as in "implemented by the
major mode and impossible to toggle off").

12345