From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: ndame Newsgroups: gmane.emacs.bugs Subject: bug#37223: 26.2; vc does not honor backup-directory-alist Date: Sat, 14 Sep 2019 19:20:25 +0000 (GMT) Message-ID: References: <630e610c-bc5e-b3be-22d7-d1a998f1e917@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14358_671922571.1568488825398" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="175922"; mail-complaints-to="usenet@blaine.gmane.org" To: "37223@debbugs.gnu.org" <37223@debbugs.gnu.org>, Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 14 21:22:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i9Dcc-000jff-94 for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Sep 2019 21:22:14 +0200 Original-Received: from localhost ([::1]:52000 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9Dca-0006vS-LT for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Sep 2019 15:22:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57605) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9DcS-0006vE-Pd for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 15:22:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i9DcR-0007ei-LE for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 15:22:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38335) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i9DcR-0007dG-4H for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 15:22:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i9DcQ-0006jR-4Y for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 15:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 19:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37223 X-GNU-PR-Package: emacs Original-Received: via spool by 37223-submit@debbugs.gnu.org id=B37223.156848888725817 (code B ref 37223); Sat, 14 Sep 2019 19:22:02 +0000 Original-Received: (at 37223) by debbugs.gnu.org; 14 Sep 2019 19:21:27 +0000 Original-Received: from localhost ([127.0.0.1]:47156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9Dbq-0006iL-K6 for submit@debbugs.gnu.org; Sat, 14 Sep 2019 15:21:26 -0400 Original-Received: from fmfe18.onbox.hu ([46.107.16.211]:61155 helo=web-out.onbox.hu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9Dbo-0006i1-8c for 37223@debbugs.gnu.org; Sat, 14 Sep 2019 15:21:25 -0400 X-fm-smtp-source: yes Original-Received: from localhost (localhost [85.238.81.81]) by web-out.onbox.hu (Postfix) with SMTP id 46W2Rd2sjwzjWJ; Sat, 14 Sep 2019 21:21:17 +0200 (CEST) In-Reply-To: <630e610c-bc5e-b3be-22d7-d1a998f1e917@yandex.ru> X-AccountId: 57978162 X-Originating-Ip: 85.238.81.81 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrtdelgddufeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpucfhtffggffotefknfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffkjghfufggtghisegrtdersgdttddunecuhfhrohhmpehnuggrmhgvuceovghmrggtshhushgvrhesfhhrvggvmhgrihhlrdhhuheqnecukfhppeekhedrvdefkedrkedurdekudenucfrrghrrghmpehhvghloheppdhinhgvthepkeehrddvfeekrdekuddrkedupdhmrghilhhfrhhomhepvghmrggtshhushgvrhesfhhrvggvmhgrihhlrdhhuhdprhgtphhtthhopeefjedvvdefseguvggssghughhsrdhgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/relaxed; t=1568488877; s=20181004; d=freemail.hu; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=3052; bh=RVIa4nnqNMk5ygAsCz6+nt8Ktf4VT6wwdq0oQiH4FW0=; b=iEM1Uw1TmWMiUHsZhwinThPfKjbUi/gQ0xwpUBsQ7hoYwn2auJaHslNuYqExXQnG 8VswsaDDid195F1igvZw/STN/alt9d3N6S63bmZ4TqRpxExaat0CdoAwbJTl+olNXWv 0W4mgvadxL4GW8XznHnh/rGx69HeLoZ/FU8Sqp5auJQgLW4NLiYVNcl6lRyVlJ1ByWL 5M66X+uXMIc1guehhMmTVqztIEAEekN5/GIdgqVpWBgmwfZ2WK6Ao3gSlD7+7dqcaQT 4tpj+uTnS9HLqoYo6/0AjqIMwKlgDD5GY2+o2i4xyznD5k6cX2tWNPY7UtCKcy1FgAn uPrwBe1S1w== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:166470 Archived-At: ------=_Part_14358_671922571.1568488825398 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >=C2=A0 > > > > 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. >=C2=A0 > I don't know if they should. The current behavior is a long-standing > one. =C2=A0But 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. ------=_Part_14358_671922571.1568488825398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > 
> >
> > 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. ------=_Part_14358_671922571.1568488825398--