[HN Gopher] Show HN: Tome, aka Tom's Editor - a new command-line...
       ___________________________________________________________________
        
       Show HN: Tome, aka Tom's Editor - a new command-line text editor
        
       Author : boutell
       Score  : 112 points
       Date   : 2023-09-22 17:23 UTC (5 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | forgotpwd16 wrote:
       | It's already pretty nice. Very fast, CUA shortcuts (that are also
       | shown at bottom), indeed very few dependencies. Good work.
        
         | boutell wrote:
         | Thanks!
        
       | LispSporks22 wrote:
       | > 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/
        
         | boutell wrote:
         | 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.
        
         | [deleted]
        
         | [deleted]
        
       | rickydroll wrote:
       | why?? TECO (now TECOC Type Every Character Over Constantly) is
       | perfection as a cli editor
       | 
       | https://github.com/blakemcbride/TECOC
       | 
       | seriously. try it.
        
       | jbritton wrote:
       | Does this use a TUI library or does it directly implement the
       | console I/O?
        
       | hackncheese wrote:
       | The THE lul
        
       | worksonmine wrote:
       | > Written in Node.js with practically no libraries (certainly no
       | Electron)
       | 
       | Still V8 though.
        
         | LoganDark wrote:
         | The bulk of Electron is the browser engine. V8 is nothing.
        
       | ThouYS wrote:
       | "written in node.js" - insert squidward packing his chair meme
        
         | disintegore wrote:
         | That's a 40mb runtime that's probably already on your system
        
           | edgyquant wrote:
           | 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
        
           | [deleted]
        
           | anthk wrote:
           | Not in my netbook.
        
         | [deleted]
        
         | nerdponx wrote:
         | If it was Ruby or Python or Perl, would you say the same?
        
           | toxik wrote:
           | For a text editor? Without a doubt.
        
         | boutell wrote:
         | 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)
        
           | nunobrito wrote:
           | These are the same kind of people criticizing the Java bunch
           | some time ago.
           | 
           | How times change.
        
           | 3836293648 wrote:
           | It's absolutely overhead on your poor cpu though
        
             | boutell wrote:
             | 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.
        
               | Y_Y wrote:
               | > But how much CPU will an editor really consume?
               | 
               | Ah, you've never had the pleasure of using Emacs I see.
        
               | 3836293648 wrote:
               | As an Emacs user, a lot more than you'd think.
        
             | tredre3 wrote:
             | 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?
        
               | toxik wrote:
               | What makes them slow is syntax highlighting. It's
               | impossible to solve well without making the highlighting
               | mechanism really basic.
        
         | [deleted]
        
         | LAC-Tech wrote:
         | 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.
        
       | uwagar wrote:
       | in go or rust?
        
         | habibur wrote:
         | 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.
        
           | boutell wrote:
           | It feels zoomy so far. v8 is quite fast to start with. But
           | we'll see.
        
       | Svip wrote:
       | Given the description, this sounds more TUI than CLI. Honestly,
       | when I saw the title, I thought it was a competitor to ed(1).
        
         | boutell wrote:
         | If I could edit that now I would
        
       | jenkstom wrote:
       | It's pretty easy to say "terminal based" or "text mode" instead
       | of CLI, which is misleading. I was expecting an alternative to
       | sed.
        
         | [deleted]
        
       | thisismyhna wrote:
       | 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.
        
         | btown wrote:
         | 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.
        
         | [deleted]
        
         | bajsejohannes wrote:
         | 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)
        
       | hobo_mark wrote:
       | All I want is nano with VSCode keybindings for multiple cursors.
       | Does is exist or do I also have to write my own?
        
         | bPspGiJT8Y wrote:
         | You can try Kakoune or Helix.
        
           | bpiche wrote:
           | Helix is NICE. Thank you
        
         | urtrs wrote:
         | I think micro is like that https://github.com/zyedidia/micro
        
           | bpiche wrote:
           | 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
        
       | lagniappe wrote:
       | 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!
        
         | [deleted]
        
           | [deleted]
        
       | danielvaughn wrote:
       | 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.
        
         | marssaxman wrote:
         | 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.
        
         | [deleted]
        
         | deepspace wrote:
         | 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.
        
         | tombh wrote:
         | I actually wrote a (Neo)vim plugin to make it behave like a
         | conventional editor https://github.com/tombh/novim-mode
        
         | mplanchard wrote:
         | 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
        
         | boutell wrote:
         | 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.
        
           | hmry wrote:
           | That just means you'll need to write a terminal emulator as
           | well :)
        
             | emi2k01 wrote:
             | Relevant: https://www.leonerd.org.uk/hacks/fixterms/
        
             | psyclobe wrote:
             | That's the spirit; because we can!!
        
               | tough wrote:
               | 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
        
           | cstrahan wrote:
           | 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/
        
           | pianohacker wrote:
           | You can do a lot with the Kitty keyboard protocol:
           | https://sw.kovidgoyal.net/kitty/keyboard-
           | protocol/#comprehen...
        
         | sixstringtheory wrote:
         | 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.
        
           | seanw444 wrote:
           | 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.
        
         | Aperocky wrote:
         | 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)
        
       | ripperdoc wrote:
       | Should run it with bun instead of Node.js for that extra speed!
        
         | boutell wrote:
         | Give it a try and let me know what happens!
        
       | tuatoru wrote:
       | > 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/
        
         | [deleted]
        
       | n3storm wrote:
       | No screenshot, no joy
        
         | boutell wrote:
         | Screenshot added.
        
       | Avshalom wrote:
       | I know this isn't an original nit-pick but a cli editor is like
       | ed, this sounds like a screen editor.
        
         | [deleted]
        
         | nerdponx wrote:
         | I think people call this a "TUI" now.
        
         | boutell wrote:
         | 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.
        
           | Avshalom wrote:
           | 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.
        
             | PH95VuimJjqBqy wrote:
             | > 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.
        
             | dllthomas wrote:
             | > 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).
        
             | Someone wrote:
             | > 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.
        
       | [deleted]
        
       | kesava wrote:
       | That's awesome! Can someone point me to a similar minimal
       | web/editableContent implementation? Would love to learn from it.
        
         | boutell wrote:
         | 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.
        
         | alexbezhan wrote:
         | CRM from scratch - https://www.youtube.com/watch?v=l4QjeBEkNLc
         | (Shameless plug)
        
       ___________________________________________________________________
       (page generated 2023-09-22 23:00 UTC)