I think it's useful to ask why a user might want a case insensitive completion, d whether that use case needs wildcard expansion. My guess is that users want case insensitive completion in simple and quick cases. In more complicated situations (where they are taking the trouble to use wildcards), case insensitivity probably ought to be indicated by the search expression.
So my preference would to indicate the desired case sensitivity explicitly in the wildcard string and do the expansion based on that. In the absence of some way to do that, I actually think that your option: >* Do not provide any case insensitive completions for string > containing expansion characters like wildcards. This is inconsistent > and limits the usability of case insensitive completions. would actually be pretty workable from an end user standpoint. Now limiting the usefulness of completion functions is another matter. I haven't played around with doing custom completion routines in fish, yet, so I don't have good sense of the issues there. Greg On Thu, 2007-03-01 at 23:25 +0100, Axel Liljencrantz wrote: > I have been experimenting a bit with implementing case insensitive tab > completions. There is a working implementation in the darcs repo, but > it is not without corner cases. > > My current thoughts on the subject: > > I like the idea of using case insensitive completions as a fallback > when case sensitive completions fail. This makes it possible for fish > to fix simple errors in case, and makes it very straight forward to > write completions that dont care about case. > > I have implemented this mode of operation for almost all types of completions. > > The question that remains is if casing of the original string should > be updated to match the completion. In some cases, this is needed for > case insensitive completions to make sense. Take file and variable > name completion for example. But on the other hand, changing the case > of the string on the commandline is intrusive, and in the general case > it is _really_ hard. There can be more than one way to change the > casing of a token to get a meaningful result. If the user is trying to > complete the string 'echo *aB*c' in a dirtectory containing the files > 'dabdcd' and 'aABdcd', it is not well defined if the replacement > string should be '*AB*cd' or '*ab*cd'. In the end, modifying the > completion token does not play nice with complicated completion modes > like providing file completion of tokens containing brace expansion, > wildcards and variable expansion. There are a few ways out of this: > > * Never modify the case of the original token. This greatly reduces > the usefulness of case insensitive completions of e.g. files. > * Do not provide any case insensitive completions for string > containing expansion characters like wildcards. This is inconsistent > and limits the usability of case insensitive completions. > * Only modify the case of the original token if it does not contain > wildcards. This is inconsistent and potentially confusing. > * Implement an algorithm that allows us to modify the case of tokens > containing variable expansions, brace expansions, etc. This is > defintely non-trivial, and as the example above showed, there may be > more than one possible solution. Still, I'm pretty sure it is > possible. Implementing this will take time. > > It is of course possible to completely scrap this idea as well. It > would also be possible to only turn it on case insensitive completions > for things that truly don't care about case, like the name of > charsets. > > Did I miss anything? Does anybody have an opinion on which one of > these would be preferable? > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
