Show HN: Tome, aka Tom's Editor – a new command-line text editor | Hacker News Reader

Show HN: Tome, aka Tom's Editor – a new command-line text editor

github.com

131 pointsboutell91 comments

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.

https://wezfurlong.org/wezterm/

https://sw.kovidgoyal.net/kitty/

Neat, there is a tracking issue to add support in the iTerm2 repo as well: https://gitlab.com/gnachman/iterm2/-/issues/10017

How does it compare to Alacrity?

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.

That just means you'll need to write a terminal emulator as well :)

Relevant: https://www.leonerd.org.uk/hacks/fixterms/

That’s the spirit; because we can!!

you could technically also use an app like iTerm2.app which lets you control most of this.

You could also take the pill and make 180 turn and put vim bindings on VSCode, lmao

You can do a lot with the Kitty keyboard protocol: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#comprehen...

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)

I went from VSCode back to emacs. I just stick with most of the emacs defaults, although I’m sure you could find a package for VSCode defaults.

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.

I actually wrote a (Neo)vim plugin to make it behave like a conventional editor https://github.com/tombh/novim-mode

but why?

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.

* I'm super fast with VSCode's keybindings*

Using the arrows keys and the mouse?

> Mostly because I want to stay in my terminal as much as possible

emacs

It's already pretty nice. Very fast, CUA shortcuts (that are also shown at bottom), indeed very few dependencies. Good work.

Thanks!

Should run it with bun instead of Node.js for that extra speed!

Give it a try and let me know what happens!

I just do not knowingly use anything that has to be installed with npm.

All I want is nano with VSCode keybindings for multiple cursors. Does is exist or do I also have to write my own?

I think micro is like that https://github.com/zyedidia/micro

Micro is excellent. I love it. Been using it for years and can't go back to vim.

- Modern keybindings and shortcuts

- mouse support, scrolling support

- copy/paste from the clipboard

- syntax highlighting

- supports extensions

All out of the box. Just wish the community extensions were more numerous but haven't written any myself and won't complain.

edit: Try tome! Dont' want to hijack this thread

I've been using micro a lot recently and it's pretty impressive. I really have no complaints.

You can try Kakoune or Helix.

Helix is NICE. Thank you

Terminal != Command line

> Written in Node.js with practically no libraries (certainly no Electron)

Still V8 though.

The bulk of Electron is the browser engine. V8 is nothing.

That’s awesome! Can someone point me to a similar minimal web/editableContent implementation? Would love to learn from it.

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.

CRM from scratch - https://www.youtube.com/watch?v=l4QjeBEkNLc (Shameless plug)

There is already a Tome. http://tome.app

It's pretty hard to find a name that isn't already _something else_. Not impossible, but hard. Your tome.app at least isn't an editor, so...

I mean.

Tomedit. Tomale. Lots of words to play with.

and no real reason to if he likes the one he chose.

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.

Does this use a TUI library or does it directly implement the console I/O?

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.

Don't. Less dependency is better.

why?? TECO (now TECOC Type Every Character Over Constantly) is perfection as a cli editor

https://github.com/blakemcbride/TECOC

seriously. try it.

No screenshot, no joy

Screenshot added.

Thank you!

in go or rust?

That was the first thing I checked and surprisingly it's JS/node.

That kills it for me. Terminal apps in Python or JS works but are significantly slower, and you can feel it.

Talking in general. Not this one. I haven't tried this one.

It feels zoomy so far. v8 is quite fast to start with. But we’ll see.

Given the description, this sounds more TUI than CLI. Honestly, when I saw the title, I thought it was a competitor to ed(1).

If I could edit that now I would

I know this isn't an original nit-pick but a cli editor is like ed, this sounds like a screen editor.

I seem to recall people calling ed a "line editor" back in the dino days, but yeah I erred on the side of comprehensibility over historical accuracy.

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.

> can't fight the jargon drift forever

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

> ed is a line editor in the sense that all of it's commands act on a \n delimited line at a time

I don't think that’s fully correct.

https://en.wikipedia.org/wiki/Line_editor (emphasis added):

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

> of course it is the goddamned year our our lord two thousand dickity twenty three after all

please stop ... my sides ... I'm in stitches.

I think people call this a "TUI" now.

"written in node.js" - insert squidward packing his chair meme

Lazy take. Node.js is fast, mature, and gives you an in-built editor scripting language for free.

...I mean it's not my favourite, but acting like that's some kind of massive barrier to users of a CLI editor is an overreaction.

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 run it on alpine linux with no issues. What distro doesn't have in the repos?

I mean fair enough if you don't like it. But it's nothing if not easy to run.

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)

It's absolutely overhead on your poor cpu though

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.

> But how much CPU will an editor really consume?

Ah, you've never had the pleasure of using Emacs I see.

As an Emacs user, a lot more than you'd think.

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?

What makes them slow is syntax highlighting. It’s impossible to solve well without making the highlighting mechanism really basic.

Tree Sitter is a significant improvement though.

These are the same kind of people criticizing the Java bunch some time ago.

How times change.

That's a 40mb runtime that's probably already on your system

Think the other poster has a point. You probably do have node on your desktop but it’s not guaranteed to be on a server where terminal editors shine

Not in my netbook.

If it was Ruby or Python or Perl, would you say the same?

For a text editor? Without a doubt.

> const tabSpaces = 2;

Shots fired.

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.

Made my own CLI text editor as well this year using rust following this: https://www.flenker.blog/hecto/

Building tools like this is great practice for learning new languages.

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)

It's pretty easy to say "terminal based" or "text mode" instead of CLI, which is misleading. I was expecting an alternative to sed.

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!

> Maybe should be THE (Tom's Hubristic Editor).

A TUI editor called THE already exists: The Hessling Editor, a work-alike of xedit.

1. https://hessling-editor.sourceforge.net/

The THE lul

Reply on news.ycombinator.com