From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH v2] ox: Cache locations of fuzzy links Date: Thu, 02 May 2013 14:35:50 +0200 Message-ID: <8738u5imop.fsf@gmail.com> References: <877gjnojsq.fsf@Rainer.invalid> <5654CA29-5F6D-4E8B-8B8B-C3609D76D189@gmail.com> <8761z5gw6w.fsf@gmx.li> <87zjwhxjla.fsf@Rainer.invalid> <87bo8uyjtc.fsf_-_@gmx.li> <87vc72idau.fsf@gmail.com> <874nelycry.fsf_-_@gmx.li> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:60524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXsjt-00039J-Ni for emacs-orgmode@gnu.org; Thu, 02 May 2013 08:35:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXsjn-0002io-BP for emacs-orgmode@gnu.org; Thu, 02 May 2013 08:35:57 -0400 Received: from mail-wg0-x236.google.com ([2a00:1450:400c:c00::236]:39651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXsjm-0002iO-Pi for emacs-orgmode@gnu.org; Thu, 02 May 2013 08:35:51 -0400 Received: by mail-wg0-f54.google.com with SMTP id x12so504509wgg.33 for ; Thu, 02 May 2013 05:35:50 -0700 (PDT) In-Reply-To: <874nelycry.fsf_-_@gmx.li> (Lawrence Mitchell's message of "Thu, 02 May 2013 10:03:13 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Lawrence Mitchell Cc: emacs-orgmode@gnu.org Hello, Lawrence Mitchell writes: > * ox.el (org-export-resolve-fuzzy-link): Look for fuzzy link in a > cache before trying to resolve it in the parse tree. > > When a document contains a large number of identical fuzzy links, it > doesn't make sense to continually search for them. Instead, cache the > locations in the position independent case. > --- > lisp/ox.el | 42 +++++++++++++++++++++++++++++------------- > 1 file changed, 29 insertions(+), 13 deletions(-) > > Changes since v1: > > - Pull initialisation of link-cache into let > - Don't use cons cells for keys, just use the path > - lift found check to top-level let since it's now common Thanks for the changes. > I've made this change. Barring the eq test. > > Remember, paths are strings and two strings are only eq or eql if > they are actually the same string (in memory). In particular: > > (let ((p "foo")) (eq (substring p 1) (substring p 1))) => nil > (let ((p "foo")) (eql (substring p 1) (substring p 1))) => nil > (let ((p "foo")) (equal (substring p 1) (substring p 1))) => t > > Hence, we must use equal or string-equal as a test in the hash > table. But string-equal isn't a predefined test, hence equal. Sorry for being dense, but why do you use _path_, which is a string and, as you say, requires `equal' for equality, instead of the first argument of the function, i.e. _link_, which only needs `eq'? Regards, -- Nicolas Goaziou