unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#37223: 26.2; vc does not honor backup-directory-alist
@ 2019-08-29 19:55 ndame
  2019-09-14  0:40 ` Dmitry Gutov
  0 siblings, 1 reply; 5+ messages in thread
From: ndame @ 2019-08-29 19:55 UTC (permalink / raw)
  To: 37223

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

I often use vc log and then f (log-view-find-revision) to view a
specific revision of a file.

The problem is the file is checked out to the same directory as the
original file with a backup file name (~, polluting the directory with
such files if multiple versions are perused.

These are backup files, the vc function uses that name too
(vc-version-backup-file-name), so their placements should honor
backup-directory-alist which is currently ignored.

[-- Attachment #2: Type: text/html, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#37223: 26.2; vc does not honor backup-directory-alist
  2019-08-29 19:55 bug#37223: 26.2; vc does not honor backup-directory-alist ndame
@ 2019-09-14  0:40 ` Dmitry Gutov
  2019-09-14 19:20   ` ndame
  0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Gutov @ 2019-09-14  0:40 UTC (permalink / raw)
  To: ndame, 37223

On 29.08.2019 22:55, ndame wrote:
> I often use vc log and then f (log-view-find-revision) to view a
> specific revision of a file.
> 
> The problem is the file is checked out to the same directory as the
> original file with a backup file name (~, polluting the directory with
> such files if multiple versions are perused.
> 
> These are backup files, the vc function uses that name too
> (vc-version-backup-file-name), so their placements should honor
> backup-directory-alist which is currently ignored.

I don't know if they should. The current behavior is a long-standing one.

But more opinions are welcome.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#37223: 26.2; vc does not honor backup-directory-alist
  2019-09-14  0:40 ` Dmitry Gutov
@ 2019-09-14 19:20   ` ndame
  2019-09-19 20:22     ` Juri Linkov
  0 siblings, 1 reply; 5+ messages in thread
From: ndame @ 2019-09-14 19:20 UTC (permalink / raw)
  To: 37223@debbugs.gnu.org, Dmitry Gutov

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

> 
> >
> > These are backup files, the vc function uses that name too
> > (vc-version-backup-file-name), so their placements should honor
> > backup-directory-alist which is currently ignored.
> 
> I don't know if they should. The current behavior is a long-standing
> one.  But more opinions are welcome.

The main problem is the user may not want these files at all.

I usually look at a particular version then close the buffer, I don't
want a file created and having such files polluting the directory. I
just want to see the contents.

I'd say more people use log to look up something in a certain version
than actually wanting to get a certain version on disk.

So there's two possible solutions:

1. Add an option to control if backup-directory-alist is honored by
these files and this can be off by default to keep current default
behavior.

2. Do not create files at all on disk, just read the selected
version's contents into a new buffer. The user can decide if he wants
to just look at the file and then close the buffer, or if he wants the
given version on disk then he can save the buffer.

The 2nd option seems better, since it gives control to the user to do
with the buffer as he wishes.

[-- Attachment #2: Type: text/html, Size: 1467 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#37223: 26.2; vc does not honor backup-directory-alist
  2019-09-14 19:20   ` ndame
@ 2019-09-19 20:22     ` Juri Linkov
  2019-11-13 20:47       ` Juri Linkov
  0 siblings, 1 reply; 5+ messages in thread
From: Juri Linkov @ 2019-09-19 20:22 UTC (permalink / raw)
  To: ndame; +Cc: 37223@debbugs.gnu.org, Dmitry Gutov

> 2. Do not create files at all on disk, just read the selected
> version's contents into a new buffer. The user can decide if he wants
> to just look at the file and then close the buffer, or if he wants the
> given version on disk then he can save the buffer.
>
> The 2nd option seems better, since it gives control to the user to do
> with the buffer as he wishes.

Please try a new option 'vc-find-revision-no-save' added in Emacs 27.
If you like it, then this report could be closed.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#37223: 26.2; vc does not honor backup-directory-alist
  2019-09-19 20:22     ` Juri Linkov
@ 2019-11-13 20:47       ` Juri Linkov
  0 siblings, 0 replies; 5+ messages in thread
From: Juri Linkov @ 2019-11-13 20:47 UTC (permalink / raw)
  To: ndame; +Cc: 37223@debbugs.gnu.org, Dmitry Gutov

tags 37223 + fixed
close 37223 27.0.50
quit

>> 2. Do not create files at all on disk, just read the selected
>> version's contents into a new buffer. The user can decide if he wants
>> to just look at the file and then close the buffer, or if he wants the
>> given version on disk then he can save the buffer.
>>
>> The 2nd option seems better, since it gives control to the user to do
>> with the buffer as he wishes.
>
> Please try a new option 'vc-find-revision-no-save' added in Emacs 27.
> If you like it, then this report could be closed.

No response within last 2 months, so I guess everything is alright,
thus closing.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-11-13 20:47 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-29 19:55 bug#37223: 26.2; vc does not honor backup-directory-alist ndame
2019-09-14  0:40 ` Dmitry Gutov
2019-09-14 19:20   ` ndame
2019-09-19 20:22     ` Juri Linkov
2019-11-13 20:47       ` Juri Linkov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).