>For me, the thing that sets sublime apart from vim and emacs is the fact that it is a full gui app. Things like go to definition, autocomplete, build panel, command pallete, sidebar, context menus, are all technically possible in vim, but hacking these features into a command line interface always ends up seeming clunky, confusing and slow.

I can't speak for vim, but Emacs is also a "full gui app." It has go to definition (in fact, I wouldn't be surprised if this idea was invented in some incarnation of Emacs), autocompletion, and various other such features like gdb integration and build message hyperlinking. The discoverability argument applies as well.

I disagree, Emacs isn't a "full gui app" even if it has a gui with menus and can show images etc.; because almost all kind of interaction happens inside buffers opened in (new) windows. there are no proper dialogs/popups (they're not used even if it's possible), so Emacs is not a proper GUI app as anyone would expect.

I don't claim it's a good or bad thing, a lot of people love emacs because of it's buffer/window centric approach, but it's not even remotely close to what you would expect from a modern gui, so Emacs is still oddball when compared to all the other gui's, which is why new users still struggle with it even though on paper Emacs has all the features other gui editors have.

It's not just a familiar interface. It's a better interface. Smooth scrolling is better than line-based scrolling. A popup is better at alerting the user that input is needed than a small prompt at the bottom of the screen. The command pallete, which is clearly visually distinguished from the surrounding text by a gui border, is better design than yet more lines of text indistinguishable from the rest. Current selection highlighted in a bright, theme-able colour is better than just toggling the background colour. Little graphical icons next to lines indicating changes, breakpoints, etc is better than a random text character put before the line. Smooth animations are better at conveying change than instantaneous changes to text. Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art. The fact that key bindings can interfere with your terminal emulator or shell's keybindings is an annoying restriction.

If all these things weren't objectively better in some way, then the gui app could just draw lines of text instead of windows, borders, selections, themes, images, and animations. But it doesn't, because lines of text is a worse interface for almost everything except the actual buffer you are editing.

I know vim very well. But I only use it out of necessity now when I'm on remote machines, because it is worse than a good gui app, precisely because it is restricted to its grid of text interface.

>It's not just a familiar interface. It's a better interface. Smooth scrolling is better than line-based scrolling. A popup is better at alerting the user that input is needed than a small prompt at the bottom of the screen. The command pallete, which is clearly visually distinguished from the surrounding text by a gui border, is better design than yet more lines of text indistinguishable from the rest. Current selection highlighted in a bright, theme-able colour is better than just toggling the background colour. Little graphical icons next to lines indicating changes, breakpoints, etc is better than a random text character put before the line. Smooth animations are better at conveying change than instantaneous changes to text. Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art. The fact that key bindings can interfere with your terminal emulator or shell's keybindings is an annoying restriction.

I agree with almost all of this, which is why I use Emacs' graphical interface instead of its terminal interface.

> I agree with almost all of this, which is why I use Emacs' graphical interface instead of its terminal interface.

You can't be seriously saying this because Emacs' graphical interface lacks half of them. Here is a breakdown:

> Smooth scrolling is better than line-based scrolling.

I can't see any smoothness in scrolling of Emacs' graphical interface in Linux.

> A pop-up is better at alerting the user that input is needed than a small prompt at the bottom of the screen.

Only a handful of 3rd party packages use some badly-imitated pop-ups and I've never seen anything even resembling a pop-up in Emacs' graphical interface (maybe except the GTK+ open file dialog)

> The command palette, which is clearly visually distinguished from the surrounding text by a gui border, is better design than yet more lines of text indistinguishable from the rest.

I can't see anything resembling the command palette Emacs' graphical interface. Everything is either use the minibuffer or open a new window.

> Current selection highlighted in a bright, theme-able colour is better than just toggling the background colour. Little graphical icons next to lines indicating changes, breakpoints, etc is better than a random text character put before the line. Smooth animations are better at conveying change than instantaneous changes to text.

I guess we have those.

> Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art.

Speedbar isn't even close.

> The fact that key bindings can interfere with your terminal emulator or shell's keybindings is an annoying restriction.

N/A

>I can't see any smoothness in scrolling of Emacs' graphical interface in Linux.

I'll grant that Emacs doesn't have this. Most programs don't either, though, and in the few I've seen that do (e.g., Firefox), it slows scrolling down so much as to make it practically unusable, even if it does make it easier to track the text with your eyes.

The real usability problem with Emacs' scrolling, in my opinion, is that the default scroll increment is too large. That's easily fixed. Some people also don't like that keying the cursor past the top or bottom of the window causing a large jump as the displayed region recenters around the point, but again, that's easily fixed.

>Only a handful of 3rd party packages use some badly-imitated pop-ups and I've never seen anything even resembling a pop-up in Emacs' graphical interface (maybe except the GTK+ open file dialog)

Most prompts (e.g., yes-or-no prompts, the password prompt for auth-sources) initiated with the mouse use pop-ups. Between that and the file chooser, what exactly is missing?

As for alerting the user that input is needed, Emacs doesn't generally require input from the user except when the user has just deliberately issued a command which requires input, in which case they don't need to be alerted (the one exception I can think of is when opening an auth-source may fail, and Emacs does use a pop-up for authorization then). What's more important in the long run is how easy the input method is to use, and unless you're already using the mouse (in which case Emacs does use pop-ups, as noted above), pop-ups are not easier to use.

