auctex
[Top][All Lists]
Advanced

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

Re: [AUCTeX] Patch to tex-info.el to support node name completion in @..


From: Vincent Belaïche
Subject: Re: [AUCTeX] Patch to tex-info.el to support node name completion in @..ref commands, and solve a few other pbs
Date: Tue, 27 Oct 2015 18:39:11 +0100

> Hi guys,
> 

Hello Tassilo,

> I'm somehow lost.  It seems that some mail, presumably Stefan ->
> Vincent, started this discussion but that hasn't been delivered to me.
> So well, yes, `pushnew' does the right thing, and in Vincent's patch
> to tex-info.el, I replaced his `add-to-list' call with (pushnew
> ... :test #'equal) anyhow.

Another discussion has started concerning the docstring of cl-pushnew.


Just to come back to the initial point concerning revision of function
Texinfo-make-node-list, what has happened is that I was not aware of the
rationale behind replacing add-to-list by pushnew, Stefan has clarified
that add-to-list is not good for variables bound by a let statement and
that this was the reason.

I was speculating that there was an execution speed issue, and on top of
that I had misunderstood that pushnew checks duplication against the
whole list. That is why I had proposed a revision.

> 
> If there's something else I have to do, please tell me.

Indeed, this revision which I had proposed seems to be useless as far as
execution speed is concerned --- at least that was not why Stefan did
the change, and nobody had complained.

However it still have some added value in terms of warning the user in
case that a duplicate node name is detected.

So, I am not really opinionated whether this further change is needed,
it is up to you...

Please note that I have just made some evaluation of the speed
difference for 1225 nodes in a file that contrains only @node
statements, on my machine the current implementation takes 0.04s, while
the proposed revision 0.01s, although it is 4 times as fast, I cannot
say that speed on its own is an issue worth the change. All the more
that the difference would certainly be smaller in a buffer where nodes
are not empty.

VBR,
    Vincent Belaïche                                      


reply via email to

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