Hi Ships:
On Mon, Jan 20, 2025 at 03:03:59PM -0500, Ship Mints wrote:
>I like the idea of "project tasks" and I'm not really sure what the name
>"multi" is supposed to suggest. project-task seems closer to what this is
>trying to support.
The name project-multi is because it adds support for multiple project
types (cmake, meson, automake, etc).
project-multi is a personal tool, and I showed it as a POC on how the
proposed api function could be used, I don't even share it in elpa o
melpa.
>
>I took a quick look at the patch and at your project-multi-mode package.
>The biggest thing that stood out to me is that all settings are global,
>when I think they should be project specific.
None of the settings are global at all. Actually the patch to project.el
was made explicitly to allow project specific, directory-local,
connection-local or even buffer-local values throw a single variable:
`project-extra-info'.
The only global variable in project-multi is project-multi--alist (which
is an internal var, not a custom), and it is actually a "cache"" to
emulate the "project-local" behavior you mention. This alist has the
project root as a key and the associated value is a plist of
project-specific information. This is similar to how connection-local
variables work internally, but for projects.
In fact, I use project-multi daily with 3 simultaneos projects, one of
them in a remote host.
The code in project-multi is eplicitly designed to manage multiple and
remote project efficiently (avoid redundant root searches in the
storage, memoize values by host and project-roots, avoid redundant calls
to find-executable or locate-dominating-file).
But also to respect directory-local or connection-local variables if
they are set.
>If I were to use project tasks, I'd configure them as I configure eglot
>for each project subtree: using dir locals.
You can do that in project.el with the given patch, and that's what I
actually do :)
Set the `project-extra-info' variable to:
(setq project-extra-info
'(:compile-command "command" :test-command "other command"))
You can do it in a connection-local:
(connection-local-set-profile-variables
'my/host-profile
'(project-extra-info . (:compile-command "command" :test-command
"other command")))
(connection-local-set-profiles '(:application tramp :host "yourhost")
'my/host-profile)
Or directory-local in .dir-locals.el
(project-extra-info . (:compile-command "command" :test-command "other
command"))
Or buffer-local in the file footer comment
As the docstring in the patch explains, the variable takes precedence
over any backend defined function.
>I do have a default global eglot configuration for
>various languages but that's a convenience and not something I'd want to
>rely on as part of a generally self-contained project and one that
>gets shared among team members, all of whom have different personal Emacs
>configurations.
>
>Many projects are multi-language and monorepos for larger projects tend to
>have quite varying content and tooling requirements including some that
>conflict with one another. A server component team uses different
>linting/formatting rules and stricter tests than a front-end component
team
>which tends to be higher velocity. For project-task to be effective for
>more complex projects, it would have to support dir locals, right?
project-multi has no customs, so, not sure what you plan to configure in
dir-locals.
The current project.el has difficulties working with multiple
roots. However, project-multi goes around that issue and supports
multiple backends/roots for a given file.
In project-multi I define the project (what returns project-current) as
a plist: That plist actually contains project-specific values like
:name, :root, :backend, and there is an :others entry to list other
backends in the same root.
For example, one project could have a cmake backend, but usually has
git, in this case cmake will be the :backend but git will be one of the
:others. When cmake does not bring information for a project-command,
then project-multi attempts to use the other backends (for example a
cmake backend does not give information about all the files for
project-files, but git does)
Best,
Ergus
>
>On Sun, Jan 19, 2025 at 7:53 PM Ergus <spacibba@aol.com> wrote:
>
>> Hi:
>>
>> Please find attached a proposed patch to add the command project-tests
>> to project.el. Documentation is still missing and Dmitry may remember we
>> were talking about this a while ago. But I bring it back again.
>>
>> The main idea is to give a customization variable for the user and a
>> cl-generic for backend developers in order to modify/specify the
>> project-compile command and (the new added) project-test one. But also
>> allow to extend for more commands in the future with very little code.
>>
>> The idea is that any external project.el backend could "construct"
>> complex build and test commands with the extra information if should
>> hold. But also, if the user wants to specify them as dir-local he could
>> do it very easily as well.
>>
>> The actual patch does not modifies the current behavior, but will allow
>> to extend project.el externally (for example, to support different build
>> systems)
>>
>> See an example: https://github.com/Ergus/project-multi-mode
>>
>> That's a simple backend that uses this new "api" to offer a transparent
>> experience for compile backends in less than 400 lines (including
>> documentation and header).
>>
>> Best,
>> Ergus
>>
>>