emacs-devel
[Top][All Lists]
Advanced

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

Re: new elpa packages for ada-mode project related stuff


From: Stephen Leake
Subject: Re: new elpa packages for ada-mode project related stuff
Date: Wed, 16 Jan 2019 13:43:24 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt)

Stefan Monnier <address@hidden> writes:

>>     Then defines a project defstruct that declares/undeclares
>> environment variables when it is selected/deselected.
>
> Shouldn't the right env-var simply be automatically selected based on
> the project of the current buffer?

Depends on the use case. I have several worktrees that are nominally in
several projects; they are utility libraries, so they can be accessed
via any project that uses them, and they also have test suites, so they
have a project of their own.

There is no way to identify the current client project from a utility
library buffer, so I rely on a global setting.

In addition, it is the act of selecting each project the first time that
sets the appropriate environment variable (in this case, giving the
path containing the appropriate versions of utility libraries).

> IOW, I'd rather have a cl-generic `project-envvars` and then somehow
> make sure these envvars are passed to any sub-process.

That makes sense. ada-mode projects support that, but I haven't had the
need for a project level generic function yet.

> I often work on several projects basically at the same time in a single
> Emacs session, so manually "selecting" a project would be
> inconvenient.

Right. That mode should certainly be supported.

>> path-iterator.el -- 243 lines
>>     Provides an iterator for directory paths;
>
> You mean something similar to locate-file (but returning "all matches"
> and in the form of an iterator)?  

Yes.

>> uniquify-files.el -- 687 lines
>>     Provides a completion style and completion table that presents
>>     uniquified file names to the user for completion.
>
> Sounds cool.
>
>> Ok to create these ELPA packages (in elpa/packages)?
>
> The usual answer for this question is "yes".  If you're unsure, making
> it an "external" (rather than a plain directory inside `packages`) makes
> it easy to get rid of it without leaving traces in the Git history.

Ok. Since env-project is somewhat controversial, I'll just include that
in the ada-mode elpa project for now; we can split it out later if that
seems useful.

-- 
-- Stephe



reply via email to

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