I was an avid user of Textmate then jumped to Sublime ages ago and have never looked back. I have all the key commands down with muscle memory and have never found another editor with better rendering quality and latency.

my 4k setup: https://i.imgur.com/yRShjn9.png

While doing a lot of Clojure at Farmlogs I genuinely tried to become an Emacs user, but I have always struggled with the sheer number of key commands. That being said, I love ctrl-e, ctrl-a etc... for day to day on macOS and admire that from Emacs.

Vim is my goto for every cli based editing interaction.

One thing I have never loved about vim/emacs is the fact that there are so many different ways to deal with plugins and configuration that I have never known 'the right way' to do things.

Full blown IDEs have always felt brutal and cumbersome, plus I tend to obsess over the details and prefer applications who use native rendering tools versus things like Java/GTK/Qt/etc...

Sublime has hardly any chrome, so I like that element as well. It has always felt the fastest, too. It will open massive files and scroll them no problem where other editors will struggle.

[off topic] I apologise in advance for the unsolicited review - I couldn't help it.

First, in service.api.api:43-49 you do:

    filename = (file.filename if file else None) or request.form.get("filename")
    [...]
    try:
        stored_metadata = storage.store(filename, file)

My understanding is you're receiving some file then storing it somewhere with the name provided by the client. That to me looks like a potential security issue. It looks like this function (what is this, Flask?) is both a view and a validator, yet it looks like the file name is not sanitised in any way. I would not accept all characters here. There are two problems: first is the name you use to save the file on disk. Think about e.g. slashes, dots, spaces and the non-printable characters. The other one is about access: if e.g. the file name contains "#" or other special URL character, the file might not be accessible at all.

Second, in service.api.api:54-55 you have:

    except storage.FileTooBigException as e:
        raise FileTooBig(str(e))

This masks the original exception. In order to avoid that, you have to tell the engine the new exception you're raising is the direct cause of some other exception:

    except storage.FileTooBigException as e:
        raise FileTooBig(str(e)) from e

It might not be that important with a client error like this, though. At worst it helps with debugging. [/off topic]

Hah, thanks for the review! Great feedback. This was a coding challenge from a few years ago when I applied for a gig at Zapier. It was time capped so I didn't spend any extra time making it perfect.

Note that in the screenshot there are yellow boxes around the `raise` keyword - this is a complaint from the linter to do exactly as you suggest.

    raise FileTooBig(str(e)) from e

I did not know this was possible. Thanks!

I, too, learned something new today even though I don't even pretend to be a Python developer!

I've been trying out Doom Emacs recently. I'll admit that I have used Vim and Emacs for reasonable periods of time previously so I am somewhat used to their way of doing things but Doom is nicely prescriptive and gives a great vim first experience. There is a bit of getting used to it but it might be something interesting for you.

> Doom is a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better).

This looks pretty neat.

I'd say the things to look out for are:

- Keybindings aren't comprehensively listed anywhere (that I know of)

- You have to go to the individual packages that are loaded and figure out how to use them

- There is some discoverability where if you type C-w you'll start to see all the window related keybindings, so you can at least get into the habit of checking there when you forget something

