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

Previous Next

To reply to this bug, email your comments to 59502 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gabriel <gabriel376 <at> hotmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Dedicated buffers per project
Date: Wed, 23 Nov 2022 02:11:36 -0300

[Message part 1 (text/plain, inline)]

Severity: wishlist

Description:

Currently, xref commands in project.el (`project-find-regexp' and
`project-or-external-find-regexp') use a "default" xref buffer (through
a call to `xref-show-xrefs').  It's a "default" buffer because it uses a
constant name ("*xref*") for the xref buffers created (see
`xref-buffer-name').

If a user is working with two or more projects, any xref command will
override a previous "*xref*" buffer.  Thus, it's required that the user
first manually rename any existing xref buffer prior to executing a new
xref command, in order to keep the xref buffers of other projects.  The
same is true for "*Buffer List*", "*Shell Command Output*" and "*Async
Shell Command*" buffers.

Currently, project.el already support prefix names for compilation,
shell and eshell commands (see `project-prefixed-buffer-name' and
`project-compilation-buffer-name-function').  The "*vc-dir*" buffer
created by `project-vc-dir' is handled by uniquify.el
(`vc-dir-prepare-status-buffer' uses `create-file-buffer').

In summary, project.el currently has the following behavior and
customization options:

| Project Command                   | Generated Buffer         | Current Behavior              | Customization Options                      |
|-----------------------------------+--------------------------+-------------------------------+--------------------------------------------|
| `project-find-regexp'             | "*xref*"                 | Use a default buffer          | Not available                              |
| `project-or-external-find-regexp' | "*xref*"                 | Use a default buffer          | Not available                              |
| `project-list-buffers'            | "*Buffer List*"          | Use a default buffer          | Not available                              |
| `project-kill-buffers'            | "*Buffer List*"          | Use a default buffer          | Not available                              |
| `project-shell-command'           | "*Shell Command Output*" | Use a default buffer          | Not available                              |
| `project-async-shell-command'     | "*Async Shell Command*"  | Use a default buffer          | Not available                              |
| `project-compile`                 | "*compilation*"          | Use a default buffer          | `project-compilation-buffer-name-function' |
| `project-vc-dir'                  | "*vc-dir*"               | Use a default buffer          | Through uniquify.el defcustom's            |
| `project-shell'                   | "*shell*"                | Use a project prefixed buffer | Not available                              |
| `project-eshell'                  | "*eshell*"               | Use a project prefixed buffer | Not available                              |

My suggestion is to improve the consistency of how project-related
buffers are created and named, providing sufficient customization
options for users.

Solutions:

1) Make all project-related buffers use by default
`project-prefixed-buffer-name'.  This is similar to how `project-shell'
and `project-eshell' behaves today.  The downsides are the lack of
customization options for users and the introduction of behavior changes
related to how some project-related buffers are currently named.

2) Create dedicated defcustom's for each project-related buffer.  This
is similar to how `project-compile' behaves today, by allowing users to
customize the option `project-compilation-buffer-name-function'.  The
downside is the excessive number of new defcustom's.

3) Create a single defcustom to compute the name of project-related
buffers.  This is similar to how `project-compile' behaves today, but
would be a more general-purpose customization option.  This is currently
my preferred solution (see the attached patch).  I tried to make it
simple, consistent and without introducing behavior changes related to
how project-related buffers are currently named, but I am not really
happy with the implementation.  An example of how users could customize
this option is presented below:

(setopt project-buffer-name-function
        (lambda (name)
            (format "*%s-%s*"
                    (project-name (project-current))
                    name)))

