Live data from Hacker News

Fine, I'll build my own text editor

dbushell.com

191–200 of 264 posts

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

#191
I was a student at Rose-Hulman back in 1981-83. Back then they had a tweaked out 11/70 running RSTS and supporting 144 terminals, and the new spiffy VAX 11/780 running VMS.

I found an old 11/40 that had a memory issue to work on, and started learning machine code, etc. Somewhere along the line, I was infected with a love of TECO, a relic of an editor that was said to be the basis for EMACS.

I wrote my own version out of nostalgia in 1991. I put it on Github a few years ago.[1]

It's only in the past few months that I learned that the first versions of TECO were actually full screen editors, which floored me, as I had always assumed TECO stood for Tape Editor, Character Oriented.... and started with teletype terminals and paper tape.

[1] https://github.com/mikewarot/teco

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

#192
post #49

Earlier quoted context omitted.

Here's Rob's editor (or at least one of them): https://en.wikipedia.org/wiki/Acme_(text_editor)

Here is another one: https://en.wikipedia.org/wiki/Sam_(text_editor) I have used both editors quite a bit and did like both of them.

Those were both amazing but so very niche.

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

#193

Earlier quoted context omitted.

The implementation is usually pretty ugly, actually

I implemented a pretty simple iOS/macOS text editor using TextKit 2, and it was astonishing how many hacks, workarounds and manual implementations were needed to support even the most basic features. That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.

I am surprised- I reimplemented Notepad for Windows CE and it was pretty much a wrapper around a standard Windows control. It was just a couple of pages of MFC code I believe.

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

#194
post #36

Hope the author finds CodeMirror 6 to be a solid foundation. It uses the same contenteditable-based approach but abstracts away all the browser-specific edge cases and quirks for you.

It's an amazing project but I always found the docs lacking. Maybe you'd have to sit down with the code for a while or ask AI to explain it, but there were concepts, like "facets", that seemed crucial but were never really explained. I also found the way the docs sites were structured to be really frustrating and confusing - it always felt like there were pages missing and I was never sure if I was on the right page…

It takes a bit of time to get used to the abstractions, but I think it is worthwhile. To make a minimal working text editor you will only need a little surface of API (covered in the system guide [0]), but to do this by yourself you need to know a lot about browsers' internal working and their undocumented quirks, which is much more overwhelming. (you can glance over `@codemirror/view`'s commit history to see what I mean)

[0]: https://codemirror.net/docs/guide/

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

#195

Earlier quoted context omitted.

I implemented a pretty simple iOS/macOS text editor using TextKit 2, and it was astonishing how many hacks, workarounds and manual implementations were needed to support even the most basic features. That codebase is the polar opposite of a finely crafted pen, and the ugliness all comes from the API.

I am surprised- I reimplemented Notepad for Windows CE and it was pretty much a wrapper around a standard Windows control. It was just a couple of pages of MFC code I believe.

It probably depends on what you're trying to do; I needed Markdown styling and Markdown-aware behaviors (e.g. when you hit return after a list item, indent the same amount and add a new list marker), context-aware nesting (hit Command-[/] to indent/outdent), hotkeys for heading levels, and so on. Between keeping the attributed text styles correct, properly grabbing the right text ranges to operate on, and doing it all in undoable transactions, it became a handful.

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

#196

Earlier quoted context omitted.

If average Google programmers are too stupid to program in C++, what kind of qualities are needed to get good at programming in C++? Like 140+ IQ? Or one needs to really sit down, think through, slow down, which is against the "velocity"?

He's also wrong; the average Google programmer was more than capable of producing good C++ and Google's C++ tooling and standardization was excellent. Source: worked there. That's not to say that C++ is a good or appropriate language or that the codebase wouldn't have been better served by another language. But "stupidity" was never the problem. And Go is not the "another language" I think fits the bill (and in fact…

I think he worked on Sawmill, where he developed a language that looks superficially a bit like Go called Sawzall. Sawzall seems to have been open sourced at some point.

It's got some common syntax similarities like using `a := b` to mean creating a new local variable of inferred type.

https://github.com/anthonyu/Sizzle/blob/master/docs/sawzall-...

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

#198
post #133

Earlier quoted context omitted.

I use Emacs and the edits I do seem imperceptible to me. Do you know of any test I should try to see whether the lag is notable and intrusive? Emacs does start fairly slowly, though, takes about 0.6 seconds.

I would love to see your config!

I'll try to remember to put it on Codeberg, though it's a little bloated and idiosyncratic (that means 'made by an idiot', right?).

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

#199

Earlier quoted context omitted.

He's also wrong; the average Google programmer was more than capable of producing good C++ and Google's C++ tooling and standardization was excellent. Source: worked there. That's not to say that C++ is a good or appropriate language or that the codebase wouldn't have been better served by another language. But "stupidity" was never the problem. And Go is not the "another language" I think fits the bill (and in fact…

I think he worked on Sawmill, where he developed a language that looks superficially a bit like Go called Sawzall. Sawzall seems to have been open sourced at some point. It's got some common syntax similarities like using `a := b` to mean creating a new local variable of inferred type. https://github.com/anthonyu/Sizzle/blob/master/docs/sawzall-...

Ah, ok, I worked a bit with Sawzall. It was fine.

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

#200
post #95

Earlier quoted context omitted.

They jump to such tools, because they are not that invested in making and having the optimal tool for their job, and don't want to spend time setting things up. Especially, not in their own time, if they even do any projects in their own time at all. Lots and lots of people in IT are not that dedicated or passionate about the work.

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.

Post reply on HN