It would be nice to have an editor which can work locally and edit remotely using keyless SSH (e.g., using PEM files) which is a common use case for cloud setups like EC2. Near impossible getting this to work on Sublime or almost anything else. I'm surprised there isnt more developer request for such tools.
Do you know you can mount a remote filesystem using sshfs? It changed my life a few years back. Super easy to use and no need to have the functionality built into the editor, which in my opinion, isn't where this functionality belongs anyway.
One thing that Windows does really well, in an all-Windows environment anyway, is network file access.
Need to open a remote file? Open \\servername\share\path\to\file.txt. No need to 'mount' a filesystem, or map a drive or anything, it just works. No need to supply credentials since Windows already knows who you are signed in as. It's really quite nice. Of course, this all relies on the Windows monoculture - it doesn't support sshfs, nfs, etc, only CIFS/SMB.
This is all done at the Windows API level, so it works across all applications with very few exceptions (like cmd.exe). It doesn't rely on an application using specific libraries (e.g., Gvfs, KIO) or having some kind of addon to enable that functionality.
Honestly, this is the number one thing I miss since switching to Mac/Linux. I can still access network resources from the Mac and Linux, but it's not as convenient or transparent as Windows.
I've never had a good experience with sshfs on Windows. Different settings are either too slow or don't kill the cache when I change something.
My current workflow is to clone the project both on my machine and my development server, then sync the changes with the SFTP plugin.
Yeah, I use sshfs a lot too with Sublime. The biggest drawback I find is that its built-in search and search/replace is basically useless on a large remote project. This is one area where the editor being able to run commands on the remote host would be a huge advantage.
That is a very limited solution. I started using VIM exactly because I should log in to a remote server AND use the libraries in that server and have some intelligent auto-completion and code checking going on in my editor.
Mounting a remote filesystem does nothing of that.
Worth noting: for the Scala (and Java!) language, there is a Sublime-Ensime integration that provides something along these lines, but even more advanced. ie: go to method declaration, rename method, find calls, code completion, type info, etc.
I think you misunderstood GP's comment, I took their comment as noting that for Java and Scala there's a language-aware refactoring framework (Ensime) with Sublime integration which can thus provide language- and semantics-aware refactorings and transformations (thus further and safer ones).
> I got this comment that "this plugin set is worth nothing" (because of the first sentence)
Goodness gracious no, "worth noting" means "probably valuable or useful to think about or remember" (in this case in the sense of talking about an other edition/refactoring engine which might be better/more powerful for a very specific set of languages rather than in the general case).
Not "[the subject] is worth nothing".
In this case "that's a cool tool, though if you're specifically using Scala or Java Sublime-Ensime provides even more features".
How do Sublime users feel about Atom (https://atom.io/) as a replacement?
I switched from Sublime 2 to Atom earlier this year and haven't really looked back. I admit, though, that my customization needs in the environment have been minimal. I've written a couple of editing short-cuts for Elixir source, but that's it.
I'm curious to learn what features in Sublime merit purchasing it over Atom or another free text editor.
I have been a Sublime 2 user for 4 years now and have always been content with the experience. When I first used Atom because it was the only browser supported by Hacklang's tooling. What I noticed was how slow Atom was, startup, large files, and typing in text. It is something I have been so used to in Sublime and I could not give that up for unless there is a tool I really need on Atom.
I agree with this. I think the only thing that has slightly annoyed me in Sublime has been that some plugins can be slow, especially if they're not Python based (e.g. Node plugins can be slow), but that's not really an editor issue, and I haven't really noticed any other issues.
I haven't used Atom much, so I can't make a truly educated comparison, but from what I remember the speed difference was staggering when typing. At the time I used vim, and now primarily use Sublime, both of which I almost never have slowdown with (the only time I ever recall having Sublime crawl was when I was compiling a massive program that ate my entire CPU). Atom didn't lag horribly but it was noticeable.
I've been somewhat curious about Atom lately, especially when I dealt with how slow stylelint was when linting through Sublime (1s+...), whereas Atom doesn't have this problem because it already runs a Node process, but really there haven't been any real impetuses to switch to another editor.
If I were deciding between the two without owning Sublime, I'd probably go with Atom first because it's free, then if I found it to be lacking, be it through customization, plugins (if I liked Python over Node for plugin writing, for example), or speed, I would probably go with Sublime.
Honestly, I've tried to switch to Atom in the past and I have found that it was slow.
Sublime has what I need and it's quicker to start. I don't need something that I can customise with CSS, I need a fast text editor with syntax-highlighting.
On a plus-note, I have just convinced myself to use Vim with the following options: set number, set mouse=a, set colorscheme evening and syntax enable
Been using ST2 for many years, then ST3 till last year. Tried out Atom but it was slow and sluggish. Out of sheer curiosity, learned myself some vi from scratch and switched to Spacemacs, haven't looked back since :)
The issues that people have with speed when handling large files are a deal breaker for me.
I frequently look at trace files that are sometimes 100MB+ in size. Of course, I don't read all 100MB+ of the file, but that's where I have to start. Normally you'd use a viewer, not an editor, for this, but I also like to annotate the trace files as I work through them.
ST3 works decently with these files, so I keep sticking with it.
I didn't like Atom because of speed and GUI settings (got used to text settings after sublime or vim). And there are migration issues - I have a lot of plugins, settings, project files and knowledge so migration process will take too much effort.
Also, I don't think that it is a good idea to implement CPU intensive real-time applications in javascript (e.g. code parsing or syntax highlighting). There are plenty of languages/tools that suit well for it, there was no reason to pick a javascript as the primary language for a editor.
I am a user of both. At this time, I'd have to say the only reason I use Atom is because its markdown support is better (nicer code highlighting right out of the box and a real nice side-by-side live preview plug-in[1]).
Away from the speed thing (which is definitely noticeable on my two year old box), and from non power user perspective, I'd say they are pretty close to equivalent.
The massive performance hit, memory hogging, and that input lag that just does not go away even in high end machines is enough to make me never consider Atom at all.
I made switch from Sublime to Atom few months back mainly because of the thriving community. I'm pretty happy with the stability. They're doing fantastic job on improvising the speed, plugins and other tools. I agree Atom's boot time is relatively slow but I believe it will eventually catch up.
I use both on a daily basis. Sublime is incredibly fast, and I constantly find myself switching from Atom to Sublime for various reasons (big files to edit or big JSONs to format, search and replace across a big project...). Atom's UI is really great though, I wish Sublime came close as for the user-friendliness of the configuration. Also Atom now has better plugins than Sublime.
Note I also use VS Code a lot because its Git Diff view is awesome and its debugger is a rock too. The extensions are generally not great though.
And I use vim when I need to edit a single file quickly.
I used Sublime for a couple years before switching to Atom. As a disclaimer, I just do HTML/CSS/JavaScript so I'm rarely working with massive files. That's where I hear most complaints. However, I have yet to come across a problem with Atom that really gets my goat. There are occasional flukes - that is to say it feels like a fairly-early-on open-source piece of software - but nothing that prevents me from using it in a professional capacity.
For me there are some issues that prevent me from switching such as opening large text files (>100 Mb), international keyboard layout problems (Atom doesn't honor some keybindings when they are typed differently than in US keyboards) and problems returning focus after compiling LaTeX documents. So for the time being I'll stick with ST3 which doesn't have these issues.
I wanted to like Atom but when I was trying it out it was awfully slow and additionally it was a real energy hog, draining my battery unacceptably quickly.
Add to that the fact that I often need to edit text on remote machines via ssh and it just wasn't worth it to me to keep using it when Vim was (and still is) perfectly satisfactory.
I had some minor "issues" after I installed ShellStatus and its dependency StatusMessage using package manager. These may be true for rest of the packages as well, luckily they are all 1-2 minute fixes at most, so they are just small quirks.
The installation instruction said: "There is 'sublime-status' file in this package. Put it in your 'bin' folder..."
I put it in my bin folder, but it didn't read it. This was because on line 20 at shell_status.py, you -only- looked into package folder(and none of "bin") if the default wasn't changed. so unless I changed the settings and put some other name as my command, putting "shell-status" file in my bin folders wouldn't work, thus putting the default file in "bin" doesn't do any good. Just a mismatch between the documentation and code I suppose.
It also didn't create a ShellStatus/ folder under Packages/, which is the place you look for commands, so I had to create that as well.
There was also no entry for settings under "Package Settings", so I had to find the settings at Packages/User/ShellStatus.sublime-settings, it would've been better if I could go Prefences>Package Settings>ShellStatus like I can do with other packages.
Also the example on that page doesn't work, but again this is a minor detail too. There is no "<?php", so it just prints the file content itself. If you just add "<?php" after the comment it works. http://hastebin.com/ezirazekaf.php
I also have a request for anyone developing sublime plugins: I want to execute a shell command while I am working on the file, in-line. This is similar to some of your plugins, so I thought you may be interested. The output could be a comment. This would be useful when developing cli files, or just standard files if we can call it with "php arg1 arg2" or just "arg1 arg2" and have this file run with the correct path, get its output. Some plugins offer terminal access, but it is done in a separate/embedded window and the output is in console or a new file, and they offer no shortcuts to "just run the current file"
Anyways, thanks for the plugin. I will be using some of this.
I didn't want to just dump a raft of plugins into my Sublime setup, but installing them manually has me doing manual dependency resolution. Does Package Manager not provide this or does the author just not take advantage?
Package control does not provide this feature. I talked to maintainers of package control and we decide not to implement this feature (although I could do it by myself) because I'm only the author who need it.
Actually, there are not much really complex plugins for editors; most of plugins it is 1-5 python files that require no dependecies.
There is "go to definition" feature that based on syntax highlighting files rather than on real language parsing. It works fine if you jump only across the project and have "vendor" folders excluded.
Would be a stronger sell with examples in at least one other language. It looks like you're trying to be language-agnostic, but from all the GIFs, I'd presume this is only useful for Python.
Actually, I love vim, because vim is on each server and can be used without any extra effort, so vim is out of competition here. But I love smooth fonts, scrolling, and appearance of Sublime Text, so I made it my primary editor.
Emacs can be installed on any server (and can be used to edit files on any server, from a client …), and it has smooth fonts and scrolling (if you like that; I turn off the scrollbar). And of course it excels at mouseless editing, navigation & automation.
I use emacs with vim emulation (evil mode) and am addicted to it, partly because I can bind vim's leader key with emacs lisp functions that can be quite complex, to do great things with a single key press while editing.
The question is how much time you spend editing files on embedded devices versus how much time you spend editing files on your main development machine.
If you have ssh access to the remote machine (goes with most methods of automatic synchronization) then you can use TRAMP mode to directly edit the remote copy.
I test different configurations on the target before syncing the right one into my build environment. If I mounted the RootFS via NFS then its possible to use ${EDITOR}, but thats not always the case.
I personally use nvim, but most of my coworkers (also vim users) haven't yet switched. There's a surprising number of people that are aware of nvim but haven't bothered switching because vim works fine for them.
The main selling point for neovim when I found out about it was the async plugin support. And I remember reading that the creator of neovim mainly did it because the maintainers of vim refused to accept his patch to add async plugin support for vim.
But about a month ago, vim added async plugin support.
So now what? I switched to neovim, and now I am undecided if I should switch back to vim or not.
neovim has a fresh start, cleaner code base but less support/timetested code than vim. What do you guys think?
My understanding was that Neovim's main strength was the fact that it is a fresh rewrite for modern platforms only. Whereas Vim has tons of legacy code in it for all sorts of legacy platforms, which makes it harder for people to contribute code, and makes it harder for the dev team to find and fix bugs, or to add features, etc.
In any case, whatever the outcome of the fork is, this is an interesting experiment :
Will the cleaner code base, using more extensively tests and CI move faster than the legacy one ?
Not accounting the number of people contributing to each project, the logic said it should. It will be interesting to see how long it takes to pay the dividend.
Is this from experience? I've switched back to regular vim from neovim because of platform support, but I've never had stability issues when I did use neovim.
Yes, it's from experience. I'm maintainer of https://github.com/SirVer/ultisnips snippet plugin for vim, and I'm often see issues when people can't get it work under nvim due nvim internal issues.
