unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tassilo Horn <tassilo@member.fsf.org>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: Leo <sdl.web@gmail.com>, emacs-devel@gnu.org
Subject: Re: Concerning the new `ido-use-virtual-buffers' feature
Date: Wed, 2 Jun 2010 10:29:02 +0200	[thread overview]
Message-ID: <201006021029.04372.tassilo@member.fsf.org> (raw)
In-Reply-To: <AANLkTikTDRtnbzNHTzVlMvHyl0pDHuhpQLu5k8Il4vP0@mail.gmail.com>

On Wednesday 02 June 2010 09:23:50 you wrote:

Sorry for removing the list and Leo on my last reply to Juanma.

> > I don't think so.  `C-x b foo RET' is in my muscle memory, and when
> > I use `C-x b' I know what buffer/file I want to open.  I don't want
> > to worry about if it is an open buffer or a recent file.  With `C-o'
> > toggling only, I always have know if that file is already visited in
> > a buffer.
> 
> If you always remember the file you want to edit, then yes. My point
> is that if you don't remember (that happens to me a lot, I remember
> what I was doing but I forget the file name), having to do C-o defeats
> having auto.

So you would have no virtual buffers by default and just enable them
when you don't remember the file name?  So why not enable them by
default?

For me, the reason to use ido is because substring matching is very
quick: I type C-x b foo RET without even looking at the completions.  In
99% of all cases, it brings me to the right buffer, unless virtual
buffers are enabled.  In that case, it will bring me to "foo.aux"
(recent file I had a look at some time ago) instead of "foo.tex"
(currently open for editing).

The 'auto value enables that DWIM behavior also for recent files for
me.  So when I type C-x b foo.a RET, I really want to open "foo.aux",
and still I don't have to care about if it is really open.

> Though the real fix, as I proposed, is having <tab> completion enable
> the virtual buffers temporarily.

From my point of view, that's not as good as the 'auto value, at least
in my usecase, because then I have to mentally distinguish between open
buffers and recent files.

So how about this: <tab> toggles virtual buffers temporarily, and if
`ido-use-virtual-buffers' is non-nil, then "no match" enables them, too.

So basically, `ido-use-virtual-buffers' non-nil does what 'auto does
with Leo's patch now.  There's no way to have virtual buffers per
default, which is pretty useless IMHO anyway.

I think <tab> should not only enable but toggle, because else I could
not create a new buffer "foo.a" if `ido-use-virtual-buffers' is non-nil.

What do you think?

Bye,
Tassilo



  parent reply	other threads:[~2010-06-02  8:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-27  9:56 Concerning the new `ido-use-virtual-buffers' feature Leo
2010-05-27 10:57 ` Tassilo Horn
2010-05-27 18:01   ` Leo
2010-05-27 19:05     ` Tassilo Horn
2010-05-28  1:21       ` Leo
2010-05-28  1:45         ` Leo
2010-05-28  6:21           ` Tassilo Horn
2010-05-28  9:07             ` Leo
2010-05-28  9:26               ` Leo
2010-05-28 10:35               ` Juanma Barranquero
2010-05-28 12:15                 ` Leo
2010-05-28 12:29                   ` Tassilo Horn
2010-05-29 14:15                     ` Leo
2010-06-01 23:54                       ` Juanma Barranquero
2010-06-02  3:28                         ` Leo
2010-06-02  5:57                           ` Juanma Barranquero
2010-06-02  9:43                             ` Leo
     [not found]                         ` <AANLkTilMurdEZBA-kiWHlS9-r0VK6W5v@mail.gmail.com>
2011-10-16 10:06                           ` Antoine Levitt
2013-07-06 12:57                             ` Leo Liu
     [not found] ` <201006020842.48913.tassilo@member.fsf.org>
     [not found]   ` <AANLkTikTDRtnbzNHTzVlMvHyl0pDHuhpQLu5k8Il4vP0@mail.gmail.com>
2010-06-02  8:29     ` Tassilo Horn [this message]
2010-06-02  9:28       ` Juanma Barranquero
2010-06-02  9:55         ` Tassilo Horn
2010-06-02 10:27           ` Juanma Barranquero
  -- strict thread matches above, loose matches on Subject: below --
2010-05-26 10:14 Tassilo Horn
2010-05-26 20:59 ` John Wiegley
2010-05-27  6:54   ` Tassilo Horn
2010-05-27  6:57     ` John Wiegley
2010-05-27  8:10       ` Tassilo Horn
2010-05-27  8:26         ` John Wiegley

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=201006021029.04372.tassilo@member.fsf.org \
    --to=tassilo@member.fsf.org \
    --cc=emacs-devel@gnu.org \
    --cc=lekktu@gmail.com \
    --cc=sdl.web@gmail.com \
    /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).