Text editors that's optimized for 16:9 Laptops

This topic is 1835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hello I'm new here and I would like to know of a split pane text editor that continues from where the the other pane left off.

I got this idea from a Coffee Shop where a Developer used a Bluetooth Keyboard and flipped his Macbook Air sideways and I asked why and he says "I can see what I'm doing more and get more lines of code on screen" he also said he also has a Thinkpad T60p and he said that was the best laptop you can get with 1,200 Vertical pixels (It's a high end 4:3 Laptop, so it's 1600x1200) without spending thousands of dollars for a 1920x1200 16:10 laptop.

Here's a diagram of what I mean with most laptops being at 1366x768:

So, is there a Text Editor that offers what I'm looking for?

Edit: I hate not having spell check in paint

Edited by kodekrunch

Share on other sites

I don't know of any, and I don't think that'd be a terribly great way to code anyhow, because then your lines are gonna start running off the right edge of the text areas if they're longer than about 50-70 characters using half of a common 1366x768 screen.

It'd probably be more effective to configure your IDE of choice such that your code window extends the entire height of the display (whereas most editors default to having some number of lines for the output window. Some IDE's have a button that allows you to quickly hide/show the output panel too.

Another option would be to turn down the font size by 2pts or so, and maybe try a different fixed-width font -- there are some that you can download which are optimized for readability at smaller font sizes. Don't strain your eyes or anything, but you can easily gain 10-15 lines with the right font and font size.

Share on other sites

I use visual studio with a window layout like that, but with two different files open in the right/left panes (and traditional scrolling, instead of book-type).

I set all the "solution explorer" etc panes to auto-hide, and then right click on a file-tab and use "New Vertical Tab Group" to create the 2 panes. I also then right-click on the find-results and output panes and change them to "Tabbed documents" so that I can place them in these panes.

I've thought before that having the 1 file in both panes (scrolling in sync with each other) would be a good idea too  but have never seen it. Maybe there's a VS plugin that can do it for me...

You can use "Window->New Window" to get two views of the same document, so you can view it in both the left/right panes, however, they don't scroll in sync with each other.

Edited by Hodgman

Share on other sites

Actually, it looks like Sublime Editor does that, though I still have reservations about how well it actually works, and it seems not to treat the second text area as "overflow" of the first, but as a second, independent window for a second location in the file, or another file entirely.

In any event, its a really neat editor anyhow, so if you're looking to try something new anyhow its a good place to start.

Share on other sites
double post Edited by Stroppy Katamari

Share on other sites
Vim's built-in functionality can do pretty much what kodekrunch is asking for. Just split the view, jump the rightmost window one screen forward, and :set scrollbind for both windows. They will then scroll in sync, with right window staying a screenful of text ahead of the other.

Putting this macro into your .vimrc file lets you switch into that view with a single press of the F12 key:
map <F12> :vs<CR><C-W>w<C-F>:set scrollbind<CR><C-W>w:set scrollbind<CR>

This simple implementation won't keep the second window updated when you jump between files in the first window, but it's easy to at least modify this so that every other keypress toggles back to single window mode, and therefore you can fix the second window's view by tapping the key twice. That should be decently usable. It's also possible someone has already made a polished vim plugin for this.

Share on other sites

After a bit of googleing with terms that's hard to make friendly to search engines, (this is one of these things that's hard to describe to a search engine, so it takes hours to find) I found out how to do it in Notepad++.

Go to View>Move/ Clone Current Document>Clone to other view

Then on the right pane, go where the left pane leaves off from

Then go to View>Synchronize Vertical Scrolling

Screenshot from my Desktop:

Share on other sites
You can layout any windowed program like that in Win 7. Hold the windows key and press the arrow keys, and you can align your windows to the edge of the screen. Left and right will snap them to either edge. Up and down will do different things depending on context. Very useful. Especially for browsing multiple websites.

Share on other sites
You can layout any windowed program like that in Win 7. Hold the windows key and press the arrow keys, and you can align your windows to the edge of the screen. Left and right will snap them to either edge. Up and down will do different things depending on context. Very useful. Especially for browsing multiple websites.

