Unfortunately, no matter how good yet another good code editor might be ...

[forthrin]

They all forget the insurmountable threshold crashing down the Sisyphus hill that is retraining decades of shortcut key muscle memory like a ton of bricks. How better to prove the point than having AI write Linus Torvalds' train of thought trying a new editor? (Not that he ever would)

Avaa tiedosto.
`C-x C-f`.
...Mikä vitun komentopaletti tämä on?
No, etsin tiedostoa. En "komentoa". Tiedostoa.
Hyvä on.
Avaa.
Löytyi.
Vaihda puskuri.
`C-x b`.
Leikkasi tekstin.
*Perkele.*
Poista sana.
Kopioi rivin.
Miksi?
Hae.
Avasi tekoälychatin.
En pyytänyt elämänvalmennusta. Halusin hakea sanan.
Riittää.
Lopeta.
`C-x C-c`.
Ei mitään.
Uudestaan.
Edelleen ei mitään.
Missä helvetissä tästä pääsee ulos?
*Vittu.*
`kill -9`
`emacs .`
Ahh...

To balance it out, in the words of an arguably more zen Scandinavian, Søren Kierkegaard:

If one is truly to succeed in leading a person to a specific place, one must first and foremost take care to find him where he is and begin there. This is the secret in the entire art of helping.

[lovehumans]

@forthrin this should be in the discussions, no?

[forthrin]

If someone wanted to label this a rant, they wouldn't be very mistaken. However, it is a general rant for all new editors, and it does carry an important message: Keystrokes, and the lack of a universal standard (or perhaps, a single universal standard outside of Emacs and vi), are the number one thing holding adaptation back, and the number one thing devs should be aware of have they any ambition in conquering the world with their creation.

PS! No contest to a move to Discussions.

[lovehumans]

I'm not disagreeing with the message

[eugenioenko]

@forthrin are you looking for vim keybidnings? If thats the case, vim plugin is available:

#386

ttt/README.md

Line 452 in f14334f

#### Vim Mode

Does that gets you covered? Or is the plugin missing some keybindings?

[forthrin]

I'm an Emacs guy. And I wouldn't actually mind switching shortcuts, but then I would only want to switch once, but since everyone and their gran is making an editor, and none of them are adhering to a common standard, that idea goes out the window, and with the scruffy hippie one stays.

If all the new editors would agree on one single, common, universal keyboard shortcut set, and then compete on everything else, now that would be the dawn of a new era.

[eugenioenko]

Yeah, I hear you!

I'm very used to sublime/vscode shortcuts. And ctrl+shift+key sadly is not supported in lots of terminals.

The discussion does remind me of this classic joke

Joke aside, ttt plugin system supports global keystroke interceptor, the vim keybindngs plugin uses that for re-wiring the keyboard and adding vim style features. It should be possible to do the same for emacs, I can take a look if you're interested?

[forthrin]

I'd laugh, but it hurts too much.

You could try, though it won't be 100% beyond the surface, because of how minibuffers work, auto-complete, quitting, etc. Then again, maybe it's enough. At least the effort is appreciated.

I started an super-simple editor some years ago that would (almost) only use standard UNIX keys. Maybe now with the advent of Skynet, getting this to a MVP would be an walk in the prompt.

The idea was that when only implementing the functions I use myself, everything would reside on keys with single modifiers, rather than Cmd + Shift + Alt + Meta + Stand on one leg and crow.

Some pointers:

https://github.com/jordanhubbard/shemacs
https://github.com/dacap/keyfreq

[lovehumans]

@forthrin Have you looked into programmable keybaords?

When I want to set a shortcut in an app I get this annoying problem where what I'm trying to set it to is already taken. It's like trying to come up with a username that is available.
With a programmable keyboard, I have a layer with F-keys and use F-keys > 12 for shortcuts, e.g. F17, F23 etc. To reach them, it's still a single modifier key.

I'm aware that this only partially alleviates your issue.

[forthrin]

There is no silver bullet. The major threshold for making your own editor is syntax highlighting, which requires AST, but that can always be outsourced. The rest is mindbogglingly easy. I mean, "cut to end of line", "copy to clipboard", a mere few lines each.

[eugenioenko]

@forthrin @lovehumans didn't want to leave you hanging so I did a quick pass on the emacs compatibility, it is as you pointed out superficial but hopefully it gets most of the job done. At least as the first pass. Plugins covers:

-	-
Move	C-f C-b C-n C-p C-a C-e M-f M-b C-v M-v M-< M-> C-l
Mark	C-SPC C-x C-x C-x h C-u C-SPC
Kill / yank	C-k C-w M-w C-y M-y M-d M-DEL C-d DEL
Edit	C-t C-o M-u M-l M-c C-q
Undo	C-/ C-x u
Files	C-x C-s C-x C-f C-x b C-x k C-x C-c
Commands	M-x C-g C-u C-h b
Macros	C-x ( C-x ) C-x e
Search	C-s C-r — incremental: DEL backtracks, C-g aborts, RET exits

