I like the combo option.
after playing with my changes for a while, one thing that I've realized
would also be good to handle is the special case of "./"
unlike in matlab which doesn't have the ./ before commands, when trying to
enter stuff in the linus shell, commands often have a ./ preceding them,
which means that matching the start of the string isn't as useful.
as a result, I think it would be good to ignore the ./ when matching at the
beginning of line for short strings
thanks!
-=Abe
On Sun, Feb 1, 2009 at 12:03 PM, Axel Liljencrantz
<[email protected]>wrote:
> Sorry for the extremely slow reply.
>
> Basically, I can see a few options for a changed behaviour:
>
> * Show matches to beginning of string first, and anywhere-matches
> afterwards.
> * Show matches at beginning of line only for short search strings, e.g.
> less than 3 characters.
> * Combo; Show matches to beginning of strings first, but only for short
> strings.
>
> Opinions on what is cooler, better or more intuitive?
>
>
> Axel
>
>
> 2008/11/7 Abe Bachrach <[email protected]>
>
> Needless to say, I do know how to touch type, however since the arrow keys
>> (on my keyboard) are not reachable from normal typing position and you have
>> to move your hand to them, it can be easier to type with my left hand while
>> moving to the arrow keys with my right...
>>
>> anyway, I had mentioned earlier that it might make sense to only search
>> the beginning first if the search is for 2 or less characters, which would
>> be totally trivial to do, but I had thought thought that the chance of a
>> "false-positive" was small enough with 3 or more characters that it wasn't
>> necessary to add that extra bit of logic, which might make the behavior more
>> "opaque".
>>
>> I just added this change and think it should fix your concerns, while
>> still allowing for the speedup gained from searching the start.
>>
>> (not really sure how darcs really is supposed to work... I did a "darcs
>> send" and had it send the patches to you, and to axel)
>>
>> thanks!
>> -=Abe
>>
>> On Thu, Nov 6, 2008 at 12:56 PM, Myrddin Emrys <[email protected]> wrote:
>>
>>> It does sound like a nice feature. My only concern is the use case where
>>> you just recently typed a command with a unique center rather than a unique
>>> beginning. In the past few days, I've had a lot of commands like this:
>>> fetchlist.rb; and ruby Script.rb; and some more stuff...
>>>
>>> fetchlist is a script I wrote to synchronize files between computers, and
>>> I use it a lot when I'm sshing in from work. So when I'm hopping back to the
>>> previous command, I'll usually search with 'Script' or 'ruby'. Specifically,
>>> if I search with ruby in your method, rather than bringing up the very
>>> recent command that had ruby in the middle, it'll jump to a very old command
>>> with ruby in the beginning.
>>>
>>> I still might be a good overall change... but you you should be aware
>>> that a single use failure of this sort (requiring the user to back out and
>>> search with a different string, or hit the up arrow a dozen times to find
>>> the correct result) would wipe out the savings of typing only one character
>>> rather than three a hundred times over.
>>>
>>> If you are a touch typist (and if you aren't, go learn now, it'll save
>>> you more time than ANY app, process, tool, or language you use) then typing
>>> three characters in under a second... you would have to save many many
>>> fractions of a second to make up for the confusions that a dual-mode search
>>> might cause.
>>>
>>> I could be wrong... if you're expecting dual modes, then it's quite
>>> likely that time could be saved. And if you can force a search to the
>>> beginning, maybe that would save time in other ways other than just typing
>>> shorter searches. But I suspect that overall it would be a net loss. It's
>>> hard to tell without actually gathering statistics both ways.
>>>
>>> But with something that's hard to call, it's usually smarter to go with
>>> the simpler system. Being quicker to learn trumps being faster to use.
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Fish-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/fish-users
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Fish-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fish-users
>>
>>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
