[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CC Mode and electric-pair "problem".
From: |
Alan Mackenzie |
Subject: |
Re: CC Mode and electric-pair "problem". |
Date: |
Mon, 18 Jun 2018 10:36:54 +0000 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
Hello, João.
On Sun, Jun 17, 2018 at 22:27:20 +0100, João Távora wrote:
> On Sun, Jun 17, 2018 at 9:13 PM, Alan Mackenzie <address@hidden> wrote:
> > Hello, Glenn.
> > On Sun, Jun 17, 2018 at 12:58:53 -0400, Glenn Morris wrote:
> > > Alan Mackenzie wrote:
> > > > However, the test suite (make check) threw up another discrepancy, in a
> > > > test called
> > > > electric-pair-whitespace-chomping-2-at-point-4-in-c++-mode-in-strings.
> > > Hello, is this still being worked on?
> > > The test continues to fail on RHEL 7 and hydra.nixos.org.
> > From my point of view, the bug is not being worked on this very day, but
> > has by no means been forgotten. It has needed a period of mulling over.
> > I think João sees it the same way.
> Yes, while mulling over things is generally good, I believe the problem
> from Glenn's perspective is the nuisance of checking whether every
> test failure is something to worry about or just the thing being
> mulled over.
Yes. But it is the master branch, where not everything can be expected
to work all the time. I think the main thing is, we're _going_ to fix
this bug.
> So I suggest taking a quick temporary action to make the test pass
> and then think about how to do it properly. This action could be
> disabling the test temporarily but IME that invariably buries the
> issue ad eternum. So it's better to do it in cc-mode.
Hmm. To modify CC Mode temporarily to make 'chomp in electric-pair-mode
work would be an order of magnitude more work than "simply" to fix the
bug. That's without disabling the handling of " in CC Mode entirely.
> Although it won't be difficult to fix, this bug is an awkward thing, and
> > will need decisions (smallish ones) to be taken.
> > My favoured method would be to alter electric-pair--skip-whitespace such
> > that a NL terminating a string (as contrasted with a NL terminating a
> > comment) would be allowed to be scanned over.
> I'm OK with adding an customization point to
> electric-pair--skip-whitespace that c-mode can customize. But I also
> wonder whether the benefit to end-users of handling NL-terminated
> strings are worth it. Perhaps there are indeed benefits, it's just that
> I haven't seen them argued.
OK, here goes. Why should major modes tie themselves in knots, just so
that electric-pair-mode can work? What CC Mode is doing is natural, and
matches the reality. A C(++) compiler regards an unterminated string as
ending at the (first unescaped) linefeed. It will then regard the next
line as code (not string). If there is a subsequent ", the compiler
won't see that as a terminator for the unbalanced opening ". CC Mode now
matches this reality, which is a Good Thing.
electric-pair-mode's chomp facility could be more rigorously coded -
sometimes it is dealing with visible whitespace, sometimes it is dealing
with syntactic properties. Surely it should be working with visible
whitespace all the time?
I've attempted a bit of debugging. In addition to
electric-pair--skip-whitespace, I encountered a scan-sexps in subfunction
ended-prematurely-fn of function electric-pair--balance-info, which
snagged on the end of string at EOL.
> But more importantly perhaps there are ways to reap these benefits in a
> way that doesn't require changes to e-p-m, or even better, in a way
> that benefits all of Emacs, not just c-mode.
We are talking about a corner case in e-p-m, namely where e-p-m attempts
to chomp space between parens inside an invalid string. This surely
won't come up in practice very much. Is it worth fixing? (I would say
yes.)
> So, in practice, is the advantage here that the user is visually
> warned of an invalid NL-terminated string?
The user is visually informed of the reality: that one or more strings
are unterminated, and where the "breakage" is (where the
font-lock-string-face stops). This is an improvement over the previous
handling, where the opening invalid " merely got warning-face, but the
following unterminated string flowed on indefinitely.
The disadvantage is that e-p-m is constraining major modes in how they
can use syntax-table text properties. I think this is a problem in
electric-pair-mode, not in CC Mode.
> João
--
Alan Mackenzie (Nuremberg, Germany).
- Re: CC Mode and electric-pair "problem"., Alan Mackenzie, 2018/06/02
- Re: CC Mode and electric-pair "problem"., Glenn Morris, 2018/06/17
- Re: CC Mode and electric-pair "problem"., Alan Mackenzie, 2018/06/17
- Re: CC Mode and electric-pair "problem"., Stefan Monnier, 2018/06/17
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/17
- Re: CC Mode and electric-pair "problem".,
Alan Mackenzie <=
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Eli Zaretskii, 2018/06/18
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Eli Zaretskii, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Eli Zaretskii, 2018/06/18
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/18
- Re: CC Mode and electric-pair "problem"., Eli Zaretskii, 2018/06/18
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/19
- Re: CC Mode and electric-pair "problem"., Eli Zaretskii, 2018/06/19
- Re: CC Mode and electric-pair "problem"., João Távora, 2018/06/19