* new elpa packages for ada-mode project related stuff @ 2019-01-16 18:57 Stephen Leake 2019-01-16 19:18 ` Stefan Monnier 2019-01-17 2:31 ` Dmitry Gutov 0 siblings, 2 replies; 6+ messages in thread From: Stephen Leake @ 2019-01-16 18:57 UTC (permalink / raw) To: emacs-devel I'd like to create one or more new ELPA packages to support the ada-mode project code. The new files are: env-project.el -- 70 lines Adds three new project defgenerics: project-refresh project-select project-deselect These should be in project.el in some future version of emacs. Then defines a project defstruct that declares/undeclares environment variables when it is selected/deselected. ada-mode project inherits this. path-iterator.el -- 243 lines Provides an iterator for directory paths; returns one file at a time. Handles a mix of flat and recursive directories. Probably should be rewritten to use generator.el. uniquify-files.el -- 687 lines Provides a completion style and completion table that presents uniquified file names to the user for completion. Uses path-iterator.el ada-mode project-file-completion-table uses this. Ok to create these ELPA packages (in elpa/packages)? -- -- Stephe ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: new elpa packages for ada-mode project related stuff 2019-01-16 18:57 new elpa packages for ada-mode project related stuff Stephen Leake @ 2019-01-16 19:18 ` Stefan Monnier 2019-01-16 21:43 ` Stephen Leake 2019-01-17 2:31 ` Dmitry Gutov 1 sibling, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2019-01-16 19:18 UTC (permalink / raw) To: emacs-devel > 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? IOW, I'd rather have a cl-generic `project-envvars` and then somehow make sure these envvars are passed to any sub-process. I often work on several projects basically at the same time in a single Emacs session, so manually "selecting" a project would be inconvenient. > 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)? Sounds fine to me. > Probably should be rewritten to use generator.el. I haven't seen the current code, so I don't know what it's using now instead of generator.el. > 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. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: new elpa packages for ada-mode project related stuff 2019-01-16 19:18 ` Stefan Monnier @ 2019-01-16 21:43 ` Stephen Leake 2019-01-17 1:41 ` Stefan Monnier 2019-01-17 13:22 ` Michael Heerdegen 0 siblings, 2 replies; 6+ messages in thread From: Stephen Leake @ 2019-01-16 21:43 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: new elpa packages for ada-mode project related stuff 2019-01-16 21:43 ` Stephen Leake @ 2019-01-17 1:41 ` Stefan Monnier 2019-01-17 13:22 ` Michael Heerdegen 1 sibling, 0 replies; 6+ messages in thread From: Stefan Monnier @ 2019-01-17 1:41 UTC (permalink / raw) To: emacs-devel >>> 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. This justifies the need to have a way to set which project to use currently for a library that can belong to several projects, but it doesn't justify making this be a global setting. So maybe I agree with your suggestion, but I object to the way it seems to have a global effect. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: new elpa packages for ada-mode project related stuff 2019-01-16 21:43 ` Stephen Leake 2019-01-17 1:41 ` Stefan Monnier @ 2019-01-17 13:22 ` Michael Heerdegen 1 sibling, 0 replies; 6+ messages in thread From: Michael Heerdegen @ 2019-01-17 13:22 UTC (permalink / raw) To: Stephen Leake; +Cc: emacs-devel Stephen Leake <stephen_leake@stephe-leake.org> writes: > >> 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. Can it be that this is quite similar to `iterator-of-directory-files' in iterators.el (and `stream-of-directory-files' in stream.el)? I don't want to say you should use these, I just want to raise the question. Michael. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: new elpa packages for ada-mode project related stuff 2019-01-16 18:57 new elpa packages for ada-mode project related stuff Stephen Leake 2019-01-16 19:18 ` Stefan Monnier @ 2019-01-17 2:31 ` Dmitry Gutov 1 sibling, 0 replies; 6+ messages in thread From: Dmitry Gutov @ 2019-01-17 2:31 UTC (permalink / raw) To: Stephen Leake, emacs-devel On 16.01.2019 21:57, Stephen Leake wrote: > I'd like to create one or more new ELPA packages to support the ada-mode > project code. > > The new files are: > > env-project.el -- 70 lines > Adds three new project defgenerics: > project-refresh > project-select > project-deselect > > These should be in project.el in some future version of emacs. I don't think so. project-refresh is debatable, but when would the user want to call it? There's no way for them to know. It'd be much better to use caches with proper automatic invalidation, e.g. with filenotify. IOW, I'd like to see the feature in the wild, in different project backends, and then we can incorporate it. But project-select and project-deselect, as previously discussed, can be implemented in terms of project-find-functions. If you and some other users find it handy to have an Emacs-wide global project and select it manually, be my guest, but please make it a globalized minor mode, and add a project-find-functions entry for it. The said minor mode can have its own commands to -select and -deselect. > Then defines a project defstruct that declares/undeclares > environment variables when it is selected/deselected. ada-mode project > inherits this. Err, I'd rather have it user explicitly in certain functions like Stefan discussed, rather than invisibly change env variables in the whole session. > path-iterator.el -- 243 lines > Provides an iterator for directory paths; returns one file at a > time. Handles a mix of flat and recursive directories. > Probably should be rewritten to use generator.el. Why an iterator, though? And not just a list? If it's used in a completion table, surely the whole sequence will have to be realized anyway the first time user types TAB. > uniquify-files.el -- 687 lines > Provides a completion style and completion table that presents > uniquified file names to the user for completion. > Uses path-iterator.el > ada-mode project-file-completion-table uses this. I wrote my feelings on that subject in a separate email. A neat feature, I'm sure, but I'd prefer if it were implemented in a radically different way. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-01-17 13:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-01-16 18:57 new elpa packages for ada-mode project related stuff Stephen Leake 2019-01-16 19:18 ` Stefan Monnier 2019-01-16 21:43 ` Stephen Leake 2019-01-17 1:41 ` Stefan Monnier 2019-01-17 13:22 ` Michael Heerdegen 2019-01-17 2:31 ` Dmitry Gutov
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).