From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Bug #25608 and the comment-cache branch
Date: Tue, 7 Feb 2017 03:42:50 +0200 [thread overview]
Message-ID: <4f0fabf3-be9c-7492-379b-59dc93e72b4f@yandex.ru> (raw)
In-Reply-To: <20170206192423.GB3568@acm>
Hey Alan,
On 06.02.2017 21:24, Alan Mackenzie wrote:
> The essence of comment-cache is scanning comments only in the forward
> direction. This is impractical without a good cache. The syntax-ppss
> cache is wholly inadequate here (and would be even if it worked in the
> general case).
How come the "alternative patch" works well, then? The only bugs you've
outlined so far are related to narrowing and syntax table change, but
not any static complex syntactic situations, which is where I would
expect scanning direction to have an impact.
> There's no sign of syntax-ppss being fixed. Bug #22983 has been open
> for almost a year, and despite repeated requests from me, there has been
> no movement on it.
You didn't show any enthusiasm about the initial proposed fix, which was
rather simple. Now we've had more discussions, and the bar for a
solution has been raised. I'm thinking about it again. Let's not give up.
> Anyways, there are other problems with the "alternative patch". It
> doesn't clear it's caches when syntax-table properties are applied to or
> removed from a buffer. It doesn't clear its caches when a "literal
> relevant" change is made to the current syntax table, or a different
> syntax-table is made current.
Tracking changes inside a syntax table is possible (at the expense of
some performance, as usual), but kinda pointless, I think. Most issues
related to that, if they ever come up, could be answered with "don't do
that".
Tracking the used syntax table is also a problem which we need to solve
for syntax-ppss. A good design could handle it and narrowing together.
> comment-cache handles these situations
> correctly - that's where its perceived complexity scores.
And it does that in a pretty inflexible way.
> comment-cache has rewriten backward_comment entirely, hence the
> troublesome merge. It's no more difficult for maintainers than the
> current version of Emacs.
But surely it is more complex, with cache handling logic.
> They shouldn't drift apart at all. But drifting apart is no worse a
> problem than a single cache being wrong.
Yes, it is worse. You have more code to debug. And comment-cache adds
quite a bit of code.
> Arguing for complete abandonment is not constructive criticism.
When an alternative approach is recommended, yes, it is.
> I'm not saying the "alternative patch" couldn't be enhanced to do these
> things properly, but it would then no longer be a 20-line patch.
I think it would be. The enhancements you're referring to will most
likely be implemented on the Lisp level, and they are needed anyway.
So the "speed up forward-comment" patch would still come out to 20 lines.
> It would also likely be much slower.
I wouldn't be so sure. A syntax table comparison, for instance, would be
pretty cheap compared to what syntax-ppss does already.
next prev parent reply other threads:[~2017-02-07 1:42 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f0fabf3-be9c-7492-379b-59dc93e72b4f@yandex.ru \
--to=dgutov@yandex.ru \
--cc=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.