Package: trn4
Version: 4.0-test76-10
I am trying to switch from trn3 to trn4. My .trninit (referred to in
TRNINIT) said:
-xsml
-XDD
-l
-m=u
-M
-S5
-h
+hFrom
+hDate
+hSummary
-EEXSAVER="%e <%A"
-EUNSHAR="unshar -s"
-f
-a
-B
-EFAST_PNEWS=y
-T
The effect with trn3 was that articles scroll up the screen one after
another. Rather than clearly the screen, trn3 would position the
cursor at the bottom of what it had already shown, and then print the
new stuff, so that the screen would scroll up. That puts all the
articles I have read in my xterm scrollback.
However with trn4 the effect of this is that it still sends the
cursor to the top left of the screen but simply neglects to send the
`clear screen' sequence. The result is a garbled display where bits
of every previous display (even from before trn4 was started) are left
over, and I still can't see old articles in scrollback because they
still get overwritten.
I was able to reproduce this with
TRNINIT='' trn4 -l
so the other things in my .trninit aren't relevant.
After RTFMing a bit and a short conversation with you, I did some
further testing including of -L and -e. I have managed to replicate
the trn3 -l behaviour with trn4 -L -l -e. Everything works absolutely
fine and as I want, except that
* the group selector (and I think maybe the thread selector too)
still cursor-to-left, overwriting the last displayed article.
* when I page through article bigger than my display, it starts it
at the top of the screen, clearing the previous article text
away (this is the behaviour expected of -e)
-L -l is no better than just -l or just -L.
I think that with -l, the cursor should never be positioned to home.
Here is the behaviour that I think -l should imply:
* group and thread selectors: in trn4 (unlike trn3) these expect to
be able to draw a keystroke reminder thing at the bottom right.
The selectors probably now use absolute cursor positioning to work
so if you simply remove the cursor home call you'll cause trouble.
I would suggest that the cursor home call be replaced with cursor
to bottom of screen print n newlines where n is size of screen
cursor home This would be a good default replacement for all `clear
screen' operations when -l is in effect.
If the selectors do _not_ use absolute cursor positioning for
updates to the menu, then I think trn4 -l should do what trn3 -l
does: whenever a selector is printed, it is allowed to scroll the
screen up, and relative positioning is used to update the selector
when appropriate. But this might involve reviewing trn4's use of
cursor motion in more detail than available effort readily permits.
* New article or restart article display:
With just -l, the behaviour should be identical to that currently
seen with -L -l -e.
With -l -e, use the `default clear screen' behaviour I specify
above.
* Next article page:
With just -l, suppress all cursor motion and simply print the
new article text, allowing the screen to scroll down. Ie the
current behaviour of trn4 without any of -l -L -e.
With -l -e, use the `default clear screen' behaviour I specify
above.
* -L should be of no consequence with -l. -l suppresses screen
clearing entirely and -L simply changes the way it happens.
* The manpage should be adjusted. -l is not for `weird terminals',
although it may be useful for those.
I'm not sure what to do if the terminal does not support absolute
cursor positioning, but -l is already halfway there. I just tried
`TERM=dumb trn4' and `TERM=dumb TRNINIT=-l trn4' and there didn't seem
to be much difference. I'm tempted to run trn4 with TERM=dumb since
the results are relatively pleasing.
Perhaps I should make a version of TERM=xterm which supports
highlighting but not absolute cursor positioning :-) (although
relative cursor positioning would be nice for updating the selector
menus rather than reprinting them).
If it would be worthwhile I could take a look at the code. I think
the current trn4 behaviour will get quite annoying quite quickly so if
you have any pointers please let me know. Hopefully it won't be so
annoying I go back to trn3 and fighting metamail for stupidly
base64-encoded postings.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
