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
Just kakoune.
• No interwebz in text editor (because why? it’s stupid)
• Fast as hell (it contains own regexp engine instead of
std::regexfrom 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)
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):
It isn’t all great (yet) from my perspective:
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.
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.
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.
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.
All right. I’ll have to take a more serious look at it soon then. Thanks! :)
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.
Along these lines, I also found micro.
My version of sam.
neovim. Updated through the OS’s package manager, plugins are downloaded with git (over TLS).
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.
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.
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.
What mouse are you using with it? A lot of the Acme loyalists get good old three button mice.
I use the contour mouse.
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.
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.
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.
Just out of curiosity, what was your favorite editor under DOS?
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.
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. ;)