---> I'd be happy to settle for 90 columns.
On Sunday 09 December 2001 11:28, Chuck Esterbrook wrote: > On Sunday 09 December 2001 11:57 am, Tavis Rudd wrote: > > On Sunday 09 December 2001 08:13, Chuck Esterbrook wrote: > > > On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote: > > > > That's the whole point, many tools are designed on this > > > > assumption and have dockbars down the left side or use > > > > multiple vertical frames. 80 might be a bit zealous, but code > > > > does get ugly in many tools when wider than 80. > > > > > > I just tested this theory with emacs, kate and wingide. The > > > code never gets ugly in kate and wingide, because they don't > > > wrap. The code does get ugly in emacs because of wrapping. Not > > > to mention the up and down arrow keys in emacs are > > > paragraph-oriented instead of visible-line-oriented. (bleck) > > > > I wasn't thinking about Emacs as one of these tools; rather: > > > > * grep on the command line > > commandLine.width does not equal 80. I don't know what makes you > think it is... True, but grep prefaces each output line with the name of the file and the line num and it doesn't wrap. Therefore I can't see the full output line when running fullscreen 1024X800 if the lines are much longer than 80. > > * viewcvs diff screens on the web > > Doesn't this scale as you shrink or enlarge your browser? I thought > it was just "normal" HTML that word wrapped? Which screws up the indentation. > > * any other visual diff tool > > They're all set to 80? I don't believe that. No, I meant they use multiple pane view and it is easier to read their output when each pane takes up roughly half my screen. > > * syncmail, the cvs checkin notifier which sends diffs as emails. > > Emails wrap at 76 columns in most clients. > > Now you just pointed out that 80 is NOT the standard.... True, but 80, 72, 76 are all pretty close. > > > In general, I'm not seeing that tools are designed around the > > > assumption that text files stop at 80 columns. > > > > stop thinking of text files ... rather 'source files' which are > > higly sensitive to newlines. > > Which are not hurt by command line tools like grep, cvs diff, > But your width=80 solution leaves me wrapping lines much more often > than I should have to bother with, and lots of unused real estate. Why are you so concerned about maximizing horizontal screen real estate? I find it easier to read any kind of text with narrow rather than wide columns. > The reason is to use the resources you have. Besides, when viewing > a file that is wider than your display, there shouldn't be any > problems. And there aren't any with a slew of editors, save for > emacs, which has other problems as well. Emacs doesn't cause me any problem with text less than 110 columns wide, it's the other tools I listed that do cause problems. > The earlier points about grep, e-mail, etc. don't hold water so > we're still left with emacs as the problem. They do hold water and Emacs doesn't cause problems for me in this respect so long as the code is less than 110. Grep, email, etc. do actually cause me problems with wide lines. > Would it kill Tavis and Ian to run one of the other editors when It isn't just me and Ian. Numerous people have commented about this on the Webware lists since I've been subscribed. Clark yesterday for instance. > using Webware source? You've already rejected lobbying for emacs to > be fixed and fixing emacs. You've even rejected what I thought were > easy solutions like "make window bigger" and "tweak fonts". Like I've said above and in the last message, this is not an Emacs problem. It's the other tools that bother me. ---> I'd be happy to settle for 90 columns. _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
