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

Fine, I'll build my own text editor

dbushell.com

Post reply on HN
Print view View original

211–220 of 264 posts

Re: Fine, I'll build my own text editor

#211

Post by Mashimo »

NetMageSCW wrote: post #200
Mashimo wrote: post #95

Earlier quoted context omitted.

Also another reason for having a single tool for a whole team: I can go to my coworkers desk for pair programming and have the same setup. I know the shortcuts, everyone has the same "run configurations" (start app, remote debug etc.), starting gradle tasks from UI, git comment style.

Counterpoint: when you go to a coworker’s desk you shouldn’t be touching the keyboard or the mouse otherwise they are just watching you do their work. You should have them come to your desk if you want to be the one running the show. Everyone can have their own environment and they translate what you say to their own methods and it helps them learn. This isn’t an episode of NCIS.

If they ask me for help, why should I not give a quick example?

On some hard tasks we sometimes switch to codes.

Must be a cultural thing, I never heard about not touching a coworkers keyboard when working together.

Re: Fine, I'll build my own text editor

#212

Post by tzs »

bigiain wrote: post #38
tzs wrote: post #31

Sometime around 1980-81 I had a part time job while an undergraduate in college doing system programming/admin for the Caltech High Energy Physics department. Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs. One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the sc…

I was hoping for this to end with "I wrote emacs, and Karl wrote vi."

Hah. Those were some of the screen editors we complained about. Emacs was popularly said to stand for "(e)ight (m)egabytes (a)nd (c)constantly (s)wapping". (8 MB is small by today's standards, but back then it was big. I believe CITHEP's VAX 11/780 was either 4 MB or 8 MB). I don't remember what we didn't like about vi.

At the time most of us were not using any screen editor. We were using the version of QED [1] that Tom Duff, Rob Pike, Hugh Redelmeier, and David Tilbrook had ported to Unix.

If anyone is curious Karl's editor was named "ted", for "(t)ext (ed)itor".

This was surprisingly bland because Karl was known for coming up with great names. For example when the undergraduate hackers who used Caltech's PDP-10 decided to agree on some standards for things like command switch conventions, Karl named the group working on that: the Organization to Define Definitive Hacks Against Catastrophic Kludges, AKA the odd hack committee.

Mine was named "smegma", for something like "(s)ophisticated (m)odern (e)ditor with (g)lorious (m)acros (a)bilities". (I don't think I ever did actually get macros in).

Re: Fine, I'll build my own text editor

#213

Post by ferguess_k »

cmrdporcupine wrote: post #205
ferguess_k wrote: post #188

Earlier quoted context omitted.

Thanks for sharing. Do you mind to share a bit more about your observation and experience with C++ in Google? I'm just curious what kind of guidelines and practices produce better C++ code, because I have used C++ in my side projects, but I found it difficult to command -- it was always like handling a lot of dishes without breaking any -- that's why I talked about IQ. And when you said "before being given carte blan…

C++ at Google is highly restricted to fit to a very normative style guide. And there was strong leadership while I was there to help define what sane defaults might look like (Titus Winters FTW). And then there was a lot of efforts into build system and static analysis tools to help enforce that. And then on top of that a very strong foundational set of libraries on which things were built that were also built quite…

Thanks for sharing! I'm not really good enough to make the right call, but I get your points. So you would prefer someone in Google to build custom tools or introduce features into the C++ language and compilers to fix those issues, not to create a new language. Either way, this is so above my head :D that I can only listen and learn.

Re: Fine, I'll build my own text editor

#214

Post by 1718627440 »

NetMageSCW wrote: post #201
1718627440 wrote: post #70

Earlier quoted context omitted.

I always wanted to learn emacs, but I never do, because while I don't know it using it doesn't pay off. I did the tutorial at some point (I mean great that it exists) and now I can move around and close the editor, but that's the same I can do in nano, so I keep using nano.

That’s how you start with emacs but as you need to do more complex actions emacs will be able to support you so your skills will grow if you keep using it.

Yeah, but before I am proficient in the more elaborate stuff, there is no reason to use emacs, so I never do it. And there is no tutorial for this.

Re: Fine, I'll build my own text editor

#215

Post by cmrdporcupine »

ferguess_k wrote: post #213
cmrdporcupine wrote: post #205

Earlier quoted context omitted.

C++ at Google is highly restricted to fit to a very normative style guide. And there was strong leadership while I was there to help define what sane defaults might look like (Titus Winters FTW). And then there was a lot of efforts into build system and static analysis tools to help enforce that. And then on top of that a very strong foundational set of libraries on which things were built that were also built quite…

Thanks for sharing! I'm not really good enough to make the right call, but I get your points. So you would prefer someone in Google to build custom tools or introduce features into the C++ language and compilers to fix those issues, not to create a new language. Either way, this is so above my head :D that I can only listen and learn.

FWIW that is exactly what happened, to some degree.

And I'm not opposed to language change, I just didn't see why they needed to create a new language instead of adopting something the industry was already working on. They could have thrown their weight behind Rust, for example, in the early days.

The specific compromises inside Go seem on the whole quite idiosyncratic and led by Rob Pike's personal biases. And it was sold as "Google's language" when in fact Google wasn't really using it for most of that time (they are in fact adopting it a lot more now)

Re: Fine, I'll build my own text editor

#217

Post by cestith »

tripledry wrote: post #151
f3408fh wrote: post #132

Earlier quoted context omitted.

Bullshit. He describes the actual reasons here: https://go.dev/talks/2012/splash.article#TOC_4 . And anyway, since when is not liking something a bad reason to try your hand at creating a better thing?

They are probably referring to what Rob said in a presentation. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be e…

This sounds like he's discounting Lisp, Scheme, OCaml, and Haskell in favor of something that's more of a safer, fresher take on the C language for his target group. The real competition for a language like Go these days are Rust, Zig, maybe D or Swift. Python, Fortran, JS, TypeScript, PHP, Julia, and such are mostly used in other niches. Common Lisp, Scheme, Haskell, OCaml, Objective Pascal, Ada, and several more are capable languages but don't benefit as much from the network effects of C-family syntax.

Re: Fine, I'll build my own text editor

#219

Post by c-smile »

Just in case...

In Sciter I have three editing behaviors (element controllers) associated with these elements by defualt:

* - plain text editor working with single text node.

* - WYSIWYG editor working with a DOM tree.

* - editor working with a list of elements. Each element is allowed to have only inline and inline-block subelements and text nodes [1].

is optimized to work as a source code editor. Local editing in one element invalidates text layout of that only element but not the whole content as in case of .

All editors support ::highlight - to style fragments of text without the need to change underlying DOM.

provides streaming API allowing to access content of the element as pure plain text but with methods to ::highlight ranges in it to minimize problems with encodings and mappings of text positions to corresponding node trees and making syntax highlighting simpler:

See screenshot: https://sciter.com/wp-content/uploads/2026/09/plaintext-colo...

and also support transactional updates allowing to make non-trivial DOM tree mutations undoable as a single operation.

[1] behavior:plaintext - https://docs.sciter.com/docs/behaviors/behavior-plaintext

Re: Fine, I'll build my own text editor

#220

Post by anon291 »

kstenerud wrote: post #25
anon291 wrote: post #3

I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.

Because very few people actually care about the things that emacs has to offer. Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use. Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's enviro…

It's just easy to install on Windows. Base emacs does exactly what you want it to do. And my emacs v vscode comparison was specifically because of infinite configurability and expandability. VSCode has the same thing with its myriad javascript extensions.
Post reply on HN