[0001-Add-user-option-project-buffer-name-function.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Please share your comments or suggestions.

---
Gabriel

Message #8 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Fri, 25 Nov 2022 03:37:09 +0200

Hi!

On 23/11/22 07:11, Gabriel wrote:
> In summary, project.el currently has the following behavior and
> customization options:
> 
> | Project Command                   | Generated Buffer         | Current Behavior              | Customization Options                      |
> |-----------------------------------+--------------------------+-------------------------------+--------------------------------------------|
> | `project-find-regexp'             | "*xref*"                 | Use a default buffer          | Not available                              |
> | `project-or-external-find-regexp' | "*xref*"                 | Use a default buffer          | Not available                              |
> | `project-list-buffers'            | "*Buffer List*"          | Use a default buffer          | Not available                              |
> | `project-kill-buffers'            | "*Buffer List*"          | Use a default buffer          | Not available                              |
> | `project-shell-command'           | "*Shell Command Output*" | Use a default buffer          | Not available                              |
> | `project-async-shell-command'     | "*Async Shell Command*"  | Use a default buffer          | Not available                              |
> | `project-compile`                 | "*compilation*"          | Use a default buffer          | `project-compilation-buffer-name-function' |
> | `project-vc-dir'                  | "*vc-dir*"               | Use a default buffer          | Through uniquify.el defcustom's            |
> | `project-shell'                   | "*shell*"                | Use a project prefixed buffer | Not available                              |
> | `project-eshell'                  | "*eshell*"               | Use a project prefixed buffer | Not available                              |
> 
> My suggestion is to improve the consistency of how project-related
> buffers are created and named, providing sufficient customization
> options for users.

This is a nice initiative, and the patch you sent seems to handle most 
of the technical issues.

There's one thing, though: some of these buffers might only start to be 
project-related, but then "relate" to some different project a little 
after. Buffers such as Dired, Shell and Eshell.

For the rest, this probably makes sense. I do wish we had an "upvote" 
button on these threads, to see how many people are interested in this.

Anyone would like to +1?

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gabriel <gabriel376 <at> hotmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Thu, 24 Nov 2022 23:55:19 -0300

Dmitry Gutov <dgutov <at> yandex.ru> writes:

>
> This is a nice initiative, and the patch you sent seems to handle most of the
> technical issues.
>
> There's one thing, though: some of these buffers might only start to be
> project-related, but then "relate" to some different project a little
> after. Buffers such as Dired, Shell and Eshell.
>
> For the rest, this probably makes sense. I do wish we had an "upvote" button on
> these threads, to see how many people are interested in this.
>
> Anyone would like to +1?

Hi Dmitry,

I agree, some buffers (Shell, Eshell and Dired) allows the user to
navigate to a different location, which would move away from the
starting project.

For Shell and Eshell buffers, the tentative patch in this bug report do
not change the current behavior (which uses
project-prefixed-buffer-name).  For Dired buffers, the buffer name is
not explicitly handled by project.el (can be controlled via
uniquify.el).

I don't have a good answer on how to properly handle these cases.  A
possible approach would be to monitor for location changes on these
buffers (e.g.: via hooks or advices) and to update the buffer name
accordingly, but seems to be an overkill.  My suggestion is to leave
this small inconvenience (buffer name and location out-of-sync) as it is
today.

The good news is that project.el already properly handles the cases when
the buffer location is moved away from a project (e.g.: project-dired,
project-find-dir, project-switch-to-buffer, project-list-buffers,
project-kill-buffers etc), since buffer names do not really mater (only
its real location).

---
Gabriel

Message #14 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: daanturo <daanturo <at> gmail.com>
To: dgutov <at> yandex.ru
Cc: 59502 <at> debbugs.gnu.org
Subject: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Fri, 25 Nov 2022 14:09:47 +0700

> I do wish we had an "upvote" button on these threads

+1 from me.

IMO stuffs like this, along with REPL buffers should be project-dedicated by
default.

I think once this get merged, individual major mode's REPL buffer should start
adopting it (by taking the customized value), rather than creating a new
variable to set for each programming language like `python-shell-dedicated`,
`geiser-repl-per-project-p`, etc.

-- 
Daanturo.

Message #17 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Fri, 25 Nov 2022 09:14:17 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> For the rest, this probably makes sense. I do wish we had an "upvote"
> button on these threads, to see how many people are interested in
> this.
>
> Anyone would like to +1?

👍

I'd say solution 3) is the one I'm most attracted to.

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.

FWIW I think the "serving suggestion" from the OP…

> (setopt project-buffer-name-function
>         (lambda (name)
>             (format "*%s-%s*"
>                     (project-name (project-current))
>                     name)))

… would make sense as a defcustom alternative (and could then be re-used
by project-buffer-name-default).

Thanks Gabriel!

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gabriel <gabriel376 <at> hotmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Fri, 25 Nov 2022 10:27:59 -0300

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> 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:

| Command                     | major-mode       |
|-----------------------------+------------------|
| project-shell-command       | fundamental-mode |
| project-async-shell-command | shell-mode       |

---
Gabriel

Message #23 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <salutis <at> me.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Gabriel <gabriel376 <at> hotmail.com>,
 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Mon, 05 Dec 2022 00:50:37 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> [...] I do wish we had an "upvote" button on these threads, to see how
> many people are interested in this.
>
> Anyone would like to +1?

+1, and especially for the compilation buffer (which I keep renaming
multiple times every day, even though Emacs knows its project).

Rudy
-- 
"I love deadlines.  I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt, 2002

Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Message #26 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Mon, 5 Dec 2022 04:35:21 +0200

Hi again!

On 23/11/2022 07:11, Gabriel wrote:
> 3) Create a single defcustom to compute the name of project-related
> buffers.  This is similar to how `project-compile' behaves today, but
> would be a more general-purpose customization option.  This is currently
> my preferred solution (see the attached patch).  I tried to make it
> simple, consistent and without introducing behavior changes related to
> how project-related buffers are currently named, but I am not really
> happy with the implementation.  An example of how users could customize
> this option is presented below:
> 
> (setopt project-buffer-name-function
>          (lambda (name)
>              (format "*%s-%s*"
>                      (project-name (project-current))
>                      name)))

A couple more thoughts: the buffer name function will generally be used 
before the buffer is created. The value of default-directory might even 
be wrong.

But even if it's not, some project backends might choose to enable or 
disable themselves based on the value of the major mode, which at the 
time that the function is called, might not be set yet.

Which is to say, it might be handy to have the project instance passed 
to this function as an argument, rather than have it looked up again.

Does it look feasible to you in most cases? If yes, we could rethink the 
story with project-compilation-buffer-name-function. Perhaps make it a 
function which returns a function.

Message #29 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Gabriel <gabriel376 <at> hotmail.com>
Cc: 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Tue, 06 Dec 2022 19:21:50 +0200

>> 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")))

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))))

Message #32 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Tue, 06 Dec 2022 19:23:27 +0200

>> (setopt project-buffer-name-function
>>          (lambda (name)
>>              (format "*%s-%s*"
>>                      (project-name (project-current))
>>                      name)))
>
> A couple more thoughts: the buffer name function will generally be used
> before the buffer is created. The value of default-directory might even be
> wrong.

I haven't tried the proposed patch yet.  But it would be interesting to
guess how it will behave with 'C-x p p ...'.  Do you think it will get
the project name from the original project, or from another project
where it switches to?

Message #35 received at 59502 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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?

Message #38 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Wed, 7 Dec 2022 04:35:35 +0200

On 06/12/2022 19:23, Juri Linkov wrote:
>>> (setopt project-buffer-name-function
>>>           (lambda (name)
>>>               (format "*%s-%s*"
>>>                       (project-name (project-current))
>>>                       name)))
>> A couple more thoughts: the buffer name function will generally be used
>> before the buffer is created. The value of default-directory might even be
>> wrong.
> I haven't tried the proposed patch yet.  But it would be interesting to
> guess how it will behave with 'C-x p p ...'.

More testing is welcome.

> Do you think it will get
> the project name from the original project, or from another project
> where it switches to?

It all depends on what's in project-find-functions. With project-vc it 
will probably work as expected (module the problem that was brought up 
in bug#59722, but we'll need to fix that separately anyway), but it can 
behave unexpectedly with more complex project-finding logic, like the 
one favored by Stephen L. or Eli Z., where belonging to a project is not 
defined by the directory only. But possibly by the major mode as well.

And I'm guessing project-buffer-name-function will usually be called 
before the major mode is set.

Message #41 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Wed, 07 Dec 2022 09:50:14 +0200

>> (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?

For designing a naming scheme, I suggest to keep in mind that
the users might already have customized the behavior for
displaying these buffers by using display-buffer-alist
that often takes into account a uniquified suffix, e.g.:

  "\\`\\*\\(?:Shell Command Output\\|xref\\|vc-dir\\|compilation\\)
      \\*\\(?:<[^>]+>\\)?\\'"

