I just sent you a change which ignores the ./ if the history item starts
with a ./ but the current command does not.
If they both begin with "./" then things will be matched as usual.
As it stands right now, the patches I've written implement the "combo"
behavior.
is the "darcs send" command what I should be using??? I'm more used to using
CVS/SVN...
thanks!
-=Abe
On Mon, Feb 2, 2009 at 10:43 AM, Abe Bachrach <[email protected]> wrote:
> 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
