Because compatibility. All the existing text programs assume the physical tele-typewriter emulator. There have been many attempts to modernize the essential parts of the text console experience and do away with the inessential parts, but they always fail to catch on because people expect to be able to run programs like 'top' and 'ls -la' and 'pstree', which expect to format their output on a handy fixed width character grid. And you can't easily patch mouse selection into the existing system because there is too much seperation between the terminal and the content - the terminal is not aware of the intended text formatting, and the program is not aware of where you clicked. Fixing this would also require patching the world.

If you want to live in the future, you can't use programs written in the past. There are many fine GUI text editors: leafpad is your basic bare-bones notepad-alike, and for my money Kate is the best 'notepad++' mega-text-editor that's still light enough to start instantly.

> And you can't easily patch mouse selection into the existing system because there is too much seperation between the terminal and the content - the terminal is not aware of the intended text formatting, and the program is not aware of where you clicked.

I'm sorry, but this is plain wrong.

gpm [0] supplies a mouse server for the console, and has been around for a very long time (the oldest release I could find was 1995). SSH, nano, vim and more all understand the events driven by it. This should even work under a raw tty, rather than a terminal emulator, in any shell, from ash to zsh.

The terminal absolutely understands the mouse, you just need to enable the bridge that lets it all work.

[0] https://linux.die.net/man/8/gpm

Does GPM let you move the insertion point in nano or vim? It didn't when I last used it 12 or 13 years ago. All it let me do was select a region of text from the screen plus the scrollback buffer of the linux console. Then I could choose to copy that region. And IIRC, the copy had a newline wherever the text being displayed had a newline and where one line of the linux console ended and the next line began, so if what I was copying had any lines that ran longer than the screen width, I'd have to manually remove the second type of newlines after pasting.

And when the user selected text using GPM, the program (e.g., nano) never learned of it: it was local to GPM and the linux console.

The man page you linked states, "The selection mechanism is disabled if the controlling virtual console is placed in graphics mode, for example when running X11, and is re-enabled when text mode is resumed," (then goes on the describe how sometimes it does not get re-enabled because of a bug).

Can a modern PC even be put into text mode anymore? (Honest question: I do not know.)

Have you ever gotten GPM to work with X11 or Wayland?

> Does GPM let you move the insertion point in nano or vim?

If you enable mouse support. (set mouse for nano and set mouse=a in vim).

> Have you ever gotten GPM to work with X11 or Wayland?

That'd be rather... Pointless. X11 and Wayland already allow the mouse to work without GPM. Just enable the mouse in nano, vim or whatever, and it'll work.

Whatever terminal-emulation app (e.g., Gnome Terminal) you are using will allow you to select text in the app's window, but nano or vim will never know about it. I.e., the user's mouse gestures are never transmitted to the program (e.g., nano) on the other side of the pseudo-TTY (PTY).

So for example, the user cannot use the mouse to move the insertion point in nano.

> So for example, the user cannot use the mouse to move the insertion point in nano.

That is not the case if you enable mouse support, as I've said.

Try it. Add:

    set mouse

To ~/.nanorc

Open a file, and click. The insertion point will move.

Oh, OK. Good to know. Thanks for your reply. vim, too?

The vim command needed to enable support is:

    set mouse=a

But yes, it works basically the same.

> the program is not aware of where you clicked. Fixing this would also require patching the world.

No, that exists for a long time and is widely implemented among terminal software. Demo: https://github.com/tinmarino/mouse_xterm

Leafpad hasn't been maintained in the last decade or so, is buggy and based on GTK 2. Please don't recommend it to anyone. Gedit is much more sensible as a replacement.

Mousepad is also pretty good and is actively maintained.

Nano, the simple editor every one loves to rag on for being overly simple, does actually support cursor cut n paste. (Hold shift and move the cursor. Then cut or paste.)

    set mouse
    set nowrap
    set softwrap

With those three lines in ~/.nanorc, it now allows you to click n drag the mouse, and may work over ssh, depending on your terminal support, and wraps lines without inserting actual breaks.

It effectively is Notepad, as far as I'm concerned.

nano isn't very weak, I have modified nanorc substantially and also have binded many keys. It works better than, say, notepad++ on windows.

For those who aren't touch typists, or occasional users, nano is just more comfort than vim or emacs.

And there is a editor named `micro`, which is similar to nano but has more features including bracket completion etc.. I am delaying switch because it is written in go (being unavailable in repos) and anyway I haven't found time to configure it. But it is scriptable in lua..

Try using vscode remote over ssh, it connects to the machine over ssh and the experience is mostly seamless. Highly recommended.

Last I checked, it does far more than just connect to the machine over SSH. It pushes up a nodejs executable and then also pulls down other stuff from the web. And it will also leave an agent running on the host you ssh into, even after you exit vscode.

I can see this being okayish when logging into a dev EC2 instance or something ephemeral but it's not something I would ever want to do on something important.

Plan 9's Acme (a GUI editor similar to sam) is just fine when ran over LAN - no felt lag at all. Not sure how well it handles modern-day internet, but quite possibly would be practical.

And yes, it uses mouse-based select/cut/copy/paste, with line- and block- level operations.

It is based on how the whole Oberon OS UI works, which took its idea from Xerox PARC Workstations OSes.

Basically on those systems you can expose code as UI callable operations, select code and give it to them.

There's a clone of notepad++ that works on Linux, called notepadqq.

https://notepadqq.com/wp/

While it may or may not be a "simple" text editor, Vim supports cursor based cut and paste with the appropriate settings in .vimrc (I forget off the top of my head, it's something along the lines of "set mouse=a" to enable the mouse and then "set clipboard=unnamedplus" to make it interface with the system clipboard.)

Assuming a mainstream terminal emulator, [CTRL] + [SHIFT] + [C/V] works well enough most of the time. Copying that way does break if you tile though.

why do you think its a good idea to keep touching the mouse? it's not about emulating a teletype machine. it's about not picking up your (probably right) hand and moving it to the mouse constantly. this is something the teletypewriters of the past never had to deal with. I guess you don't yet have RSI?

For example pasting a piece of code in the middle of a typed line is more convenient with a “mouse” driven cursor.

I use a Macbook as my keyboard/trackpad combo, so my “mouse” is actually extremely close to the keyboard, and I don’t have to move my hand much.

It's about familiarity.

Learn those cursor movement keys combos and you'll find it ends up being way faster to get to the middle of your line to drop your ctrl-v that way once you're used to it.

Not that I mean to rag on you in a superior way like so many keyboard-only primadonnas like to. You do you, and I understand that for a lot of people the investment in learning this non-critical stuff just isn't worth the time.

Micro and geany are good CUA options.

I think `micro` will do.. not sure about cursor based cut-paste though..