GNU bug report logs - #21555
25.0.50; per-project *vc-change-log* buffers

Previous Next

To reply to this bug, email your comments to 21555 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Tom Tromey <tom <at> tromey.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; per-project *vc-change-log* buffers
Date: Thu, 24 Sep 2015 15:49:33 -0600

I often work on several projects at once, using a *vc-dir* buffer for
each.

If I type "l" in this buffer, I get a *vc-change-log* buffer with the
history of the project.

However, all calls to vc-print-log use this same buffer.
This seems to be hard-coded in vc.el (vc-print-log-internal).

I would like to be able to make it so that each use of "l" from a
*vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v l"
in some source file gets a separate buffer.  This way the per-project
change-log buffers could be relatively long-lived; as it is recomputing
the data in them takes much too long.




In GNU Emacs 25.0.50.5 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-08-18 on pokyo
Repository revision: 78284d534ba7c17c3b5d9d6d1e538277546f8159
Windowing system distributor `Fedora Project', version 11.0.11702000
Configured using:
 `configure --prefix=/home/tromey/Emacs/install/
 --with-file-notification=no'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS
LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  erc-spelling-mode: t
  erc-truncate-mode: t
  diff-auto-refine-mode: t
  flyspell-mode: t
  which-function-mode: t
  projectile-global-mode: t
  projectile-mode: t
  erc-notify-mode: t
  erc-notifications-mode: t
  erc-services-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-netsplit-mode: t
  erc-hl-nicks-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  savehist-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

Recent messages:
Saving file /home/tromey/firefox-git/gecko-dev/.git/rebase-merge/git-rebase-todo...
Wrote /home/tromey/firefox-git/gecko-dev/.git/rebase-merge/git-rebase-todo
Mark set
C-x C-g is undefined
Mark saved where search started
Making completion list...
Finding changes in /home/tromey/firefox-git/gecko-dev/...
Type C-x 1 to delete the help window.
uncompressing vc.el.gz...done
Mark saved where search started

Load-path shadows:
/home/tromey/.emacs.d/elpa/bubbles-0.5/bubbles hides /home/tromey/Emacs/install/share/emacs/25.0.50/lisp/play/bubbles

Features:
(shadow emacsbug arc-mode archive-mode calc-aent calc-menu calc-embed
calc-ext calc calc-loaddefs calc-macs tramp-cache tabify man compare-w
iso-transl perl-mode gamegrid recentf tree-widget with-editor
async-bytecomp term ehelp esh-var esh-io esh-cmd esh-opt esh-ext
esh-proc esh-arg esh-groups eshell esh-module esh-mode esh-util async
tar-mode cus-edit url-handlers disass gud autoload lisp-mnt hi-lock
etags dired-aux vc-annotate ffap rect css-mode eww url-queue python
tramp-sh tramp tramp-compat tramp-loaddefs trampver shell webjump xref
project thai-util thai-word mailalias bbdb-sc supercite regi mail-hist
nnir gnus-fun find-dired url-http url-gw url-auth epg conf-mode
gnus-draft ido nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util
rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph
nxml-enc xmltok eieio-opt speedbar sb-image ezimage dframe gnus-html
url-cache mm-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf flow-fill bbdb-gui bbdb-hooks
bbdb-rmail rmailsum rmail sort gnus-cite smiley shr-color url-util
url-parse url-vars shr dom mm-archive gnus-async gnus-bcklg qp gnus-ml
disp-table gnus-topic nndraft nnmh nnfolder utf-7 bbdb-gnus bbdb-snarf
mail-extr bbdb-com warnings gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg nntp gnus-cache gnus-registry registry eieio-compat
eieio-base gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap
gnus-sum gnus-group gnus-undo smtpmail sendmail gnus-start gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range gnus-win gnus gnus-ems nnheader org-element org-rmail org-mhe
org-irc org-info org-gnus org-docview doc-view image-mode org-bibtex
bibtex org-bbdb org-w3m org org-macro org-footnote org-pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs dxr
browse-url find-file idutils sgml-mode vc-mtn vc-hg gnutls
network-stream nsm starttls tls erc-spelling erc-truncate
git-commit-mode log-edit message dired rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev mail-utils gmm-utils mailheader dabbrev smerge-mode copyright
git-rebase-mode term/xterm xterm misearch multi-isearch js json cc-mode
cc-fonts cc-guess cc-menus cc-cmds grep bug-reference add-log log-view
pcvs-util vc-git diff-mode vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs
flyspell ispell diminish appt diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs which-func imenu projectile ibuf-macs ibuf-ext ibuffer
minimap autorevert filenotify desktop frameset cus-start cus-load
erc-notify erc-desktop-notifications notifications dbus xml erc-services
erc-list erc-menu erc-join erc-ring erc-networks erc-pcomplete pcomplete
erc-track erc-match erc-netsplit erc-hl-nicks color erc-button erc-fill
erc-stamp wid-edit erc-goodies erc erc-backend erc-compat format-spec
auth-source eieio byte-opt bytecomp byte-compile cl-extra seq cconv
gnus-util mm-util help-fns mail-prsvr password-cache thingatpt pp status
advice vc-dir ewoc vc vc-dispatcher flycheck derived easy-mmode cl-seq
edmacro kmacro find-func help-mode rx subr-x dash jka-compr sh-script
smie executable compile let-alist cc-styles cc-align cc-engine cc-vars
cc-defs bbdb cl timezone ange-ftp comint ansi-color ring server savehist
finder-inf bbdb-autoloads dwarf-mode-autoloads eieio-core cl-macs gv
cl-loaddefs pcase cl-lib lisppaste-autoloads pydoc-info-autoloads
info-look info weblogger-autoloads package easymenu epg-config time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 3011681 859506)
 (symbols 48 132351 1487)
 (miscs 40 29224 21152)
 (strings 32 816797 269877)
 (string-bytes 1 34115078)
 (vectors 16 214055)
 (vector-slots 8 4461660 211249)
 (floats 8 1265 3664)
 (intervals 56 134269 106424)
 (buffers 976 1018)
 (heap 1024 439477 770948))

