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

Build Your Own Text Editor

viewsourcecode.org

Post reply on HN
Print view View original

81–90 of 164 posts

Re: Build Your Own Text Editor

#81

Post by aethertron »

johnfn wrote: post #74
aethertron wrote: post #73

1000 lines of code is considered small. But check this out http://kparc.com/edit.k Under 50 lines for a text editor written in K by the language's author. Way beyond my present understanding, but the promise of very small, powerful code is incredibly attractive.

Just to be that guy. Yeah, it's cool that the language author built a text editor in under 50 lines, and there's a sort of geeky hacky appeal to trying to cram as much functionality as possible into as small a space as possible. But what does it actually mean in terms of programming? How maintainable is "small code"? How readable is it? (Well, you answered that question already.) How hackable is it? It's a curiosity,…

Fine questions.

But super-compact code could be very practical/readable/hackable, as long as there's the prerequisite knowledge. Fewer symbols means less complexity to parse. This works, provided that those symbols map to powerful operators that can be really understood and effectively combined to produce the desired outcome.

And there's no need to scroll: perceive everything in one glance!

Re: Build Your Own Text Editor

#82

Post by taejo »

mrkgnao wrote: post #58
Dangeranger wrote: post #4

Reference implementations of medium sized applications are incredibly useful for leveling up as a programmer. While there are many large successful open source applications, many are overwhelming to read and learn from. Having something that outlines the key features and components and which ignores the important but complicated edge cases assists in keeping the attention focused. Now if there are annotation within t…

https://github.com/jameysharp/corrode/blob/master/src/Langua... Corrode is absolutely incredible. This file is literate Haskell, which means there's more documentation than code (I guess), and it transforms C into Rust.

> This file is literate Haskell, which means there's more documentation than code (I guess)

That's the intent, but to the compiler, the meaning of literate Haskell is that comments are the default, and only lines starting with > contain code

Re: Build Your Own Text Editor

#84

Post by vbernat »

For better portability, terminfo should be used instead of using hard-coded terminal sequences. Otherwise, this is a really great intro. I liked the beginning with how to put your configure your terminal.

Re: Build Your Own Text Editor

#85

Post by de_Selby »

johnfn wrote: post #74
aethertron wrote: post #73

1000 lines of code is considered small. But check this out http://kparc.com/edit.k Under 50 lines for a text editor written in K by the language's author. Way beyond my present understanding, but the promise of very small, powerful code is incredibly attractive.

Just to be that guy. Yeah, it's cool that the language author built a text editor in under 50 lines, and there's a sort of geeky hacky appeal to trying to cram as much functionality as possible into as small a space as possible. But what does it actually mean in terms of programming? How maintainable is "small code"? How readable is it? (Well, you answered that question already.) How hackable is it? It's a curiosity,…

> But what does it actually mean in terms of programming?

Without trying to be too trite, what does this question mean in terms of English?

> How maintainable is "small code"?

Once you get the hang of it it's as maintainable as any other code base

> How readable is it? (Well, you answered that question already.)

There is a learning curve, but the code is actually reasonably readable. It takes time to get used to many operations occurring in one line but there are benefits (eg you can see everything that the CTRL-Z function for undo does at a glance).

> How hackable is it?

Again, I'm not sure what you're asking here.

The editor is very bare bones so isn't a great example of production code. In a real system generally people are a bit more verbose.

Re: Build Your Own Text Editor

#86

Post by ash »

vbernat wrote: post #84

For better portability, terminfo should be used instead of using hard-coded terminal sequences. Otherwise, this is a really great intro. I liked the beginning with how to put your configure your terminal.

Why would you need to care about portability? Do people use terminals that are incompatible with xterm?

Re: Build Your Own Text Editor

#87

Post by bobochan »

jason_slack wrote: post #64
bobochan wrote: post #39

Earlier quoted context omitted.

I would not say that I use it regularly, but I have a somewhat working version of what I remember to be the Norton Editor in C++ / ncurses. It was 100% motivated by seeing antirez's artistic triumph, and my effort is sadly lacking in comparison. Still, I look at it every few weeks and add a new feature, and now I am mostly editing the code in the editor itself, which is gratifying. I actually need to get off my duff…

