Building A Text Editor

Is anybody interested in building text editors? I've been working on one for the past few months as an assignment (we have to build some kind of software that we'd use as a small group). It's finally coming to the point where it's usable so I thought I'd share it. https://github.com/DandyHQ/mace Has anybody else tried to make one before? Is anybody interested in how they're made. Or how fuarrrking horrible text rendering is?

I watched the Light Table team try to make one, find out how hard it is to make it any good, and then quietly stop after burning through their crowd funding money. I would say the world has enough text editors, but I would really like an open source Sublime Text clone and I feel like I'll never get it. Feels bad man.

>>1489 Yeah, making a mediocre text editor isn't too difficult, but making one that's good enough to become people's daily driver is shockingly difficult. This is part of the reason why I like vim, it's not going to stop being viable anytime soon because it's widespread enough that there will always be people making plugins to keep it up-to-date. And regarding a FOSS Sublime clone, you can look at http://limetext.org/ but it's unfortunately (of course) not ready for production.

>>1493 Yeah, I've discovered how hard it is. Even just making it render text nicely and efficiently is pretty hard. What do you really want from a text editor that emacs or vim don't satisfy?

>What do you really want from a text editor that emacs or vim don't satisfy? Something that doesn't feel like a punishment? If people ever manage to reimplement most of the functionality of emacs and popular modes with Atom, I feel confident that new interest in emacs will dry up considerably.

>>1496 People have been trying that with vim for years, and many, many editors include a kind of vim-mode. Yet none of them (literally zero afaik) have feature-parity with vim, and I haven't even found one that implements all the vim commands that I use on a regular basis (which is a fair subset of the total). But I get what you mean about not feeling like a punishment. If Sublime had existed before I started learning vim I would have probably gone with that instead. But now that I've put in the effort and sunk the cost of learning, I'll keep using it because it's more comfortable and at least as featureful as others.

>>1493 >>1489 reasons for wanting a FOSS sublime clone other than the license fee? (since you can get around that)

>>1489 >>1493 >>1500 isn't Atom basically "FOSS sublime"? >>1496 what kind of functionality are you talking about here? Isn't the main difference that emacs/vim are used a 100% through the keyboard, which enables a much efficient and faster manipulation of the editor? Basically the very nature of these text editors are what makes people interested in them, and its self-selected demographic are what gives them so much power, you can't migrate this into a GUI text-editor nor dumb it down to 'functionality'.

>>1501 >isn't Atom basically "FOSS sublime"? if it wasn't an Electron app it would be. But since it's basically a browser app running on the desktop it's basically unusable slow. The fonts look great, and skinning your editor with CSS seems cool too, but it's just junk. >>1500 >reasons for wanting a FOSS sublime clone other than the license fee? (since you can get around that) Do you know where you are?

Obligatory xkcd comic.

>>1501 http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._Keyboard/index.html It is quite possible that for most things a mouse is a better option.

>>1496 >Something that doesn't feel like a punishment? Vi doesn't feel like a punishment. Neither does ed, actually. ed is actually neat because it's scriptable. If you want something that's closer to punishment, try this out: https://github.com/blakemcbride/TECOC I've used it before, despite finding it difficult.

>>1488 Made https://github.com/IGI-111/Smith both as a way to improve my Rust and contribute a bit to Termion (like adding mouse support and stuff). Ultimately it's just another featureless terminal text editor, but the guys behind Xi have bigger, more interesting plans that i'm on the lookout for. Unfortunately making good tools is much harder than just toys.

>>1536 Xi is quite interesting. Do you know what their goal is?

>>1558 Basically making a state of the art text editor engine that is decoupled from ui/extensions and make the core and extensions threads communicate through a P2P protocol. Currently it's just a core that does relatively good rendering and various UIs that kinda-sorta work. I'm convinced that the idea is sound, and probably the future of text editors but since it's more of a hobby project for some google guys, it's not formalized enough to actually be something at the moment.

>>1567 So the back end is decoupled from the UI yet still handles the rendering? Does it send bitmaps of how the text should look? And I don't think that is how peer to peer should be used. Duplex or multiplexed might be a better term.

>>1568 >Does it send bitmaps of how the text should look? It sends the changed lines on screen and the gui is supposed to hold a cache of those. >I don't think that is how peer to peer Addmitedly, it's more of a bus.

The first Lainzine has an article that recommends this book, The Craft of Text Editing: https://www.finseth.com/craft/ I recommend you either revisit the first edition to read the article or give the website itself a look. To save some time, this is based on a bachelor's thesis that's been expanded into a full book; it covers history and many fundamentals of text editors and I believe anyone using this thread will find reading it time spent well.

