emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text


From: Alan Mackenzie
Subject: Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.
Date: Mon, 14 Mar 2016 21:20:24 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Dmitry.

On Mon, Mar 14, 2016 at 09:33:25PM +0200, Dmitry Gutov wrote:
> On 03/14/2016 08:46 PM, Alan Mackenzie wrote:

> >>> CC Mode doesn't use syntax-ppss.  It would be too much work to put it in,
> >>> particularly as that function's future is unclear.

> >> Could you please avoid FUD like that?

> > There's no FUD in my last paragraph, it's an accurate representation of
> > the facts.

> Not at all. syntax-ppss's future is rather clear, and it's here to stay, 
> after years of successfully being in use.

I meant, its deficiencies need fixing, and it's not clear at this stage
how that's to be done.  I've said elsewhere what I expect to happen:
that it will be superseded by a different function with the same name.

> > I am not prepared to spend the time needed to adapt CC Mode
> > to use syntax-ppss, and wouldn't be even if it worked properly.

> That's a separate issue. Right now we're discussing how to best 
> implement "comment cache", and if it's needed at all.

Are we?  Oh, all right then, let's discuss that.

> Apparently, the point is that you've been offered a simpler solution for 
> the same problem, and that you basically ignored it.

The simpler solution is a solution to a subset of the problem, more of a
workaround than a solution in my view, as I've already said.

[ .... ]

> > Yes, applying that patch and doing measurements would be a lot of work.
> > You're welcome to do it if you're interested enough.

> I might, but you'd first have to let me know what to test.

Working out what to test is the time consuming bit.

> If the comment cache patch doesn't actually help with 22884, why are
> we even discussing it?

Because it solves the problem which was the ultimate cause of bug
#22884.

> > I have tried out Stefan's patch, and for the vast majority of
> > comments on which it actually works, I've no doubt it will work fast
> > enough.  Its speed isn't the issue.

> Ah, so the speed advantage of using text properties is not that much of 
> advantage. Correct?

It's currently unknown.  That's one reason I'd like to get it merged
with master, so as people could try it out.  As already discussed, on
certain restricted tests it's significantly faster.

> > Stefan's patch doesn't actually fix what I see as the root cause of bug
> > #22884, namely that comments get scanned backwards.  At some time in the
> > future this backward scanning will cause more bugs.

> Can you produce a test case where it fails? This time without involving 
> narrowing, please.

Of course not.  The code is twisted, with lots of special cases,
exceptions, and so on.  It even notes in its comments certain corner
cases which won't work.  It will fail again.

Anyhow, when you're testing something like this, what's the point of
only testing with nice easy cases?  The code must work correctly with or
without narrowing.

> > What has been tried is Martin Rudalics's `foo' and `bar' functions
> > (which repeatedly perform `c-end-of-defun' and `c-beginning-of-defun'
> > respectively).  I'm not the only person who has noticed a dramatic
> > increase in speed for the comment-cache branch in these
> > (unrepresentative) tests.  If you're interested, look at some of the
> > timings in the posts branching off of Martin's first post in this
> > thread.

> Do you have any non-synthetic tests? (while (not (eobp)) (end-of-defun)) 
> is not something that is likely to occur is a user's interaction with 
> Emacs with any regularity.

No, I don't have any such tests.

> For a synthetic test, by the way, a 60%-80% increase in performance is 
> not that impressive.

It's slightly more impressive than a 60% decrease in performance.  Note
that the test wasn't specially written to exhibit high performance (like
some "benchmark" tests are arranged to do).

> > It will make no difference to the scenario in #22884, no, and it was
> > never envisaged that it would.  What all these things have in common is
> > problems caused by scanning comments backwards.

> syntax-ppss helps with avoiding that.

Not the way Stefan's patch uses it, it won't.  If you look at my patch
in any detail, you'll see the former back_comment renamed to
old_back_comment.  It's due to be removed entirely.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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