Actually you could do that in winxp as well i think - ctrl+clicking on multiple windows in the taskbar let you select multiple ones and could then right click and select Tile Horizontally / Vertically (it's some combination like that, not 100% sure). It's one of those features that I don't think Windows ever advertised as much as it should have.

Share on other sites

What a coincidence. I'm on a Thinkpad T60p right now (1400x1050).

Many text editors allow you to use multiple views to do this, as stated above. I use Kate, which has multiple views that can divide the screen somewhat arbitrarily and view any (including the same) file in each.

However, I like having the width of the screen, as well; code rarely stays within the 80 columns that are recommended, as far as I've seen. I'm not sure what editor puts the text in the center like that, but I use a comfortably smaller font size and a single view, with fast scrolling. As much as I like to see as much code as possible, I find that in practice, it often goes to waste.

Think of it this way: if you had a screen that was as large as your wall, you'd see a ton of code at once, but how much can you physically see and interact with at the same time? At a certain point that is different for each person, there is no more benefit in displaying more lines; if my screen was twice as high, and I had to look down to see the extra lines, I could just as easy scroll down a page and not move my eyes too far. Additionally, there's a decent chance that the code on the other view is not needed, and thus is taking up half of the screen with irrelevant text.

Don't let me discourage you, however; I'm just saying that for me, a smaller font size and an efficient touchpad setup outweigh the benefits of bisecting my screen width-wise, so if you are simply looking to see more code, this may be another option.

Share on other sites
<blockquote class="ipsBlockquote" data-author="Ectara" data-cid="5018884"><p>Think of it this way: if you had a screen that was as large as your wall, you'd see a ton of code at once, but how much can you physically see and interact with at the same time? At a certain point that is different for each person, there is no more benefit in displaying more lines; if my screen was twice as high, and I had to look down to see the extra lines, I could just as easy scroll down a page and not move my eyes too far. Additionally, there's a decent chance that the code on the other view is not needed, and thus is taking up half of the screen with irrelevant text.</p></blockquote>It depends a lot on language, purpose of the code, quality of code, even indentation style. For bad quality, verbose, deeply indented C++ code with no STL/algorithms/etc., a single logical section can stretch tall and wide. Then it's really useful to be able to see a long stretch of code at a time. I used to have a display pivoted to 1200x1920 for that purpose, and did not feel like it was a waste at all.<br /><br />That said, I think seeing code flow in side by side columns is marginally useful at best. Such a view causes the visual form of the indentation to break up, and isn't nearly as good as seeing the same lines in uninterrupted succession.<br /><br />What matters for real editing efficiency is powerful tools for jumping around text and code elements. Fast shortcuts to jump to next function, to search things by name, to select blocks of code, copy, paste, fold, etc. Vim is by far the best editor I know in this regard.

Share on other sites
Speaking of text editors, what the hell is wrong with the forum text editor? My posts are constantly getting broken while submitting them for the first time, like above. I really don't want to go back and manually edit them in shape.

Share on other sites
<blockquote class="ipsBlockquote" data-author="Ectara" data-cid="5018884"><p>Think of it this way: if you had a screen that was as large as your wall, you'd see a ton of code at once, but how much can you physically see and interact with at the same time? At a certain point that is different for each person, there is no more benefit in displaying more lines; if my screen was twice as high, and I had to look down to see the extra lines, I could just as easy scroll down a page and not move my eyes too far. Additionally, there's a decent chance that the code on the other view is not needed, and thus is taking up half of the screen with irrelevant text.</p></blockquote>It depends a lot on language, purpose of the code, quality of code, even indentation style. For bad quality, verbose, deeply indented C++ code with no STL/algorithms/etc., a single logical section can stretch tall and wide. Then it's really useful to be able to see a long stretch of code at a time. I used to have a display pivoted to 1200x1920 for that purpose, and did not feel like it was a waste at all.<br /><br />That said, I think seeing code flow in side by side columns is marginally useful at best. Such a view causes the visual form of the indentation to break up, and isn't nearly as good as seeing the same lines in uninterrupted succession.<br /><br />What matters for real editing efficiency is powerful tools for jumping around text and code elements. Fast shortcuts to jump to next function, to search things by name, to select blocks of code, copy, paste, fold, etc. Vim is by far the best editor I know in this regard.

The real quote is somewhere in there.

Don't get me wrong, I'm a strong advocate for a larger screen and viewing more code at once; this is the largest screen that I have that isn't a television. But if doing so requires you to lose your focus and take mental effort to interpret what you see (i.e. display big enough that you have to look down, lose your place, and find it again, or two views next to each other that take some practice to see them as a continuation of each other and reconcile the differences in indentation), then you may be better off just being able to seek faster and more efficiently.

Share on other sites
However, I like having the width of the screen, as well; code rarely stays within the 80 columns that are recommended, as far as I've seen.

QFE - Width only seems so excessive now because our monitors have given us so much of it, but they haven't given us so much that we can comfortably cut it in half, either (maybe with the new 21:9 monitors  ). The 80-column idea is really just a hold-over from the days when screens and text terminals could only show 80 columns with reasonable fonts. Not that we should let our lines run on forever, but in modern times we can afford more than 80 columns, and I think doing so is a better use of screen real-estate than some of the creative formatting folks sometimes do to keep lines short (e.g. placing each parameter to a function call on its own line).

Personally, I usually set two column indicators in my IDE -- one at 100 columns and the other at 120. The first is "soft" -- tells me I should think about wrapping this line up soon -- and the second is "hard" I usually will break up a line that's longer than that. Even still, all my screens are plenty wide (My desktop screen is 2560x1200, flanked on either side by 1600x1200s in portrait orientation), and my laptop is 1920x1080. I don't cut my code off hard at 120 columns for *my* benefit, but for benefit of anyone else that might have to read it.

Edited by Ravyne

Share on other sites

[quote name='Ravyne' timestamp='1357674437' post='5019165']
The 80-column idea is really just a hold-over from the days when screens and text terminals could only show 80 columns with reasonable fonts. Not that we should let our lines run on forever, but in modern times we can afford more than 80 columns
[/quote]

No.

The 80-column idea is from centuries -- yes, at least 700 years -- of experience in laying out printed information in order to convey the maximum of information to the most people with the least fatigue or difficulty reading.

People who are busy reinventing the text page layout wheel aren't special because they're new at the game -- just the opposite in fact.  They still have the same eye musculature and neural pathways as Johann Gutenburg.

Picture trying to read a newspaper broadsheet if there was one column with all the text the width of the page.  The collected wisdom of the centuries is that the optimal column width is about 3 inches (7 cm), left justified, ragged right.  You're already starting with a deficit with most computer displays running at an incredibly crude 96 dpi vs. 300 or more for a newspaper or between 700 and 1200 dpi for quality printing, and the glowing screen makes it even worse.

Between 50 and 80 per cent of the total cost of a software project over its lifetime will be maintenance.  You would do well to attempt to minimize that cost by making your writing more legible.  Longer lines are not better.  'Getting more code on the screen' is a symptom of shit code, not of being more productive.

Share on other sites

[quote name='Bregma' timestamp='1357682809' post='5019214']
'Getting more code on the screen' is a symptom of shit code, not of being more productive.
[/quote]
In terms of viewing more code at once, I mean vertically; I never try to lay my code out horizontally to use up available screen real-estate.

Share on other sites
Picture trying to read a newspaper broadsheet if there was one column with all the text the width of the page.
The collected wisdom of the centuries is that the optimal column width is about 3 inches (7 cm), left justified, ragged right.

Picture trying to read C++ code if we formatted it as we do newspaper!

for ( int j = 0; j < Rasterizer::
g_width; ++j ) { for ( int y = 0;
y < Tile::g_tile_height; ++y )for
( int  x  =  0;  x   <   Tile::
g_tile_width; ++x ) { int idx = j
+Rasterizer::g_width; __m128i buf
=  rast  .  m_tiles  [ idx ]  .
m_frame_buffer[ y ]; unsigned int
mask = ( ( unsigned int * ) ( &
buf ) ) [ x >> 5 ] ;  int  bit  =
mask & ( 1 << (  x  &  31  ) )  ;
COLORREF col = bit ? RGB ( 255  ,
255 , 255 ) : 0 ;     g_data[ j *
Tile::g_tile_width + 127 -  x   +
( Tile::g_tile_height + y )     *
g_info . bmiHeader . biWidth ]  =
( unsigned ) col ; } }

Not arguing for or against 80-columns here, but reading code is a very different activity to reading a newspaper or a novel, and code itself is a very different kind of content (closer to a mathematical theorem than prose), so conventional wisdom for laying out text is largely irrelevant.

[quote name='Ravyne' timestamp='1357674437' post='5019165']
Width only seems so excessive now because our monitors have given us so much of it, but they haven't given us so much that we can comfortably cut it in half
[/quote]Works for me on my 2048*1152 monitor. Often with a 50/50 split, and sometimes with a 70/30 split if a file contains long lines.

[quote name='Ectara' timestamp='1357670925' post='5019132']
if doing so requires you to lose your focus and take mental effort to interpret what you see (i.e. display big enough that you have to look down, lose your place, and find it again, or two views next to each other that take some practice to see them as a continuation of each other and reconcile the differences in indentation), then you may be better off just being able to seek faster and more efficiently
[/quote]I used to use a 16:9 monitor rotated 90º to be a tall-screen for writing code, and another in regular landscape mode for playing the game on, because I found that "scrolling by looking" took less mental effort than actually scrolling, and I wouldn't lose my place as much

[quote name='Stroppy Katamari' timestamp='1357657590' post='5019046']Speaking of text editors, what the hell is wrong with the forum text editor?[/quote]The staff are waiting on a patch from IPB (the forum software), as the last update has caused a lot of issues.

Share on other sites
I used to use a 16:9 monitor rotated 90º to be a tall-screen for writing code, and another in regular landscape mode for playing the game on, because I found that "scrolling by looking" took less mental effort than actually scrolling, and I wouldn't lose my place as much wink.png

I guess the other factor is that I do much of my programming on a laptop; while I could rotate my display, it'd require me to attach an external keyboard to take advantage of it. As a result, I became more accustomed to using 8pt monospace fonts and optimizing my touchpad's scrolling to look quickly.

On a side note, does anyone use variable-width fonts for programming? I don't, but I'd imagine that 80 columns would be a lot more frustrating to manage if the characters weren't the same width.

Edited by Ectara

Share on other sites

The 80-column idea is really just a hold-over from the days when screens and text terminals could only show 80 columns with reasonable fonts. Not that we should let our lines run on forever, but in modern times we can afford more than 80 columns

No.

The 80-column idea is from centuries -- yes, at least 700 years -- of experience in laying out printed information in order to convey the maximum of information to the most people with the least fatigue or difficulty reading.

People who are busy reinventing the text page layout wheel aren't special because they're new at the game -- just the opposite in fact.  They still have the same eye musculature and neural pathways as Johann Gutenburg.

Picture trying to read a newspaper broadsheet if there was one column with all the text the width of the page.  The collected wisdom of the centuries is that the optimal column width is about 3 inches (7 cm), left justified, ragged right.  You're already starting with a deficit with most computer displays running at an incredibly crude 96 dpi vs. 300 or more for a newspaper or between 700 and 1200 dpi for quality printing, and the glowing screen makes it even worse.

Between 50 and 80 per cent of the total cost of a software project over its lifetime will be maintenance.  You would do well to attempt to minimize that cost by making your writing more legible.  Longer lines are not better.  'Getting more code on the screen' is a symptom of shit code, not of being more productive.

Code is hardly a newspaper or novel though, and I don't think the same principles can be applied -- Code has a whole lot more shape to it, generous whitespace, and often color. All of us scan tons of code every day quickly by its shape alone -- You can recognize function blocks, switches, loops and other things with pretty good accuracy without actually reading any of it.

Width only seems so excessive now because our monitors have given us so much of it, but they haven't given us so much that we can comfortably cut it in half

Works for me on my 2048*1152 monitor. Often with a 50/50 split, and sometimes with a 70/30 split if a file contains long lines.

Fair enough, 1920 begins to be wide enough for a comfortable 50/50 split, but I was generally assuming that most people are only rocking 1 screen and may want to look at something else too--a web page, documentation, etc. I guess on the desktop these days you can mostly assume 1080p+, but for those stuck on an even-better-than-average-but-sub-1080p laptop its pretty much a no-go.

Share on other sites
Code is hardly a newspaper or novel though, and I don't think the same principles can be applied -- Code has a whole lot more shape to it, generous whitespace, and often color. All of us scan tons of code every day quickly by its shape alone -- You can recognize function blocks, switches, loops and other things with pretty good accuracy without actually reading any of it.

I would disagree strongly.  Reading printed matter is reading printed matter:  the same mechanics of eye movement and psychology of comprehension apply regardless of content or the fact that you don't want to follow the established convention because NIH.  Hodgman's example was incredibly contrived and is just a poor attempt at introducing a strawman.

Look at a typical printed page.  You will find gutters, margins, leading, all kinds of things that are generally eschewed by coders who think code is for writing with Visual Studio and then forgetting about.  Yes, good code has good physical layout with indentation to show logical structure, vertical separation of logically disconnected constructs (in traditional literature, these are called 'paragraphs'...  look at how they're laid out in a book), and horizontal alignment to aid the eye in finding useful information (just like an index, table, callout, or glossary in a book).  That doesn't mean long lines are good practice, it just means the physical layout of code is very important.  Line length is a part of the physical layout of code.  Line length is important.

It turns out that maintaining code is never a matter of typing it in to an IDE quickly, and maintaining code accounts for the majority of cost over its lifetime.  Code is often view on a printed page, on a web page using a VCS viewer, in chunks of diff when reviewing changes.  It's not hard to make your programming literate so it is understandable in any of these common formats as well as in your text entry tool.  Using long lines is not one of the ways to do that.

Share on other sites

I don't think anyone is saying to use long lines wantonly, just that they aren't such a scourge as they are made out to be. Most lines of code, I find, are naturally only a few tens of characters long, and I can't recall a single instance of seeing two 80+ character lines adjacent to one another. You can argue for some other points, perhaps, but I just don't think readability is a good reason -- certainly not if the alternative is to artificially format it in a way that is, arguably, just as unreadable, or to start abbreviating code structures and object names (which I don't think either of us would advocate, but which some people would undoubtedly do) to save characters.

You bring up a point of how other tools might present the source code differently, and that's true. However, I would say in response that I see this as a presentation issue, and something which the tool should handle better. I evaluated, for work last year, some tools we could use to pretty-print code as a PDF, and none of them handled long lines well -- some by truncating, some by naively word-wrapping with no attempt to preserve some kind of formatting, others by scaling the font size relative to the longest line in a section and the output page width. But its a tools deficiency. I shouldn't have to think about what some third-party tool does with my code, other the standard tool chain. Of course we can agree that one should consider specific requirements of specific tools if those tools are important to us, but working around tool limitations is a problem regardless because then we have to know our entire toolbox up-front to plan accordingly, or simply settle for the lowest common denominator.

Specifically you say:

[quote name='Bregma' timestamp='1357742829' post='5019458']
It's not hard to make your programming literate so it is understandable in any of these common formats as well as in your text entry tool.  Using long lines is not one of the ways to do that.[/quote]

And I would argue just the opposite -- simply saying without specific merit or cause that all lines longer than an arbitrary limit are verboten does not aid overall readability. Remember that the alternative to "can't use, ever" is not "must use, always", but "can use, sometimes". I further argue that the natural structure of code, at least in any of the languages I use, is such that even the mere opportunity to create lines longer than 80 characters is so exceedingly rare (laying aside ridiculous streams of unrelated statements because C++ et al allows me to) to be almost a non-issue.

Sometimes the most legible or 'literate' thing to do is to allow for an occasional long line, rather than to force some unnatural structure upon it.

There likely is some reasonable upper-bound, but I'd wager its quite a bit north of 80 characters -- even the box I'm typing in now, on a website, in a frame, with margins at the side, in an application window which is not fullscreen, all on a not-particularly-wide 1080p screen, displays about 120 characters comfortably in a fixed-width font.

Share on other sites

I try to keep my lines to 70 characters or less. It means I don't have to scroll sideways to read the line when I'm splitting the screen in VS.

I find really long lines to be jarring as I try to read code. The eye settles into a back-and-forth of a few inches and then suddenly here's a line of 3 or 4 times the length. It breaks the process of reading smoothly.

I also find that super-long lines are either doing too much (doing math in arguments, etc) or else the function itself is designed to accept too many parameters. If a function needs a ton of information I prefer to package that as a POD struct and also ask questions about whether or not the function is doing more than it should. There are certainly cases where a function can need a lot of information, but I think not as often as certain APIs would indicate. Trying to figure out all of what such a function is more difficult as well since you have to sort of hunt down the commas or unfold the parenthesis (or whatever) mentally.

I don't know if there's really a magic number to it, but a kind of smoothness to the code body is what I hope for.