>>1517 I am a fan of obscure/arcane tools, I'll give this a try. thanks!

Check this http://viewsourcecode.org/snaptoken/kilo/

>>1682 Enjoyee! Become a true LISPer.

>>1503 >if it wasn't an Electron app it would be. But since it's basically a browser app running on the desktop it's basically unusable slow. The fonts look great, and skinning your editor with CSS seems cool too, but it's just junk. oh, I had no idea, I had just found out abot atom (haven't even used it). That is, very sad :'( got a bit hyped about it but now this. I guess the only TRUE programmable text editor is OBVIOUSLY emacs

>>1509 >for most things a mouse is a better option yoyoyo as an osu player and someone who worries about efficiency im opinionated about this. Basically keyboard will always be faster in every way if you do not strictly need a mouse, the key is to implement navigation efficiently. For apps where dealing with precise vectoring (like anything graphic design) the mouse is an absolute requirement. Then for everything else you have to wonder which one is a better idea, of course for most things the ease of understanding a GUI over learning a gazillion hotkeys is way way better than doing things a bit faster. But for something as basic as text-edition, especially someone who uses computer-text a lot, the learning curve is well beyond worth it.

>>1598 "The idea that I settled on for my thesis was a description of the technology that underlies all text editors, but with a special emphasis on Emacs-type editors. The thesis was written and published as a technical memo (Finseth 1980)." this looks like a boring, basic, monograph, sorry.

>>1693 but the original Emacs has nothing to do with Lisp

>>1696 If you'd only read it instead of just dismissing it on account of an immediate impression based on nothing but a single phrase...

>>1489 Can you give more details? Which problems and difficulties did they face? How did other editors deal with them?

>>1695 Did you read the article? It clams that for anything beyond moving a few glyphs the mouse is more efficient. It reasons that you think the keyboard is more efficient because when you use it you are thinking about how to use it, not thinking about how slow the mouse is. So although the keyboard seems faster it is in fact not. Other than trying to click on a specific glyph or select to a small area I am inclined to agree. In those situations the keyboard's discrete nature gives it an advantage.

>>1716 Not the same guy but. I don't really know about efficiency, but yes about immediateness. Even when I used windows, I would much rather use C-v C-c to copy/paste rather than drag the mouse all the way to the menu and select "copy", and a great deal of it was because I barely had to move my hands. For text manipulation the mouse is obviously way more efficient, since the bulk of your work is going on on the keyboard anyway. Likewise, operations like 'd2w' or 'c%' or 'f.' in vi are inmensely faster than doing it with the mouse however that might be. If your WM is configured to open a terminal with CM-<Ret> that's more efficient than most other ways. implementations. I've always found the Emacs-style C-a, C-e, C-k infinitely convenient, since they are immediate editing operations not unlike pressing backspace to delete characters. If, on the other hand, you're editing images, audio, or video, 3D modelling, or similar activities, obviously the mouse is better. The point is that it's stupid to say that the keyboard is the best solution for everything, or that it's the mouse. For drawing, for example, you better have a drawing pad.

>>1717 >For text manipulation the mouse is obviously way more efficient s/the mouse/the keyboard/ Sorry.

>>1718 obviously as in subjectively, objectively the mouse is always faster

>>1724 Not always. For actions around the cursor like >>1717 mentions the keyboard is probably faster. But for jumping around a file or a large paragraph the mouse is probably faster. We should do a study. And by we I mean not me.

>>1729 Been done a million times by plan9 team: https://9p.io/wiki/plan9/mouse_vs._keyboard/index.html Mouse is faster. What slows you down is switch between mouse use and keyboard

>>1730 So what we need is a keyboard with a built in trackball that the thumbs rest on? I'm sure one must exist... otherwise it'd make a cool project.

>>1730 The research the plan9 team bases its affirmations on was made by Apple. Apple probably used "random", "normal" users, not developers. The main reason why the mouse is actually faster according to the cited article is that when doing something using a keyboard shortcut, the user has to spend a significant amount of time remembering the corresponding keyboard shortcut. I really doubt these results would be the same if the test subjects where developers using a tool they have muscle memory for.

>>1735 I saw several keyboards from 90s with built-in trackball, albeit in upper right corner. Alternatively, you can make a "chorded keyboard" mouse with with 8 buttons (5 for each finger plus 3 modifiers) and 2-3 switches. Maybe several scrolling wheels, for example free-floating and stepped. I hope to create something like that one day.

>>1730 >>1742 I too believe that these "studies" are biased. The plan9 page does have good arguments, it's probably faster to just click wherever you want to go if you can spot it. The scrollbar thing is moot since, for example in more you can just keep pressing space or C-f and the bottom line tells you the % of the page scrolled so far. The same goes for Vim if you configure it. Probably the same goes for Emacs. Ultimately, you can't compose what you do with the mouse the way you do in Vim. You can't have "mouse macros". And as has been pointed out, you don't really "think" of what the keybindings do, it's all muscle memory. Often I find myself pressing C-a automatically only to remember the current application doesn't support it (firefox for example). In the end, when you are used to a workflow, that's the most efficient you can get. You learn to adapt to the tool, and with the mouse, you learn to be sloppy because the mouse is inmensely limited compared to what the keyboard can do. Again, motions like '%', 'db', cf.', 'j0~', 'd%', 'c2w', and things like the dot (.) command would be either sloppy or just impossible with the mouse. The point here is that you learn to use a language to edit your files, so you do it in the most efficient way available. People fail to realize this when they compare the mouse with the keyboard, perhaps because the mouse limits them to think that the only relevant motions are to highlight a text and jump to a particular location, because that's really all the mouse can do.

>>1753 the first sentence may seem like I am just handwaving the results of those people, I am not, even if I am biased for the keyboard (this is inevitable), what I am saying is that the studies are biased too, and it kind of shows by the format.

On the topic of mice versus keyboards, this was a nice read: https://danluu.com/keyboard-v-mouse/

>>1773 That is a good read. >>1754 You are probably right. It will depend a lot on how used to the tools you are and what you are working with.

customize the soykaf out of emacs until you can call it your own. there's no point starting from scratch from such software.

have you heard of <insert any other text editor>

>>1488 Yours looks really cool actually. The features sound very nice

>>2528 >using <that editor> Your tastes are Wrong. <another editor> is clearly better because <personal preferences>. <Your editor> is everything that's wrong with the world and should be derezzed, I bet you use <your programming language>.

>>2786 Thanks. In the time I've been working on it I have learnt that we were wrong about everything we wanted to change. Acme is pretty much perfect. It's been interesting though. Mace is usable now. Not sure I'd recommend it but it's fun to use.

I tried to make one as a project for a course in university. I wrote it in Java. It worked, but it was slow as hell; it took a second to get the syntax highlighting right. Speaking of syntax highlighting, I only made it work with C and languages that have syntax similar to C because I was lazy and because I only had two weeks to make this project. I think the project is still somewhere on my messy external HDD, but it's too embarrassing to show.

I wanted to add to what I posted in >>2814 The most important thing I learnt from doing this project is that making a text editor is quite difficult. One of the most challenging things I encountered was implementing syntax highlighting. But those two weeks were fun and full of sleepless nights, especially since I was taking three other courses that required work (theory of algorithms, component-oriented programming and calculus 2; calculus 2 being the most time-consuming). That was a fun semester.

>>1501 >Isn't the main difference that emacs/vim are used a 100% through the keyboard, which enables a much efficient and faster manipulation of the editor? I've found this to be more of a baseless elitist talking point that stems from a time where the mouse didn't exist yet so all the old hackers were keyboard wizards. The reality is that some things (maybe even most) are faster with the keyboard, and some are definitely faster with the mouse, such as scrolling through a large file and arbitrarily switching between numerous tabs.

>>2892 >The reality is that some things (maybe even most) are faster with the keyboard, and some are definitely faster with the mouse, such as scrolling through a large file and arbitrarily switching between numerous tabs. It usually boils down to an argument of long term vs short term utility. The analogy I like to make is stairs vs elevator. Using a mouse is like using an elevator. It is quick and easy to get started with but you reach maximum performance almost instantly. Sprinting up the stairs takes more effort initially, but you will get faster everyday and the potential maximum performance is much higher. Most people use computers casually and don't care about remembering a bunch of keyboard shortcuts. But if your job is editing code 8 hours a day then taking the time to learn Vim or Emacs will pay off in the long run.

>>2899 >the potential maximum performance is much higher. I generally agree that keyboard is better than mouse, but that's an awful analogy. What sort of slow elevators are there where you live, such that you could realistically sprint up more than one or two flights of stairs more quickly? >But if your job is editing code 8 hours a day then taking the time to learn Vim or Emacs will pay off in the long run. Programming jobs are very rarely about "editing code 8 hours a day" and haven't been for a long time.

>>2899 8 hours a day full of writing code, I couldnt imagine it seems bad for the end result. you would literally tire out your men wich will result in less effective done in the long run, I would think atleast.

>>2901 >What sort of slow elevators are there where you live, such that you could realistically sprint up more than one or two flights of stairs more quickly? ....we have 2 story buildings. I guess there's some implied cultural context in that analogy. >Programming jobs are very rarely about "editing code 8 hours a day" and haven't been for a long time. What do you mean? Browsing hacker news is not work. Besides a few hours of meetings per week, you should be reading or writing code all day.

>>1488 I've been working on reimplementing ed and adding some features to make a usable line editor. I also have some ideas for a better improved vi, but that won't be done for a long time.

>>3145 The main benefit of Vim and Emacs is that they let you get edits or navigation done before you forget the context that required the edit or navigation. Spending a minute editing code is the mental equivalent of walking through a doorway. You have to clear wetware cache. Paging kicks in. You forget things that need to be remembered soon. Jump to definition is an excellent tool in any IDE or editor, but it's not because it helps people code faster.

>>1700 >>1489 >>1493 I want to know too. Which parts, specifically, were hard? When I have difficulties, I look at free software source code for inspiration. What stopped them from doing that? >find out how hard it is to make it any good That is pretty vague. Are you talking about usability? Editing features? The editor internals themselves? Data structures? What exactly did they have trouble with? >making a mediocre text editor isn't too difficult, but making one that's good enough to become people's daily driver is shockingly difficult Which features do mediocre text editors lack? Which features must they gain to stop being regarded as mediocre?

>>2814 >Speaking of syntax highlighting, I only made it work with C >I only made it work with one of the trickiest languages to parse I'm impressed.

>>3546 C89 is pretty easy to parse. The dot syntax for inline struct creation is a little harder but it wasn't added until C99. You're probably thinking of C++, which is so difficult to parse that the centuries-old compiler tools lex and yacc can't actually parse it anymore.

Honestly, if I could just get a Gnu Nano that had line numbers and didn't have that weird indentation problem that Nano has then I would be set for life.

Just use emacs.

>>3606 Can you give us an overview of how Emacs works internally? I just want to understand how things work. I usually accomplish this by writing my own versions of stuff.

I've thought about writing my own version of vi, mostly for personal pleasure. basically something that I could get to "good enough for daily use" quick enough (I use vim in vi-compat mode with no plugins, so this wouldn't take *that* long) and then add the features I think are nice as I please. basically I'd like roughly my current vim setup but with tab completion, full undo tree, separate command mode for fast buffer/window management, few other odds and ends. the one "big" thing would be the ability to handle arbitrarily large files (I often have to work with log files tens of gigabytes in size for work, which neither vim nor less handle well at all. often I'l just tail a million lines and open that; if I have to go back further, I use ed) the big thing stopping me at this point is I still haven't decided whether to write it in haskell or C yet. the former would make it much more pleasant and maintainable, but I worry about perf/memory usage given it's, yknow, a text editor. and I work across several dozen servers and ghc is one *hell* of a dependency

