🚀 go-pugleaf

Jos Vermaseren T68@nikhefh.uucp writes
>....................................... A good example of this is the
>editor tempus which reads a little faster but assumes that each line ends
>in <cr>+<lf>. A file with only <lf> gets still read, but each line misses
>its last character!....................................................
**** mild flame follows ****
It just happens to be, that while the CP/M, MS-DOS and GEMDOS family of
operating systems do not enforce any particular end-of-line marker, it
IS convention to use CR LF (carrige return linefeed). How many UN*X
utilites break if you suddenly decide to use CR LF as eol instead of
LF ? Or what if I decide to start using RS (record separator) as eol?
You would correctly say, that's my problem. So if you want to use LF,
do so, but don't complain if 90% of all programs break.
**** flame off ****
Anyway since the behaviour of Tempus in above case was without question
a bug, it was fixed in version 1.10 (over three months ago!).

>Also it cannot deal with tabs while reading. The tabs have to be expanded
>afterwards resulting in a time which is much longer than the 80K per second
>when all is considered.
Which naturally depends on how many tabs are in the file.........

Just a few times I mesured with Tempus:

Read a 275kB file from a 5MB partition on a SH204:   < 3 sec
Write a 275kB file to a 5MB partition (80% full):     ~9 sec
Compress above file (=GNU-Emacs tabify)-> 7111 Tabs: < 2 sec
Expand above file ('de-tabify'):                     ~20 sec
Change all 7111 tabs to '+':                         < 5 sec

The file was 275 kB of Pascal source with about 8000 lines. As you really
only have to expand the file once (if you use tab in the editor  spaces
are inserted), I don't think this is so serious. Anyway the obvious way
to fix this is, to have the screen driver of Tempus  expand the tabs
(something I will suggest to CCD in the letter I'm writing to them this
weekend), not as Jos seems to suggest (I hope he didn't really mean that)
expand them while reading the file.


                                       Simon Poole

                 Bitnet:           K538915@CZHRZU1A
                 UUCP:      ...mcvax!cernvax!forty2!poole


PS: due to a major slipup in our computing center (=CZHRZU1A), all
    mail sent to me before last Friday has got lost (> 60 messages
    GRRRRRRRRRRRRR!).