Tom

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Tom Tromey <tom <at> tromey.com>
Cc: control <at> debbugs.gnu.org, 21555 <at> debbugs.gnu.org
Subject: Re: 25.0.50; per-project *vc-change-log* buffers
Date: Fri, 14 Mar 2025 14:27:22 +0800

tag 21555 + moreinfo
thanks

Hello,

On Thu 24 Sep 2015 at 03:49pm -06, Tom Tromey wrote:

> I often work on several projects at once, using a *vc-dir* buffer for
> each.
>
> If I type "l" in this buffer, I get a *vc-change-log* buffer with the
> history of the project.
>
> However, all calls to vc-print-log use this same buffer.
> This seems to be hard-coded in vc.el (vc-print-log-internal).
>
> I would like to be able to make it so that each use of "l" from a
> *vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v l"
> in some source file gets a separate buffer.  This way the per-project
> change-log buffers could be relatively long-lived; as it is recomputing
> the data in them takes much too long.

You can already do something similar by using C-x x u to rename the
*vc-change-log* buffer, and then 'g' inside it works to regenerate it.

This is how Emacs works with these special-mode buffers across the board
-- freely reuse them unless the user has renamed them out of the way of
the buffer's default name, in this case "*vc-change-log*".

Unlike compilation-mode buffers, *vc-change-log* buffers are already
adequately protected from re-use with just C-x x u.
I.e. the caveat in that command's docstring does not apply.

I think we would want VC to be consistent with the rest of Emacs, here,
rather than doing something special.
Therefore, I would be inclined to think anything cleverer is better left
to a command in the user's init.el, or an external package.

I'm tagging this as moreinfo for now in case Tom wants to come back, but
my inclination would be to close this.

-- 
Sean Whitton

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org
Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log* buffers
Date: Fri, 14 Mar 2025 09:47:00 +0200

>> However, all calls to vc-print-log use this same buffer.
>> This seems to be hard-coded in vc.el (vc-print-log-internal).
>>
>> I would like to be able to make it so that each use of "l" from a
>> *vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v l"
>> in some source file gets a separate buffer.  This way the per-project
>> change-log buffers could be relatively long-lived; as it is recomputing
>> the data in them takes much too long.
>
> You can already do something similar by using C-x x u to rename the
> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.

Or (add-hook 'log-view-mode-hook 'rename-uniquely)

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

From: Matthias Meulien <orontee <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>, Sean Whitton <spwhitton <at> spwhitton.name>, 
 Tom Tromey <tom <at> tromey.com>
