3 ms·

>Though both vim and emacs have gui interfaces, most of the users use them inside a terminal. The overwhelming majority of developers edits in a GUI editor tho

>Though both vim and emacs have gui interfaces, most of the users use them inside a terminal. The overwhelming majority of developers edits in a GUI editor though, be it in Visual Studio, XCode, IntelliJ, Eclipse or Vim / Emacs / TextMate / ST2 etc. >You can wait till 22nd century, but as long as your definition of 21st century isn't the same as developers definition, not much is going to happen. I don't have to wait. Plenty of other developers live in your "22th century" and offer nice and functional native editors already. >BTW what century are terminals? Mid-20th century. I don't mind the terminal (I use one everyday and have done so since the day's Sun OS was SUN's offering), but it's also another technology stuck in the past. Not because of the textual nature etc. Because most of the components are crappy old time things, from terminal emulators to userland unix commands, etc. Bad support for millions of colors, bad support for Unicode, no support for a structured type (e.g JSON), ad-hoc implementations for lots of things given in the desktop. Where's a proper autocompletion in the shell that behaves like in a native app? Where's spell checking with wiggle lines? Only ZSH and Fish tried a few things to take us further, but still very short of what a desktop could be. I mean tmux/screen borking the scroll buffer? Is this 2013?

irahul 14y ago
> The overwhelming majority of developers edits in a GUI editor though, be it in Visual Studio, XCode, IntelliJ, Eclipse or Vim / Emacs / TextMate / ST2 etc. The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers. > I don't have to wait. Plenty of other developers live in your "22th century" and offer nice and functional native editors already. My comment about waiting was with respect to vim/emacs(as examples of other open source editors). You can wait till 22nd century; it probably still won't happen. Users are mostly happy; developers don't care. > Bad support for millions of colors, bad support for Unicode, My terminal(terminator) does that fine. > no support for a structured type (e.g JSON), ad-hoc implementations for lots of things given in the desktop. Why and how would a terminal support JSON? What are those ad-hoc desktop things? > Where's a proper autocompletion in the shell that behaves like in a native app? shell has to support autocomplete in million things, compared to your native app which only does one thing say Java. Whether shell offers completion or not depends on the external tool as well. You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>". > I mean tmux/screen borking the scroll buffer? Is this 2013? tmux/screen scroll buffers work fine. You are just making shit up.
- pretoriusB 14y ago
  >The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers. Way to fuck up the discussion in a disingenuous and insulting way by summing down my arguments to "I like shiny things". I specifically talked about native integration. That has myriads of aspects, of which "oh, shiny" is just an insignificant part of. As for the "overwhelming majority of vim/emacs" users using them in the terminal, citation needed. My anecdotal data tell me that they use them in both in both terminal and GUI form (terminal for working on stuff remotely, admin stuff etc, GUI for long term programming sessions). Plus, no matter what the "overwhelming majority of vim/emacs" do, those do not represent the future or cutting edge of programming editor use in any conceivable way. And that is precisely what we are discussing. >bad support for Unicode >>My terminal(terminator) does that fine. Does that answer mean that you don't have the mental capacity to follow the discussion? Maybe you're too tired or something? Isn't it obvious from my comment that I mean Unicode support THROUGHOUT the system? That one or ten terminals has got it doesn't mean a thing if there are 200 other components involved in doing unicode CLI work. For example GNU/BSD unix userland programs supporting full unicode capabilities. Unicode and font-rendering without X-running, etc etc. >Why and how would a terminal support JSON? What are those ad-hoc desktop things? What is this stupid notion that I talk about terminal emulators ONLY? I specifically bloody state that I complain about all terminal-side stuff "from terminal emulators to userland unix commands". In this case, what I ask for (when giving JSON as an example) is a structured way of communication between userland commands, to go beyond '70s style pipes. Microsoft's Powershell AFAIK has some of that built-in. >shell has to support autocomplete in million things, compared to your native app which only does one thing say Java. You'd be surprised. And context-sensitive autocomplete is so solved that it's not even a problem... >You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>". See how luck of imagination and blind acceptance of what's there cripples programmers? Off the top of my head: programs could come with definition files for their autocompletion. Adding a program adds those to your shell (in the same way programs come with man-pages). I seriously hope you don't work in R&D. >tmux/screen scroll buffers work fine. You are just making shit up. Only if "switching in copy-mode to scroll, instead of transparently incorporating the terminal scroll buffer" fits your definition of "fine".

irahul 14y ago

> The overwhelming majority of developers edits in a GUI editor though, be it in Visual Studio, XCode, IntelliJ, Eclipse or Vim / Emacs / TextMate / ST2 etc. The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers. > I don't have to wait. Plenty of other developers live in your "22th century" and offer nice and functional native editors already. My comment about waiting was with respect to vim/emacs(as examples of other open source editors). You can wait till 22nd century; it probably still won't happen. Users are mostly happy; developers don't care. > Bad support for millions of colors, bad support for Unicode, My terminal(terminator) does that fine. > no support for a structured type (e.g JSON), ad-hoc implementations for lots of things given in the desktop. Why and how would a terminal support JSON? What are those ad-hoc desktop things? > Where's a proper autocompletion in the shell that behaves like in a native app? shell has to support autocomplete in million things, compared to your native app which only does one thing say Java. Whether shell offers completion or not depends on the external tool as well. You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>". > I mean tmux/screen borking the scroll buffer? Is this 2013? tmux/screen scroll buffers work fine. You are just making shit up.

pretoriusB 14y ago
>The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers. Way to fuck up the discussion in a disingenuous and insulting way by summing down my arguments to "I like shiny things". I specifically talked about native integration. That has myriads of aspects, of which "oh, shiny" is just an insignificant part of. As for the "overwhelming majority of vim/emacs" users using them in the terminal, citation needed. My anecdotal data tell me that they use them in both in both terminal and GUI form (terminal for working on stuff remotely, admin stuff etc, GUI for long term programming sessions). Plus, no matter what the "overwhelming majority of vim/emacs" do, those do not represent the future or cutting edge of programming editor use in any conceivable way. And that is precisely what we are discussing. >bad support for Unicode >>My terminal(terminator) does that fine. Does that answer mean that you don't have the mental capacity to follow the discussion? Maybe you're too tired or something? Isn't it obvious from my comment that I mean Unicode support THROUGHOUT the system? That one or ten terminals has got it doesn't mean a thing if there are 200 other components involved in doing unicode CLI work. For example GNU/BSD unix userland programs supporting full unicode capabilities. Unicode and font-rendering without X-running, etc etc. >Why and how would a terminal support JSON? What are those ad-hoc desktop things? What is this stupid notion that I talk about terminal emulators ONLY? I specifically bloody state that I complain about all terminal-side stuff "from terminal emulators to userland unix commands". In this case, what I ask for (when giving JSON as an example) is a structured way of communication between userland commands, to go beyond '70s style pipes. Microsoft's Powershell AFAIK has some of that built-in. >shell has to support autocomplete in million things, compared to your native app which only does one thing say Java. You'd be surprised. And context-sensitive autocomplete is so solved that it's not even a problem... >You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>". See how luck of imagination and blind acceptance of what's there cripples programmers? Off the top of my head: programs could come with definition files for their autocompletion. Adding a program adds those to your shell (in the same way programs come with man-pages). I seriously hope you don't work in R&D. >tmux/screen scroll buffers work fine. You are just making shit up. Only if "switching in copy-mode to scroll, instead of transparently incorporating the terminal scroll buffer" fits your definition of "fine".