| |||||||||||||
Thoughts on the ext4 panicThoughts on the ext4 panicPosted Oct 30, 2012 0:55 UTC (Tue) by ikm (subscriber, #493)In reply to: Thoughts on the ext4 panic by nix Parent article: Thoughts on the ext4 panic
When one runs a terminal emulator, it's usually 80-chars wide by default. I have a strong feeling that the 80-chars wrapping is still considered relevant largely because of that default.
(Log in to post comments)
Thoughts on the ext4 panic Posted Oct 30, 2012 4:28 UTC (Tue) by martinfick (subscriber, #4455) [Link]
Or perhaps enough programmers still like to put more than one terminal or editor on their screen at once side by side? I suspect that who use IDEs forget that this is even possible.
Thoughts on the ext4 panic Posted Oct 30, 2012 7:14 UTC (Tue) by Aliasundercover (subscriber, #69009) [Link]
What is it with the IDEs not allowing multiple source windows? I can't imagine working without my screen filled with various views of my source. The IDEs I look at give tabs but no way to display multiple at once. When writing code I normally want to see a header defining the structures I'm using, some other source file which my code interacts with, yet another source file where I did something vaguely similar once before ...
I don't see a Linux IDE which allows this. Visual Studio on Windows does, I just have to tell it to work in its multiple document mode.
If given the choice between a pack of x-terms and vi straight out of the 80s and a modern IDE with all the bells and whistles but just one source window I would take x-terms and vi. Hard to imagine how anyone can use these IDEs much less design them the way they are.
Thoughts on the ext4 panic Posted Oct 30, 2012 12:42 UTC (Tue) by fb (subscriber, #53265) [Link]
> What is it with the IDEs not allowing multiple source windows? [...]
> I don't see a Linux IDE which allows this.
FYI, just checked and Eclipse (at least Juno/4.2) allows this. I can drag a source tab and place it next to my main source view.
Thoughts on the ext4 panic Posted Oct 30, 2012 17:26 UTC (Tue) by marcH (subscriber, #57642) [Link]
It is indeed much easier to split and generally manage the screen with a full screen Eclipse than with most window managers.
Thoughts on the ext4 panic Posted Oct 30, 2012 21:17 UTC (Tue) by khc (subscriber, #45209) [Link]
But only if all the windows you need to manage are eclipse windows, of course. I recently started to play with Dart using the Dart Editor which is basically eclipse, it works ok, but I don't know if I'd consider managing a full screen eclipse along with other windows "easy"
Thoughts on the ext4 panic Posted Oct 31, 2012 8:40 UTC (Wed) by marcH (subscriber, #57642) [Link]
> but I don't know if I'd consider managing a full screen eclipse along with other windows "easy"
No it's not easy; you are not supposed to do that. Instead, you are supposed to install and use whatever plug-ins give you the functionality you need *within* Eclipse.
Eclipse is the new Emacs: a Developer Operating System :-)
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.ecl...
Thoughts on the ext4 panic Posted Nov 1, 2012 3:52 UTC (Thu) by Aliasundercover (subscriber, #69009) [Link]
> FYI, just checked and Eclipse (at least Juno/4.2) allows this. I can drag a source tab and place it next to my main source view
Hmm, I last poked at Eclipse a while back and got stuck in tile land till I gave up and moved on to try other IDEs which also left me in tiles. I find tiles most unsatisfying as I wind up spending my time fiddling with them and scrolling too small window fragments even on the biggest screen. I much prefer overlapping windows I can customize. I have been working in Kate which lets me arrange things as I like, permits multiple windows into the same source file and shares the screen well with windows from other programs.
Taking another look based on your message I got the Eclipse 3.7 Ubuntu offered me and found I can indeed get decent looking windows if I fiddle enough. It will take time to know if the fiddling stays excessive or I can tame it with more knowledge.
Of course it wants to mangle my code as I type. It really wants me to follow someone's idea of correct style and I know I will be some time getting it to stop helping me by making an awful mess of my code. Why exactly does it insist on extra * characters on each line? (No, don't answer that, I just want to turn it off.)
/*
Will have to see. Looking better than last time. Qt Creator and KDevelop never got me this far, not past tiles and tabs with them. So much IDE stuff filling the screen, so little space for the source code I actually care about.
Thanks
Thoughts on the ext4 panic Posted Oct 31, 2012 9:25 UTC (Wed) by cesarb (subscriber, #6266) [Link]
> What is it with the IDEs not allowing multiple source windows? [...] I don't see a Linux IDE which allows this.
VIM has split/vsplit. Qt Creator also has split modes. And as others have already noted, Eclipse also has something of the sort. IIRC, Emacs can split the screen too.
Thoughts on the ext4 panic Posted Oct 31, 2012 13:20 UTC (Wed) by nix (subscriber, #2304) [Link]
Emacs has always been able to split the screen, since long long before X support existed. (It calls the panes 'windows' and the GUI windows 'frames' because Emacs does everything differently.)
Emacs 24 can split the screen, both manually and automatically, in so many ludicrous ways I have not begun to explore the possibilities. (The window-management code was rewritten by Martin Rudalics, and the new code is... very flexible. Almost too flexible to understand.)
Thoughts on the ext4 panic Posted Nov 1, 2012 9:32 UTC (Thu) by ncm (subscriber, #165) [Link]
"So many ways"?
1. Wrong
Any others?
Thoughts on the ext4 panic Posted Nov 1, 2012 19:50 UTC (Thu) by daglwn (subscriber, #65432) [Link]
> I don't see a Linux IDE which allows this.
Emacs/CEDET.
Thoughts on the ext4 panic Posted Oct 30, 2012 10:38 UTC (Tue) by nix (subscriber, #2304) [Link]
Well, yeah. Given how wide modern monitors are, 80 chars is still silly narrow. I can easily fit *three* 120-char-wide panes side by side. (Now maybe I use a smaller font than most, but even a normal xterm font should be able to fit two.)
Thoughts on the ext4 panic Posted Oct 30, 2012 5:00 UTC (Tue) by wblew (subscriber, #39088) [Link]
Interestingly enough, I have not used a terminal window, for source code viewing, that is less than 150 characters for a number of years.
I truly enjoy programming my 1920x1200 27" monitor.
Thoughts on the ext4 panic Posted Oct 30, 2012 5:01 UTC (Tue) by MTecknology (subscriber, #57596) [Link]
I love 80 char limits. Thanks to larger screens we can make that a soft limit too! I find that it still makes a crazy about of sense, especially when it comes to readability. I believe that's covered in chapter two of the Linux kernel coding style? "The limit on the length of lines is 80 columns and this is a strongly preferred limit."
Thanks nix! I love that summary. It saves me from having to read anything or do any of my own research and still sound smart when I explain it to others! :D
Thoughts on the ext4 panic Posted Oct 30, 2012 10:39 UTC (Tue) by nix (subscriber, #2304) [Link]
I agree with the limit on the length of lines: it should generally be shorter, more like 70 chars. That has nothing to do with terminal emulator width and everything to do with readability and the human eye.
But that width is the length of the line from its first character to its last: you do not sweep your eye over the indentation, so it should not count.
Thoughts on the ext4 panic Posted Oct 30, 2012 18:53 UTC (Tue) by vonbrand (subscriber, #4458) [Link] According to Poynton's "Ten Common Mistakes in the Typesetting of Technical Documents", a 66-character line of text is widely considered ideal for readability. I've seen other claims in the same vein (e.g. in the LaTeX memoir and KOMA packages documentation, aimed at serious book-writing). The 80 characters come from the IBM punched cards of yore, but their design in turn surely wasn't completely random either. The decree from the $POWERS_THAT_BE is enshrined in the Linux coding style; trying to change that is futile (or at least, there are more fruitful outlets for your creative energies).
Thoughts on the ext4 panic Posted Oct 30, 2012 21:00 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
80 characters was based on 10 characters per inch on standard typrwriters combined with 8 1/2" wide paper and the fact that you needed margins of ~1/4" to avoid problems with trying to type up to the edge of the paper.
When teletypes were built, they used the same print mechanisms and so had the same limits.
When terminals were built, they mimicked the printed stuff (so that you could see everything that you could see on the paper, and it was a waste to have anything wider, since the people who were still using paper wouldn't be able to see it)
IBM punch cards were 80 columns to match the paper as well.
The problem is none of these are good reasons any longer.
As for the ideal column width to read, go do some research on why newspapers use such narrow columns, the ideal width for reading is surprisingly narrow, and NOT 66 characters.
a paperback book is about the outer edge of what a good width is (no matter what the font size)
Thoughts on the ext4 panic Posted Nov 4, 2012 23:37 UTC (Sun) by marcH (subscriber, #57642) [Link]
> As for the ideal column width to read, go do some research on why newspapers use such narrow columns, the ideal width for reading is surprisingly narrow, and NOT 66 characters.
Source code and newspaper articles are quite different types of "literature". The are typically laid out in extremely different ways. It would be a very surprising coincidence if their "ideal widths" were the same.
Thoughts on the ext4 panic Posted Nov 6, 2012 18:25 UTC (Tue) by anselm (subscriber, #2796) [Link]
Newspaper columns are as narrow as they are because that lets the publisher fit more stuff on a page and cut paper costs, not because narrow columns are especially easy to read.
Newspapers even go to the trouble of having special fonts designed for them (where do you think Times Roman got its name?) in order to be able to cram more type into a narrow column, thus making the effective column width greater.
|
|||||||||||||