Cc: 21555 <at> debbugs.gnu.org
Subject: Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log* buffers
Date: Sat, 24 May 2025 21:58:20 +0200

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

Juri Linkov <juri <at> linkov.net> writes:

>>> However, all calls to vc-print-log use this same buffer.
>>> This seems to be hard-coded in vc.el (vc-print-log-internal).
>>>
>>> I would like to be able to make it so that each use of "l" from a
>>> *vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v l"
>>> in some source file gets a separate buffer.  This way the per-project
>>> change-log buffers could be relatively long-lived; as it is recomputing
>>> the data in them takes much too long.
>>
>> You can already do something similar by using C-x x u to rename the
>> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.
>
> Or (add-hook 'log-view-mode-hook 'rename-uniquely)

Note that while browsing a change log buffer, when one runs the command
`log-view-diff', the log buffer is not killed.

For people like me who makes an heavy use of "C-x v l", "C-x v L" and "l"
in *vc-dir* buffers, it leads to have hundreds of *vc-change-log* buffers
at the
end of the day…
-- 
Matthias

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matthias Meulien <orontee <at> gmail.com>, tom <at> tromey.com
Cc: spwhitton <at> spwhitton.name, 21555 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#21555: Subject: Re: bug#21555: 25.0.50;
 per-project *vc-change-log* buffers
Date: Sun, 25 May 2025 09:23:49 +0300

> Cc: 21555 <at> debbugs.gnu.org
> From: Matthias Meulien <orontee <at> gmail.com>
> Date: Sat, 24 May 2025 21:58:20 +0200
> 
> 
> Juri Linkov <juri <at> linkov.net> writes:
> 
> >>> However, all calls to vc-print-log use this same buffer.
> >>> This seems to be hard-coded in vc.el (vc-print-log-internal).
> >>>
> >>> I would like to be able to make it so that each use of "l" from a
> >>> *vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v l"
> >>> in some source file gets a separate buffer.  This way the per-project
> >>> change-log buffers could be relatively long-lived; as it is recomputing
> >>> the data in them takes much too long.
> >>
> >> You can already do something similar by using C-x x u to rename the
> >> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.
> >
> > Or (add-hook 'log-view-mode-hook 'rename-uniquely)
> 
> Note that while browsing a change log buffer, when one runs the command
> `log-view-diff', the log buffer is not killed.
> 
> For people like me who makes an heavy use of "C-x v l", "C-x v L" and "l" in *vc-dir* buffers, it leads to have
> hundreds of *vc-change-log* buffers at the
> end of the day…

Why having many such buffers a problem?  We have features (like
midnight.el) to kill unused buffers, if the user doesn't want to do
that manually.

Anyway, it sounds like there are already solutions for this issue, so
should we close it now?

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

From: Juri Linkov <juri <at> linkov.net>
To: Matthias Meulien <orontee <at> gmail.com>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log*
 buffers
Date: Sun, 25 May 2025 09:36:58 +0300

>>>> However, all calls to vc-print-log use this same buffer.
>>>> This seems to be hard-coded in vc.el (vc-print-log-internal).
>>>>
>>>> I would like to be able to make it so that each use of "l" from a
>>>> *vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v l"
>>>> in some source file gets a separate buffer.  This way the per-project
>>>> change-log buffers could be relatively long-lived; as it is recomputing
>>>> the data in them takes much too long.
>>>
>>> You can already do something similar by using C-x x u to rename the
>>> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.
>>
>> Or (add-hook 'log-view-mode-hook 'rename-uniquely)
>
> Note that while browsing a change log buffer, when one runs the command
> `log-view-diff', the log buffer is not killed.
>
> For people like me who makes an heavy use of "C-x v l", "C-x v L" and "l"
> in *vc-dir* buffers, it leads to have hundreds of *vc-change-log* buffers
> at the end of the day…

Indeed, hundreds of *vc-change-log* buffers is what I have.
But not a problem.  On the contrary, preserved buffers often help
to check for their previous content.

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

From: Matthias Meulien <orontee <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50;
 per-project *vc-change-log* buffers
Date: Sun, 25 May 2025 09:06:28 +0200

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

Le dim. 25 mai 2025 à 08:38, Juri Linkov <juri <at> linkov.net> a écrit :

> >>>> However, all calls to vc-print-log use this same buffer.
> >>>> This seems to be hard-coded in vc.el (vc-print-log-internal).
> >>>>
> >>>> I would like to be able to make it so that each use of "l" from a
> >>>> *vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v
> l"
> >>>> in some source file gets a separate buffer.  This way the per-project
> >>>> change-log buffers could be relatively long-lived; as it is
> recomputing
> >>>> the data in them takes much too long.
> >>>
> >>> You can already do something similar by using C-x x u to rename the
> >>> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.
> >>
> >> Or (add-hook 'log-view-mode-hook 'rename-uniquely)
> >
> > Note that while browsing a change log buffer, when one runs the command
> > `log-view-diff', the log buffer is not killed.
> >
> > For people like me who makes an heavy use of "C-x v l", "C-x v L" and "l"
> > in *vc-dir* buffers, it leads to have hundreds of *vc-change-log* buffers
> > at the end of the day…
>
> Indeed, hundreds of *vc-change-log* buffers is what I have.
> But not a problem.  On the contrary, preserved buffers often help
> to check for their previous content.
>

