

Tell HN: A request for saner text-editors - tarkin2

I have an problem with tradional unix text-editors--vim and emacs for example--and I'd like not to have that problem with future text editors you or others may create.<p>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.<p>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.<p>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.
======
coliveira
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.

~~~
itodd
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 gk

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

~~~
chaosprophet
I agree. Perhaps the OP should go in for a word processor rather than a text
editor???

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

    
    
      // Here_ is a really long comment that has wrapped in my
      window

and end up with

    
    
      window

left in your editor, no doubt breaking your code?

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

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

------
quoderat
Unix abandoned (or never had) any conception of WYSIWYG, and probably never
will. I hate it, too.

~~~
anamax
> 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".

