couple of zsh features

couple of zsh features

[Matt Liggett]

Fellow zsh hackers,

I was talking to a friend about shells the other night when the 
discussion of a couple of neat features came up.  There are a couple 
of features which we both thought could be very valuable and I'd like 
to know if anyone is working or has worked on them so I don't 
re-invent the wheel if I decide to delve into the source.

1) Right-hand command prompting.

   I know about RPS*, but how about a right-hand command prompt like 
so:

213 19:22                                                  <seven:~
213 19:22                                                 l<seven:~
213 19:22                                                ls<seven:~
213 19:22                                               ls <seven:~
213 19:22                                              ls -<seven:~
213 19:22                                             ls -l<seven:~

This shows how the line would progress as each command was typed.  
The stuff on the left is what I tend to keep in my prompt (history 
number and time).  I think this sort of "right justifying" could be a 
good visual clue for some people and help them set commands off from 
output.

2) `oops'

    Any of you ever used Infocom games or other interactive fiction?  
The construct is simple:

> get sord

?- What's a sord?

> oops sword

Taken.


In this example, it doesn't save you much work, but it can many other 
times.  What oops does is takes the first word that failed to parse 
correctly in the previous line and replaces it with its argument.  
Maybe some kind of compctl-based matching could be used to determine 
which word in the previous command was a likely mismatch.

Thoughts?

--
http://seven.ucs.indiana.edu/~mliggett |||        Matt Liggett       |
$_="5673089a34120b12c048de12f\n"; ///  |||   <mliggett@indiana.edu>  |
@j=split//," erthJusanoPlck.";   ///   |||   '70 Midget '74 Bronco   |
s/./$j[hex $&]/ge;print         ///    |||       '78 Civic 1200      |

Re: couple of zsh features

[Barton E. Schaefer]

On Dec 7, 11:31am, Matt Liggett wrote:
} Subject: couple of zsh features
}
} 1) Right-hand command prompting.
} [...]  I think this sort of "right justifying" could be a 
} good visual clue for some people and help them set commands off from 
} output.

I think you ought to think about this a bit longer.  Anybody who is
that confused about what's a command and what's output shouldn't be
driving a shell without supervision.

} 2) `oops'
} 
} What oops does is takes the first word that failed to parse 
} correctly in the previous line and replaces it with its argument.  

Have you tried "setopt correctall"?

I do think correctall would be more usable if you could actually enter
the corrected spelling at the SPROMT, rather than merely accepting or
rejecting the guess and then having to go back to zle to edit the line.

} Maybe some kind of compctl-based matching could be used to determine 
} which word in the previous command was a likely mismatch.

It might be useful to have the word or character position of the last
failed correction available to compctl, and to have a history reference
for the last unknown command or syntax error.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: couple of zsh features

[Matt Liggett]

At Thu, 7 Dec 1995 09:29:00 -0800, Barton E. Schaefer writes:
> On Dec 7, 11:31am, Matt Liggett wrote:
> } 1) Right-hand command prompting.

> I think you ought to think about this a bit longer.  Anybody who is
> that confused about what's a command and what's output shouldn't be
> driving a shell without supervision.

I can tell what's what, but it could save me the odd 0.75 second here 
or there when I'm scanning up to find the command.