Ok, I'll try to live with that.

For the record I attach two patchs that enable per projet change log and
diff buffers.

-- 
Matthias

[Message part 2 (text/html, inline)]

[0001-Per-project-change-log-buffer.patch (text/x-patch, attachment)]

[0002-Per-project-vc-diff-buffer.patch (text/x-patch, attachment)]

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

From: Matthias Meulien <orontee <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50;
 per-project *vc-change-log* buffers
Date: Wed, 28 May 2025 08:13:46 +0200

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

With rename-uniquely added to log-view-mode-hook, revert-buffer now display
another buffer. As a result after pressing g in a log view there's now two
almost identical buffers displayed... Is this working as expected or should
I open a bug report?

Matthias

Le dim. 25 mai 2025, 09:06, Matthias Meulien <orontee <at> gmail.com> a écrit :

> Le dim. 25 mai 2025 à 08:38, Juri Linkov <juri <at> linkov.net> a écrit :
>
>> >>>> However, all calls to vc-print-log use this same buffer.
>> >>>> This seems to be hard-coded in vc.el (vc-print-log-internal).
>> >>>>
>> >>>> I would like to be able to make it so that each use of "l" from a
>> >>>> *vc-dir* buffer gets its own *vc-change-log* buffer; and that "C-x v
>> l"
>> >>>> in some source file gets a separate buffer.  This way the per-project
>> >>>> change-log buffers could be relatively long-lived; as it is
>> recomputing
>> >>>> the data in them takes much too long.
>> >>>
>> >>> You can already do something similar by using C-x x u to rename the
>> >>> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.
>> >>
>> >> Or (add-hook 'log-view-mode-hook 'rename-uniquely)
>> >
>> > Note that while browsing a change log buffer, when one runs the command
>> > `log-view-diff', the log buffer is not killed.
>> >
>> > For people like me who makes an heavy use of "C-x v l", "C-x v L" and
>> "l"
>> > in *vc-dir* buffers, it leads to have hundreds of *vc-change-log*
>> buffers
>> > at the end of the day…
>>
>> Indeed, hundreds of *vc-change-log* buffers is what I have.
>> But not a problem.  On the contrary, preserved buffers often help
>> to check for their previous content.
>>
>
> Ok, I'll try to live with that.
>
> For the record I attach two patchs that enable per projet change log and
> diff buffers.
>
> --
> Matthias
>

[Message part 2 (text/html, inline)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Matthias Meulien <orontee <at> gmail.com>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log*
 buffers
Date: Wed, 28 May 2025 09:50:23 +0300

> With rename-uniquely added to log-view-mode-hook, revert-buffer now display
> another buffer. As a result after pressing g in a log view there's now two
> almost identical buffers displayed... Is this working as expected or should
> I open a bug report?

This is expected since it always worked this way.  It's inconvenient when
it pops up a window with a new buffer.  But OTOH, often it helps to compare
content before and after reverting.  The same applies to rename-uniquely
added to diff-mode-hook, etc.

It would be nice to configure the desired behavior with a simple
customization like

  (add-hook 'log-view-mode-hook
              (lambda ()
                (unless (eq this-command 'revert-buffer)
                  (rename-uniquely))))

But this works only for the initial buffer name *vc-change-log* and
doesn't keep the suffix in renamed buffers like *vc-change-log*<2>.

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

From: Juri Linkov <juri <at> linkov.net>
To: Matthias Meulien <orontee <at> gmail.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Tom Tromey <tom <at> tromey.com>,
 21555 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log*
 buffers
Date: Wed, 28 May 2025 09:54:56 +0300

>> Indeed, hundreds of *vc-change-log* buffers is what I have.
>> But not a problem.  On the contrary, preserved buffers often help
>> to check for their previous content.
>
> Ok, I'll try to live with that.
>
> For the record I attach two patchs that enable per projet change log and
> diff buffers.

I think such buffer names would be more consistent with
project-specific prefixes added by project-compile, etc.
Although such prefixes are still removed after reverting
the compilation buffer.  So I rely more on 'C-x p C-b'
to see what buffers belong to the project.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Matthias Meulien <orontee <at> gmail.com>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#21555: Subject: Re: bug#21555: 25.0.50; per-project
 *vc-change-log* buffers
Date: Wed, 28 May 2025 13:00:51 +0100

Hello,

On Wed 28 May 2025 at 08:13am +02, Matthias Meulien wrote:

> With rename-uniquely added to log-view-mode-hook, revert-buffer now
> display another buffer. As a result after pressing g in a log view
> there's now two almost identical buffers displayed... Is this working
> as expected or should I open a bug report?

This is intentional.

-- 
Sean Whitton

Message #42 received at 21555-done <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juri <at> linkov.net, tom <at> tromey.com, Matthias Meulien <orontee <at> gmail.com>,
 21555-done <at> debbugs.gnu.org
Subject: Re: bug#21555: Subject: Re: bug#21555: 25.0.50; per-project
 *vc-change-log* buffers
Date: Wed, 28 May 2025 13:51:05 +0100

Hello,

On Sun 25 May 2025 at 09:23am +03, Eli Zaretskii wrote:

> Anyway, it sounds like there are already solutions for this issue, so
> should we close it now?

I think so, doing that now.

-- 
Sean Whitton

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org
Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log* buffers
Date: Fri, 30 May 2025 04:10:58 +0300

On 14/03/2025 09:47, Juri Linkov wrote:
>> You can already do something similar by using C-x x u to rename the
>> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.
> Or (add-hook 'log-view-mode-hook 'rename-uniquely)

Could we have a function that would do such a renaming, but only when 
project differs? E.g. it would take the base buffer name and add the 
abbreviated project root to it.

We could call it 'rename-prefixed-with-project' or something like that.

This way one would only have as many log-view buffers as they have 
projects open. Might even fix the revert-buffer issue?

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Tom Tromey <tom <at> tromey.com>, 21555 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log* buffers
Date: Fri, 30 May 2025 09:38:03 +0300

>>> You can already do something similar by using C-x x u to rename the
>>> *vc-change-log* buffer, and then 'g' inside it works to regenerate it.
>> Or (add-hook 'log-view-mode-hook 'rename-uniquely)
>
> Could we have a function that would do such a renaming, but only when
> project differs? E.g. it would take the base buffer name and add the
> abbreviated project root to it.
>
> We could call it 'rename-prefixed-with-project' or something like that.

I tried it, and this works nicely:

#+begin_src emacs-lisp
(defun project-rename-uniquely ()
  (interactive)
  (if-let* ((project (project-current)))
      (let ((base-name (replace-regexp-in-string
                        "\\`\\*\\(.*\\)\\*\\(?:<[0-9]+>\\)?\\'" "\\1"
                        (buffer-name))))
        (rename-buffer (generate-new-buffer-name
                        (project-prefixed-buffer-name base-name)))
        (force-mode-line-update))
    (rename-uniquely)))

