5 ms·
>doesn't address what Sublime is missing at all. Being a fully programmable work environment. Edit: I used ST2 for about a month. The Python was neat but it's
by codewright 13y ago
>doesn't address what Sublime is missing at all.
Being a fully programmable work environment.
Edit: I used ST2 for about a month. The Python was neat but it's going to fade away eventually.
- FuzzyDunlop 13y agoVim and Emacs have had decades to get to that point. ST is a comparative baby. I'd love to see a modern editor that isn't designed around a terminal join those ranks.
- codewright 13y agoPretty hard to "get to that point" when your editor isn't programmable. Which goes back to my original point. Seen lots of IDEs and editors come and go. Nothing new here, just more polish than the last guy.
- lake99 13y agoThere is Acme for Plan9 [1] and it has inspired a few other editors. I don't use them myself because they don't have syntax highlighting. [1]: demo at http://www.youtube.com/watch?v=dP1xVpMPn8M http://www.youtube.com/watch?v=dP1xVpMPn8M
- symmetricsaurus 13y agoThat looks awesome. Having used the WMII window manager it looks quite familiar. Even then the learning curve seems steep.
- tomsthumb 13y agoWhat can't you do with ST2 if you write a plugin? Or is that just a relative pain compared to emacs & vim?
- codewright 13y agoFriction + capability + turtles all the way down.
- roryokane 13y agoI know that one thing you can’t do is have custom tabstops for text. The plugin https://github.com/SublimeText/ElasticTabstops https://github.com/SublimeText/ElasticTabstops is unable to completely implement elastic tabstops, and its README says that “Limitations in Sublime Text's API make it virtually impossible to use elastic tabstops with spaces.” Though neither Vim nor Emacs currently provide all the APIs necessary for elastic tabstops plugins, either. They only have the possible advantage that since they’re open source, such support is a little more likely to be added.
- mrgoldenbrown 13y agoCan you give a specific example of how being "fully programmable" improves your workflow?
- SoftwareMaven 13y agoWhen I decide something needs to be added to my workflow, it is easy to add. The difference is whether your tool drives your workflow or you workflow drives your tool. The Java world is a great example of tool-driving-workflow. IDEs are massive, and you are generally constrained to a code-build process as thought out by the vendor. Generally speaking, the tools have good "average" efficiency. Anybody who has used the tool could sit in front of anybody else's and be as efficient. Emacs is obviously the other end. My workflow influences the tool in so many ways that it would be nearly impossible for somebody to sit in front of my Emacs and use it efficiently. However, I am far more efficient than within any IDE, because I have bent the tool to my will. Something like Sublime doesn't necessarily prohibit you from building a workflow and tools around it. It would just have include the command line as the programmable part. EDIT: Specifics. A simple example: I was editing a bunch of wiki pages, do a combination of creating, formatting and moving content. I built a small set of tools to handle the repetitive parts. It is the aggregation of all the small things like this that makes the tool so much more valuable.
- mrgoldenbrown 13y agoI understand that customizing can improve productivity. What I haven't seen is someone name a particular task, and show how much easier it is to customize in their favorite editor vs emacs/vim/sublime/editor of the day. Sort of like a benchmarksgame.alioth.debian.org or rosettacode.org but for editors.
- SoftwareMaven 13y agoI'm not sure how that would work, because the very nature of the beast is exceedingly personal. As I mentioned in the example I added to my original comment, it is about small things that, cumulatively, add up to big things. I think the kinds of things that would show up on a rosettacode-type site are most likely already exposed in terms of plugins of some sort (however the editor defines "plugin"). It is the murky area between keyboard macros and plugins that the programmable editor makes its mark, and those things are highly individualized. It would be fun to have something like seewhatididinmyeditor.com, that just let you post snippets of these kinds of things in your editor's native tongue. Here's another example: I was converting some javascript to coffeescript. Coffeeescript's conventions are snake_case, and I wanted to follow those conventions, so I added this little thing: (defun my-uncamelize (s &optional sep start) "Convert CamelCase string S to lower case with word separator SEP. Default for SEP is an underscore \"_\". If third argument START is non-nil, convert words after that index in STRING." (let ((case-fold-search nil)) (while (string-match "[A-Z]" s (or start 1)) (setq s (replace-match (concat (or sep "_") (downcase (match-string 0 s))) t nil s))) (downcase s))) Now, I didn't write it; I grabbed it as a snippet somebody else had written and shared. Now, with a bound key, I had a single key-stroke that would snake-case an identifier. Again, not a big deal, but it made the workflow for converting those js files just that much easier.