1. 32

  2. 6

    Cool to see someone post this here :) Happy to answer any questions.

    I have a lot of thoughts about text editors in general I think there is a lot of room for new ideas in the space. I don’t really see many text editors trying weird/interesting things and I think that’s sad.

    This exploration definitely isn’t the answer, but there were some really fun things that came out of it for me. I definitely plan to keep build more experiments.

    1. 3

      As to exposing windows as http/whatsit services, see the acme editor of the Plan9 OS. As far as I recall, their philosophy of “everything is a file” extends to graphical windows (they’re also represented as files), as well as windows in the editor, I believe.

      edit: found it:

      (…) The text file /mnt/acme/index holds a list of all window names and numerical identifiers, somewhat analogous to the output of the ps command for processes. The most important, though, is /mnt/acme/new, a directory that makes new windows, similar to the clone directory in the Plan 9 network devices [Pres93]. The act of opening any file in new creates a new Acme window; thus the shell command

      grep -n var *.c > /mnt/acme/new/body

      places its output in the body of a fresh window. (…)

    2. 2

      I’ve never seen a text editor with a “floating panes” approach before, very cool! I don’t think I would personally enjoy working with panes like that, but I love to see exploration in this space.

      What I found most interesting was the draw panes concept, where any script can control the editor by writing to stdout.

      I was curious about the source code so I did some digging to find it: https://github.com/jimmyhmiller/PlayGround/tree/master/rust/editor

      1. 2

        Yeah, the floating panes are something I think should be supported. But definitely think a more structured layout mode would be beneficial. Definitely want to continue to explore different ways of displaying text in an editor, so glad you like the exploration.

        The source is definitely a mess, I had started considering changing my rendering setup but halfway through abandoned the code base. Plan on starting fresh soon with my next experiment.

        I think the draw panes is one of the most powerful patterns I found there. That’s what I want to take further. Allowing extension to be external, but also immediate is something I really want in an editor and something I think can unlock a ton of power.

        1. 2

          The source is definitely a mess

          Nothing wrong with messy code when you’re experimenting :) I do hope you continue to share your future experiments!

        2. 1

          Aren’t the “floating panes” basically like Multi Document Interface in (old) Windows apps? Over time that approach became deprecated, though you can still find it here and there. Back in the day, there was a MicroEmacs for Windows (3.x) that used MDI, and it was kind of neat.

          1. 2

            I guess it is! I haven’t run into many uses of MDI, though it makes sense if its deprecated and out of touch with “modern” UI design anyway (for better or worse). Thanks for putting a name to the design!

        3. 2

          Why haven’t we explored new avenues for user interfaces in text editors?

          Others have, but the mainstream has converged on user interfaces that fit well on the main platforms. If you do your own, it will not integrate with the other programs in your user’s desktop, it will be forgotten, and some years later someone will think up something similar and write a blog post asking “Why haven’t we explored new avenues for user interfaces in text editors?”.

          I happen to be building my own, and the proof-of-concept I built before outputs HTML+JS to stdout which I then load in the web browser. There I do have a souped-up version of the token pane, also on the left: in my case it’s a tree, at the top is each opened file, and under each are the tokens in that file, so I can see quickly where to find something.

          If you keep refining it, you’ll realize that you probably don’t want to display there all tokens, but select certain types. You might end up with something similar to Eclipse’s Package Explorer for a mainstream example, or going further back in time, SmallTalk’s Browser [1] where you will find many other interesting ideas, such as editing one function at a time, which simplifies some things like replacing all appearances of a token but only in that function, and to take another branch in the code editors history, you can get that effect in Emacs with its concept of regions, where you can also narrow-to-region to work on a part of a file (might be a function, a block, whatever) as if it was the whole file.

          The graphics pane made me think of Sun Microsystem’s NeWS (application front-ends written in Postscript). Actually, the much older Tektronix storage-tube displays [3][4][5] worked in that way: they had a serial port that received the drawing instructions from a computer. I would guess that some of its users did pipe a program’s stdout to the serial port. That protocol was included in XTerm [6].

          As you dig deeper and deeper into the past, you’ll find that those and other ideas have been implemented to some degree before, but that doesn’t mean that you can’t do a better job, maybe make them useful and usable enough for them to reach the mainstream.

          You mention how Jamie Brandon found that storing the edited source code in a simple string worked surprisingly well, without any fancy data structures, and you did the same with Vec. Today’s computers are immensely more powerful than those on which the alternative user interface ideas were tried, and I think it’s time to explore them again. Similar to how neural networks exploded in popularity when the hardware got powerful enough and have now eclipsed all other approaches to AI. There is a correction to that trend under way, but neural networks are here to stay.

          You are right, there are many creative ways in which source code editors can be made more interesting.

          1. 2

            In Plan 9, Acme exposed the internals of the editor as a filesystem. It’s funny to think that nowadays there are so many tools for HTTP that’s easier to just expose internals as a REST-ish API instead. The article doesn’t mention Acme, but it seems like a lot of the ideas (panes that can consume STDOUT from programs written in any language) are very Acme-like.

            1. 1

              In my experience, sdl2 is insufficient for text-editing needs. For example, key presses with modifiers on non-US keyboard layouts will sometimes result in surprising keydown/textinput events. I’m also not very fond of SDL’s non-thread safe model, as it prevents doing things like handling inputs in a thread and managing windows/graphics in another.

              1. 1

                Nice blogpost! The afterburner rendering method is quite enticing. I like the idea of data being the interface to interact with the text editor, not a full language runtime.

                I had a question about the method to expose pane content to external programs. You exposed the editor as an HTTP server. I would have gone with passing the pane’s content to the external program via stdin, which I find a bit simpler. Did you consider that option? If so, any reason you ended up choosing the http server option?

                1. 1

                  I do think having that as an option would make perfect sense. The reason I went with http is that 1) it was easy 2) it allowed me to do modifications completely outside the editor. I don’t want to have anything be a walled garden at all, so I can be in my normal terminal and interact with the editor. Sometime I just want to pipe things into my editor and have a pane appear, with an http interface I could easily.