unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sat, 4 Feb 2017 10:24:10 +0000	[thread overview]
Message-ID: <20170204102410.GA2047@acm> (raw)
In-Reply-To: <0a40d539-b7bc-2655-5429-6280022106ee@yandex.ru>

Hello, Dmitry.

On Sat, Feb 04, 2017 at 00:08:41 +0200, Dmitry Gutov wrote:
> On 03.02.2017 19:29, Alan Mackenzie wrote:

> > The objectors do not seem to want compromise - they want comment-cache
> > to be wholly abandoned.

> It's silly to seek a compromise between implementations. Rather, we 
> should discuss hard requirements (with some test cases).

You want comment-cache to be wholly abandoned.

The requirements are simple.  First, and foremost, (forward-comment -1)
must work.  Secondly, it should do so fast, preferably at least as fast
as the current (buggy) implementation.

Here is a test case from months gone by.  Put point-min at the indicated
position, put point at EOL, then do M-: (forward-comment -1).

    char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /*  */  /*   '"'"  */
                      ^

This test works in comment-cache.

> And then we should seek the simplest solution that satisfies all of our 
> requirements.

As simple as possible, but definitely not simpler.  The "solution" you
favour is too simple.  It doesn't work all the time.

> > They object to it for reasons I don't
> > understand, despite the fact that it elegantly solves a long standing
> > problem that continues to cause pain on a frequent basis.

> Elegance is in the eye of the beholder. It certainly doesn't seem 
> elegant to me, design-wise.

> > If you (or anybody else) could summarize what these objections are, I'd
> > be very grateful.

> "It introduces a second source of truth" seems like a concise summary.

So what?  There are any number of "sources of truth" in Emacs.  If one
of them turns out to be a "source of untruth" we call that a bug, and we
fix it.

> At best, it'll use more memory than it has to.

The thing to do here is measure this extra memory.  I did this back in
spring last year, and the number of extra conses used for the cache was
not inordinately high.  Especially not for a 64-bit machine with several
gigabytes of RAM.

> At worst, we risk divergence in the information contained in those
> sources (so functions depending on one or the other will behave in
> incompatible fashion). That means nasty bugs that aren't easy to track
> down.

I think you're seeing something that's not there.  You're picturing some
imagined process where two alternative ways of storing information have
great difficulty staying together, and somehow, over time, are destined
to drift apart.  Sort of like two national currencies trying to stay
pegged to eachother, or something like that.

That's not how computer programs work.  If those two ways end up
differing, we have a bug, which can be fixed like any other bug.  Heck,
even a single "source of truth" can be buggy, with just as severe
consequences.  We get bugs, we fix them.

Note, in this context, that syntax-ppss is broken (bug #22983) and
doesn't look like getting fixed any time soon, yet the world hasn't come
to an end.

> > Note that there has been NO constructive criticism of comment-cache.

> That's insulting, Alan.

It might be, but I think it's true.  You want comment-cache to be wholly
abandoned.  You are not suggesting ways to make it better.  You haven't
tried it, that I'm aware of.  You haven't looked for flaws, with the
intention of getting them fixed.  Instead you are putting forward
reasons, not all of them good, for abandoning comment-cache.

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2017-02-04 10:24 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=20170204102410.GA2047@acm \
    --to=acm@muc.de \
    --cc=dgutov@yandex.ru \
    --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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).