Questions

Questions

[Sven Wischnowsky]

Would anyone object if I applied the patch below to make newlines in
strings in the job text be output as spaces (keeping the `jobs' output 
better readable)?

And did anyone have the time to try the patch for scrolling completion 
lists? (I have a new version which is faster and allows status lines --
it's getting silly ;-)

Bye
 Sven

diff -u -r ../oz/Src/text.c ./Src/text.c
--- ../oz/Src/text.c	Fri Apr 14 23:34:43 2000
+++ ./Src/text.c	Fri Apr 14 23:56:30 2000
@@ -58,6 +58,7 @@
 taddstr(char *s)
 {
     int sl = strlen(s);
+    char c;
 
     while (tptr + sl >= tlim) {
 	int x = tptr - tbuf;
@@ -68,8 +69,8 @@
 	tlim = tbuf + tsiz;
 	tptr = tbuf + x;
     }
-    strcpy(tptr, s);
-    tptr += sl;
+    while ((c = *s++))
+	*tptr++ = (c == '\n' ? ' ' : c);
 }
 
 /**/

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

Re: Questions

[Peter Stephenson]

> Would anyone object if I applied the patch below to make newlines in
> strings in the job text be output as spaces (keeping the `jobs' output 
> better readable)?

It's a good idea to keep the job text on one line for any kind of automated
use, too.

> And did anyone have the time to try the patch for scrolling completion 
> lists? (I have a new version which is faster and allows status lines --
> it's getting silly ;-)

It seems fine.  The natural way of showing that text is missing would be to
put an ellipsis (`...' in English) at the top or bottom, like it does when
a line is too long.  It's most confusing when you wrap around the bottom
without warning.  A scroll-step style would certainly be useful, and in the
long run a special keymap.  I have doubts about `return' forcing the
display to scroll a line, since in menu-selection it already has another
meaning (and you have to hit it twice to execute a line, which took me a
long time to get used to), so this may be overloading it too much.

If it reaches something roughly constant soon, it can go into 3.1.7, since
it should be fairly self-contained, but if it's going to be a long project
to get it usable (though a brief test suggests it already is) it can wait.
Ideally we'd like it so that at least the basics of the user interface are
in place, so that it doesn't change too much next time (which may well be
4.0.1).

I don't see that it has to be that much more sophisticated.  I'm against
implementing a rewrite of `less' in the shell, at least unless it goes into
a completely self-contained library.

I tried this on the /etc directory, and was a bit worried when the first
thing that showed up was `\M-,'.  But ls confirms that there really is a
file of that name there.  Weird.  Hope I'm not giving away a commercial
secret.

Would people rejoice or complain if we had this on by default (other
settings permitting)?

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Questions

[Zefram]

Peter Stephenson wrote:
>Would people rejoice or complain if we had this on by default (other
>settings permitting)?

I'd like it.  I've often cursed at too-long completion listings that (a)
take a long time to scroll past at 9600 baud (well that was a while ago)
and (b) aren't readable because they've scrolled past.  And I've often
used completion listing to get a quick directory listing; having that
work for more than one screenful would be good.

My only real concern here is that the pager shouldn't get in the way of
normal typing.  What I'd like is that repeated <tab>s show successive
pages of listing, after the <tab> that shows the first page.  That seems
intuitive to me, but it might be difficult to fit in with the form of
menu completion where the first match is inserted at the same time the
list is shown.  Not to mention the case of an explicit list requested
during completion.  That needs some thinking about.

-zefram