On 18/09/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> On 9/17/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
> > * Expose the whole history in $history as recently discussed.
>
> I did this in my internal tree. Observations:
>
> * This makes the output of 'set' meaningless, since $history alone is
> several screenfulls.
This is generic a problem with ``set``. It means any big array is
inconvenient in fish. I'd rather change ``set`` to shorten long
arrays. One approach is to restrict the number of values (e.g. ``a b
c ... x y z``), but perhaps restricting the total string length is
even better (e.g. ``aaaaaaaaa...aaaa bbb c``).
The downside is that the output of ``set`` ceases to be reliably
parsable. I don't think that's important. Perhaps shortening only
when the output is a terminal is best.
> * The indexes for history items change all the time, making it hard to
> keep track of history items.
>
True enough. Let's use normal order then, growing at the end. The
last commands will still be easily accessible with negative indexing.
> In conclusion, a $history variable seems to me to be a solution that
> is great on paper and a pain in practice. My way was bad and the bash
> way is better. Unless someone has some good arguments, I'm going to
> implement a history builtin like in bash.
>
A builtin whose only purpose is accessing something which is
essentially an array means two interfaces to a single concept. It
violates the law of orthogonality. Unless someone has good arguments,
history should be just an array.
> > * Expose the history of command-line editing commands in
> > $__fish_edit_history or something like that. The motivation is
> > commands like M-. that notice when they are used repeatedly.
>
> A detailed suggestion of exactly how this should be exposed, and what
> information is critical would be needed.
>
Looking at Emacs' facilities for this, it's enough to remember only
the last editing command (what's enough for Emacs is surely enough for
us :-). Let $__fish_last_edit_command be one string containg the last
editing command executed (builtin, function name or arbitrary string,
whatever was on the right side of bind/inputrc). Every keyboard
sequence must set it (to '' if there is some problem computing the
real name).
Then, I could do something like this::
function yank-last-arg
if [ $__fish_last_edit_command = yank-last-arg ]
set -g __yank-last-arg_index (expr $__yank-last-arg_index + 1)
commandline $__yank-last-arg_base_cmd
else
set -g __yank-last-arg_base_cmd (commandline)
set -g __yank-last-arg_index 1
end
commandline -a (commandline -o $history[-$__yank-last-arg_index])[-1]
end
For such tasks you could just expose a counter of how many times the
current command was repeated - but that would be weaker and one day
somebody will write several cooperating commands.
> > * Add options to ``commandline`` for quering and moving the cursor position.
>
> Definitely. How about using -C/--cursor-pos to set the commandline
> buitlin in 'cursor-mode', so that 'commandline -C' will output the
> cursor position, and 'commandline -C POS' will move the cursor to POS?
>
Sounds good.
--
Beni Cherniavsky <[EMAIL PROTECTED]>, who can only read email on weekends.
-------------------------------------------------------------------------
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
