hellerve

Comments like these are the reason why I need an editor.

I’m not sure what you’re trying to tell me here, so maybe this comment is going in the wrong direction entirely:

I think we are on the same side of the fence. Reasoning about your designs—and communicating your reasoning openly, not fearing scrutiny but rather embracing it—are important in any project.

But you compare an introductory article in which I try to explain a language to prospective users or other interested parties with the notes, musings, and writings of someone working on a compiler, aimed at an entirely different set of interested parties. Sure, in the end we’re all programmers and should all be interested in both, but trying to cover both at the same time will only result in mental overload.

I’m also in no position to talk about these things. I provide the occasional compiler bug fix, but I’m not the principal driving force behind the compiler. I build tools and libraries with Carp, and see whether it breaks in interesting ways, or try to come up with use cases that don’t yet exist. In other words, I’m just a user.

None at the moment, to my knowledge. High on the list of priorities, but it’s not far enough along, I fear.

While I do agree with the fact that one of the best features of Rust is the communication, I’d tend to find the comparison of the two a little unfair. Carp is very young and in an entirely different position than Rust.

That being said, this is why I want to start to write more blog posts about Carp. I had to wade through the deep waters alone, with occasional help in the Gitter channel. Now I want to share that experience. As such, the blog post goes in a different direction than, say, Matsakis’.

In a perfect world someone who cares about communication and is good at it will be in the core team of the language at one point. In the meantime, we’ll have to make-do with me.

That’s probably true. I honestly didn’t expect this little blog post to gain that much attention, honestly.

That’s quite true, but from the users perspective, it mostly doesn’t matter, at least in my mind. For people interested in the internals—which is an increasing amount of the user base—, and the people working on the compiler, it most definitely is a concern.

I fixed it now! You can script it through Lua. (through `set_left(<char>)` etc.)

It shouldn’t be too hard: [kilo](https://github.com/antirez/kilo), the editor on which this is partially based, is modeless. All of the modes are thus addons that I’ve built. You’d have to tweak a bit of the code to make it usable as a modeless editor, but it could definitely work!

Thanks for telling me. Github issue is filed: https://github.com/hellerve/e/issues/10

Will work on it when I find time.

ANSI can do it in one escape sequence: "CSI2K".

https://en.wikipedia.org/wiki/ANSI_escape_code

I actually didn’t know wasd weren’t always in the same place and hjkl were. Do you know any of these layouts at the top of your head? It might come in handy next time when I think about typing UX.

I neither ignore it or assume I can do it better. I just did it because it was fun and satisfying.

I don’t believe I could do better than curses/ncurses. What I do believe, however, is that replicating the work isn’t always bloat. If you’re only going to use a small subset of the library anyway, replicating a bit of it might actually be less bloaty than including the whole thing. That said, when in doubt using pre-made solutions surely is better _if_ you’re working in a professional/production-grade environment. I on the other hand am just playing around and seeing how far I can take this.

You can shoot pretty much any keybindings down with that argument, though. hjkl makes about as much sense on Dvorak as wasd.

I was actually scolded—by a friend—for not using curses, but I honestly prefer working with escape sequences.

Is your editor available on Github?

Heh, that actually sounds like a fun thing to implement. But no, as of yet it can’t.

And when I think about having to adhere to my "as few dependencies as possible" standards, which basically means I’d have to implement a bunch of image file parsing, I think I’d rather not. I just saw imgcat uses CImg for that, which seems like a smart move.

Yeah, the comment was a little tongue-in-cheek. I didn’t think just writing yet another Vim clone would be very interesting, whereas trying to keep it minimal yet usable would be an interesting challenge.