TextMate 2.0
github.com
github.com
But apparently VS Code is becoming extremely popular. I wonder if its literally just because of GitLens (still missing from other text editors).
Disclaimer: RubyMine / IntelliJ for life.
I use Atom for my quickie projects here and there, but you really can't beat an IDE. (IMO)
CPU use is negligible and I have plenty of RAM.
Sure, much of the API and all the plugin stuff is in Python, but the core is all native C++ AFAIK.
Having said that, if they had known all the modern alternatives were going to be even less “native” amd run in a browser engine, they'd probably have been less nitpicky.
It may not be heavy on archaic Mac features such as AppleScript integration, but I hope we can all agree to ignore those technologies.
TextMate just brings memories of the 10.4 Tiger days.
I personally liked ST2 but I know that some people held their nose.
Also, I'm not convinced we should ignore those "archaic" technologies, at least in the abstract. Applications can provide "dictionaries" of commands that, when implemented well, provide GUI applications with the kind of "snap together for amazing effect" you get with shell scripts and a host of well-written CLI tools. You arguably can't script the AppleScript-intensive BBEdit to the same level that you could, say, Emacs or Vim, but imagine the possibilities of a suite of apps from different makers that all had complete scripting dictionaries that could all be woven together with a deep system-wide scripting language.
I actually think it's a shame that AppleScript has been kicked to the curb. I don't think we have a "modern" replacement yet -- certainly not in the Apple ecosystem, and I'm not sure anywhere else. (Shortcuts on iOS is trying, but it's not on the Mac yet, and it gets pretty clunky if you start doing overly complicated automation bits with it.)
Unfortunately, the language itself is a horrible abomination from the wild 1990s days of Mac OS... sorry, now macOS... and writing absolutely anything in it is painful.
I feel like Apple introduced Automator to overcome the pain of AppleScript, but it never really caught on (I don't even know if Automator is still on macOS.... yep it is, still with the cute Aquaesque icon)
Nowadays everything is Electron anyway and those are not that well AppleScript-able, but what to do, that's life
In fact, there are several production-tested Apple event bridges that totally wipe the floor with Apple’s failed attempts, but caveat emptor as I don’t do support:
http://appscript.sourceforge.net https://www.npmjs.com/package/nodeautomation https://hhas.bitbucket.io/welcome.html
We’ll see what happens when Shortcuts lands in 10.16, but I’d say the chances of Apple event automation having a long and healthy life ahead are 50/50, at best.
I think the main developer of AppleScript left Apple last year.
I think I read something on these lines on HN, I may be remembering things slightly wrong
iOS Workflow/Shortcuts is what Automator should have been in a lot of ways. If Automator was superseded by a macOS version of Shortcuts, I'd actually love it, as long as it didn't lose any of Automator's functionality. (All they'd really need to do is add Shortcuts that run AppleScripts and shell scripts, I think, and be able to use automator actions exposed by applications.)
https://twitter.com/stroughtonsmith/status/11359563313603461...
Compare the file browsers and find dialogs and the difference is night and day.
The only fight it can't win over VSCode is the extensions and ecosystem.
Maybe you don't care about any of these but don't tell me you don't really lose anything.
If I wasn’t writing so much Python, I’d say I have a type.
Panic seems prepared to take that bet, with their development of Nova [1], a replacement for Coda.
(Wait, maybe I'm misreading your comment. Are you trying to say "Sublime is free, so Nova will have to be way better to compete with Sublime" or "Sublime wasn't good enough to justify its price, so Nova will have to be way better than that to justify its price"?)
People invest a lot of time into their existing text editors. For many people (myself included) a potential replacement would have to be more than a little better, because otherwise it's not worth the somewhat large cost (in terms of time spent on setup+mastery) of switching.
They just have too many products than what they can focus on...
That one feature makes such a difference to me as I switch between big project trees that I can't do without it.
I'd happily pay Panic for Nova if they add that back in.
(Ironically, as I get more deeply into Vim, I've found the :find and :buffer commands to be faster and just as useful as the CtrlP plugin, even if they're not quite as forgivingly fuzzy.)
Coda is more like VS Code and Sublime Text in some ways, but it definitely has Dreamweaver's "one stop shop for big web sites" thing going. (BBEdit also has that to a large degree, despite being even more of a pure HTML/text editor.) The biggest liability Coda has is that it feels designed for a time when we were primarily building sites out of hand-coded HTML; like BBEdit, it really isn't optimized for working on MVC-based apps, whether server-side or front-end.
It is native, cross platform, and not based on Electron. It also uses Vim as the core editing engine.
It isn’t native in this context; As a sibling comment mentioned, OniVim2 uses revery[0], which uses it’s own widgets (not native ones) like flutter[1].
Quoting from my old comment[2]:
> We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch.
> Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y.
[0] https://github.com/revery-ui/revery
[1] https://github.com/revery-ui/revery/blob/master/README.md#de...
Personally, I'm not looking to increase the ways that I'm locked into my current operating system, so all else equal, I'd favor an editor that runs everywhere.
(and also FWIW, of all text editors personally i use Notepad++ on Windows and Geany on Linux - though as i really dislike Gtk3 and Geany switched to that, i'm looking for some alternative that uses a more snappy and lightweight toolkit - for now the Debian version i use is still on Gtk2 but that is just a matter of time to be replaced)
Though i also believe that the functionality some people want from their applications is only available on (what i see as) applications with inferior UIs and they'd rather get used to these UIs than not have the functionality - that is, their vote is for the functionality, not for the UI.
Haven't noticed any performance problems with VS Code, since I started using it everyday maybe 3 years ago. I switched from Intellij based editors to VS Code and before that I used vim for a decade.
Especially on MACs were RAM is priced at a premium.
On Windows I developed a small program that sums the ram usage of my browsers and Electron apps I use. Between Firefox, Chromium and VSCode it's frequently around 4 GB of ram ! That's insane just to basically browse text.
Visual Studio, Sublime Text, TextMate, BBEdit, SlickEdit, Notepad++, XCode, Vim, Emacs, heck, one could add IntelliJ into the mix...
That's an interesting comparison. I completely agree that VSCode is the rage right now. Sublime was big 2014-2016. I'm surprised atom isn't as popular (I suspect its because of the awful loading time)
https://trends.google.com/trends/explore?date=all&geo=US&q=%...
Also "vs code" trends higher than "visual studio code", so take all of these results with a pinch of salt.
https://trends.google.com/trends/explore?date=today%205-y&ge...
Half-joking, but I think it is actually over-estimating the vim user base because there are so many things to search when learning to use vim, whereas the others are much closer to a traditional word processors.
Apart from that, Emacs usage mostly correlates how much of text heavy tasks a programmer is doing. Most people tend to write tons of shell/perl/python scripts and take a lot of time recreate the magic of emacs outside it, Sadly most of it is also throw away effort with a lots of manual effort in between. Sometimes its entirely manual effort because eventually you need to learn Perl regexes, or sed or awk really well, and that's another black hole in itself. To me that's kind of a gap in developer training itself. If you are wasting man-hours to weeks doing what should be done in man-minutes you probably have a huge gap in the way you are used to thinking about how your work in general.
Growth of Python is a big problem for programming community at large. It's a tool largely designed for beginners and people refuse to move beyond that. What's worse they also carry that kind of thinking to any tool they want to use.
Developers are generally bad at automating our own work. We wish to liberate accountants and ware house workers from drudgery. But rarely do we look at our own very work the very same way.
Using git with vim also seems a popular search combo.
Personally I am amazed that the younger generation are keen to learn vim. I don't see why as I have gone the other way to only use phpStorm for editing in earnest. For me using vim for code instead of phpStorm is a bit like handwriting instead of typing, a definite loss of formatting and neatness.
The reason I find modern interest in vim so amusing is that there is no compelling excuse to use it. In the olden days when you had to queue to use a terminal in a computer room to enter code you had handwritten on paper there were no 'nano' or other editors, you had to learn and use vi.
I don't believe vi is quicker than a full size IDE but I still use vi, find and grep because I don't fully trust these new IDE tools and I am fairly dyed in the wool as a command line user.
The tools I don't fully understand are the textmate, sublime, notepad++ and other middling editors that don't offer the brilliance of vim or the possibilities of a phpStorm grade editor.
Obviously its php specific features aren't relevant here since we're discussing editors (or development environments) in general.
Personally I find that most IDEs are far too language specific, and I can't possibly invest the time to learn an IDE per language when there's so many languages I regularly need to edit (and probably yet more in the future).
VSCode isn't half bad, as it has plugins for just about everything, but it's still a juggernaut in terms of software size. None of the jetbrains product I've used had decent plugins for all the languages I need.
And of course none of these work over a purely terminal ssh connection, which is a bit of a deal breaker for me.
Definitely not trying to convince you to use vim over your favourit IDE, I'm just currious what your top 10 missing features are.
https://trends.google.com/trends/explore?date=all&geo=US&q=%...
I really built a habit of vanilla vim usage, and to this day I have yet to find a "modern" text editor that really supports everything that vim has to offer i.e. "vim mode" being more than binding the arrow keys to hjkl and providing modes.
https://trends.google.com/trends/explore?date=all&geo=US&q=%...
(and if you keep it to search terms but swap "visual studio code" for "vscode" you see a simialar rise)
Looks like Emas used to rule the roost but then died away. What really piques my interest is why those of us in Wyoming (and the Dakota’s and Alaska) and apparently love Vim:
https://trends.google.com/trends/explore?q=%22textmate%22,%2...
I'd even go to an extent and say vim trends show supply of intermediate level programmers. Emacs trends show supply of expert programmers. The fact that those trends are in a downward direction tells a story in itself.
https://trends.google.com/trends/explore?date=all&geo=US&q=%...
I don't search 'vscode [something]' nearly as much. Most of the configuration options are explained in the interface (both the visual one and `settings.json`). I can find plugins right from the editor and that usually also includes essential information about working with the plugin.
I still use barebones vim for commit messages, and I still find myself looking for how to trigger the spelling suggestions. I never seem to recall the `z=` when I need it.
Just because something is less user-friendly and requires more knowledge or looking for help, it doesn't mean it's more popular.
The Stack Overflow developer survey is probably a more representative sample: https://insights.stackoverflow.com/survey/2019#technology-_-....
See for example: https://trends.google.com/trends/explore?date=all&geo=US&q=%...
Instead of abandoning the project he open sourced it and almost a decade later it is being released.
Textmate is now my graphical Notepad on Mac, with VS Code being my IDE and vim my text editor.
Thanks Allan.
I hope no one reads that and assumes that’s all TextMate is. TextMate is the godfather of all modern “smart” GUI code editors — VSCode included.
BBEdit magic was all through AppleScript, which was always inscrutable for me.
(And you could edit not just C++/VB/Microsoft-language files with Visual Studio back then. It was extendable to support many languages, which they did.)
Once you add panels and toolbars with all sorts of GUI tools, consoles, language servers, remote editing, debugging and built-in commands for common external tools like Git - you've got yourself an IDE in my opinion.
However, aside from all of that, Microsoft's mastery of autocomplete - which they call Intellisense - is really what attracted people to Visual Studio and later VS Code. I know that's the reason I've always used it. Also, VS always had syntax highlighting before TextMate even if it was implemented differently than how TextMate did it.
So, I don't think it's fair at all to say that TextMate is the godfather of VS Code assuming that by saying that, we're saying that it's the reason that we have VS Code or that it's the reason that people are using VS Code... I don't fully understand implication of the phrasing but my guess would be that TextMate is the godfather of the implementation of syntax highlighting that VS Code and many others are using.
(I think if we changed godfather to grandfather, it'd make more sense to me because then you have lineage. A godfather is more there as a backup, to be your father in case your biological dad dies. But perhaps, like in the Godfather movies - you go to him for help and advice. So in that respect it sorta makes sense.)
You can have all (or none) of those features in either an editor or an IDE.
The core idea of an IDE was to provide a single UI for all aspects of development — which originally included source code editing, compiling, debugging, and testing. To handle all of these tasks within an IDE required the IDE to have a top-down configuration that would enable it to compile and run the project.
Editors like VSCode don’t compile or run anything on their own (though doing so is possible via the integrated terminal). Editors thus normally don’t require a project file. They may use files like tsconfig.json to inform internal language services, but those config files are not specific to VSCode.
From the point of you of the user they are all an IDE I think.
On the other hand Visual Studio Code is just an editor, like Textmate.
Allan had been making very fast progress on TextMate for the first several years, and the community was full of excited “early adopter” types, who were very chatty and supportive, and were actively engaged in improving the TextMate language “bundles”, trying out new features, etc. I found the ##textmate IRC channel at the time to be the best place to get technical help with pretty much any programming language.
Then at some point Allan decided that he had made some suboptimal design choices in pretty much every component of TextMate 1, and wanted to improve those with new designs. But he thought it would take more work to incrementally swap new parts in that were compatible with all of the other stuff he wanted to eventually replace, so he started in on what was a substantial rewrite of everything.
That (a) took away his incremental improvement of TextMate 1, (b) took his time away from being as responsive to user questions/ideas, (c) caused bundle authors to slow down on improvements to TM1 bundles while they waited to see what new features TM 2 had in store.
At the same time, the creation of an "insider" IRC channel took away some of the activity from the main IRC chat, the migration from one big SVN repository to a bunch of separate per-language Git repositories damped a lot of the bundle development activity as people were no longer exposed to every change to every bundle, so the bundles didn’t cross-pollinate as much.
Many of the core people in the community gradually drifted away, and weren’t being replaced by new people, from some combination of existing bundles being good enough, and less overall buzz.
As Allan was getting less feedback about the code he was working on, and less interaction overall from users, he became less motivated. As the TextMate 2 project dragged past its original timeline, both Allan and others in the community started to get discouraged. I would speculate he started to feel like more of the work was a chore rather than a joyful adventure.
There are many great TextMate 2 features which have still not been properly explored by bundle authors all these years later. It could use more screencasts, more technical documentation, more people testing zany things and making feature requests...
For my money TextMate is still the best editor available, from a purely technical perspective. The experience of customizing one’s own editor environment has less friction than pretty much anything else out there. Almost completely nontechnical people can do amazing things with it. But the community isn’t the same as it was.
* * *
Aside: Sublime Text was an unauthorized (and for at least the first few years half-baked) rip-off which borrowed TextMate bundles wholesale without contributing anything back whatsoever. In early versions [and maybe still?] people couldn’t actually edit all of the bundle items in Sublime, so its users were disempowered from customizing their own experience, arguably the main point of TextMate’s design. In the early days many of them came to complain at us about TextMate bundle items which didn’t work in Sublime. In my opinion the Sublime author profoundly missed the point of what TextMate was about and why it was special, and viewed it as nothing more than a convenient pile of existing work he could exploit to kickstart his own app.
I might have found time here and there to contribute to TextMate after the open sourcing, but my company won't let me even look at GPL3 source. I don't even dare look at the bundles.
> Aside: Sublime Text was an unauthorized (and for at least the first few years half-baked) rip-off
This puzzles me though. What "authorization" should Sublime's author have sought?
I don't know why application XYZ would/should need permission/blessing to be compatible with application ABC's plugins.
To me it's just a completely sensible decision; why would the author(s) of application XYZ want to force users to reinvent the while to write a plugin to do Ruby or Javascript or HTML or whatever highlighting, when this work has already been done so many times over?
> In the early days many of them came to complain at us about TextMate bundle items which didn’t work in Sublime.
Well this was certainly exasperating I'm sure. Sorry you had to deal with that.
> In my opinion the Sublime author profoundly missed the point of what TextMate was about and why it was special
Sublime's author has never really engaged the community much like Textmate's author, which is a shame. Though I would have to point out that a small team (both were single-man teams for most of their lives) can only accomplish so much, and I would say that ST's development has greatly outpaced TextMate's. Also I think ST has somebody working full-time on package management stuff now, not sure.
If you try ripping off large companies, you run the risk of getting sued. But if you do it to a 1-person company, you can generally get away with it. Still scummy.
> completely sensible decision
From a purely selfish “how can I profit without doing my own work” perspective, sure. Same is true of many types of unethical shortcuts in the world.
> ST's development has greatly outpaced TextMate
I haven’t looked in years, but when Sublime was about 4–5 years old (when I last spent some time examining it) this was nowhere close to true.
I would say instead that the man-on-the-street external impression of ST’s development has been faster.
I'm not a fan of this argument. We all build upon the work of those who came before us, and usually even the most blatant rip-offs add something.
I'd even argue the opposite: We should copy good ideas. There's no point in re-inventing the wheel over and over again. If we copy good ideas, we can build on them, and we can spend time inventing new things, rather than re-inventing everything just to make sure it's all original.
(And I say this as someone whose work has been shamelessly ripped off multiple times in the past.)
AFAIK, Sublime is/was cross-platform? I wouldn't call that nothing novel.
I think it’s unethical to copy an existing program’s features one by one, as precisely as possible
I'd argue that conceptually, TextMate borrowed at least as much from Emacs and BBEdit as ST did from TextMate.
After all, what was TextMate's raison d'être? It was not some totally new idea. It was a successful iteration of existing ideas. It was lightweight like a text editor, but highly extendable via scripting.
So, it was like Emacs, except not quite as infinitely extendable, but more friendly and had a native OSX GUI interface. And it was like BBEdit, except more extendable. (Correct me if I'm wrong on this -- I used BBEdit a bit back in the day but never dove too deeply into it)
ST iterated further upon TM's ideas and others. Yes, it implemented TM's bundles and syntaxes for compatibility reasons, which I would call a very good thing because why invent those wheels again. Any new entry into an existing software category certainly should leverage the existing ecosystem to the fullest extent possible, unless there is a very good reason not to.
It's been years since I used TM but I think ST's command palette was a big innovation over TM, and more keyboard-friendly. ST's integrated Package Control is also something I don't believe TM has an equivalent for. And ST is of course cross-platform: it's not like using TM is even an option if you're on Windows/Linux.
So I really reject the talk of ST being a "ripoff". Good software should borrow ideas and leverage existing work whenever possible. And it's demonstrably false to claim that ST offered nothing new, or that TM itself didn't borrow very heavily from other editors.
(I also don't think SublimeText "just ripped off" TextMate and didn't add anything new. They added Windows and Linux support, for one.)
I won't say VSCode as stable as TextMate, and it certainly doesn't feel like a native Mac app in the same way, but it's simply easier for me to find plugins that I need.
But it took him way too long, unfortunately.
Had him realized he couldn't move the project forward and open sourced it earlier, it could have been a different story.
I'm just doing light HTML/CSS/JS prototyping, so my needs are easily satisfied, but TextMate is just so light. Launches instantly, doesn't crash, and uses minuscule resources. (Versus the 9 Adobe processes running in the background, even though I don't have an actual application open.) It's just nice to have a completely blank window, no sidebar, no nothing, just a place to plonk text.
I used Sublime for the same reasons, which is to say I understand why people like TextMate over something like VS Code. Being able to do something like open up a 400 CSV without in an editor without the editor choking is just really nice!
I've been taking TM 2.0 for spin for the past few weeks. I must say - it is THE editor that gives true Mac editor experience.
No complaints on performance. And it is very stable.
1. Among the existing features, UI refresh for Quick Open window is required as it feels very heavy now in 2.0. TM 1.x Quick open window UI was slick and neat and I wish they kept it as such. Same comment goes for Go to Symbol window (CMD + SHIFT + T).
2. They would win back a lot of users if they provide a slick option to have split editor to make use of very common high-DPI Mac screens.
3. Documentation for Textmate 2.0 is still WIP as I see on their website. Lot of pages are empty with titles alone.
And glad to see Alan's comment in ChangeLog - `Not everything on the wishlist made it into 2.0, but TextMate remains a work in progress, so don’t despair :)`
Jumped ship to Sublime when it was released because it was evolving much quicker. Was glad to have backwards compat on a lot of things like themes. Still have my modified “Made or Code” theme kicking today. Tried TM2 a ton during the betas but never managed to reach the same level of productivity as Sublime. My muscle memory is too strong now and I can’t find any reason to leave.
Regardless, this is a great accomplishment/milestone and I’m very stoked for Allan and the team. Maybe I’ll need to take it for another test drive.
A different time.
When I switched to Linux my first choice was Gedit (it was usable at the time) with a ton of plugins to make it like TextMate as much as possible, but I very soon turned to Emacs and I've not gone anywhere else since.
I am using TextMate as a text editor, coding for Python/Django, and as scratch pad for code.
I still find textmate the best for my needs:
1. Nice search interface (sorry sublime) 2. Fast and memory efficient 3. Best autocomplete 5. Multi line editing.
But few things could be better: editor tabs not contrast, slow when editing files with very long lines, feature to see memory usage per project
Surprisingly, my 15-year-old license is still considered valid
I was a die hard editor purist (Sublime) for a while but after using an IDE for Java I realized how powerful they can be - even for frontend.
Everything works well. The intellisense and linting integration is amazing. CSS selectors are autocompleted from indexed HTML. If you don't have any red squigglies in your TS or HTML files then most likely your Angular app will just work. Plus, point-and-click to navigate through classes/methods like Intellij. No more "let me search for this method by name to find the declaration."
Good unit test integration w/ jasmine to top it off.
Just too many benifets to ignore. If I had a company I'd require development in an IDE.
Then the complete rewrite was announced and, as 2.0 was delayed and the author disappeared… I switched to Vim.
I downloaded 2.0 out of curiosity, though, and it feels just like 1.5.x with VCS badges built-in. Too little, too late.
So I don't know what the backstory is with the slow release cycle, but at a certain point it became untenable to use TextMate 1 on our large codebase with performance problems and features missing from other tools.
Now however, I worship Vim, the one true god
2005, the Mac alone had lots of good options (BBEdit to name just one), but I think it is fair to say that TextMate charted the course that every successful text editor has followed over the last 15 years. And I'm not just talking about the ingenious bundle system (the syntax of which VS Code still uses to this day!) or the themes -- stuff like the "mate" command genuinely changed how I interacted with files (it's possible this existed for other editors before TextMate but I'm unaware of it). When TM 2 first went into beta/alpha in 2011, rmate was a revelation. Now, I could use my editor of choice on all my remote machines. VS Code now does this elegantly with the VS Code Remote extension (it works super well in WSL/WSL2), but for those of us who abhor vi/nano/emacs, this is the sort of thing that has really made my life easier. There are more examples I could cite -- but TextMate really paved the way for the editor market we have today.
TextMate was one of the first apps I bought when I became a full-time Mac user in 2007 and nearly 13 years later, it's remained one of the most important applications I've ever owned. I've been using the 2.0 release basically since it was in alpha stage (when it was necessary to have TM1 installed alongside it) and I would honestly probably still use it if the community hadn't all but abandoned it (first for Sublime -- an editor I respect but could never love -- and later for Atom, which was soon usurped by Code).
Even now, for writing stuff in Markdown the way I like to write, my customized TextMate packages remain the best way to do that. I've ported most of what I used to do over to Code but there are some thing that just aren't perfect. (And more accurately, it's hard to get used to something new.)
I bought TextMate when I was still a broke college student, so I took advantage of the student discount offered at the time for TextMate 1.5 or whatever it was. I've always felt bad about that because over the course of the 11 years or so that I used it for my primary writing tool, I easily composed ~5 million words or more into it (one year, 2009 - 2010, I did more than 1 million words -- and this is of prose/Markdown, to say nothing of however many lines of code I might have typed. To put that in perspective, the longest Harry Potter books are ~110,000 words. Suffice to say, I cut back on my writing obligations in 2011 and beyond to save myself from burnout) and an ungodly number lines of bad code across assorted projects (so much bad JavaScript!). I paid a friend initially to customize a plugin he'd made when we worked together for my more specific purposes, and I later maintained/ported those plugins to TM2 (and now, VS Code), but when I look at my TCO for TM versus what it gave me, I can't help but feel guilty.
Congrats, Allan!
OT. Anyone know of a secured text editor for iOS that can encrypt and decrypt text files on writing and reading? The encrypted files should be portable so that I can encrypt and decrypt them on other platforms.
This would defeat the point of it really, the whole point of TextMate in 2019 is to have an editor that leverages the native Mac UI.
If you ported it to Linux you'd either just be making a completely new application that didn't work the same or you'd be making as weird application that felt like a Mac app running in the Linux world.