21 replies to this topic

[kodekrunch]

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, 06 January 2013 - 04:15 PM.

[Ravyne]

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.

[Hodgman]

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, 06 January 2013 - 07:48 PM.

[Ravyne]

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.

[Yrjö P.]

double post

Edited by Stroppy Katamari, 07 January 2013 - 05:54 AM.

[Yrjö P.]

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.

[kodekrunch]

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:

 

[MrDaaark]

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.

[Milcho]

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.

[Ectara]

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.

[Yrjö P.]

<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.

[Yrjö P.]

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.

[Ectara]

<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.

[Ravyne]

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, 08 January 2013 - 01:48 PM.

[Bregma]

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.

[Ectara]

'Getting more code on the screen' is a symptom of shit code, not of being more productive.

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.

[Hodgman]

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.

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.

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

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 

Speaking of text editors, what the hell is wrong with the forum text editor?

The staff are waiting on a patch from IPB (the forum software), as the last update has caused a lot of issues.

[Ectara]

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, 08 January 2013 - 07:00 PM.

[Ravyne]

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.

[Bregma]

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.