(add-hook 'log-view-mode-hook 'project-rename-uniquely)
(add-hook 'diff-mode-hook 'project-rename-uniquely)
#+end_src

> This way one would only have as many log-view buffers as they have projects
> open.

Ah, you meant one buffer per project?  Then maybe add another
similar function without 'generate-new-buffer-name'?
But then it fails with the error "Buffer name is in use".
This means that for one buffer per project the changes should be
in vc and project like in the patch provided by Matthias.

> Might even fix the revert-buffer issue?

The revert-buffer issue can't be fixed with 'generate-new-buffer-name'.

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

From: Matthias Meulien <orontee <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Tom Tromey <tom <at> tromey.com>,
 21555 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50;
 per-project *vc-change-log* buffers
Date: Sun, 8 Jun 2025 09:57:49 +0200

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

> > For the record I attach two patchs that enable per projet change log and
> > diff buffers.
>
> I think such buffer names would be more consistent with
> project-specific prefixes added by project-compile, etc.
>

Yes. It also "fix" the duplication of change logs on revert call.


> Although such prefixes are still removed after reverting
> the compilation buffer.


I can't reproduce that. When pressing `g' key in a `*myproject-compilation*'
buffer (mapped to `recompile'), the buffer name doesn't change.

So I rely more on 'C-x p C-b'
> to see what buffers belong to the project.
>