>I can't see anything resembling the command palette Emacs' graphical interface. Everything is either use the minibuffer or open a new window.

The command palette looks a lot like helm-M-x to me.

>Speedbar isn't even close.

I didn't say it was. Now, I don't know about connector lines, but direx looks the same to me as Sublime's file tree sidebar and neotree even has icons.

> The real usability problem with Emacs' scrolling, in my opinion, is that the default scroll increment is too large. That's easily fixed. Some people also don't like that keying the cursor past the top or bottom of the window causing a large jump as the displayed region recenters around the point, but again, that's easily fixed.

You're right on spot with that one but I'm not sure it's that easy. I mean, I know there are some variables for it, but I'll try to explain with my anecdote. The scrolling issues you mentioned was felt so alien in my first try of Emacs, so it was the first thing I set out to fix in my second try. I found the relevant page in Emacs wiki, and damn, there was like 10 or more solutions, some similar, some not, each with their own issues (according to the wiki page, not that I've tried all). Then I went further with a Google search, and there was even more different solutions. As a result, I gave up on it and I still use the defaults even though I hate it with passion.

Setting a sane default for such a user facing thing must be top priority, not less.

> Most prompts (e.g., yes-or-no prompts, the password prompt for auth-sources) initiated with the mouse use pop-ups. Between that and the file chooser, what exactly is missing?

(I don't know what unfamiliar had in mind so I'll try to explain my own thoughts on the this.)

Things like search/replace/goto doesn't use pop-ups. But you're right that they don't need to, thanks for clarifying that. I was actually thinking about things more like dialogs rather than yes/no prompts. Again the window-centric approach I mentioned elsewhere in this thread. I don't have exact things in my mind, but yeah, command palette again. I would much prefer C-x C-b to show a dialog/popup which immediately gets focus, and in which I can either easily select the buffer or discard the dialog easily in case I change my mind. Or the About Emacs screen. I know it's not a functional thing but still one would expect it to show a dialog window instead of a buffer. Or the menu bar menus. I don't have a specific pain point with it but the whole thing still feels very odd. There is a lot of commands there, some are checkboxes, some fire up some prompts etc. I'm not sure but I guess some of them would be hidden under a dialog window in a more traditional gui application.

I don't think I'll be able to get more specific in this issue as it falls into the realms of "x feels better but I don't know why". The only thing I know is the extreme use of windows and buffers and it doesn't feel right. I'm sure it feels just right to Emacs veterans but as a newbie I can tell it doesn't to the rest.

> The command palette looks a lot like helm-M-x to me.

I've looked at it and it seems nice. Thanks.

>>Speedbar isn't even close.

> I didn't say it was. Now, I don't know about connector lines, but direx looks the same to me as Sublime's file tree sidebar and neotree even has icons.

I checked both of them and I'm sure none of them are what unfamiliar had in his mind when talking about "Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art." Both as ASCII art as it gets. Both are still rendered inside a buffer and they use a different font than the other gui elements in the system. The only different thing is neotree can display icons and that's all. Both are only marginally better than speedbar and they're joke when evaluated according to unfamiliar's criterias above.

> What I wouldn't say is fair, though, is characterizing something as incomplete and especially improper simply for being different from what you're used to.

I didn't tell them to offense Emacs fans, so sorry if you're offended. And the point is not being different from what I am used to, it's being different from what the rest of the world used to, only the Emacs users are accustomed to the Emacs convention of graphical ui's, and the way Emacs does it is not a proper gui in the sense that they invented their own conventions and they're different from every other GUI convention in the world. I'm not implying anything insulting here.

Incomplete GUI is another thing, yes, Emacs gui is incomplete because it does not use all existing GUI facilities and conventions to the full extent, and prefer existing Emacs ui facilities instead of gui toolkit's. Again, being incomplete is their choice, that doesn't mean it's a bad thing as I said in my previous comment (and a lot of people actually love it), but if you find that offensive I can't help with that.

I'm not offended or insulted by what you said. I don't even disagree with most of it, except maybe how you're using the terms "complete" and "proper." Saying that something isn't complete or proper generally really isn't compatible with a claim of impartiality.

I really have no problem with criticism of Emacs (provided that it's true, and now that you've expanded a little, I think what you're saying is true), but if you feel that familiarity (whether everyone's or just someone's) really sets Emacs and Sublime Text apart, call it criticism! :)

I'm happy I didn't offend anybody, then :).

I want to explain the terms again. First of all "not proper" or "incomplete" isn't the adjectives I've used for Emacs itself, but the GUI of Emacs. I did use proper in the sense of common GUI idioms and conventions, and I'm not a native speaker, so if you think that was not a right choice, you're probably right.

For the incomplete, again we are not talking if Emacs is complete or not, we are debating if Emacs is a "full gui app" or not, and since I don't think it is using gui facilities to full extent (and instead it just creates a basic gui window, shows some menus and prompt dialogs here and there, and then handles everything with it's own mechanisms like windows and buffers), it's not a "full gui app". Again, if you have a better word of choice for it than the words I chose, I'd be happy to accept them. Sorry it caused trouble more than it worth.