So for compatibility it would be better to add the project name
in the suffix without changing the standard base buffer names, e.g.:

  "*Shell Command Output*<project-a>", "*xref*<project-b>"

But if you want to add the project name after the first asterisk,
this is easy to do as well with just:

  (setf (substring buffer-name 1 1) (project-name project))

Message #44 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Sat, 10 Dec 2022 03:50:56 +0200

On 07/12/2022 09:50, Juri Linkov wrote:
>>> (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?
> For designing a naming scheme, I suggest to keep in mind that
> the users might already have customized the behavior for
> displaying these buffers by using display-buffer-alist
> that often takes into account a uniquified suffix, e.g.:
> 
>    "\\`\\*\\(?:Shell Command Output\\|xref\\|vc-dir\\|compilation\\)
>        \\*\\(?:<[^>]+>\\)?\\'"
> 
> So for compatibility it would be better to add the project name
> in the suffix without changing the standard base buffer names, e.g.:
> 
>    "*Shell Command Output*<project-a>", "*xref*<project-b>"
> 
> But if you want to add the project name after the first asterisk,
> this is easy to do as well with just:
> 
>    (setf (substring buffer-name 1 1) (project-name project))

The naming scheme is often affected by the uniquify package, and 
different people use different ordering. Should we really go there?

Message #47 received at 59502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Gabriel <gabriel376 <at> hotmail.com>, 59502 <at> debbugs.gnu.org
Subject: Re: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Sat, 10 Dec 2022 19:34:20 +0200

>>>> (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?
>> For designing a naming scheme, I suggest to keep in mind that
>> the users might already have customized the behavior for
>> displaying these buffers by using display-buffer-alist
>> that often takes into account a uniquified suffix, e.g.:
>>    "\\`\\*\\(?:Shell Command Output\\|xref\\|vc-dir\\|compilation\\)
>>        \\*\\(?:<[^>]+>\\)?\\'"
>> So for compatibility it would be better to add the project name
>> in the suffix without changing the standard base buffer names, e.g.:
>>    "*Shell Command Output*<project-a>", "*xref*<project-b>"
>> But if you want to add the project name after the first asterisk,
>> this is easy to do as well with just:
>>    (setf (substring buffer-name 1 1) (project-name project))
>
> The naming scheme is often affected by the uniquify package, and different
> people use different ordering. Should we really go there?

It was an example of my customization preference.  So anyone can
customize project-buffer-name-function to comply with own
uniquification scheme.  My point was to ensure that
project-buffer-name-function should support any format.

Previous Next

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