Norton Editor. Interesting that you mention this. I loved the Norton Editor. I have wanted to for years add a more Norton feel to the text editor that I write. I wonder if I can still get a copy to play around with and run in a virtual machine. Any idea?

I had a copy that I found on an old floppy about 15 years ago and I tried to see if I could use it in a Windows command window, but unfortunately it did not seem to work at all. Now that you mention a virtual machine though, I regret that I did not try and setup a FreeDOS VM.

Googling "norton editor manual pdf" lead me to a few old copies of the manual, so that is what I have used as a guide in my work, but most of it is just driven by how I remember it.

Re: Build Your Own Text Editor

#88

Post by mhd »

johnfn wrote: post #74
aethertron wrote: post #73

1000 lines of code is considered small. But check this out http://kparc.com/edit.k Under 50 lines for a text editor written in K by the language's author. Way beyond my present understanding, but the promise of very small, powerful code is incredibly attractive.

Just to be that guy. Yeah, it's cool that the language author built a text editor in under 50 lines, and there's a sort of geeky hacky appeal to trying to cram as much functionality as possible into as small a space as possible. But what does it actually mean in terms of programming? How maintainable is "small code"? How readable is it? (Well, you answered that question already.) How hackable is it? It's a curiosity,…

I wouldn't say the code is really that small in its language context, which is why comparing code by lines is inherently fallacious.

It's just that a large percentage of languages are quite similar in how they're structured. Since Pascal and at least until Java/C#, most mainstream languages ended up roughly doing "one thing" per line. Quite often one function call or simple mathematical operation. Then each function or block of a larger one does one larger thing. And so forth.

Code and/or languages that break that paradigm are often confusing to "switchers" and thus often abandoned or maligned way too early.

But most often, they're just scanned differently.

Assembly would be the opposite end. It basically takes "do one thing per line" to the extreme. But quite often, experienced asm programmers scan the program by blocks, as some patterns are quite common or you find some constant/string to attach your focus to, then continue from there into the details.

Forth programmers obviously read slightly differently, due to the high level of decomposition and the stack based nature (fewer parameters). Lisp looks a bit weirder at the first glance, but I wouldn't even say that it's read all that differently from the Algol family, if written imperatively enough.

Functional code, in almost any language, often has to be read differently, as a lot of things can happen in one line.

APL and some DSLs (regular expressions for example) are the opposite end of the spectrum. But line length would be the wrong axis to judge things, the amount of operations isn't necessarily that much smaller.

Data exchange (arrays vs. stacks vs. function parameters) is the bigger change, as is symbolic density (APL symbols vs J shorthand vs. function names vs. HiHowYouDoingIAmAnAbstractJavaBeansFactoryConsumerImplementationNiceToMeetYou)

Re: Build Your Own Text Editor

#89

Post by mhd »

WalterBright wrote: post #23

Here's one from the 1980s, which I still use and keep up to date: https://github.com/DigitalMars/me and translated to D: https://github.com/DigitalMars/med

Still use for occasional quick edits instead of vi/notepad or for proper, longer development tasks?

Re: Build Your Own Text Editor

#90

Post by quickben »

akkartik wrote: post #53
quickben wrote: post #48

Earlier quoted context omitted.

For example: https://github.com/martanne/vis/blob/master/buffer.c bool buffer_prepend0(Buffer buf, const char data) { return buffer_prepend(buf, data, strlen(data) + (buf->len == 0)); } Two function calls plus arithmetics plus step-return. Depending on the debugger interface(eclipse with gdb, vs, etc), one will have to press some form of Step 1 to 4 times to advance the line. Depending on the complier that was suppos…

Ok, I understand now. Thanks. This is a pretty common way to write C, though, it's not something specific to this particular codebase. You just had a non-standard use case where you were constantly running into low-level bugs. (In an embedded platform?) If you aren't in that domain anymore, it's worth revisiting the trade-off. In most domains, gdb's continue command is super useful.

Mhm. One was an actuall driver/firmware developmwnt. The other one a cross platform debugger.

I will in few hours, thanks.

Post reply on HN