- I'm used to using C-c to return to normal mode in Vim which doesn't work here so my suggestion is to use C-[, jk or ESC I guess

- Autosave is disabled by default due to a preference of the maintainer, so you'll want to install a package or tweak the config to enable that

- I find window management difficult right now compared to something more conventional like VSCode or even compared to something like i3, it just doesn't seem to do what I want

Overall I'd say its like good guard rails but you'll probably need to dive into Emacs stuff to accomplish certain tasks. With that said, the vim emulation is miles better than what's available in VSCode.

There is also Spacemacs which aims to be much more comprehensive but I haven't tried that.

Hm, for a 4k screen, it has surprisingly little on the screen. Is the monitor pretty small (<32")?

I run scaled down slightly, it appears to me as 2560x1440 but still having the benefits of better pixel density.

FWIW I have an HP Z27 display which I adore. It uses a single usb-c umbilical cord to deliver power to my Macbook Pro ('18 touchbar model) and simultaneously video to the display.

The light that indicates whether the display is on or not is also incredibly small, the same size and intensity of the green 'webcam active' light on a Macbook, but in a white color.

I was an avid Sublime Text user for versions 2 and 3. The speed and responsiveness kept me coming back.

Then over time computers for faster, VSCode got more efficient, and plug-in developers started paying less attention to Sublime Text because we all assumed development had stopped.

I started using VSCode because I needed a specific plugin that wasn’t available in Sublime Text. From there I got comfortable with VSCode and slowly stopped using Sublime Text. I think an active plug-in ecosystem and IDE-like features are necessary for text editors to stay relevant in 2021. Sublime Text’s long development hiatus may have stalled that process. Hopefully they can spring back.

This may sound weird, but I genuinely hope they don't "spring back".

IF we consider Sublime to be a text editor and not an IDE, then all I really want from the Sublime dev team is to fix problems if/when they arise. If there are no problems, then push feature development into the plugin ecosystem, but leave out-of-the-box Sublime mostly alone.

When I look at that preview video, I see a team that shares my values in a text editor. They've made updates to keep with changes to operating systems, a few features that would be universally useful in a text editor, but not much else.

For me and my idea of a text editor, that's perfect. It's stable. It's dependable. It's fast. I never have to worry whether the dev team is about to destroy the editor that I love, nor do I have to worry about it becoming obsolete.

Some people may feel it's already obsolete, but every complaint seems to be for IDE-like features, not for a better text editor. If that's what you want, then by all appearances, VS Code is the way to go.

That being said, I hear what you're saying about the plugin ecosystem. If plugin developers have interpreted the relatively quiet and deliberate release cycle of Sublime as "this is no longer being actively developed", then of course they won't develop their plugins for it. But if that's anyone's interpretation, I think they're wrong.

To put it another way, I think of Sublime's approach like Google's approach to their homepage (at least when Marissa Mayer was running things): Job #1 is to say no to scope creep. Keep it simple. Keep it focused. If you can make it better at the focused list of things it's meant to do, then great, do that. But don't add, don't clutter.

Sublime Text has never crashed on me (or been slow) and that's why I use it as my primary tool. VSCode is still slow for me, last I checked.

The performance and reliability of subl is unmatched in my experience as well.

I use them the other way around - I do almost all my dev work in VSC these days, but I bought ST3 years ago (ST2 originally I think) and I still prefer it for opening huge log files, XML, etc. which bog down VSC.

For some languages, VSC plays in IDE territory. Compared to other IDEs in the same space, it's pretty similar, if not lighter.

Except... it all was a marketing issue.

Development continues, and having a stable API for plugins can be considered a feature.

Let's see what will they do in the future. Both ST developers and plugin developers.

I started out with vi and then Vim. When TextMate came out, I became an avid user. I liked how easily I could customize it but then it seemed kind-of abandonware (could be just my own perception) so I moved on to Sublime Text. I played around with others during that time including Visual Studio Code.

All of the editors I've used are great and I don't knock them at all. About two years ago, however, I realized how much I love Vim. It is also easily customizable but most importantly, I just plain feel really productive with it.

I loved TextMate.

But I think the facts speak for themselves now...

- their site is now little more than a vanilla bootstrap theme

- their News section hasn't been updated since 2014

- the blog appears to be miscellaneous developer notes that may or may not even be related to TextMate

...I'd agree with the sentiment that development appears to be dead.

That said, I think Sublime is as worthy a spiritual successor as any. (It also may be the biggest reason for TextMate's demise.)

FWIW, Textmate itself gets pretty frequent updates (latest one was on Feb 25th). It has also been open-sourced[1].

[1] https://github.com/textmate/textmate

I had no idea... I was basing my conclusion on the TextMate site, and both of these facts are kinda buried.

Gonna have to give TM another go sometime soon.

I've been a Vim user for a long time and still use it today occasionally. VSCode has replaced most applications of Vim for me because of the good out-of-the-box experience for different programming languages.

In VSCode all it typically takes to get started with a new language is to install one or two extensions, click one to three buttons, followed by a restart. Now you got syntax highlighting, auto-completion, go to definition, find all references, build system integration, test runners, debugging support, etc.

You can also get these features in Vim or Emacs, but from my experience it takes a lot longer to setup and integrate properly.

I would pay a lot of money for a curated vim distribution that works out of the box. I've used vim heavily for years, and still nothing compares to it when things are working well, but every time I want to change something I get so frustrated. Every extension uses it's own set of principles, the learning curve is steep, error messages super vague.

If anyone is looking for a side-hustle, I'd be your first customer

Honestly, there is not a lot of Vim I really miss. Yeah, macros with motion commands are cool, but in many cases VSCode's multi-cursor is sufficient.

Editing code in Vim is probably faster, but that speedup is neglectable if you are missing precise go-to-definition or auto-completion instead.

When it's set up nicely it works great, but any modifications are a pain. Also i can't put in words how much i hate using the mouse, after having tmux+vim+tiling wm set up

I'm building something like that. Feel free to reach out, would love to chat.

VSCode + vim plugins are this for me. Best of both worlds

Emacs is an IDE, though. It's greatest strength is that "I" part, not necessarily the text editor. Vim is more of a direct competitor.

For me, to complete as best text editor, disk-based editing is a must. For that reason alone, Ultraedit remains the best text editor and has done for many, many years.

You're an honest-to-god hex editor? I thought that was just something people said to sound bad ass, knowing they'd almost never get called on it. Most impressive.

(In case any of that sounded sarcastic, it's not. I'm in genuine awe.)

I’m wondering why you’re not putting ST and VSC in the same basket. They’re the same type of text editor: light, extensible with community plugins. Hell, the design and the shortcuts are the same as well!

I think it’s going to be hard for ST to compete with VSC, their major offering seems to be native over electron, which is great but will it be enough?

Fair comment. I struggle to categorize VSC in the Editor-IDE spectrum, and it may simply be a matter of market positioning. But let me take a stab at it.

The way I've seen VSC used in the wild is as a highly customizable IDE. Yes, it can be used as a minimal text editor. But it seems to want to be more than that. I've yet to see anyone using it that weren't also using it as a terminal and a bug checker and git manager and and and...

By contrast, most ST users (again, based on personal experience, I could be statistically way off) use it as a pure text/code editor, with plugins to help with code completion and such. ST can be extended, but it doesn't much care whether you choose to extend it or not. Using VSC without plugins just feels... weird, somehow? Like I'm missing the point of it?

As for whether ST can compete with VSC, I don't think it should compete. They're each appropriate for different situations. They do overlap more than any other ST "competitor", granted, but I think there are situations where VSC is the better choice, some where ST is better, and some where a full-blown IDE is the best way to go.

When the situation calls for a really great text editor, ST is, in my experience, the fastest and most productive way to go.

I think the shift from ST to VSC is due to the fact that many (most?) developers actually want an IDE, but just don't like the other ones on the market.

VS Code has never been sold to me as a lightweight text editor and I've only ever seen it coupled with atrocities of plugins for "developer productivity" that equates to do it the way the wizard in the corner created their environment to enforce or else feel their impotent wrath on your PRs.

Exactly! Very happy with both; VSCode for... code :) and Sublime for everything else. As far as I’m concerned these two are not competitors.