iswitchb

iswitchb

[Richard Stallman]

After trying iswitchb for several days, I concluded it was not very
helpful, and was occasionally a pain in the neck.

It is not very helpful for me because I know what buffer I want to go
to and I start typing the beginning of it without looking at anything.
The only way iswitchb could help me is if I were to look at its
display to try to find a shorter string that would work.  But that
would slow me down.

iswitchb was a pain in the neck when I wanted to go to buffer inout
and it kept taking me to 4inout and 5inout instead.  I did not at first
even see what was happening.  When I did see, I still didn't know
a way to prevent it.  I suppose there is some iswitchb feature I
could use, but rather than learn it, I turned off iswitchb.

I don't think this feature should be enabled by default.

Re: iswitchb

[paul r]

2008/3/19, Richard Stallman <rms@gnu.org>:
> After trying iswitchb for several days

Thanks for that.

>  It is not very helpful for me because I know what buffer I want to go
>  to and I start typing the beginning of it without looking at anything.
>  The only way iswitchb could help me is if I were to look at its
>  display to try to find a shorter string that would work.  But that
>  would slow me down.

In some cases, I think it can help, especially for buffers you did not
open yourself but were opened automatically by emacs or by some mode.

>  iswitchb was a pain in the neck when I wanted to go to buffer inout
>  and it kept taking me to 4inout and 5inout instead.  I did not at first
>  even see what was happening.  When I did see, I still didn't know
>  a way to prevent it.  I suppose there is some iswitchb feature I
>  could use, but rather than learn it, I turned off iswitchb.

I warned about this eventuality when you asked how does iswitchb
behave, last week.
IIRC, in this thread, some people agreed that :
  - what is really helpful in iswitchb in the possibility to enter any
substring of the buffer name to find it, but this could be implemented
into current default switch-to-buffer.
  - occasionaly, real-time display of matching buffer can help, but if
you think it clutters, that could be disabled by default. Or at least
it could be let to the user to disable it as an option.
  - C-s and C-r to cycle through matches are not intuitive enought,
some better idea about how to disambiguate buffer names should be
proposed.

Re: iswitchb

[Don Armstrong]

On Wed, 19 Mar 2008, paul r wrote:
>   - what is really helpful in iswitchb in the possibility to enter
> any substring of the buffer name to find it, but this could be
> implemented into current default switch-to-buffer.

What probably should be adjusted here is the ordering when you've
typed in the exact name of a buffer; that buffer should just come to
the front of the list (with possible exceptions for foo<1> et al?).
That way iswitchb will get out of the way of people who expect the old
behavoir, but allow people to gradually learn the new behavoir.

>   - C-s and C-r to cycle through matches are not intuitive enought,
> some better idea about how to disambiguate buffer names should be
> proposed.

This is how most everything does forward and reverse searching, so
it's not that unintuitive.


Don Armstrong

-- 
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the people
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
 -- Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p390)

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: iswitchb

[Daniel Colascione]

On Wednesday 19 March 2008 10:51:28 pm Don Armstrong wrote:
> >   - C-s and C-r to cycle through matches are not intuitive enought,
> > some better idea about how to disambiguate buffer names should be
> > proposed.
>
> This is how most everything does forward and reverse searching, so
> it's not that unintuitive.

What about this?

