From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Proposal for a closed-buffer tracker Date: Sun, 22 Feb 2015 17:53:25 +0200 Message-ID: <83a906c58q.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1424620435 13120 80.91.229.3 (22 Feb 2015 15:53:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Feb 2015 15:53:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kelly Dean Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 22 16:53:47 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YPYqo-0006QC-NE for ged-emacs-devel@m.gmane.org; Sun, 22 Feb 2015 16:53:46 +0100 Original-Received: from localhost ([::1]:40442 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPYqo-0007hr-37 for ged-emacs-devel@m.gmane.org; Sun, 22 Feb 2015 10:53:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPYqa-0007ha-K6 for emacs-devel@gnu.org; Sun, 22 Feb 2015 10:53:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPYqT-0001zB-Cf for emacs-devel@gnu.org; Sun, 22 Feb 2015 10:53:32 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:58394) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPYqT-0001yy-3n for emacs-devel@gnu.org; Sun, 22 Feb 2015 10:53:25 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NK600600K1PLU00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sun, 22 Feb 2015 17:53:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NK6006CCK4YLX00@a-mtaout20.012.net.il>; Sun, 22 Feb 2015 17:53:22 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183385 Archived-At: > From: Kelly Dean > Date: Sun, 22 Feb 2015 04:11:54 +0000 >=20 > Below is code for a closed-buffer tracker. It lets you reopen close= d buffers,=20 > and restores the major mode, minor modes, point, mark, mark ring, a= nd other=20 > buffer-local variables returned by the function desktop-buffer-info= . Currently,=20 > it's implemented only for file-visiting buffers. It's comparable to= the =C2=ABclosed=20 > tabs=C2=BB feature of modern web browsers, and useful for the same = reasons. Thanks. > Note that although it uses functions in desktop.el, it doesn't requ= ire=20 > desktop-save-mode to be enabled; the two operate independently. If by "independently" you mean that desktop saving does not have to b= e enabled, then fine. But this functionality should IMO be able to do everything desktop.el is able to do wrt restoring buffers. In particular, desktop.el is able to restore buffers whose buffer-file-name is nil, at least for Info buffers. I'd presume that buffers visiting URLs via eww should also be restorable (I don't know if desktop.el can do that already, but if not, it should be taught to do so, and this feature should then be able to reuse that). > Stefan suggested I submit this feature as a patch. If other people = might find=20 > it useful, should it go into desktop.el? Or perhaps GNU Elpa? Curre= ntly it's=20 > just part of a larger convenience package at: > http://prtime.org/emacs/usablizer.html IMO, it should definitely go to desktop.el, as it uses its infrastructure. > (defvar closed-buffer-history-max-saved-items 1000 This should be a defcustom, of course. > "Max items to save on `closed-buffer-history' list. > Use -1 for unlimited, or zero to disable tracking closed files. I think we tend to use nil for "unlimited", not -1. Please use 2 spaces between sentences in doc strings, we use the US English style. > To clear the list, set it to nil. The list is an internal variable, so telling users to set it is a minor annoyance, I think. How about an explicit function to do that, a-la "Clear Recent History"? > (defvar closed-buffer-history-max-full-items 100 > "Max full items to save on `closed-buffer-history' list. Should be a defcustom. > Use -1 for unlimited, or zero to disable tracking of full items. Again, nil for unlimited is better, IMO. > (interactive > (list (ido-completing-read "Last closed: " Why ido-completing-read, rather than completing-read? I think it6's up to the users to customize their completion. > ;;Load from info list, using base filename as new buffer name. > (let ((buf > ;; Set variables needed by desktop-create-buffer. > ;; Need dlet because they're not globally special, but o= nly locally > ;; special in desktop.el, which according to Stefan, is = not weird. > (dlet ((desktop-buffer-ok-count 0) > (desktop-buffer-fail-count 0) > desktop-first-buffer) > (silently ; Silence desktop-restore-file-buffer if= file can't be found > (apply 'desktop-create-buffer (string-to-number= =20 > desktop-file-version) > name (file-name-nondirectory name) (cddr b= ufinfo)))))) What happens if there is already a buffer by the same name? Also, should we somehow draw user's attention to the fact that another buffer visits the same file? > (add-hook 'kill-buffer-hook #'track-closed-buffer) Why the hash? > (global-set-key [S-XF86Close] #'reopen-buffer) Why this strange binding? Also, if we are targeting newbies who are accustomed to Web browsers, this functionality should be easily reachable from the menu bar, IMO. Thanks again for working on this.