From: Dmitry Gutov <dgutov@yandex.ru>
To: Stephen Leake <stephen_leake@stephe-leake.org>, emacs-devel@gnu.org
Subject: Re: Unified project interface
Date: Sat, 1 Aug 2015 03:57:32 +0300 [thread overview]
Message-ID: <55BC197C.3050006@yandex.ru> (raw)
In-Reply-To: <868u9wz4mw.fsf@stephe-leake.org>
On 07/31/2015 07:13 PM, Stephen Leake wrote:
> I often want to look at project.el (or xref.el, ada-mode.el, etc); I
> bind this function (currently using load-path) to M-F12, so M-F12
> proj <ret> finds it for me easily.
To reach the same result, I currently either use ido-switch-buffer (with
ido-use-virtual-buffers set to t) or projectile-find-file (which asks
the user to choose between files in the project, based on file names
relative to the root). The key thing here is substring matching: I also
simply type "project." and see lisp/progmodes/project.el as the only
completion.
Using relative paths also helps with navigating to files with the same
name inside different directories.
> Which is faster/friendlier depends on the details, so we'll have to wait
> for actual implementations. All I'm asking is that we do not make design
> decisions at the generic project API level that rule out this approach.
We do have to make some decisions, though. For instance, supporting both
recursive and non-recursive elements in search-path will require a
separate code path for each function that uses it.
As such, it will require a separate code path in xref-collect-matches
and an alternative for xref--rgrep-command.
>> There are many directories inside /usr/include, but C_INCLUDE_PATH
>> won't mention most of them. Instead, #include <postgresql/pg_config>
>> will use /usr/include/postgresql/pg_config.h, as long as /usr/include
>> is in C_INCLUDE_PATH.
>
> Yes. So if the user wants to search all relevant includes for some
> declaration, they have to treat C_INCLUDE_PATH as recursive. But the
> compiler (which _defines_ C_INCLUDE_PATH) does _not_ treat it as
> recursive. So it's confused.
We need to search files in subdirectories as well, and that is the key
distinction.
The fact that compiler treats the roots in a special way, however, can
be important. Because of that, the list of roots contains information
that can be lost after a naive translation to a list of "flat"
directories. For instance, if you have the roots, you can search them
linearly and tell whether there's a file corresponding to
'postgresql/pg_config' inside one of them.
With a flat list, we could only give an imprecise answer to that
question, and the search might have to perform extra work.
> I think cedet is the only exception to the 'flat load-path' rule (at
> least in core emacs); I hope it goes away, and is not copied by other
> projects.
Even though it's not very popular, it's unlikely to go away. But in any
case, the corresponding path variables in all other ecosystems that I
know of (Ruby, Python, Java, Node.js) follow in the footsteps of C and
Emacs.
And the principle of translating qualified package (or module, or class)
names to file names is quite pervasive.
Ada is an exception, rather than the rule.
> I would provide a special syntax to handle this in
> project-add-search-path:
>
> (defun project-add-search-path (project path &optional make-recursive)
> "Add PATH (a list of directories) to the search path for PROJECT.
>
> If a directory in PATH ends in \"/**\", also add all directories under
> that directory.
>
> If MAKE-RECURSIVE is non-nil, the full project search path is pruned so
> that only highest-level directories are present, and all uses of
> `project-search-path' recurse into subdirectories. In this case, it is
> likely you will also need to specify ignored directories with
> `project-add-ignores'.
This description explains the purpose, but doesn't describe the
resulting data structure that would hold that information. The ones that
come to mind are rather ugly.
> If MAKE-RECURSIVE is nil, uses of `project-search-path' no not recurse
> into subdirectories."
> ... )
>
> The Ada project files support the ** sytnax.
The /** syntax is rather nifty. But why do you propose to have it and
MAKE-RECURSIVE at the same time? We could just interpret /** as the
recursive marker. Then the result could be a list of strings.
> This could be handled if the user can explicitly specify project ignores
> (not just rely on .gitignore etc; git does _not_ ignore the lisp-emacs-*
> and ada directories). More complicated structures are harder to handle
> with ignores; you'll end up with a long flat list of ignores, so it
> might be simpler to have a flat list of includes instead.
I've just started to write about this... Yes indeed, I think every flat
structure can be translated into path/to/dir, plus path/to/dir/*/ in the
ignores. The translation function shouldn't take too much work to write.
There's no need to produce the list of ignores manually. The Ada project
backend could do that for the user. And if the list is long... first,
you can use wildcards. Second, at least xref-collect-matches won't have
to handle the flat case specially. Nor will the other consumers of the
project API.
> It would be surprising to an Ada user (used to flat search paths), if the
> Emacs project silently started using recursive search paths.
The Ada project implementation can provide a friendlier interface/set of
customizations/etc for Ada users. Different communities are used to
different things. Any default would be surprising to someone.
>>> It is not at all clear how to convert a flat path into a recursive path
>>> with ignores; the solution you have for elisp load-path is a kludge,
>>> and could easily be wrong for some users.
>>
>> I'd like to see one of those users first.
>
> Me, and many other teams at NASA - structures similar to the above,
> where the non-included directories can also be release version,
> debug/release options, target hardware/os option, compiler
> vendor/version, etc.
There can be different opinions about this. As a project maintainer, I'd
rather be able to find all references to the function foo, no matter the
target OS of the code, or the targeted compiler version.
> The jdee project has lisp and java directories.
The Java class path is also "recursive".
> The kludge is in the root implementation of project-search-path, so it
> applies to all project backends that only customize
> project-search-path-function.
Please, stop calling major modes that do that "project backends".
Customizing project-search-path-function does not constitute one.
A real backend can always override project-search-path (and smart ones
should).
>>> So move it to "location" instead of "xref". The longest journey starts
>>> with one step ...
>>
>> Until it's used in at least two different places, creating a separate
>> package for it is, I think, premature.
>
> Right. We now have those two places; xref-find-definitions,
> project-find-regexp.
Both still use xref for display. The location values aren't consumed by
anything else. So that's just one place.
> Although it would be even better if project-find-regexp uses the compile
> location data structure wrapped in a location-compile class, derived
> from the root location class, renamed from xref-location.
You're welcome to explore this direction with code.
next prev parent reply other threads:[~2015-08-01 0:57 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 11:43 Unified project interface Dmitry Gutov
2015-06-04 14:40 ` Stephen Leake
2015-06-05 0:08 ` Dmitry Gutov
2015-06-05 10:08 ` Stephen Leake
2015-06-05 13:03 ` Stephen Leake
2015-06-05 13:14 ` Dmitry Gutov
2015-06-08 1:24 ` Stephen Leake
2015-06-09 18:16 ` Dmitry Gutov
2015-06-09 18:21 ` Eli Zaretskii
2015-06-09 18:49 ` Dmitry Gutov
2015-06-09 19:03 ` Eli Zaretskii
2015-06-07 23:22 ` Dmitry Gutov
2015-06-08 1:35 ` [SPAM UNSURE] " Stephen Leake
2015-06-09 19:04 ` Dmitry Gutov
2015-06-07 23:15 ` Dmitry Gutov
2015-06-08 1:59 ` Stephen Leake
2015-06-09 22:31 ` Dmitry Gutov
2015-06-10 7:13 ` Steinar Bang
2015-07-08 0:25 ` Dmitry Gutov
2015-07-11 13:43 ` Bozhidar Batsov
2015-07-11 14:17 ` Dmitry Gutov
2015-07-12 14:42 ` Dmitry Gutov
2015-07-13 8:49 ` Bozhidar Batsov
2015-07-13 10:23 ` Dmitry Gutov
2015-07-24 23:43 ` Dmitry Gutov
2015-07-25 0:55 ` Stephen Leake
2015-07-25 7:29 ` Eli Zaretskii
2015-07-26 2:12 ` Dmitry Gutov
2015-07-26 2:45 ` Eli Zaretskii
2015-07-26 11:25 ` Stephen Leake
2015-07-26 2:11 ` Dmitry Gutov
2015-07-26 11:22 ` Stephen Leake
2015-07-26 17:23 ` Dmitry Gutov
2015-07-26 18:57 ` Stephen Leake
2015-07-26 23:56 ` John Yates
2015-07-27 1:49 ` Dmitry Gutov
2015-07-27 11:12 ` Stephen Leake
2015-07-27 11:27 ` Dmitry Gutov
2015-07-27 13:00 ` Dmitry Gutov
2015-07-27 13:02 ` Dmitry Gutov
2015-07-28 1:21 ` Stephen Leake
2015-07-28 11:05 ` Stephen Leake
2015-07-28 14:33 ` Dmitry Gutov
2015-07-28 15:45 ` Stephen Leake
2015-07-28 16:25 ` Dmitry Gutov
2015-07-29 1:36 ` Stephen Leake
2015-07-29 2:10 ` Dmitry Gutov
2015-07-28 14:18 ` Dmitry Gutov
2015-07-28 16:15 ` Stephen Leake
2015-07-28 18:44 ` Dmitry Gutov
2015-07-29 2:27 ` Stephen Leake
2015-07-29 22:51 ` Dmitry Gutov
2015-07-30 8:17 ` Stephen Leake
2015-07-31 0:15 ` Dmitry Gutov
2015-07-31 16:13 ` Stephen Leake
2015-08-01 0:57 ` Dmitry Gutov [this message]
2015-08-01 9:50 ` Stephen Leake
2015-08-01 10:51 ` Stephen Leake
2015-08-01 12:42 ` Dmitry Gutov
2015-08-01 12:40 ` Dmitry Gutov
2015-08-01 14:15 ` Stephen Leake
2015-08-01 15:09 ` Dmitry Gutov
2015-08-01 19:04 ` Stephen Leake
2015-08-01 22:33 ` Dmitry Gutov
2015-08-01 1:14 ` Per-language project-search-path, was: " Dmitry Gutov
2015-08-01 10:43 ` Stephen Leake
2015-08-01 14:12 ` Dmitry Gutov
2015-08-01 18:57 ` Stephen Leake
2015-08-02 0:25 ` Dmitry Gutov
2015-08-02 2:29 ` Eric Ludlam
2015-08-02 8:57 ` Nix
2015-08-02 17:14 ` Michael Heerdegen
2015-08-02 23:09 ` Eric Ludlam
2015-08-02 23:39 ` Michael Heerdegen
2015-08-03 11:33 ` Eric Ludlam
2015-08-02 23:07 ` Dmitry Gutov
2015-08-03 10:24 ` Nix
2015-08-03 10:35 ` Dmitry Gutov
2015-08-07 15:25 ` Nix
2015-08-03 1:21 ` Dmitry Gutov
2015-07-29 23:11 ` xref display and multiple locations, " Dmitry Gutov
2015-06-06 10:20 ` Bozhidar Batsov
2015-06-06 10:29 ` Dmitry Gutov
2015-06-06 12:32 ` Eric Ludlam
2015-06-06 18:44 ` Dmitry Gutov
2015-06-06 19:28 ` Eli Zaretskii
2015-06-07 22:29 ` Dmitry Gutov
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=55BC197C.3050006@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=stephen_leake@stephe-leake.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.