1. 4

I tried VSCode because I’m looking for a nice, modern, user-friendly, and fast source code editor, that also won’t give me malware. Atom is my current favorite, but it’s resource-heavy, and I have to sandbox it manually.

What’s your favorite source code editor that optimizes not only developer UX, but also practices strong security principles and respect’s user’s privacy? How do you do your development to compensate for the sad security of source code editors?

Examples of “strong security principles” include:

  • Pinned certificate that’s used for auto-updates
  • Verification of hashes/SSL certs/signatures for packages/plugins/extensions
  • (probably a long shot): built-in sandboxing, or easy-to-sandbox with firejail or something similar

  2. 10

    Just kakoune.

    • No interwebz in text editor (because why? it’s stupid)

    • Fast as hell (it contains own regexp engine instead of std::regex from Boost)

    • Not resource-heavy (still able to render in what-your-screen-needs FPS when loaded with 4GB XML file)

    • Easy to sandbox (can be built as static binary, has a client-server model so you can control it from anywhere)

    • Respects user privacy (it doesn’t disclose any data for 3rd parties, developer is not a twat, but very friendly and helpful person)

    • Totally not malware (has a user-friendly Clippy to help you all the time)

    1. 4

      I have slowly migrated from vim to kakoune. The design document spells out a lot of what I like about it, which I will repeat a bit here.

      In addition to what is great about kakoune is what I have grown to dislike about vim. Neovim added a terminal to it, which I thought was a great fit for it and I had hoped vim would stick to being “just an editor” – but it didn’t – it chased neovim despite mocking such things as a terminal in an editor right in its help file. /rant

      Anyway, kakoune isn’t perfect, and it isn’t even 1.0. But the author of it has very firm goals for what he wants it to do – and as importantly what he doesn’t want it to do.

      So things I love (again, a lot of this is also in the design document):

      • Multiple cursors: a lot of editors have this feature, but it is the only operating mode of kakoune. When you have a single char under the cursor, that is a single 1 char selection.
      • Limitations: it doesn’t manage windows, tmux or i3 or (other thing) does; it doesn’t try to be multithreaded; it isn’t a file manager; it isn’t a terminal; it doesn’t have its own scripting language; it doesn’t support binary plugins; it avoids being “clever” based on context confusing the user. It makes no attempt to be all things to all people, it is a fantastic editor… this ties into composability.
      • Composability: it makes no effort to implement a sort or have its own scripting language, it outsources this stuff to the existing sort command and gives tools for interacting with system tools. This is a bit of a mixed bag at this point – you get a bit of escape hell in shell scripts.
      • Client/Server: a core part of the architecture.
      • Powerful primitives: built right in is stuff for selection rotation, case manipulation, alignment, and tons more.
      • Info boxes: last but not least, the info box feature is fantastic, when you are using a command it lets you know the parameters, when you hit like “g” for goto, it shows all the stuff that can follow “g” (like “f” for file). This is easy to add to your own custom commands as well and makes learning the editor interactively amazing.

      It isn’t all great (yet) from my perspective:

      • Documentation: it exists, there is a :doc feature. But a lot of it is thin and a bit hard to find. I suspect some of this is because people lean on the info boxes feature a lot and it doesn’t get as much use as it would in Emacs or Vim. But I consider it a great place for improvement. Would love a :doc changelog for example.
      • Breaking changes: it isn’t 1.0 yet, and the author is still trying to improve some core features, which means breaking changes will happen, and they will break your workflow for a bit. Thus far most of these breaking changes only take minutes to fix.
      • Binaries: it isn’t 1.0 yet, it moves fast, so the best way to stay up to date is absolutely to build it yourself. The good news is this only takes a few minutes at most, and its library/etc requirements are relatively low.
      1. 1

        Limitations: it doesn’t manage windows, tmux or i3 or (other thing) does; it doesn’t try to be multithreaded; it isn’t a file manager; it isn’t a terminal; it doesn’t have its own scripting language; it doesn’t support binary plugins; it avoids being “clever” based on context confusing the user. It makes no attempt to be all things to all people, it is a fantastic editor… this ties into composability.

        I like this, except that I want my text editor to give me some way to manage buffers. Managing splits in Vim is infinitely nicer than managing splits in Tmux.

        If I remember right, this is the main reason I dropped Kakoune. So if this has improved (as in, there’s some implementation somehow that works closer to Vim), then I can probably give it a serious try again.

        1. 1

          It has lots of ways to manage buffers, it just offloads the windowing/pane stuff to others, you can use :tmux-new-horizontal or :tmux-new-vertical, and :tmux-repl-vertical, and there is similar stuff for x11 windows, i3 windows (via a small plugin) etc.

          Bind to the same keys you would bind to in Vim and barely tell the difference (except now you can have a properly tmux pane in the bottom right and the other three be kakoune). I haven’t missed anything from vim in terms of window management.

          1. 1

            I think the problem was that I wanted the tmux splits and the editor splits separated, but still in the same window. Say in Vim I have 3 horizontal splits and then in Tmux there’s two horizontal splits, one with Vim and its splits and the other with a terminal.

            Tmux is really not good at managing the splits, or at least not when I got into it, so if it’s all in tmux then it’s horrible (in my experience).

            So in the case of tmux, it’s more a limitation of the medium for me.

            1. 1

              I would have to know your specific complaints about tmux’s pane/window handling to be able to respond. But on the upside you aren’t limited to tmux!

              I personally once I got over the learning curve really like tmux handling, specifically stuff like choose-tree which is amazing if you have many tmux windows and panes, window and pane rotation, etc. It has a learning curve like Vim or Kakoune – but similar to them, the curve has non-trivial payoffs.

              1. 2

                All right. I’ll have to take a more serious look at it soon then. Thanks! :)

                1. 2

                  V.v.V! Awesome.

                  When I first started using tmux I really didn’t dive in and learn it properly and it made me hate it a bit. But then when I started to dig deeper and found like choose-tree, and then that choose-tree had a search mode inside it, and I could bind a key to put me right in search mode… then I started making bindings to like fire up ranger in a way that made sense, yada… I was hooked.

      2. 1

        Along these lines, I also found micro.

      3. 7

        My version of sam.

        • Auto-updating is by compiling the source yourself. :)
        • No extensions/packages/plugins means no verficiation needed
        1. 6

          neovim. Updated through the OS’s package manager, plugins are downloaded with git (over TLS).

          1. 4

            I’ve been using Acme for the past few months and it works fine. It’s pretty bare, but it works. No completion, no syntax highlighting, no nothing. Still enjoy it. Also there’s like no updates, especially not automated. If you need modern features, I recommend Emacs. Spacemacs is pretty neat.

            1. 2

              The nice thing about Acme is that it’s command set is so minimal and quasi-irreductible (except for the window management stuff, that could be handled by another program).

              And “modernity” is a very relative term, so all I’ll say is that it encourages you to use unix as your ide and gives you a simple interface to do so with. So as long as your unix-like system is secure and up to date, you’ll always be using top of the line tools.

              1. 1

                Well. I’m really a big fan of the plumber. I’m definitely looking to use that more in my general workflow. I’m already a big fan of accumulating scripts in $HOME/bin, and that idiom has a nice synergy with Acme too. I also don’t miss syntax highlighting as much as I thought I would. Or completion.

              2. 1

                What mouse are you using with it? A lot of the Acme loyalists get good old three button mice.

                1. 1

                  I use the contour mouse.

                  1. 1

                    I have a mouse that has a mouse wheel, which doubles as a middle-clicky-thing. My office one is a bit sensitive for my taste, and also does a weird web-page-navigation thingie when you press the wheel to the left or right, which I profoundly hate (and renders middle-clicking a bit harder).

                    My home mouse is much better, but it’s also a run-of-the-mill wheely mouse. Less sensitive to scroll action, no left-or-right action. Works perfectly fine for my purposes. I’ve learned over time that Acme is also decently easy to manoeuvre with a trackpad, since you can simulate middle-clicks with Ctrl (even in chording, at least with the Left->middle chord (which is useful, because, like, copy-paste)). Doesn’t work with middle->left though.

                2. 2

                  I’ve been using joe for over 25 years. Yes, it’s a plain text editor. It has features to help with coding. It can load files of any size. It’s fast. It’s not as small as I like [1], but compared to what people use today, it’s tiny. And more importantly, it’s NOT Internet enabled.

                  [1] The current version I use has an executable size of 1.5M. Large compared to my favorite editor under MS-DOS, which was 40K.

                  1. 1

                    Thumbs up for JOE, even when I don’t understand it (config format is pretty damn complex), I really, really espect people using it daily, though I haven’t seen anyone using it IRL.

                    1. 1

                      Just out of curiosity, what was your favorite editor under DOS?

                      1. 3

                        PE version 1.0 written in 1982 by Jim Wyllie (while at IBM). I only ever found one bug (lines have to end in CRLF or it does strange things) and one limitation—lines are limited to 253 characters (255 with CRLF). Other than that, no limitations. Ran under MS-DOS 1.0 (it will probably still run under Windows today) and could deal with files that even exceeded memory (tested once—it was … sluggish). 45K (oops, mis-remembered the size) in size, and programmable (to a limited degree).

                        Later versions were okay.

                    2. 2

                      Assuming they work, compile a code editor with Softbound+CETS, SafeCode, or something similar. Run it in an isolated partition/VM. Use append-only storage for things that change. A software solution + CD-R’s works fine. Helps even more to use an air gapped machine with a data diode where you straight-up type the source into it with your executables coming out a one-way link. A lot of people find that too painful to be worth stopping serious attackers, though. ;)