bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#41890: 28.0.50; [PATCH]: Add bindings for project.el


From: Philip K.
Subject: bug#41890: 28.0.50; [PATCH]: Add bindings for project.el
Date: Fri, 19 Jun 2020 12:26:45 +0200

Simen Heggestøyl <simenheg@runbox.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 18.06.2020 17:09, Philip K. wrote:
>>
>>> The patch below fixes that, but allows changing if you only want the
>>> listed keys to be valid (the default) or every key in
>>> project-prefix-map.
>>> It turned out that the transiment map approach didn't work, as it
>>> ignored the value in default-directory, thus running all commands in
>>> whatever the current project was.
>>
>> Looks reasonable to me. But let's also hear from the original author.
>>
>> Simen, what do you think? The patch is at
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41890#127.
>
> Looks good to me too!
>
> My only gripe would be that it makes it a bit harder to add new
> commands, since it now requires modifying both project-switch-commands
> and project-prefix\-map. 

As in for developers, when they want to contribute a new project-*
function or users who want to just change stuff (I know the line might
be blury)?

> Maybe we could reintroduce the helper function we had for that purpose
> earlier.

I missed when this happened. In what commit was it removed, or was it
just in a patch?

> -(defvar project-switch-commands
> -  '((?f "Find file" project-find-file)
> -    (?g "Find regexp" project-find-regexp)
> -    (?d "Dired" project-dired)
> -    (?v "VC-Dir" project-vc-dir)
> -    (?e "Eshell" project-eshell))
> -  "Alist mapping keys to project switching menu entries.
> +(defcustom project-switch-commands
> +  '((project-find-file . "Find file")
> +    (project-find-regexp . "Find regexp")
> +    (project-dired . "Dired")
> +    (project-vc-dir . "VC-Dir")
> +    (project-shell . "Shell")
> +    (project-eshell . "Eshell"))
>
> The project-shell command is added here, don't know if that was
> intentional?

No, this must have been a local git mistake.

> Also why not stick with the easier extensible list format? I could
> imagine for instance adding long descriptions as an optimal third
> element for the commands later on.

The main reason I changed it was so that the alist was recognized as an
alist in customize, but I agree that changing this would be good for
forwards compatibility.

-- 
        Philip K.





reply via email to

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