>>3948 Use the source Luke. Besides, Lain has been getting less technical lately... I highly doubt he's going to lay out the architecture of e-macs for you. Instead, I'm expecting some kind of invective implying that you should in some way "suck it up and be a real man", but maybe he will pull through and actually layout EMacs for you. Here's what you need to know about Emacs: 1) It was written by Autists several decades ago. 2) It's not as well maintained as you think, or as well as the inevitable contrarian replying to me will say it is. 3) If you bitch about it being hard to understand, someone will come out of the wood work to condescend you. 4) Basically you can modify everything to do anything with Lisp, more or less. Most Emacs grognards have basically rewritten the thing in personal macros, so get started with that. Hope that helps? Vim's source code is far, far, far worse.

>>3955 It's better to have a high-level overview of how the program works before jumping into a source code repository. I could theoretically start from the main function and work my way into it but it would take so much time. Last time I tried reading GNU source code it wasn't such a pleasant experience. It would be better if someone who is already familiar with it provided an explanation. I write a project overview readme for my own projects but it appears nobody else does.

>>3958 One of the goals of remacs, the Rust rewrite of emacs' source code, is to get a better understanding of the innards of emacs, so even if nothing comes directly out of the rewrite there will be a lot more people ready to contribute to emacs. You could ask some people in the project's gitter channel.

>>3958 Code of that vintage tends not to be as organized as you'd like anyway. Honestly, and this comes from someone who understand's other people's squirrel nests for a living, what I recommend is that you just read the entire repo top down. Seriously. I wont take as long as you think it will. >One of the goals of remacs, the Rust rewrite of emacs' source code, is to get a better understanding of the innards of emacs, so even if nothing comes directly out of the rewrite there will be a lot more people ready to contribute to emacs. You could ask some people in the project's gitter channel. I feel like it'd be a better project just to make something new from scratch. Just look at how NeoVim is going these days.

>>3971 >Just look at how NeoVim is going these days. Neovim started by forking vim, it's not a reimplementation from scratch. I also wanted to mention nvi, which is BSD's reimplementation of vi in a much cleaner way.