all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sun, 5 Feb 2017 22:00:45 +0000	[thread overview]
Message-ID: <20170205220045.GB2294@acm> (raw)
In-Reply-To: <83h94bvhzw.fsf@gnu.org>

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 <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > > 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).



  parent reply	other threads:[~2017-02-05 22:00 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 20:24 Bug #25608 and the comment-cache branch Alan Mackenzie
2017-02-02 20:47 ` Eli Zaretskii
2017-02-02 21:51   ` Alan Mackenzie
2017-02-02 22:15     ` Dmitry Gutov
2017-02-03  7:41     ` Eli Zaretskii
2017-02-03 17:29       ` Alan Mackenzie
2017-02-03 22:08         ` Dmitry Gutov
2017-02-04 10:24           ` Alan Mackenzie
2017-02-06  2:09             ` Dmitry Gutov
2017-02-06 19:24               ` Alan Mackenzie
2017-02-07  1:42                 ` Dmitry Gutov
2017-02-07 19:21                   ` Alan Mackenzie
2017-02-14 15:28                     ` Dmitry Gutov
2017-02-14 16:38                       ` Stefan Monnier
2017-02-22  2:25                         ` Dmitry Gutov
2017-02-22  3:53                           ` Stefan Monnier
2017-02-23 14:23                             ` Dmitry Gutov
2017-02-23 14:48                               ` Stefan Monnier
2017-02-24  7:46                                 ` Tom Tromey
2017-02-14 21:14                       ` Alan Mackenzie
2017-02-16 14:10                         ` Stefan Monnier
2017-02-18 10:44                           ` Alan Mackenzie
2017-02-18 13:49                             ` Stefan Monnier
2017-02-12  2:53               ` John Wiegley
2017-02-12  8:20                 ` Elias Mårtenson
2017-02-12 10:47                 ` Alan Mackenzie
2017-02-12 11:14                 ` martin rudalics
2017-02-12 15:05                   ` Andreas Röhler
2017-02-12 15:39                   ` Eli Zaretskii
2017-02-05 22:00       ` Alan Mackenzie [this message]
2017-02-06  1:12         ` Stefan Monnier
2017-02-06 18:37           ` Alan Mackenzie
2017-02-08 17:20         ` Eli Zaretskii
2017-02-11 23:25           ` Alan Mackenzie
2017-02-12  0:55             ` Stefan Monnier
2017-02-12 12:05               ` Alan Mackenzie
2017-02-12 13:13                 ` Juanma Barranquero
2017-02-12 15:57                 ` Dmitry Gutov
2017-02-12 17:29                   ` Alan Mackenzie
2017-02-12 20:35                     ` Dmitry Gutov
2017-02-13  1:47                     ` zhanghj
2017-02-13  5:50                       ` Stefan Monnier
2017-02-13  6:45                         ` zhanghj
2017-02-13  7:24                           ` Stefan Monnier
2017-02-13  7:59                             ` zhanghj
2017-02-13  9:25                               ` Stefan Monnier
2017-02-13 16:14                           ` Drew Adams
2017-02-13  7:05                         ` zhanghj
2017-02-13  7:16                         ` zhanghj
2017-02-13 14:57                           ` Dmitry Gutov
2017-02-12 17:49                 ` Stefan Monnier
2017-02-13 18:09                   ` Alan Mackenzie
2017-02-13 19:34                     ` Eli Zaretskii
2017-02-13 21:21                     ` Stefan Monnier
2017-02-02 22:14 ` Dmitry Gutov
2017-02-03 16:44   ` Alan Mackenzie
2017-02-03 21:53     ` Dmitry Gutov
2017-02-04 11:02       ` Alan Mackenzie
2017-02-06  1:28         ` Dmitry Gutov
2017-02-06 19:37           ` Alan Mackenzie
2017-02-06  2:08         ` Stefan Monnier
2017-02-06 20:01           ` Alan Mackenzie
2017-02-06 22:33             ` Stefan Monnier
2017-02-07 21:24               ` Alan Mackenzie
2017-02-08 12:54                 ` Stefan Monnier
2017-02-07 15:29             ` Eli Zaretskii
2017-02-07 21:09               ` Alan Mackenzie
2017-02-08 17:28                 ` Eli Zaretskii
2017-02-02 23:57 ` Stefan Monnier
2017-02-03 16:19   ` Alan Mackenzie
2017-02-04  9:06     ` Andreas Röhler
2017-02-04 18:18     ` Stefan Monnier
2017-02-04 18:28       ` Alan Mackenzie
2017-02-03  7:49 ` Yuri Khan
2017-02-03 18:30   ` Andreas Röhler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170205220045.GB2294@acm \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.