From: Dmitry Gutov <dgutov@yandex.ru>
To: Gabriel <gabriel376@hotmail.com>, 59502@debbugs.gnu.org
Subject: bug#59502: 29.0.50; [PATCH] Dedicated buffers per project
Date: Mon, 5 Dec 2022 04:35:21 +0200 [thread overview]
Message-ID: <93661c9e-c754-0fcf-1eb9-7a5479aedbd5@yandex.ru> (raw)
In-Reply-To: <SJ0PR06MB86090A147EE6E14492A051198B0C9@SJ0PR06MB8609.namprd06.prod.outlook.com>
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.
next prev parent reply other threads:[~2022-12-05 2:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 5:11 bug#59502: 29.0.50; [PATCH] Dedicated buffers per project Gabriel
2022-11-25 1:37 ` Dmitry Gutov
2022-11-25 2:55 ` Gabriel
2022-11-25 8:14 ` Kévin Le Gouguec
2022-11-25 13:27 ` Gabriel
2022-12-06 17:21 ` Juri Linkov
2022-12-07 2:31 ` Dmitry Gutov
2022-12-07 7:50 ` Juri Linkov
2022-12-10 1:50 ` Dmitry Gutov
2022-12-10 17:34 ` Juri Linkov
2022-12-04 23:50 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-25 7:09 ` daanturo
2022-12-05 2:35 ` Dmitry Gutov [this message]
2022-12-06 17:23 ` Juri Linkov
2022-12-07 2:35 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=93661c9e-c754-0fcf-1eb9-7a5479aedbd5@yandex.ru \
--to=dgutov@yandex.ru \
--cc=59502@debbugs.gnu.org \
--cc=gabriel376@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.