GNU bug report logs - #59502
29.0.50; [PATCH] Dedicated buffers per project

Previous Next

Package: emacs;

Reported by: Gabriel <gabriel376 <at> hotmail.com>

Date: Wed, 23 Nov 2022 05:12:02 UTC

Severity: wishlist

Tags: patch

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, Gabriel <gabriel376 <at> hotmail.com>
Cc: 59502 <at> debbugs.gnu.org
Subject: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Wed, 7 Dec 2022 04:31:26 +0200
On 06/12/2022 19:21, Juri Linkov wrote:
>>> Idly wondering if it'd make sense to also pass the major-mode to
>>> project-buffer-name-function, since string matching might be unreliable
>>> in some situations?  Can't think of any concrete problem off the top of
>>> my head, I just have a vague expectation that mode symbols might be more
>>> stable than buffer names.  It's unsubstantiated though, so feel free to
>>> dismiss.
>>
>> I agree, and actually my first implementation used the major-mode symbol
>> as the argument to function project-buffer-name-function.  I changed to
>> a string to be able to handle the following cases:
> 
> A string is too confusing.  After seeing
> 
> +        (shell-command-buffer-name (funcall project-buffer-name-function
> +                                            "Shell Command Output")))

I think that's not too bad.

> the first thought was: why the buffer name is without asterisks
> as in the standard name "*Shell Command Output*".

>> | Command                     | major-mode       |
>> |-----------------------------+------------------|
>> | project-shell-command       | fundamental-mode |
>> | project-async-shell-command | shell-mode       |
> 
> More consistent would be to accept a symbol as the argument of
> project-buffer-name-function.  Then every project-supported command
> could have the corresponding symbol that is part of the command name:
> 
> | Command                     | name        |
> |-----------------------------+-------------|
> | project-shell-command       | shell       |
> | project-async-shell-command | async-shell |
> 
> Also for calling the user customized function it would be useful to
> provide an argument with the standard buffer name.  So users won't need
> to copy the mapping from project-buffer-name-default.  Then the default
> implementation will be just:
> 
> (defun project-buffer-name-default (project command-symbol buffer-name)
>    (or buffer-name (format "*%s-%s*" (project-name project) command-symbol)))
> 
> And here is an example of how I'd like to customize it:
> 
> (setopt project-buffer-name-function
>    (lambda (project _command-symbol buffer-name)
>      (format "%s<%s>" buffer-name (project-name project))))

I think *prjname/Shell Command Output* sounds nice enough.

If it doesn't, we probably wouldn't choose *Shell Command Output* as the 
name for non-project buffers of this type, would we?





This bug report was last modified 2 years and 190 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.