Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing my own text editor, and daily-driving it

blog.jsbarretto.com

Post reply on HN
Print view View original

61–70 of 124 posts

Re: Writing my own text editor, and daily-driving it

#61

Post by dhruvmittal »

greatgib wrote: post #30

One of the best kept secret and one that he should have tried is "Kate". Good old style editor that is a native app, not an electron app. All the features that you might want and more, but simple and efficient. And the most important for me, super snappy. I can't bear the latency that you get for typing code when using things like vscode. I don't know how people can appreciate that.

I'm a big Kate fan as well, used it for years on all my Linux systems. Recently I got a little fed up with vscode lagging on large files, I bit the bullet and installed Kate on my windows 11 work PC as well.

Re: Writing my own text editor, and daily-driving it

#62

Post by mghackerlady »

greatgib wrote: post #30

One of the best kept secret and one that he should have tried is "Kate". Good old style editor that is a native app, not an electron app. All the features that you might want and more, but simple and efficient. And the most important for me, super snappy. I can't bear the latency that you get for typing code when using things like vscode. I don't know how people can appreciate that.

I just wish the extension ecosystem was more fleshed out

Re: Writing my own text editor, and daily-driving it

#63

Post by freedomben »

nickjj wrote: post #55
whynotmaybe wrote: post #11

Fond memory of when I wrote an editor in the 90's because we didn't want to use "ms edit" for COBOL and asm files. Syntax coloring, fast buffering and even a screen saver. You could even call the compiler directly from it. All this running on a pentium 120 and it felt a thousands times faster than today's vscode. But vscode can edit multiple files at the same time...

Yes, I remember writing a VB6 driven editor. I was so happy when I got find and replace to work. I still have the marketing page copy from 2002: Unlimited fully customizable template files Fully customizable syntax highlighting Very customizable user interface Color coded printing (optional) Column selection abilities Find / Replace by regular expressions Block indent / outdent Convert normal text to Ascii, Hex, and…

This is definitely aging me, but I'm still disappointed that all caps didn't win. That style made it so much easier to visually parse tags when scanning through the HTML code. I admit that syntax highlighting has mostly done away with that benefit, and now that I'm used to the lower case I don't mind it anymore, but the uppercase always felt better to me. Even reading that example above it feels more natural. Style is a hard thing.

Re: Writing my own text editor, and daily-driving it

#64

Post by mghackerlady »

fragmede wrote: post #18
whynotmaybe wrote: post #11

Fond memory of when I wrote an editor in the 90's because we didn't want to use "ms edit" for COBOL and asm files. Syntax coloring, fast buffering and even a screen saver. You could even call the compiler directly from it. All this running on a pentium 120 and it felt a thousands times faster than today's vscode. But vscode can edit multiple files at the same time...

Firing up VSCode on an old laptop, and having it get totally bogged down running a text editor killed a part of my soul. I'm from the vim era of computing, but I have a hard time telling people that's the route to go today with today's tools.

Whoever decided to write a text editor in JavaScript and HTML/CSS for any reason other than absolute necessity deserves to be taken out back and shot

Re: Writing my own text editor, and daily-driving it

#65

Post by mghackerlady »

nurettin wrote: post #39
whynotmaybe wrote: post #11

Fond memory of when I wrote an editor in the 90's because we didn't want to use "ms edit" for COBOL and asm files. Syntax coloring, fast buffering and even a screen saver. You could even call the compiler directly from it. All this running on a pentium 120 and it felt a thousands times faster than today's vscode. But vscode can edit multiple files at the same time...

> But vscode can edit multiple files at the same time borland turbo pascal and turbo c could also open multiple files at the same time.

If you're creative with it ed can as well

Re: Writing my own text editor, and daily-driving it

#67

Post by zesterer »

catapart wrote: post #56

Any chance people in this thread have some recommendations for text-editing libraries? I would love to build my own text editor, to do some things in my own way that no one else seems to have an interest in doing, but one of the big things for me is that it must be a GUI. I won't bore people with the reasons, but that requirement forces me to bring along a lot of stuff, like a font renderer (at least one) and a graph…

A thing that shocked me as I was working on the text editor was how capable modern terminal emulators are when you account for ANSI extensions. First-class clipboard access, mouse events, precise text styling, focus tracking, system notifications, key press/release events, etc. are all possible with a modern terminal emulator. There's not really anything else you need to build a very competent, ergonomic editor UI.

You can even use tools like trolley to wrap the entire application up in a ghostty-powered shim that presents the application as a native UI application: https://github.com/weedonandscott/trolley

Re: Writing my own text editor, and daily-driving it

#68

Post by ivanjermakov »

I went the same path of writing a text editor from scratch. There are a lot of moving parts, so I tried to outsource as much features as possible - LSP for intellisense, tree-sitter for highlighting and syntax-aware features, fzf for search and file handling, etc. I also tried to design it so that it can be tweaked to one's needs with simple code changes, suckless-style.

It was indeed a pain using it for the first few weeks, where every 5 minutes I found some bug and had to go back and fix it, instead of steadily working on some other project. Good news is more bugs you fix, less bugs is left.

https://github.com/ivanjermakov/hat

Re: Writing my own text editor, and daily-driving it

#69

Post by catapart »

kryptiskt wrote: post #59
catapart wrote: post #56

Any chance people in this thread have some recommendations for text-editing libraries? I would love to build my own text editor, to do some things in my own way that no one else seems to have an interest in doing, but one of the big things for me is that it must be a GUI. I won't bore people with the reasons, but that requirement forces me to bring along a lot of stuff, like a font renderer (at least one) and a graph…

Several of the lean GUI text editors are built on Scintilla ( https://scintilla.org/ ), which provides a cross-platform editing component that can be integrated in GTK, Windows or Mac GUI apps. Maybe that has too much bells and whistles for you, since it's both about editing and presentation.

I guess I might be misunderstanding what Scintilla is? Everything I've seen with it has it coupled with native controls, like a winform control or a Qt control. Are you saying that the library can be used, on its own, without a graphical component? If so, that might fit the bill!

Re: Writing my own text editor, and daily-driving it

#70

Post by catapart »

zesterer wrote: post #67
catapart wrote: post #56

Any chance people in this thread have some recommendations for text-editing libraries? I would love to build my own text editor, to do some things in my own way that no one else seems to have an interest in doing, but one of the big things for me is that it must be a GUI. I won't bore people with the reasons, but that requirement forces me to bring along a lot of stuff, like a font renderer (at least one) and a graph…

A thing that shocked me as I was working on the text editor was how capable modern terminal emulators are when you account for ANSI extensions. First-class clipboard access, mouse events, precise text styling, focus tracking, system notifications, key press/release events, etc. are all possible with a modern terminal emulator. There's not really anything else you need to build a very competent, ergonomic editor UI. Y…

I appreciate this, but I'm not concerned with the capabilities of the terminal or the GUI. What would be unhelpful, to me, would be to build a TUI because then if I wanted to send the actual app state to - for instance, a web browser which runs the library in WASM - the only way would be to pipe the terminal output across the shared buffer, instead of just blitting the app/editor state into it (or the relevant messages, like CRDTs).

Contrast that with a library: I could capture the inputs from any source - browser, native app, network, etc - work with the data using the single library, and then render the result in whatever client (or as many clients) as I wanted.

Post reply on HN