> } 2) `oops'

> Have you tried "setopt correctall"?

Yes, but this would be a less active correction (more passive?) by 
the shell, and would be a bit more powerful.

> I do think correctall would be more usable if you could actually enter
> the corrected spelling at the SPROMT, rather than merely accepting or
> rejecting the guess and then having to go back to zle to edit the line.

Yes, this would be nearly as good.  Hmm...

--
http://seven.ucs.indiana.edu/~mliggett |||        Matt Liggett       |
$_="5673089a34120b12c048de12f\n"; ///  |||   <mliggett@indiana.edu>  |
@j=split//," erthJusanoPlck.";   ///   |||   '70 Midget '74 Bronco   |
s/./$j[hex $&]/ge;print         ///    |||       '78 Civic 1200      |

Re: couple of zsh features

[Barton E. Schaefer]

On Dec 7, 12:59pm, Matt Liggett wrote:
} Subject: Re: couple of zsh features
}
} At Thu, 7 Dec 1995 09:29:00 -0800, Barton E. Schaefer writes:
} > On Dec 7, 11:31am, Matt Liggett wrote:
} > } 1) Right-hand command prompting.
} 
} > I think you ought to think about this a bit longer.  Anybody who is
} > that confused about what's a command and what's output shouldn't be
} > driving a shell without supervision.
} 
} I can tell what's what, but it could save me the odd 0.75 second here 
} or there when I'm scanning up to find the command.

I still think there's got to be a better way than right-justified prompts.
Can you imagine what kind of hoops zle would have to jump through to edit
a single right-justified line that was wider than the screen?  What would
you have that look like?  Multi-line commands (PROMPT2) would be ghastly,
too, from a readability standpoint if nothing else.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: couple of zsh features

[Richard Coleman]

> I do think correctall would be more usable if you could actually enter
> the corrected spelling at the SPROMT, rather than merely accepting or
> rejecting the guess and then having to go back to zle to edit the line.
> 
> } Maybe some kind of compctl-based matching could be used to determine 
> } which word in the previous command was a likely mismatch.
> 
> It might be useful to have the word or character position of the last
> failed correction available to compctl, and to have a history reference
> for the last unknown command or syntax error.

I've also been thinking about similar things.  A lot of the recent
work in zsh has moved more of the intelligence in the code into
the hashtable code.  To use an overused buzz-word, the internals
of zsh have become more `object-oriented' in some sense.  This is
a trend I would like to continue.  The next thing would be to move
some of the command completion and spelling correction code into
hashtable.c.  So (in some sense) each type of object (alias, builtin,
etc...) would know how to complete itself, or spell check itself.
Once this is done, I think we could generalize the code so that both
spelling correction and command completion would be  programmable
in similar ways.

Just a thought.

rc

Re: couple of zsh features

[Bas V. de Bakker]

Matt Liggett <mliggett@seven.ucs.indiana.edu> writes:

> I can tell what's what, but it could save me the odd 0.75 second here 
> or there when I'm scanning up to find the command.

But there is a way to do this.  Put an escape sequence in your prompt
to make the text boldface, red, blinking, whatever your terminal can
handle.  Then set the POSTEDIT variable to the sequence that resets
this feature.

Bas.

Re: couple of zsh features

[Thomas Pierre Schweikle]

At 10:07 Uhr 08.12.1995, Bas V. de Bakker wrote:
> Matt Liggett <mliggett@seven.ucs.indiana.edu> writes:
>
> > I can tell what's what, but it could save me the odd 0.75 second here
> > or there when I'm scanning up to find the command.
>
> But there is a way to do this.  Put an escape sequence in your prompt
> to make the text boldface, red, blinking, whatever your terminal can
> handle.  Then set the POSTEDIT variable to the sequence that resets
> this feature.

Quite the best way to find out where the last command was typed! But on
some (elderly) terminals this might not work - they don't have colours,
blinking, bold or even inverse! There is a solution too: just print a line
containing some 80 characters all the same:

-----------------------------------------------------------------------------
Like the above! I do this to find my way inbetween commands and there
output - expecialy when using terminal emulators. Most of them don't even
have inverse.

-- Thomas

Re: couple of zsh features

[Sven Wischnowsky]

Richard Coleman wrote:

> 
> > I do think correctall would be more usable if you could actually enter
> > the corrected spelling at the SPROMT, rather than merely accepting or
> > rejecting the guess and then having to go back to zle to edit the line.
> > 
> > } Maybe some kind of compctl-based matching could be used to determine 
> > } which word in the previous command was a likely mismatch.
> > 
> > It might be useful to have the word or character position of the last
> > failed correction available to compctl, and to have a history reference
> > for the last unknown command or syntax error.
> 
> I've also been thinking about similar things.  A lot of the recent
> work in zsh has moved more of the intelligence in the code into
> the hashtable code.  To use an overused buzz-word, the internals
> of zsh have become more `object-oriented' in some sense.  This is
> a trend I would like to continue.  The next thing would be to move
> some of the command completion and spelling correction code into
> hashtable.c.  So (in some sense) each type of object (alias, builtin,
> etc...) would know how to complete itself, or spell check itself.
> Once this is done, I think we could generalize the code so that both
> spelling correction and command completion would be  programmable
> in similar ways.
> 
> Just a thought.
> 

Oh yes. I thought about that a lot when I was working on
zle_tricky. It would be nice to turn that completion code into a
general `produce a list of what we need here'-code. The main problem
(I think) is that we would need a good internal representation for
lexed (and parsed) command lines that would be used throughout the
whole code. Once we had this, it wouldn't be too complicated to turn
the completion code (and merge it with the correction code) into the
above mentioned list-generator (we probably would also have to add
some more possibilities for describing command arguments).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de