Honestly I really want to make one. Mostly because I want to stay in my terminal as much as possible, but I'm super fast with VSCode's keybindings and I can't handle the velocity drop during the learning curve.
Alternatively, if it's possible to emulate VSCode's keybindings in an existing editor, I'd be happy to go that route. I just don't know the space very well.
Yes, you're in for some disappointment there alas: many terminal applications, especially macOS terminal, will devour most cool combinations of the "meta" keys (shift, control, alt, command...) for themselves. This is why I had to make a slightly modal "select mode" entered with the escape key. I'm still trying to make it mostly familiar but 100% vscode keybindings isn't possible.
Easy fix: Use a more featureful (and more spec compliant) terminal emulator, like Kitty or WezTerm, and enable the Kitty keyboard protocol.
If you’re using iTerm, or Konsole, or Gnome Terminal, or urxvt, or… pretty much anything other than Kitty or WezTerm, you owe it to yourself to make the switch.
Personally, I use WezTerm.
Support for Windows, macOS and Linux. Better configuration. Better font rendering. Built-in fallback to Nerd Font for vscode-like icons in your editor of choice (I use neovim), so you don’t need to patch your font. Supports the Kitty keyboard protocol, and image display. Tons of features, too many to list here.
It's been a while since I looked at Alacritty, so I've tried to double check things, but feel free to add corrections in the comments in case I get some of this wrong.
Features WezTerm has that Alacritty doesn't:
1) iTerm Image Protocol (inline image display)
2) Kitty Keyboard Protocol (allows for keybindings that otherwise wouldn't be possible)
3) Semantic prompts (e.g. you can configure a keybinding to navigate in your scrollback to the previous/next prompt)
4) Built-in SSH support. Creating new tabs or panes will each create a new channel in your existing session so you won't need to re-authenticate for additional tabs that you create.
5) Alternatively, you could use WezTerm's multiplexing support. Think tmux (remote sessions persist even when you disconnect, and reconnecting gives you all of the existing windows/tabs/panes again), but graphical and built into the terminal emulator.
6) Config is written in Lua, and you can use that for clever automation, new keybindings, custom formatting of window/tab titles, etc.
7) Multiple fonts can be specified, where glyph rendering will attempt to fallback to the other fonts when not found. Advanced font shaping configuration -- you could do things like enable/disable ligatures, enable font options (if the font supports it) for alternative styling, like having zeros render with a dot or slash (to differentiate from a capital letter 'O').
Those are just some of the things I could think of real quick. Definitely recommend skimming the WezTerm documentation site.
Well there are existing tools.. one of which starts with "v" and had more than 3 decades of changes and I found it achieving the purpose you described (with a small learning curve)
Yeah Emacs is insane. It's the only editor that is so customizable that it can imitate any other editor. Obviously, that comes with some effort to do, though.
You should! It's a satisfying exercise, and it's not hard to get an editor working well enough to be useful.
I've been daily-driving my own little editor for many years now. I do like VSCode, and drop in on occasion, but it's really nice to work with a tool that only changes when I want it to change.
emacs and vim work well in the terminal and are almost certainly customizable enough to mimic the VSCode keybindings, /but/ definitely not without a velocity drop while you get everything set up as you like it
My TUI editor of choice is "joe". It allows you to freely assign keybindings through a config file. Comes out of the box with Wordstar, Vi and Emacs bindings, but it is easy to roll your own.
The heavy part is contenteditable is usually a million workarounds for weird browser specific stuff, which is why DIY is very risky there… or it was. I haven’t explored contenteditable from scratch since the final death of IE11. Might not be as crazy today.
Considering there're many projects named tome in github (and not, such as the same named tomeapp.com) linked app has probably done some good marketing/SEO to come as first result in searches.
Has my own shitty implementation of a subset of termcap right now because I initially wrote it on an airplane with only manpages for documentation. But I should probably switch to a library for that.
ed is a line editor in the sense that all of it's commands act on a \n delimited line at a time (compare to say sam/acme's commands that act on a selection and treat \n as just any other character, I can't say much about teco).
I completely understand the conflation of cli and "uses a terminal" of course it is the goddamned year our our lord two thousand dickity twenty three after all, can't fight the jargon drift forever; I just think there is still room in the world for a new text editing command language that exists independent of a particular visual representation.
Within reason, yeah. But it's obnoxious to have the ambiguity, and what term do we use now for an editor that you interact with from the shell's command line (eg. sed, I guess?), or principally from its own command line (eg. ed)? While we're at it, if we're coining new terms, ideally we could distinguish those two.
sed in particular is "the streaming editor" but "streaming" isn't the category I'm looking for, which would also include something like nmh for mail (vs the traditional mail client behaving like ed, or things like mutt/pine that run in the terminal but provide more of a GUI that happens to be rendered in text).
“a line editor is a text editor in which each editing command applies to _one_or_more_ complete lines of text designated by the user”
Also, ed commands all can work on multiple lines by prefixing them with an address range. For example,
1,4l
will output the first four lines of the file to the output device.
I also think a defining feature is that line editors don’t automatically show a full screen of the document because they’re designed to be usable on a teletype, where printing a line took about 10 seconds. In fact, even just outputting the current line after each command was considered wasteful.
The Node ecosystem has caused me nothing but pain, is large and memory-intensive, and Doesn't come stock with the distros I use, requiring much manual configuration. I too will be avoiding this editor, whatever its merits, due to JabbaScript.
I meant that it's not preinstalled in the distros I use, not that it's unavailable. Each time I try and bite the bullet and get over myself to try and use a Node app, I end up having to deal with not having the right version of Node as well as have to deal with a litany of stupid, outdated, and insecure library dependencies. They're just not worth my sanity.
Planning to minimize npm dependencies on this one. As for node version, debian 12 ships with node 18, which means there's someone planning to do a true LTS of a node major version... for once. Wishing them luck on that!
Hey, your mileage will vary! My workday includes Node.js being present on basically everything, so it's not overhead for me. (As others have pointed out it's also not that heavy a thing to have around, especially compared to Electron)
I... guess? Compared to an editor written in Rust? Sure? But how much CPU will an editor really consume?
As with most things outside of tight loops in games, good architectural decisions are going to matter a lot more than language choice. Premature optimization is the root of all evil, but if I see that the algorithm is inefficient in practice I'll change the algorithm.
VIM but particularly Emacs can get painfully slow on semi-large files (and forget about it if you have very long lines) and you have to tweak or disable lots of features if you want them to be reactive and not peg your CPU.
So I think it's more down to the implementation than the language it's written in. V8 is really efficient at running JS, what slows it down is the 25 levels of abstraction and indirection that is usually added on top of it. OP claims to try to reduce that, so maybe give it a chance?
Building your own editor is a fun project for sure. Curious with node whether you can build it into a single executable that you can, for example, conveniently scp around to host:.local/bin/
You probably noticed that ".editorconfig" support is in the plan, so this won't be forced forever, but it's good for proving out various indentation features.
There are ways to make a binary/flatpack/etc., but since Node.js is used by many things it probably makes more sense not to. Notably debian 12 ships with Node.js 18, which will probably be supported by tome for as long as it's supported by debian e.g. quite a while.
Just wanted to share that this is one of the best tutorials that I've read in quite a while! Super clear writing style, the use of diffs for each stage (as well as showing the progression via different tags in the repository) is incredible (and something I may borrow in the future!), and you do a great job walking the reader through the complexities of Rust in an approachable way. Really, really cool.
I haven't read about hecto (yet), but I can thoroughly recommend the one about kilo, which is linked in the first paragraph of that article http://antirez.com/news/108 . Or even just reading the C code. It's achieving a lot with few lines and no dependencies (outside of the OS, that is)
Yes! We need more "because I can" and "because I wanted to" in this. More art, less ... idk what to say here ... less formality. Some of the most fun projects I've done were ones that I knew already existed but I just had to -know- what it'd be like to write one.
Good work Tom :) I'll give it a shot BECAUSE I CAN!
Alternatively, if it's possible to emulate VSCode's keybindings in an existing editor, I'd be happy to go that route. I just don't know the space very well.