I can't see anything when that buffer list is filled of *vc-change-log*<57>,
*vc-change-log*<98>, *vc-diff*<17> etc. buffers.

(there's a missing "(require 'vc)" in project.el in the posted patches,
sorry.)
-- 
Matthias

[Message part 2 (text/html, inline)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Matthias Meulien <orontee <at> gmail.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Tom Tromey <tom <at> tromey.com>,
 21555 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log*
 buffers
Date: Sun, 08 Jun 2025 19:54:58 +0300

>     Although such prefixes are still removed after reverting
>     the compilation buffer.  
>
> I can't reproduce that. When pressing `g' key in a
> `*myproject-compilation*'
> buffer (mapped to `recompile'), the buffer name doesn't change.

Since (add-hook 'compilation-mode-hook 'rename-uniquely) doesn't work
for creating unique buffer names I'm using this instead:

(setq compilation-buffer-name-function
      (lambda (name-of-mode)
        (generate-new-buffer-name
         (concat "*" (downcase name-of-mode) "*"))))

but it removes the project prefix on `g'.

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

From: Matthias Meulien <orontee <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Tom Tromey <tom <at> tromey.com>,
 21555 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50;
 per-project *vc-change-log* buffers
Date: Sun, 8 Jun 2025 19:59:56 +0200

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

Le dim. 8 juin 2025 à 18:55, Juri Linkov <juri <at> linkov.net> a écrit :

> >     Although such prefixes are still removed after reverting
> >     the compilation buffer.
> >
> > I can't reproduce that. When pressing `g' key in a
> > `*myproject-compilation*'
> > buffer (mapped to `recompile'), the buffer name doesn't change.
>
> Since (add-hook 'compilation-mode-hook 'rename-uniquely) doesn't work
> for creating unique buffer names I'm using this instead:
>
> (setq compilation-buffer-name-function
>       (lambda (name-of-mode)
>         (generate-new-buffer-name
>          (concat "*" (downcase name-of-mode) "*"))))
>
> but it removes the project prefix on `g'.
>

Starting with 28.1, one can use :
(setq project-compilation-buffer-name-function
'project-prefixed-buffer-name)
-- 
Matthias

[Message part 2 (text/html, inline)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Matthias Meulien <orontee <at> gmail.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Tom Tromey <tom <at> tromey.com>,
 21555 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: Subject: Re: bug#21555: 25.0.50; per-project *vc-change-log*
 buffers
Date: Mon, 09 Jun 2025 09:29:20 +0300

>     >     Although such prefixes are still removed after reverting
>     >     the compilation buffer.  
>     >
>     > I can't reproduce that. When pressing `g' key in a
>     > `*myproject-compilation*'
>     > buffer (mapped to `recompile'), the buffer name doesn't change.
>
>     Since (add-hook 'compilation-mode-hook 'rename-uniquely) doesn't work
>     for creating unique buffer names I'm using this instead:
>
>     (setq compilation-buffer-name-function
>           (lambda (name-of-mode)
>             (generate-new-buffer-name
>              (concat "*" (downcase name-of-mode) "*"))))
>
>     but it removes the project prefix on `g'.
>
> Starting with 28.1, one can use :
> (setq project-compilation-buffer-name-function
> 'project-prefixed-buffer-name)

This setting doesn't produce unique buffer names
for every new compilation with added prefixes <1>, <2>, ...

Does your path support such use cases when
'rename-uniquely' is used in a hook to add <1>, <2>?

Previous Next

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