GNU bug report logs - #47799
28.0.50; Default `project-files' implementation doesn't work with quoted filenames

Previous Next

Full log

Message #35 received at 47799 <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 47799 <at> debbugs.gnu.org
Subject: Re: bug#47799: 28.0.50; Default `project-files' implementation
 doesn't work with quoted filenames
Date: Sun, 16 May 2021 15:37:07 +0200

> Am 19.04.2021 um 22:48 schrieb Dmitry Gutov <dgutov <at> yandex.ru>:
> 
> 
>> Rather than making assumptions in xref-matches-in-files, maybe we
>> could work more with relative filenames. For example:
>> 1. Add another project method "project-relative-files" that returns
>> filenames relative to the root. By default, this would call
>> project-files and make the filenames relative, but project
>> implementations can provide an optimized implementation.
>> 2. Give xref-matches-in-files an optional root directory argument and
>> allow users to pass names relative to that root.
>> Then I think both project and xref could leave these relative
>> filenames alone. WDYT?
> 
> We've discussed this before, but it's a change in the API, a +1 method for a very minor feature.
> 
> And how will we explain anyway that xref-matches-in-files, when called without the new ROOT argument, doesn't handle remote or quoted file names?
> 
> So if you can fix this to avoid performance loss in the general case, that would be a good improvement for now.

Yeah, I think you're right, we shouldn't complicate the API unnecessarily for optimization purposes.

One thing that came to my mind is: in general, in Elisp (not just XRef), we spend lots of time parsing filenames to support remote and quoted filenames.  Other languages probably solve this by introducing proper types for filenames (e.g. the Java Path class), which can then hold preprocessed information about the underlying filesystem (or special file name handler, in the case of Elisp).  How about doing similar for Elisp?  For example, introduce a `parsed-file-name' class or structure holding the remote/quoting state, or attach it to string properties?  I haven't tried out that idea, but I think it could significantly speed up the parsing (since we'd only have to do it once and don't have to search for filename handlers all the time), as well as remain backward-compatible to "plain" unparsed filenames by allowing both strings and this new object type.  WDYT?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.