[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: Re: CC Mode and electric-pair "problem".
Date: Sat, 30 Jun 2018 22:29:12 +0300

> Date: Sat, 30 Jun 2018 19:03:27 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: Clément Pit-Claudel <address@hidden>,
>       Stephen Leake <address@hidden>,
>       João Távora <address@hidden>,
>       address@hidden
> I am in the middle of writing a trial implementation (code speaks louder
> than words).  Thus far, it has already worked in shell-script-mode
> (which required a one-line change, this:
>     -       ?\n ">#"
>     +       ?\n ">#s"
> the new `s' flag is how I've constructed it, so far).
> > But that's for Eli to judge.
> > So let's look at the technical issues:
> > You suggest introducing a new syntax-table thingy similar to > but for
> > strings.  Let's call it ]
> As I noted above, I have implemented it as another flag, `s'.
> > - This implies we'll need a new C-level function `back_string` to jump
> >   backward over such a ]-terminated string, corresponding to
> >   back_comment.
> Yes.
> >  `back_comment` has proved to be rather nasty, so while
> >   we can learn from it, part of what we learn is that jumping backward
> >   over such things is much easier ....
> much less easy.  :-)
> >   .... than jumping forward, so this
> >   innocuous ] will be more costly than might meet the eye.
> It requires the new function, which at the moment seems somewhat less
> complicated than back_comment, and this requires to be called from
> scan_lists.
> > - In CC-mode, \n already has syntax > so it can't also have syntax ]
> >   How do you intend to deal with that: will you mark those few \n that
> >   terminate strings with syntax-table text-properties?
> This is simple with the flag `s'.  NL would thus have end-comment syntax
> _and_ the `s' flag.  In scan_lists, back_comment will be tried before
> what I'm calling `back_maybe_string', since being a comment ender must have
> precedence over being a string terminator.
> >   If so, what's the benefit over using string-fences?
> String-fence stopped the 'chomp facility of electric-pair-mode working
> properly (for the currently accepted value of "properly").
> > - Another approach would be to make it possible to mark \n as both ] and
> >   > at the same time, which would make the CC-mode feature much cleaner
> >   (no need to muck with syntax-table text-properties) but the cost of
> >   yet more complexity in the syntax.c code.
> That's what I'm doing with `s'.  The extra complexity in syntax.c
> doesn't seem all that bad at the moment.  back_maybe_string is currently
> 137 lines long (including a macro analogous to INC_FROM, and a lossage:
> clause modelled on the one in back_comment)), compared with
> back_comment's 289 lines.  I'm planning on committing this new code to a
> branch in the next few days, then you can judge better whether the new
> facility is worth it.

Could you please recap what problem(s) you are trying to fix with
these changes?  (I'm sorry for not following, but this thread spans
two months and many long messages with several days in-between.  It's
hard to keep focused on the main issues.)


reply via email to

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