* Re: couple of zsh features
@ 1995-12-16 0:52 Thomas Pierre Schweikle
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Pierre Schweikle @ 1995-12-16 0:52 UTC (permalink / raw)
To: Bas V. de Bakker; +Cc: mliggett, zsh-workers
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: couple of zsh features
@ 1995-12-08 7:20 Sven Wischnowsky
0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 1995-12-08 7:20 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* couple of zsh features @ 1995-12-07 16:31 Matt Liggett [not found] ` <mliggett@seven.ucs.indiana.edu> 0 siblings, 1 reply; 8+ messages in thread From: Matt Liggett @ 1995-12-07 16:31 UTC (permalink / raw) To: zsh-workers 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 | ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <mliggett@seven.ucs.indiana.edu>]
* Re: couple of zsh features [not found] ` <mliggett@seven.ucs.indiana.edu> @ 1995-12-07 17:29 ` Barton E. Schaefer 1995-12-07 17:59 ` Matt Liggett 1995-12-07 20:22 ` Richard Coleman 1995-12-07 19:02 ` Barton E. Schaefer 1 sibling, 2 replies; 8+ messages in thread From: Barton E. Schaefer @ 1995-12-07 17:29 UTC (permalink / raw) To: mliggett, zsh-workers 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: couple of zsh features 1995-12-07 17:29 ` Barton E. Schaefer @ 1995-12-07 17:59 ` Matt Liggett 1995-12-08 9:07 ` Bas V. de Bakker 1995-12-07 20:22 ` Richard Coleman 1 sibling, 1 reply; 8+ messages in thread From: Matt Liggett @ 1995-12-07 17:59 UTC (permalink / raw) To: zsh-workers 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 | ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: couple of zsh features 1995-12-07 17:59 ` Matt Liggett @ 1995-12-08 9:07 ` Bas V. de Bakker 0 siblings, 0 replies; 8+ messages in thread From: Bas V. de Bakker @ 1995-12-08 9:07 UTC (permalink / raw) To: mliggett; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: couple of zsh features 1995-12-07 17:29 ` Barton E. Schaefer 1995-12-07 17:59 ` Matt Liggett @ 1995-12-07 20:22 ` Richard Coleman 1 sibling, 0 replies; 8+ messages in thread From: Richard Coleman @ 1995-12-07 20:22 UTC (permalink / raw) To: zsh-workers > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: couple of zsh features [not found] ` <mliggett@seven.ucs.indiana.edu> 1995-12-07 17:29 ` Barton E. Schaefer @ 1995-12-07 19:02 ` Barton E. Schaefer 1 sibling, 0 replies; 8+ messages in thread From: Barton E. Schaefer @ 1995-12-07 19:02 UTC (permalink / raw) To: mliggett, zsh-workers 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1995-12-16 1:18 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1995-12-16 0:52 couple of zsh features Thomas Pierre Schweikle -- strict thread matches above, loose matches on Subject: below -- 1995-12-08 7:20 Sven Wischnowsky 1995-12-07 16:31 Matt Liggett [not found] ` <mliggett@seven.ucs.indiana.edu> 1995-12-07 17:29 ` Barton E. Schaefer 1995-12-07 17:59 ` Matt Liggett 1995-12-08 9:07 ` Bas V. de Bakker 1995-12-07 20:22 ` Richard Coleman 1995-12-07 19:02 ` Barton E. Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).