Comment by deckard1 | Hacker News Reader

Comment by deckard1 | Hacker News Reader

Parent Full thread

Regarding the vertical cursor movement, back in the day there was an alternative behavior. You can see this in QuickBASIC/QBasic[1]. Here, Microsoft treated the entire screen as a grid. I always thought that was a great UI. It hides the fact that there are line endings (\n on Unix or \r\n for DOS). And why shouldn't it? That's an implementation detail. And as evident by DOS using CR+LF it goes back to the days where you had an actual physical carriage on a typewriter. Nearly every modern text editor you have to type out the spaces/tabs you want to reach the area you what to add text. In QBasic, you just move the cursor wherever you want on the screen with arrow keys and start typing. Because, unlike a typewriter, a computer screen is 2D. Vim has block mode but, AFAIK, can only work on selections. Of course, this is not universal and only works with monospace fonts in certain languages. But back in the day it made it easy to create ASCII/ANSI diagrams and art.

Modern text editing is a multilayered mess. Rendering, input methods, variable width fonts, and the special codes (markdown, etc.). On some sites it's not even self-consistent. Take Jira. Last I checked, they have one editor for creating a ticket and an entirely different editor for editing that same ticket[2] (one of these editors sucks more than the other, but I can never remember which... but neither one is remotely what I would consider a "good" interface). How they got there is truly the 8th Wonder of the World.

[1] https://archive.org/details/msdos_qbasic_megapack

[2] https://community.atlassian.com/t5/Jira-Software-questions/H...

Vim supports the style of editing you describe; see the documentation for the 'virtualedit' option.

https://vimhelp.org/options.txt.html#%27virtualedit%27

I think this feature is called 'virtual space'. I like it too and would always look for it and turn it on if available in any text editor I used. But it's not as common as it once was.

This feature conflicts with whitespace-at-line-end rules, because if your editor truncates ws at eol, it must account for multiline string literals in a generic way, and if it doesn’t, everyone else editing that file has to deal with ················’s scattered randomly all over the text/code/diffs. Especially when “·” renders as as “ ” instead, and pressing the End key turns into a lottery. I can see ways for this mode to remain tempting to someone, but it’s just incompatible with everything beyond that editing session.

I don't see why this is so. I like auto removal of trailing space, I don't see why you can't combine that feature and virtual space. Virtual space just means the cursor/caret moves strictly vertically as you press the up/down keys even as you visit lines that are shorter than the current offset from the left margin. If you alight at such a line and start typing text, the editor simply inserts sufficient spaces to extend the shorter line to the current offset before it inserts the text you are entering. If you are entering only spaces, that's fine too but unless you enter something else at some point all the excess space can be trimmed when you leave the line.

You're misinterpreting the problem.

Auto-removal of trailing space is only possible if the trailing space is meaningless. Many programming languages have meaningful trailing spaces which cannot be removed. The most common example is inside multi-line strings.

Fair enough, I agree that virtual space is not useful or even possible if you can't or don't want auto trimmed trailing space as well. Fortunately there are many workflows and languages where auto-trimmed trailing space is a plus, and these overlap with my areas of interest.

Sadly, that's not a possible alternative behavior for a world where proportional fonts exist. It's for monospace only.

as I said

> Of course, this is not universal and only works with monospace fonts in certain languages.

But even then, monospace didn't go away. Most developers are working with code in monospace right now.

Monospace is the more sensible option as an editing medium for symbolic content. It's in having "WYSIWYG" editors that do everything in one modeless widget that we start getting this particular kind of feature creep.

And considering how awful it tends to be to navigate a complex word processing task in Word or LibreOffice even now - mystery-meat selections abound - I'm not sure this is the right feature to support all of the time.

Speak for yourself.

Proportional fonts are more aesthetically pleasing and legible (the entire reason for their existence).

When I'm editing "symbolic content", I like it to be easy on my eyes. If I'm constantly re-reading what I've just written, I appreciate the added legibility.

(With the exception of heavily punctuation-based computer code, of course, where monospace results in greater legibility.)

I rarely care about my position on the "page" unless I'm typesetting something (otherwise I'm just typing from X number of tabs in), and when I'm typesetting, I'm not going to use a monospaced font very often.

I liked doing ANSI art back in the 80s, but that's not really interesting outside of terminal connections to a BBS.

> you have to type out the spaces/tabs you want to reach the area you what to add text

If you move the cursor to an empty area and start typing, should the missing characters be tabs or spaces then? Or NULs?

Also, how do you insert spaces/newlines/tabs in between other text? Everything would be implicitly modal.

It's good UI for some things, but it's not as good for a general editor like vim. I'm not looking forward to write Python with it, for example :)

IIRC the Commodore 64 did something similar with its built-in Basic prompt.

Fun fact: Python and QBasic both came out in 1991. Though QuickBASIC is a few years older.

> should the missing characters be tabs or spaces then?

I'm not sure what QBasic does. But it's irrelevant since they control the format and the display. All Microsoft needed to care about is whether the file displays the same as before when loaded.

But it's really no different than text editors that let you switch a tab character to insert 2/4/8 spaces. If you've ever had the misfortune of working on a code base that allowed both tabs and spaces (fake tabs) then you'll be keenly aware that plaintext has always been modal. Your editor either has to figure out how many spaces to display a tab character, or how many spaces to insert on the tab key. Even line endings, CR+LF vs. LF. I think Mac even just used a single CR once upon a time.

Makefile is another format that is particular about requiring an actual tab character. The first time I "discovered" this I had the urge to toss my computer out the window. That was probably the late '90s when that sort of information was a bit more difficult to come across.

Reply on news.ycombinator.com