Feature suggestion: iswitchb should have an option to show virtual buffers like ido does

Feature suggestion: iswitchb should have an option to show virtual buffers like ido does

[Tom]

I see ido now has a virtual buffers option which shows unopened
matching buffers from the recent files list:


 	(defcustom ido-use-virtual-buffers nil
  "If non-nil, refer to past buffers as well as existing ones.
Essentially it works as follows: Say you are visiting a file and
the buffer gets cleaned up by midnight.el.  Later, you want to
switch to that buffer, but find it's no longer open.  With
virtual buffers enabled, the buffer name stays in the buffer
list (using the `ido-virtual' face, and always at the end), and if
you select it, it opens the file back up again.  This allows you
to think less about whether recently opened files are still open
or not.  Most of the time you can quit Emacs, restart, and then
switch to a file buffer that was previously open as if it still
were."



I suggest adding an option to iswitchb to get this behavior.

iswitchb does have an option for virtual buffers, but it shows
them only if there is no match in the list of open buffers
(so if you type "list" then it doesn't show the unopened
file "list-test.c" if, say, there is a "list.c" buffer open):

(defcustom iswitchb-use-virtual-buffers nil
  "If non-nil, refer to past buffers when none match.
..."


ido's version is much more useful, because it completely blurs
the difference between buffer switching and file opening and there is
no need to explicitly open files if you want to switch to a
recently used file.


iswitchb should also support that.

Re: Feature suggestion: iswitchb should have an option to show virtual buffers like ido does

[Richard Riley]

Tom <adatgyujto@gmail.com> writes:

> I see ido now has a virtual buffers option which shows unopened
> matching buffers from the recent files list:
>
>  	(defcustom ido-use-virtual-buffers nil
>   "If non-nil, refer to past buffers as well as existing ones.
> Essentially it works as follows: Say you are visiting a file and
> the buffer gets cleaned up by midnight.el.  Later, you want to
> switch to that buffer, but find it's no longer open.  With
> virtual buffers enabled, the buffer name stays in the buffer
> list (using the `ido-virtual' face, and always at the end), and if
> you select it, it opens the file back up again.  This allows you
> to think less about whether recently opened files are still open
> or not.  Most of the time you can quit Emacs, restart, and then
> switch to a file buffer that was previously open as if it still
> were."
>
> I suggest adding an option to iswitchb to get this behavior.
>
> iswitchb does have an option for virtual buffers, but it shows
> them only if there is no match in the list of open buffers
> (so if you type "list" then it doesn't show the unopened
> file "list-test.c" if, say, there is a "list.c" buffer open):
>
> (defcustom iswitchb-use-virtual-buffers nil
>   "If non-nil, refer to past buffers when none match.
> ..."
>
> ido's version is much more useful, because it completely blurs
> the difference between buffer switching and file opening and there is
> no need to explicitly open files if you want to switch to a
> recently used file.
>
> iswitchb should also support that.

Or use ido mode which is fast gaining popularity and is a superset of
what iswitchb provides. Why duplicate effort? Ido mode now ships with
emacs and more and more modes integrate with it in the from of using ido
to complete all input prompts.

Re: Feature suggestion: iswitchb should have an option to show virtual buffers like ido does

[Tom]

Richard Riley <rileyrg <at> gmail.com> writes:
> 
> Or use ido mode which is fast gaining popularity and is a superset of
> what iswitchb provides. Why duplicate effort? Ido mode now ships with
> emacs and more and more modes integrate with it in the from of using ido
> to complete all input prompts.

It's also a possibility though I like the look of iswitchb better. Maybe
ido can be confgiured to look like iswitchb.

BTW, there is one feature which ido could implement. This virtual buffer
concept could be extended, so that the user can specify additional lists,
not just recent files.

For example, if I work on a project then there are files in it which
I open only rarely, so these files are not on the recent files list.
In this case I would compile the list of all files in the project and
tell ido to also use this list. This way ido would list matches from
the buffer list first, then from the recent files and then also from
the list of project files. 

And I could I add more than one such lists, so I could cover all the
usual places from where I open files. This would almost completely
elminate the need for any kind of file opening. Every file could be 
accessed conveniently with a simple buffer switching regardless if
it is open or not.

Re: Feature suggestion: iswitchb should have an option to show virtual buffers like ido does

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Fri, Jan 13, 2012 at 10:11 AM, Tom <adatgyujto@gmail.com> wrote:

>
> BTW, there is one feature which ido could implement. This virtual buffer
> concept could be extended, so that the user can specify additional lists,
> not just recent files.
>
> For example, if I work on a project then there are files in it which
> I open only rarely, so these files are not on the recent files list.
> In this case I would compile the list of all files in the project and
> tell ido to also use this list. This way ido would list matches from
> the buffer list first, then from the recent files and then also from
> the list of project files.
>

I would absolutely love to see such a capability.

Today I already place in the root directory of each of my projects a list
of paths to all of the files in that project.  I make a project current by
loading that file into s special buffer.  Finally I have a special key
binding that uses that buffer and completion to open any project file.

Ideally I would have ido seach upwards through the directory tree starting
from the directory part of buffer-file-name for something like
.ido-project-files.

Such ido integration would eliminate my separate key binding and the
awkward statefulness of my current project files buffer.

/john

[-- Attachment #2: Type: text/html, Size: 1672 bytes --]

Re: Feature suggestion: iswitchb should have an option to show virtual buffers like ido does

[Tom]

John Yates <john <at> yates-sheets.org> writes:

> Ideally I would have ido seach upwards through the directory
> tree starting from the directory part of buffer-file-name for
> something like .ido-project-files.
>
> Such ido integration would eliminate my separate key binding
> and the awkward statefulness of my current project files
> buffer.


I don't think that should be integrated into ido or at least only if 
it builds upon a more general feature.

The basic feature would be to specify additional lists for ido besides
recent files, so one could specify other groups of files too for
completion.

Project files is a special case of this which could easily be implemented
if the above feature is added, but this feature could be useful in
other cases too (e.g. I sometimes look into emacs .el source files,
so I would create a list of all emacs lisp source files, so I could
simply switch to any of them without having to use find-file), so the
implementation should not be narrowed down only to the case of project
files.

BTW, if this generic feature is added then ido should also use the
code in the uniquify package, so it can indicate the difference
if two files with the same names are matching, but they
are in different directories. In this case the file name without
directory is not enough to know which file is which.

Re: Feature suggestion: iswitchb should have an option to show virtual buffers like ido does

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On Fri, Jan 13, 2012 at 2:59 PM, Tom <adatgyujto@gmail.com> wrote:

I don't think that should be integrated into ido or at least only if
> it builds upon a more general feature.
>

I fully agree.  I am all for generality.  My main point was to warn against
limiting ourselves to static lists.


> The basic feature would be to specify additional lists for ido besides
> recent files, so one could specify other groups of files too for
> completion.
>

As I see it the basic ido framework is an ordered list of sets of names.
 ido presents a completion list built by collecting - in list order - match
candidates from each set of names.  My suggestion is these sets of names
may be concrete (e.g. actual buffers, recentf's files list, user provided
list, etc) or they may be lazy (e.g. a function conforming to an ido
defined API).  Lazy evaluation has the added virtue that it is less likely
to impact emacs start up.

I sometimes look into emacs .el source files,
> so I would create a list of all emacs lisp source files, so I could
> simply switch to any of them without having to use find-file


My solution is to append to load-path source directories which have be
separated from their corresponding .elc's.  (Emacs still loads a .elc in
preference to a .el or .el.gz even when the .elc shows up further down the
path.)  After that I can open emacs source via ilocate-library-find-source (
https://github.com/emacsmirror/ilocate-library.git) using only the file
name.  And I get completion support.

BTW, if this generic feature is added then ido should also use the
> code in the uniquify package, so it can indicate the difference
> if two files with the same names are matching, but they
> are in different directories. In this case the file name without
> directory is not enough to know which file is which.
>

Absolutely.

/john

[-- Attachment #2: Type: text/html, Size: 2711 bytes --]