Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99824: 2010-04-04 John Wiegley <jwiegley@gmail.com>

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99824: 2010-04-04 John Wiegley <jwiegley@gmail.com>

[Stefan Monnier]

Hi John,

Always happy to see your contributions.

Just a few points about this last one to ido.el, which might be good for
other people to hear as well:
- Please start your commit messages with one line that summarizes the
  change (so that "bzr log --short" gives useful info).
- Don't expect the commit message (and/or the ChangeLog) to be read by
  end-users, so to advertise new end-user features, put them in
  etc/NEWS instead.
- Before putting extra text in the change message, think whether it
  would be appropriate as a comment in the code instead.  Between the
  two, we usually prefer comments.

One more thing, while I'm here: IIUC this new feature doesn't work well
when you have multiple files with the same name in different
directories, right?  I mean, it would be good to extend this feature to
work well together with uniquify.el.


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99824: 2010-04-04 John Wiegley <jwiegley@gmail.com>

[John Wiegley]

On Apr 4, 2010, at 2:20 PM, Stefan Monnier wrote:

> Just a few points about this last one to ido.el, which might be good for
> other people to hear as well:
> - Please start your commit messages with one line that summarizes the
>  change (so that "bzr log --short" gives useful info).
> - Don't expect the commit message (and/or the ChangeLog) to be read by
>  end-users, so to advertise new end-user features, put them in
>  etc/NEWS instead.
> - Before putting extra text in the change message, think whether it
>  would be appropriate as a comment in the code instead.  Between the
>  two, we usually prefer comments.

Thanks, Steven, I'll make the appropriate the changes.  I also thought about the uniqify tie-in, but didn't do it this time around because in practice it has never been that big of a deal.  When there are two files of the same name, you only get to select the most recent of the time via virtual buffers, but this has almost always been the one I wanted anyway.  But I do agree this feature should be added for completeness, and I'll put it on my work list.

John

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99824: 2010-04-04 John Wiegley <jwiegley@gmail.com>

[Juanma Barranquero]

I'm not sure the virtual buffers behavior makes much sense for
ido-kill-buffer. You cannot "kill" nonexistent buffers, you *don't*
want to kill the file, and you cannot kill the entry from the buffer
list.

So, I think either the following patch should be installed (plus
changes to a few docstrings, of course) or ido-kill-buffer "fixed" to
remove the nonbuffer entry from the buffer list. The problem with that
second option is that, to work right, it should either modify the
recentf list (which would likely be surprising to the user), or jump a
few hoops to maintain a list of buffers killed from the ido list but
still present into the recentf list. A bit hackish for so short a
reward, IMHO.

    Juanma


=== modified file 'lisp/ido.el'
--- lisp/ido.el	2010-04-06 18:17:55 +0000
+++ lisp/ido.el	2010-04-14 11:40:45 +0000
@@ -4078,5 +4078,6 @@
 For details of keybindings, see `ido-switch-buffer'."
   (interactive)
-  (ido-buffer-internal 'kill 'kill-buffer "Kill buffer: "
(buffer-name (current-buffer)) nil 'ignore))
+  (let (ido-use-virtual-buffers)
+    (ido-buffer-internal 'kill 'kill-buffer "Kill buffer: "
(buffer-name (current-buffer)) nil 'ignore)))

 ;;;###autoload