unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Kelly Dean <kelly@prtime.org>
Cc: emacs-devel@gnu.org
Subject: Re: Proposal for a closed-buffer tracker
Date: Sun, 22 Feb 2015 17:53:25 +0200	[thread overview]
Message-ID: <83a906c58q.fsf@gnu.org> (raw)
In-Reply-To: <KhIjsqABVYs7J9HGl7O1gJ70KCg9IOrmRf4iJlXBuzs@local>

> From: Kelly Dean <kelly@prtime.org>
> Date: Sun, 22 Feb 2015 04:11:54 +0000
> 
> Below is code for a closed-buffer tracker. It lets you reopen closed buffers, 
> and restores the major mode, minor modes, point, mark, mark ring, and other 
> buffer-local variables returned by the function desktop-buffer-info. Currently, 
> it's implemented only for file-visiting buffers. It's comparable to the «closed 
> tabs» feature of modern web browsers, and useful for the same reasons.

Thanks.

> Note that although it uses functions in desktop.el, it doesn't require 
> desktop-save-mode to be enabled; the two operate independently.

If by "independently" you mean that desktop saving does not have to be
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 
> it useful, should it go into desktop.el? Or perhaps GNU Elpa? Currently it's 
> 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 only 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 
> desktop-file-version)
>                          name (file-name-nondirectory name) (cddr bufinfo))))))

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.




  reply	other threads:[~2015-02-22 15:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12 21:32 Why is Elisp's defvar weird? And is eval_sub broken? Kelly Dean
2015-02-13 19:03 ` Stefan Monnier
2015-02-14  7:35   ` Kelly Dean
2015-02-14 14:36     ` Stefan Monnier
2015-02-15 14:17       ` Daniel Colascione
2015-02-16  5:42       ` Kelly Dean
2015-02-16  7:40         ` Stefan Monnier
2015-02-17 23:39           ` Kelly Dean
2015-02-18 22:29             ` Stefan Monnier
2015-02-19 10:32               ` Kelly Dean
2015-02-19 13:23                 ` Stefan Monnier
2015-02-20  0:11                   ` Kelly Dean
2015-02-20  2:02                     ` Stefan Monnier
2015-02-22  4:11                       ` Proposal for a closed-buffer tracker Kelly Dean
2015-02-22 15:53                         ` Eli Zaretskii [this message]
2015-02-22 22:03                           ` Stefan Monnier
2015-02-22 22:23                             ` Dmitry Gutov
2015-02-23 13:53                               ` Artur Malabarba
2015-02-23 16:44                                 ` Eli Zaretskii
2015-02-22 21:59                         ` Stefan Monnier
2015-02-28 10:15                         ` Artur Malabarba

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a906c58q.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=kelly@prtime.org \
    /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 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).