> 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.