Tell HN: A request for saner text-editors
6 comments
You don't need another editor for this. In vim, you can use gk and gj to move up and down on screen lines, instead of internal lines. Also, you can use g0 and g$ to go to the begin or end of the screen line.
You could add this to your ~/.vimrc so that you don't skip wrapped lines:
" Don't skip a wrapped line
nnoremap j gj
nnoremap k gk
vnoremap j gj
vnoremap k gkThese days vim and emacs are mainly used for programming, if I'm not mistaken. As a programmer, I need to have complete control and understanding of how my code is stored internally, so it wouldn't make sense to make this the default behavior, especially if it does exist as another option.
I agree. Perhaps the OP should go in for a word processor rather than a text editor???
I think this is personal preference. One way is not "saner" than the other, it's just a design philosophy that must be consistent within an app.
I can't speak to Emacs, but Vim assumes that if you put something on the same line, you want it treated as a single line, regardless of where your window is causing text to wrap. For example, dd deletes your whole line, not just the window's line. I think this makes perfect sense in the Vim context, particularly since Vim is geared a bit more towards coding than word processing. How weird would it be to dd
I can't speak to Emacs, but Vim assumes that if you put something on the same line, you want it treated as a single line, regardless of where your window is causing text to wrap. For example, dd deletes your whole line, not just the window's line. I think this makes perfect sense in the Vim context, particularly since Vim is geared a bit more towards coding than word processing. How weird would it be to dd
// Here_ is a really long comment that has wrapped in my
window windowI actually rely on the "jump" of the cursor to tell me where new-lines are, and that's important. (Consider something like a Python program, where the real line-ending will terminate a statement, and the next line's indentation is significant.)
If navigation behavior is to change, there must still be some way for the editor to show the wrapping points. One option is Unicode, which is now fairly well supported by editors and terminals; for instance, special symbols like "¬" could be used to show wrapping points.
If navigation behavior is to change, there must still be some way for the editor to show the wrapping points. One option is Unicode, which is now fairly well supported by editors and terminals; for instance, special symbols like "¬" could be used to show wrapping points.
This is the default behavior in Emacs 23.1.
Most of the time, it makes editing text easier, as one would expect. The exception is when using a keyboard macro to do something to a bunch of lines. It's common for such macros to have a form like
1) start at the beginning of the line 2) do stuff to the line 3) go to the beginning of the next line
When the navigation commands take line wrap into effect, you can wind up with a macro that gets run once on short lines, but twice on long lines.
Most of the time, it makes editing text easier, as one would expect. The exception is when using a keyboard macro to do something to a bunch of lines. It's common for such macros to have a form like
1) start at the beginning of the line 2) do stuff to the line 3) go to the beginning of the next line
When the navigation commands take line wrap into effect, you can wind up with a macro that gets run once on short lines, but twice on long lines.
Unix abandoned (or never had) any conception of WYSIWYG, and probably never will. I hate it, too.
> Unix abandoned (or never had) any conception of WYSIWYG, and probably never will. I hate it, too.
In this case, the complaint is that what you've got can't be represented by what you see. There are a couple of ways to approximately display what you see, but they're approximations. (One is wrap and the other is "off the edge of the screen".)
In a WYSIWYG, you can't represent a line longer than the screen width. This is a problem when lines matter.
That's why WYSIWYG is more accurately called "What You See Is All You Have".
In this case, the complaint is that what you've got can't be represented by what you see. There are a couple of ways to approximately display what you see, but they're approximations. (One is wrap and the other is "off the edge of the screen".)
In a WYSIWYG, you can't represent a line longer than the screen width. This is a problem when lines matter.
That's why WYSIWYG is more accurately called "What You See Is All You Have".
That's a major difference in the "culture" (which was discussed on here yesterday), that probably shouldn't be changed (and you're right - it probably never will). Windows and Macs cater to WYSIWYG more because they focus on the end user. Unix is very much made for other developers, and when you add WYSIWYG into apps it complicates the situation. The UNIX philosophy explicitly states a preference for plain text.
The crux of this problem comes down to navigation and newlines. Traditional unix text editors understand a new line as ending when the newline character appears. This means a line can span many 'rows' on the screen. This makes sense because this is how lines are represented internally. But unless you think this way--and you wouldn't unless you habitually think in low level computer representation and don't often use saner text editors--navigation in such text-editors is quite un-natural.
For example, let's say you're reading back some text you've written and find you want to change something. Your initial reaction is to navigate to that error from where you are at the moment. So, you find where the cursor is located and say something like, "five lines up and a bit to the left." But you can't directly do this with the arrow keys or key shortcuts, because you're thinking about lines in a fundamentally different way to such a text-editor.
In everyday life we navigate objects visually. We should be able to navigate the cursor in text-editors in the same way. And so I implore the developers of future text-editors to make the default navigation behaviour to understand lines as how they are visually represented, not how they are internally represented. Please.