You do need lastest ttt, I haven't released 1.2.0 yet so you might need to build the binary yourself make build should do it.

The plugin can be installed form plugins tab by searching emacs or just do install from url:

https://github.com/eugenioenko/ttt-emacs

A restart might be required.
Seems like emacs restore undo cursor to the start of the word, while vscode at the end.
There is a new setting for this and the plugin handles settings.

I don't use emacs myself, so can't really do a good job testing it out, but I did create a differential tester with real emacs as oracle using emacs -Q --batch --eval and ttt --exec so that should have cought most of issues. It runs the same input on emacs and ttt and checks for differences in ouputs . There are still a few divergences all related to undo grouping, hopefully nothing major.

If you do try, would love some feedback. Some keybindings like multi-cursor ctrl+d have been taken over C-d for delete. And the multi-cursor keybindings hasn't been rebound, so if you need it you will need to update keybindings.json for it or use the View >> Keybindings Settings to rebind

[forthrin]

Yeah, it's sort of working. You have a good system for extending the product! Makes it a little easier to get into from the get-go. Default colors are nice, and so on.

However, what does a 90's File-Edit menu and F-keys have do to in a UNIX terminal editor?

Line numbers are not really useful for code.

The scrollbar would be better off just marking the current position with inverted colors over the rightmost column of text, because of how the Terminal makes vertical spacing between lines (depending on settings, obviously).

And for Donald Knuth's sake, do not blink the cursor! That's like the guy who's pushing your shoulder and says, "Yeah? Whatcha gonna do about it, eh? Eh?" The opposite of the zen you need when thinking about your code.

https://en.wikipedia.org/wiki/Blink_element

[eugenioenko]

Thank you fro trying out!

I bring good news :)

Line numbers can be disabled.
~/.config/ttt/settings.json or View >> Settings and set editor.lineNumbers to false that will remove them.
(Bonus tip, if the 1col padding bothers you between code and the left edge, it can disabled by setting line gutters to minimal)

Cursor style can be changed
editor.cursorStyle and available options are steadyBlock steadyBar and steadyUnderline.
(I just realized, the steady ones are not documented but they are visible options in View >> Settings)

Line numbers are not really useful for code.

So true, they eventually stressed me out in vscode i removed them but then when dooing peer programming folks had hard time pointing out the line XD
In ttt they dont stress me out that much, still can be disabled.

do not blink the cursor

XD . Solid block for the win. The reason blinking bar is the default because ttt vision is to be very familiar to vscode/zen crowd and pull them from electron app into the terminal where they can start enjoying life finally and not miss out on the best dev environment which is the terminal.

[forthrin]

Good answers!

What about the menu and F-keys? It seems mostly like a novelty, "Ha ha! Windows 95 Notepad / Edit in the terminal", but after 30 seconds, the fun is over.

This has not prevented a bunch of people (including Bill) from building dozens of these, as featured on Terminal Trove, leveraging AI and ANSI libraries, but to no real everyday usefulness.

[eugenioenko]

What about the menu and F-keys? It seems mostly like a novelty,

That's an interesting point and it does take a whole row that can be used by code. For ttt specifically, the reason it's there is: "Visual Memory". Similarly how you have muscle memory with emacs shortcuts, folks that are used to vscode style editors would expect it to be there. Design wise, the menu toolbar also facilitates discovery. You can click "Options" and see the line for "Border Style" without the need of reading the manual.

ttt specifically is trying to create a familiar environment for vscode/sublime/zed users but in the terminal. So the menu being there is becasue thats what's kinda expected in a modern GUI application. North start for ttt is TUI that feels like GUI (and not trying to resuscitate Turbo Vision XD)

You do bring a really good idea for a feature, hiding the menu toolbar. That can be an editor option and would allow folks who don't really want it there hide it.

Great chat! Really appreciate your perspective on editors

[forthrin]

OK, so you have an thoughtful idea behind it, which is good. As you can see, the idea is not immediately obvious, but possibly curious to some users. Also, most coders are very well versed in terminals, and usually know about emacs, vi and nano, even if they're not necessarily seasoned in them.

F-keys were great in the 90s, particularly for copying and moving files in Norton Commander, but then they became media keys, and you can't have both. One as to be with Fn modifier, which ruins it.

It is allegedly possible to force F-key mode for a single app with macOS hacking, so if you can do that, you have freed F-keys for your users, while letting them keep media keys for general macOS use.