Steffen Daode Nurpmeso dixit:
>But we're deep in a very complicated program, right?
Right.
>I thought about digging into and sending patches for
>
> - no tab completion over / boundary in upward direction
Eh, *what*?
> - no tab completion in the middle of a word (for partial word before cursor)
That’s by design. If you’re in the middle of a word, it’ll still
complete the whole word. I find it appalling that e.g. GNU bash
doesn’t work that way. You get the partial behaviour by inserting
a space (temporarily).
> - jobs names hard cut to ridiculous size (should at least be START..END, not
> STARTUNTILCUT, for, e.g., playing music or having multiple jobs which read
> RFCs)
It’s pretty hard to do this well. Additionally, there are some
memory constraints *and* terminal sizes come into play… but your
improvement idea is noted and gives me some ideas; I know where
and what to change, for this.
> - when traversing history, the terminal width should be fully used; i.e., if
> a line has 88 characters only 8 characters are shown, which often results
> in
> the need to jump to the front to see the exact command...
Yeah, the positioning algorithm is nōntrivial and sometimes
pretty annoying. That’s in the Emacs part in edit.c FWIW.
No good ideas about that one.
>But this seems to be pretty condensed:
Huh, this doesn’t say me anything. Best is really to try to
get the people who develop (a)sh and (pd)ksh on NetBSD® to
give hints.
Benny, Ádám, you’re called as well! ☺
bye,
//mirabilos
--
„nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist
eine Plattform für Einzelkämpfer“
-- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn
mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann
