5 ms·

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 i

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.

sjolsen 12y ago
>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.
- kasabali 12y ago
  > 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
  - sjolsen 12y ago
    >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.

sjolsen 12y ago

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

kasabali 12y ago
> 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
- sjolsen 12y ago
  >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.