emacs-devel
[Top][All Lists]
Advanced

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

Re: Bug #25608 and the comment-cache branch


From: Alan Mackenzie
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sun, 5 Feb 2017 22:00:45 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello again, Eli.

On Fri, Feb 03, 2017 at 09:41:23 +0200, Eli Zaretskii wrote:
> > Date: Thu, 2 Feb 2017 21:51:54 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: address@hidden

> > > I say there's too much resistance to doing that from people whose
> > > opinions I respect and trust.  Each time this issue comes up, I see
> > > that resistance being expressed again.

> > Primarily from Stefan.

> Not only Stefan.  Also Dmitry.

> > > I hope it's possible to find some kind of compromise or a different
> > > solution that leaves people less unhappy.

> > Compromise with what?

> With the objections, ideas, and suggestions expressed in those
> discussions.

(forward-comment -1), implemented by backward_comment in syntax.c is an
essential part of Emacs.  There are currently four contending ways for
how this should be done:

(i) The comment-cache branch ("CC").
(ii) The current master with open-paren-in-column-0-is-defun-start set
  to t (its default) ("M-t").
(iii) As (ii) but with o-p-i-c-0-i-d-s set to nil ("M-nil").
(iv) The "alternative patch" proposed by Stefan and advocated by Dmitry
  ("AP").

These four ways have the following characteristics:

        |      Speed       Direction of scanning     Correct parsing
------------------------------------------------------------------------
CC      |       OK             forwards                   yes
M-t     |       OK             backwards                  no [1]
M-nil   |       Slow           backwards                  probably [2]
AP      |       OK             backwards                  no [3]

[1] M-t fails on comments containing parens in column zero.
[2] M-nil depends on scanning comments backwards.  It is believed to be
  correct, but it is difficult to be sure.
[3] AP depends on syntax-ppss, which returns spurious values for narrowed
  buffers (bug #22983).  A test case exists for which AP fails.

By the above criteria, CC is the clear winner.

CC is opposed by Stefan and Dmitry, if I understand correctly, because
they think the type of action performed by CC should be done using
syntax-ppss and no other way.  Additionally, Dmitry has expressed some
minor concern at the extra RAM used by CC, and Stefan has expressed some
concern at how CC might affect multiple major modes in a single buffer.

Right now, I am facing a tedious and quite difficult merge of master
into comment-cache, necessitated by extensive changes in syntax.c since
I last merged, back in December.  Should I bother?

I strongly believe that comment-cache is the best way for Emacs to do
back_comment.  As already said, I am not enthusiastic at continually
having to field bugs with parens in column 0 inside comments, caused by
the current buggy backward_comment.

But I need your acceptance of comment-cache to go any further.  It has
taken a lot of my time to develop, and I am still hopeful of merging it
into master.  If there is a sound technical reason why it should be
abandoned, that is fair enough.  If it is rejected without such a
reason, I will need to reconsider my relationship with Emacs.  I am
currently working (or "working") on several ambitious changes in Emacs.
One of them is restructuring the byte compiler so that error and warning
messages get the correct line number (bug #22288, etc.).  If there is
the prospect of these being rejected without good reason, I am not
willing to take the risk of wasting my time on them.  I would restrict
my participation in Emacs to CC Mode and simple changes in the non-C
part of Emacs which can be done in at most a very few hours.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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