(define-key iswitchb-mode-map [(left)] #'iswitchb-prev-match)
(define-key iswitchb-mode-map [(right)] #'iswitchb-next-match)

I think of buffer switching as a funny kind of isearch.

Re: iswitchb

[paul r]

> What probably should be adjusted here is the ordering when you've
>  typed in the exact name of a buffer; that buffer should just come to
>  the front of the list (with possible exceptions for foo<1> et al?).
>  That way iswitchb will get out of the way of people who expect the old
>  behavoir, but allow people to gradually learn the new behavoir.

Yes, that what I thought later, reading again RMS case. In any case,
*exact match* should alway take you to this buffer, with the exception
of when you already are in this buffer.
More generaly, I agree iswitchb should behave like switch-to-buffer
for features they share.

Re: iswitchb

[Stefan Monnier]

>> What probably should be adjusted here is the ordering when you've
>> typed in the exact name of a buffer; that buffer should just come to
>> the front of the list (with possible exceptions for foo<1> et al?).
>> That way iswitchb will get out of the way of people who expect the old
>> behavoir, but allow people to gradually learn the new behavoir.

> Yes, that what I thought later, reading again RMS case. In any case,
> *exact match* should alway take you to this buffer, with the exception
> of when you already are in this buffer.
> More generaly, I agree iswitchb should behave like switch-to-buffer
> for features they share.

The completion package that I use (and that I ultimately would like to
install as the default, tho it needs a lot of work or a rewrite) does
the following:
1 - first try completion the old way.
2 - if that fails, try completion the partial-completion-mode way.
3 - if that fails, try it with a substring search.

So compared to the current default completion, the behavior should be
different only if the default completion finds no completion.

Combined with icomplete-mode, it is reminiscent of ido and iswitchb.


        Stefan

Re: iswitchb

[paul r]

2008/3/20, Stefan Monnier <monnier@iro.umontreal.ca>:

> The completion package that I use (and that I ultimately would like to
>  install as the default, tho it needs a lot of work or a rewrite) does
>  the following:
>  1 - first try completion the old way.
>  2 - if that fails, try completion the partial-completion-mode way.
>  3 - if that fails, try it with a substring search.
>
>  So compared to the current default completion, the behavior should be
>  different only if the default completion finds no completion.
>
>  Combined with icomplete-mode, it is reminiscent of ido and iswitchb.

Sounds good. Is there somewhere we can find this package ?

minibuffer completion functions [was: iswitchb]

[Drew Adams]

> The completion package that I use (and that I ultimately would like to
> install as the default, tho it needs a lot of work or a rewrite) does
> the following:
> 1 - first try completion the old way.
> 2 - if that fails, try completion the partial-completion-mode way.
> 3 - if that fails, try it with a substring search.

I certainly hope that will _not_ be adopted as the default behavior. Add it
as another, alternative behavior, if you like, but please leave the default
behavior alone.

It is not necessarily the case that a user or a Lisp caller of
`completing-read' (or another completing function) _wants_
partial-completion or substring completion to occur when the standard prefix
completion fails. There must be a way to get today's default behavior (and
that way should remain the default behavior).


The change that I would like to see for minibuffer completion is just to
have `completing-read' and `read-file-name' do the following:

1. Retain their current signatures (arg lists) - no change.

2. Funcall the value of a global variable: `completing-read-fn' or
`read-file-name-fn', if non-nil, to perform the completion. Else call a
default completing function, `completing-read-default' or
`read-file-name-default'.

That is, move the current behavior of `completing-read' and `read-file-name'
to new functions that perform that behavior as the default case. Change the
current completion functions to be just wrappers that call either the value
of a variable or the default function.

This simple change would keep the behavior we have now as the default. But
it would also allow flexibility for packages and users that want to use
different completion mechanisms, and it would help such packages play better
together.


Example: Icicles (just an example that I'm familiar with) and Viper mode
each adapt `read-file-name', in different ways, for their own use. Icicles
does this by redefining `read-file-name' when in Icicle mode (it is restored
when you leave the mode). Viper does it by advising `read-file-name'. If you
load Icicles first, the two play well together; if you load Viper first,
they do not, obviously. Neither redefining nor advising is a great approach
here, IMO.

With what I propose, a package can define its own completion function. That
function would have the same signature as `read-file-name' (or
`completing-read'), and it would bind or set its completion function as the
value of `read-file-name-fn', for use in some context (e.g. a minor mode).

This function definition for a package could then, to do part of its job,
call either `read-file-name-default' or the function that was the current
value of `read-file-name-fn' at the time of the package's own definition of
that variable. Or it could just do its own thing altogether, from scratch.
That is, the package's completion function could reuse the existing
completion mechanism (default or current) in some way, or it could ignore it
altogether. This is similar to the various defadvice possibilities (before,
after, replace).

I think this would be a simple and clean way to provide flexibility for
minibuffer completion. It is an alternative to using advice that I think is
better, in this case.

You might ask why a package doesn't just define and then use its own
completion function - why have it make the standard `completing-read' or
`read-file-name' adopt the package's way of completing? The reason is that
by going through the standard Emacs completion functions as a dispatcher,
all code that calls `completing-read' or `read-file-name' can take advantage
of the package's completion mechanism.

This is why, for instance, Icicles redefines `completing-read', even though
its redefinition never calls the original `completing-read'. The idea is to
let users take advantage of Icicles completion everywhere that
`completing-read' (or `read-file-name') is used (while in Icicle mode). Your
code need not be rewritten to call `icicle-completing-read'; it is enough
that it calls `completing-read'.

I don't want to argue about this (but I'm willing to clarify or discuss it).
If you don't like such an approach, fine. But in that case, please at least
leave the signature and default behavior of `completing-read' and
`read-file-name' alone. Some users and some packages count on those
functions doing what they do now.

If you do adopt an approach like I suggest, then you can always write a mode
or package that does what you want (tries prefix-, then partial-, then
substring-completion), and your preferred behavior will be available to
users without altering the default behavior. Just like any other completion
package.

Re: iswitchb

[Richard Stallman]

I am not trying to propose any change in iswitchb.
If the people who use it like it, why change it?
However, I object to making it the default.

Re: iswitchb

[Don Armstrong]

On Thu, 20 Mar 2008, Richard Stallman wrote:
> I am not trying to propose any change in iswitchb.

Sure, but I did.

> If the people who use it like it, why change it?
> However, I object to making it the default.

The suggestion was a change that would overcome (from what I saw) the
major problem that you and others like you who are used to the current
behavoir had, hopefully allowing it to become the default.

I know I personally wish I had known about iswitchb far earlier than I
learned about it, and I suspect that I'm not the only one.

Don Armstrong

-- 
Do not handicap your children by making their lives easy.
 -- Robert Heinlein _Time Enough For Love_ p251

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: iswitchb

[Richard Stallman]

    The suggestion was a change that would overcome (from what I saw) the
    major problem that you and others like you who are used to the current
    behavoir had, hopefully allowing it to become the default.

Thanks but no thanks.