
How I'm still not using GUIs in 2019: A guide to the terminal - lucasfcosta
https://www.lucasfcosta.com/2019/02/10/terminal-guide-2019.html
======
plexicle
"Not every machine has VSCode, Sublime or Atom installed, but every machine
has a terminal."

I love that the article goes from this sentence immediately to:

"These are the main programs I use to make my terminal a complete development
environment:"

And proceeds to list 5 different programs, some of which are only available on
macOS.

Brilliant.

Edit: One of which are only available*. My point isn't that there isn't a
place for GUI and terminal, it's that "not every machine has x and y software"
is a fruitless argument.

~~~
rhinoceraptor
Using the terminal at least makes you proficient with the lowest common
denominator of tools.

I know I can SSH into any random machine, and edit a config with the copy of
vi/vim it has, even if it doesn't have my fancy plugins.

And if I get a new machine, all I have to do is install my tools via
Apt/Brew/etc, clone my dotfiles repo, and run an install script.

~~~
Faark
> I know I can SSH into any random machine, and edit a config with the copy of
> vi/vim it has, even if it doesn't have my fancy plugins.

The android phone I'm currently messing around with had neither vi nor vim...

Yes, knowing the lowest common denominator is great. But doesn't make a great
dev environment. OP is describing how to set up a customized one for exactly
that reason.

~~~
yjftsjthsd-h
Eh...it's not out of the box, but either busybox or termux will fix that in 30
seconds. The lowest common denominator is extremely portable.

------
olig15
I'm a game developer mainly writing/reading/debugging C++ on a codebase that's
well over a million lines of code. As with most game-dev I'm developing almost
entirely using Visual Studio, and I can't imagine trying to navigate code
using a terminal based editor.

Maybe it's just because this is what I'm used to, however I just don't see how
some of the tools would even be displayed in a terminal (parallel stacks
window, for example) without some horrible ascii node graph.

GUI's are definitely more than just bloat. Possibly not for what the author us
developing, but there is definitely a use for IDEs/GUIs.

~~~
dangom
What kind of navigation are you relying on that could not possibly work faster
on a terminal?

Horrible ascii graphs look horrible, but they are arguably more functional in
that you can navigate them with your keyboard.

~~~
lm28469
Navigation is rarely the limiting factor in development speed. I'd take better
auto completion / integrated tools over faster navigation every day.

~~~
TeMPOraL
I hope that language servers fully take off. This way, Vim and Emacs can gain
semantic autocomplete & navigation. To be clear: it's not that they _can 't_
have that in principle, it's just that engines for semantic operations are
difficult and expensive to write, so they were made primarily by IDE companies
- and until recently, it meant they were tied to those IDEs.

With that, the only remaining thing in which IDEs are a better choice than vim
or Emacs is debugging. I wish for decent and fully featured debugging TUIs.

~~~
NateEag
I've never been a big debugger user, but I thought if you like LSP, you might
be interested in Microsoft's analogous debugger protocol:

[https://code.visualstudio.com/api/extension-
guides/debugger-...](https://code.visualstudio.com/api/extension-
guides/debugger-extension)

I imagine Emacs, vim, and friends could implement their own frontends for
this, much as has been happening with LSP.

~~~
TeMPOraL
Wow, thanks!

And it turns out, Emacs and vim _do_ implement their own frontends for this -
[0], [1]. My wish just literally came true!

[0] - [https://github.com/emacs-lsp/dap-mode](https://github.com/emacs-
lsp/dap-mode)

[1] -
[https://github.com/puremourning/vimspector](https://github.com/puremourning/vimspector)

~~~
NateEag
Awesome - glad to be of assistance!

------
da_chicken
> _GUIs are bloatware._

This is only true, firstly, when what you're trying to represent can be
accurately, completely, and most concisely represented by plain text. That's
actually a fairly narrow range, unless you're a programmer. And secondly, it's
only true when you're not interested in using common interface conventions to
teach your users how to use your program. While that can certainly be done --
the -? and --help parameters spring to mind -- it's much easier when there are
UI guidelines [0] that everybody sticks to simply by virtue of how GUIs tend
to work (i.e., there are existing common libraries to describe the interface
in predictable ways).

If everything you do deals with text (i.e., you're a programmer), and you
never or rarely need to use unknown programs, then the terminal is great.

Think about it this way. Exactly what have you had to do to learn how to use
web pages? Like, since the 90s when Mosaic would still render most websites.
You haven't. It's point, click, scroll, and type. That user interface has
worked, essentially unchanged, for nearly 30 years. You've gone to brand new
websites, potentially written by people who don't speak your language, and
you've been able to use the site because there's a shared convention that
everybody uses. And _everybody_ does use it. There are _4.2 billion_ users of
the world wide web [1], and the interface works for essentially everyone.
That's an extremely impressive feat for interface design.

Meanwhile, nearly 50 years after vi was first introduced, it's still
notoriously difficult to learn -- even the basics. You might argue that
programming is more complicated than browsing the web, but realistically,
_editing a text document_ is about as basic a task that you can have on a
computer.

[0]: [https://docs.microsoft.com/en-
us/windows/desktop/appuistart/...](https://docs.microsoft.com/en-
us/windows/desktop/appuistart/designing-a-user-interface) [1]:
[https://internetworldstats.com/stats.htm](https://internetworldstats.com/stats.htm)

~~~
TeMPOraL
> _This is only true, firstly, when what you 're trying to represent can be
> accurately, completely, and most concisely represented by plain text. That's
> actually a fairly narrow range, unless you're a programmer._

You would be surprised. I encourage you to visit the lands of Emacs at some
time. The reason Emacs feels like an OS is because it turns out that _quite a
lot_ of tasks can be accurately, completely and concisely represented as text
on a 2D grid, and doing so enables interoperability features that are close to
impossible to achieve with GUIs.

> _And secondly, it 's only true when you're not interested in using common
> interface conventions to teach your users how to use your program._

Well, the difference between a tool and an educational toy is that the former
is optimized for productivity, not ease of learning. I'm not saying that
productive interfaces need to require a PhD to use; there are ways to make
user-friendly advanced UIs - but reducing functionality for the sake of just
easing the learning curve is optimizing for popularity, not utility.

> _it 's much easier when there are UI guidelines [0] that everybody sticks to
> simply by virtue of how GUIs tend to work (i.e., there are existing common
> libraries to describe the interface in predictable ways)._

Which no one gives a flying fuck about these days, because everything is web
driven now, and the no.1 rule of webapps is that everyone invents their own
variations of GUI, inconsistent with every other variation, and lacking any
interoperability.

> _Exactly what have you had to do to learn how to use web pages? Like, since
> the 90s when Mosaic would still render most websites. You haven 't. It's
> point, click, scroll, and type._

I think you're confusing lack of functionality with lack of learning need. You
have to learn to operate almost every website anew. There's just so little you
can do on a modern website with modern browser, that it doesn't feel like a
chore. Scroll, point, click. Oh, "weather forecast", click. Select city.
Click. Select date. Click. They're not even optimized for consumption - just
for ad exposure. Your typical experience with CLI/TUI is with tools optimized
for providing value to the user. You may need to spend some more time up front
figuring things out, but as a reward, you get much faster repeated access,
better data, better control over format, _only_ data you need and zero noise.
Is this for everyone? No. You do something once every year, point&click is
fine. Stuff you do regularly? Web is wasting your life.

> _You 've gone to brand new websites, potentially written by people who don't
> speak your language, and you've been able to use the site because there's a
> shared convention that everybody uses._

That shared convention - "use mouse to click on stuff" \- is about as deep as
the convention of "pressing buttons on keyboard types letters in". It doesn't
make you comprehend websites. It only limits the scope of your initial
confusion to "I don't need a keyboard for this (unless there are forms)".

> _nearly 50 years after vi was first introduced, it 's still notoriously
> difficult to learn_

It's not difficult. It's just people have been trained to have a strong
aversion to learning, where it comes to computers. Everything must be easier
to use than your hair dryer, or it's garbage.

To anyone who believes this, that vim is hard to learn: I ask you to do this
challenge. Fire up vimtutor, spend 10 minutes on it, report back whether it's
still hard.

\--

I may sound confrontational here, but it's really just out of care. Truth be
told, love of GUIs and the web, and allergy to CLI and TUIs is just reducing
your own power in using computers. If one has better things to do, that's
fair. But if one's spending a lot of time doing stuff on a computer, it's
worth learning to do it well.

~~~
soVeryTired
> To anyone who believes this, that vim is hard to learn: I ask you to do this
> challenge. Fire up vimtutor, spend 10 minutes on it, report back whether
> it's still hard.

I'm learning right now - as in, I started on Sunday. It's not hard to learn,
but it's hard to use effectively. I could edit code twice as fast if I
reverted to my standard keybindings, but I'm waiting for muscle memory to
build.

Learning isn't hard, but building muscle memory is a tonne of work. It's like
learning to touch type all over again.

~~~
jolmg
Yes, the more your resist that urge, the faster that muscle memory will
develop. It's even faster if you take a second to think of the most keyboard
efficient way to do things with vi-keybindings and doing that, resisting the
urge to use simpler keybindings. For example, `a` instead of `li`, or `A`
instead of `lllllllllllla`.

Another important point is that one should never try to move around in INSERT
mode. If you do, you're limiting yourself to moving around with the arrow keys
and also are grouping multiple edits that you may want to undo piece by piece
with u. If you need to move around, change to NORMAL mode and then move.

Yes, it's normal to hit Escape a lot. Personally, I like to have CapsLock act
as Escape with `setxkbmap -option caps:escape`. If I ever really want to write
something in all caps, it's always seemed faster to hold Shift with my left
pinky.

> It's like learning to touch type all over again.

A very apt way to put it. Touch typing is like learning a language for your
fingers. You do it once for your language (e.g. English), and now you're doing
it for vi NORMAL mode, which is basically a language for text editing and
navigation.

Like TeMPOraL said though, if you feel the frustration getting to you, you can
just relax however much you want, and take things at the pace most comfortable
to you.

------
estsauver
I always find the benefits of portability to be a rather funny one: It's
always immediately followed by 800 lines of dotfiles that do an incredible
amount of customization.

The IDE vs. vim/emacs purist debate is always crazy to me. There are some
places where IDE's are almost certainly better: Java in a large project in
IntelliJ has to be 100x better than in Vim. For new languages or languages
where there isn't substantial IDE integration, it's probably 5x better in
Vim/Emacs with a nice configuration.

~~~
brootstrap
Just wait for the vim guy who will be like "but muh java plugins make it more
efficient then IntelliJ"...

I think i am more productive in an IDE, faster. Sure if you have this insane
VI/EMACS setup that you have tuned for years. Good for you, you probably are a
fucking wiz.

My standard right now is a terminal & IDE combo. Working in the cloud era as a
data person, you need to be comfortable with terminal & vi/emacs (vi for me
but whatevs) as it makes life a ton easier. I hate watching co-workers do
terminal shit and write code. Seriously guys if you invest a little time into
VI pretty soon you are flying around your code. People literally watch my
screen and are like WTF are you doing. I feel like a surgeon with precise
incisions, cuts, tweaks. Compare this to spamming down arrow 30 times and then
right arrow 80 times to get to a character in your editor...

~~~
TeMPOraL
> _Sure if you have this insane VI /EMACS setup that you have tuned for years.
> Good for you, you probably are a fucking wiz._

To share a glimpse of the mindset of us on the editors side: that insane Emacs
setup I've been tuning for years enables me to be "a fucking wiz" not just
with Lisp. The very same setup lets me work efficiently with Python, Shell,
configs, SQL databases, HTML+CSS+JS, running a personal Wiki, organizing
tasks, tracking time spent on those tasks, billing customers for that time,
reading/writing mail, and a bunch of other things. We love our editors because
of compound interest - we get to reapply the same tricks to almost every task
done on a computer (and we complain loudly when we can't shoehorn a task into
editor-oriented workflow :)).

That said, I'll still grant you're better off with IntelliJ IDEA for Java. For
the time being, at least. I'm having high hopes for language servers trend -
they're the bridge that could enable vim and Emacs to reach feature parity in
all the places they're currently deficient compared to IDEs.

~~~
nickjj
> The very same setup lets me work efficiently with Python, Shell, configs,
> SQL databases, HTML+CSS+JS, running a personal Wiki, organizing tasks,
> tracking time spent on those tasks, billing customers for that time,
> reading/writing mail, and a bunch of other things. We love our editors
> because of compound interest.

I think that's really the takeaway here. Spending time in your environment
allows you to accumulate skills that let you solve pretty much any text based
problem you can think of.

Whether that's using emacs with elisp or vim with shell scripts and Unix tools
isn't important. It's having that playground of an environment to solve
arbitrary problems.

------
CivBase
> GUIs are bloatware.

Why stop there? Most terminal editors are bloatware!

 _" When I use an editor, I don't want eight extra KILOBYTES of worthless help
screens and cursor positioning code! I just want an EDitor!! Not a 'viitor'.
Not a 'emacsitor'. Those aren't even WORDS!!!!"_[0]

GUI and terminals both have their place. There is no single combination of
software that perfectly covers everyone's use cases. By all means, share
details about the environment that works best for you, but blanket statements
like that just create controversy.

Besides, modern terminals are really just GUIs designed to use the keyboard as
the only peripheral. You don't necessarily need a REPL interface to support
that use case.

[0]: [https://www.gnu.org/fun/jokes/ed-
msg.html](https://www.gnu.org/fun/jokes/ed-msg.html)

------
hyperman1
For me, things like VIM where you first have to configure the hell out of it
are a pain. Every time you're on some other machine, all your customization is
gone. So after switching machines a bazillion times over the years, making the
same little tweaks over and over, I've learned to deal with the default
config. What I didn't expect: It made me a lot more productive in the long
run.

~~~
jandrese
This is why defaults matter. People sometimes downplay changes with "well, you
can just tweak it if you don't like it", but in the long run tweaking the
install every time is effort. Especially when you're working on non-internet
connected machines. It's why I get annoyed when for example Ubuntu stops
shipping the ability to burn DVDs on the install disk.

~~~
zelos
The default vim config is pretty weird: incremental search is off by default
for some reason, I think it still defaults to using tabs for indentation, it
doesn't change the working directory to the current file's.

~~~
flukus
Incremental Search - This can be incredibly slow on large files and/or network
mounted files. It can also interact with line wrapping and highlight search to
slow vim to a crawl. So I think it makes sense to leave it off.

Tabs - That's the way god intended it. Stop trying to force your indentation
width on me.

Stable working directory - This is how every text editor I'm aware of works. I
can see use cases where you might want to change it manually or automatically,
but I don't want to have to guess which directory I'm in every time I open a
file.

Even some seeming no brainers like turning syntax highlighting on can be
terrible because it doesn't work well with dark backgrounds or other random
colour schemes.

------
jb3689
Title is a bit misleading. Not sure this is "I'm not using GUIs" but rather
"I'm using a terminal-based dev environment". I was hoping to find some nice
terminal-based tools for browsing and e-mail and all the other annoying real-
life things I need to use

~~~
zeveb
I use eww to browse simple web pages when programming, and notmuch-el to read
my email. For git I use Magit, and for Slack I use emacs-slack. As you might
imagine, that all runs within emacs rather than vim.

In my own case, emacs is running in a GUI frame most of the time, but I often
use terminal-displayed frames as well.

~~~
TeMPOraL
> _but I often use terminal-displayed frames as well._

Fun trick: if you run your terminal in 256 colors, the resulting terminal
frame is nigh-indistinguishable from GUI Emacs for like 95% of the tasks. This
works amazing over SSH, and allows me to work on heavy applications with full
productivity even on a bus, with el-cheapo netbook and a mobile connection.

(I really need to write a blog post about this.)

------
gambler
What are the chances that teletype simulation is the best possible way to
interact with computers? This is what command line emulates:

[https://www.youtube.com/watch?v=AIWZ_pbLYqQ](https://www.youtube.com/watch?v=AIWZ_pbLYqQ)

Yes, this was _way_ better than punch-cards. But it was incremental and used
completely arbitrary technology simply because it was available from somewhere
else.

UI as a concept was poisoned by Windows and its shitty derivatives.

Like, there is _no_ real reason you can't compose stuff when using GUIs. In
fact, it should be easier than pipelining commands.

There is no real reason the keyboard should be crippled by working in a GUI.
It should be _easier_ to learn commands. (But have you noticed that we still
don't have dedicated keys for cut, copy, pate, undo and redo? The most common
operations present in almost all applications. But we have a Windows key and
caps lock.)

Despite what people think, UI is still mostly unexplored territory with tons
of potential for improvement.

BTW, my favorite code editor isn't an IDE. It's LINQPad, because it gives me
immediate feedback without much noise. Going from it back to REPLs feels like
a downgrade.

~~~
JdeBP
"still don't have"? For many years we _did_. "no longer have" is more correct.

* [http://xahlee.info/kbd/i/kb/sun_keyboard_left.jpg](http://xahlee.info/kbd/i/kb/sun_keyboard_left.jpg)

~~~
gambler
You're right, I should have said "still don't have on PC". I believe Xerox
Star also had all those keys and then some.

This might not seem like a big deal for some. But there are two important
points to consider:

1\. A lot of inexperienced user still go to mouse menu for copy-paste. This is
horrible, but kind of natural, since a lot of UIs don't teach shortcuts.

2\. Cut/Copy/Paste/Undo/Redo should be treated as fundamental building blocks
of user interaction, not some "shortcut" that happens to do a thing. They
aren't even UI-specific. You can do all of them in a command line app
(although the semantics would much poorer).

When I saw the demo of Xerox Star on YouTube I was both enlightened and
depressed by the current state of things. Most people have no idea that icons
were supposed to be objects and that interacting with them was supposed to be
a way to send and direct messages to and between them.

~~~
JdeBP
I hope that the people who remember the OS/2 Workplace Shell have some idea.
(-:

------
going_to_800
Used Atom and other IDEs for 5 years. 3 years ago switched to vim + tmux and
love it. I'm very productive with my setup and I can't imaging going back.

I also love that I can git clone my dotfiles + an install script and I have my
full dev environment on any machine in 2 minutes.

------
tom_
You can always run a terminal alongside your IDE, you know! The IDE-type
approach is generally very convenient, making your day go past that bit more
smoothly, and the terminal is good for all sorts of things that are just a
faff to do with a GUI.

(Interop is straightforward: just save from the IDE, operate on the file from
the command line, then reload.)

This probably won't be to all tastes, but I've been happy working like this
for years.

~~~
jshevek
Before Android Studio, I found eclipse to be a laggy, buggy, slow-moving mess,
but still I relied on it heavily for a variety of functions.

I started using your solution out of necessity, but with a little bit of
context switching muscle memory found it to actually be a wonderful way to
code.

------
fxfan
terminals unfortunately are a complete no-go for "all" Asian languages.

to my knowledge right now no terminal emulator properly handles

* cjk- specially so called double width chars

* Indic- dependant vowels

* west asia- rtl

that's the entire breadth of Asia for you who cannot use terminals if hey want
to write a letter in their own language.

~~~
188201
With urxvt and hassle to install the correct font, it is doable to edit cjk
using vim. Though it is less usable than using English, since you have to go
back and forth to input cjk for input, and switch back to English for
navigation and vim tricks. Some binding like f[some cjk work] becomes
pointless since you are effectively typing f + (ctrl + shift) + (cjk word
input) + (Ctrl + Space). You would rather use nano for extensive editing cjk.
However, one or two words in cjk in some codebase is okay and not that bad.

------
xemdetia
I kind of wish this article was deeper on what benefits the OP was seeing from
the plugins or what have you. I just was left hoping for something more from
something that claimed to be a 'guide to the terminal' which usually is much
more in depth to a particular workflow and you can usually glean one or two
things you can add for yourself.

I'm from emacs land, and so generally using terminal over the emacs+GTK has a
lot of limitations (ex: can't display or embed images, no drag and drop, copy
and paste usually integrates better with the rest of the applications you are
using when selecting regions of textual data). On top of that emacs comes with
tiling for free where normally you would have to tmux+vim.

------
watergatorman
I generally agree with Lucas' sentiments re GUIs and in his other article "In
Praise of Plain Text."

But I currently select portions of text with a mouse by highlighting it, and
then execute programs that accept that selection as input.

I no longer am limited to entire text that would be written to StdOut or piped
or redirected and so could be treated as complete text files.

I can currently select and execute programs in a GUI in just 2 steps, using a
mouse.

Admittedly, I integrated the <program to execute> into the GUI, but it was
relatively simple.

To do this in Linux it looks like I would need to run a port of Plan9's Acme
or the Wily editor.

The port of Plan9 is way more than I need, so I will look at Wily.

Maybe there are some other Linux editors that will do what my GUI currently
does?

~~~
watergatorman
Answering my own question, Geany has "Sending text through custom commands"
and ability to add custom commands via "Send Selection to->Set Custom
Commands"

But it looks like this just replaces the selected text so it may be more for
formatting.

I prefer a new window to open so the selected text isn't altered.

I know I can program vEdit+ to do this, but that is not Linux.

~~~
watergatorman
You need to look at TUIs (Text User Interfaces).

------
majewsky
> To avoid the annoying seconds in which vIM would freeze during tasks like
> syntax-checks, neovim lets you run jobs asynchronously.

Vim 8 also has asynchronous tasks, as well as a builtin terminal emulator. So
there is not much of a reason to use Neovim (except Lua scripts, maybe?).

~~~
phailhaus
It's faster, which I discovered after switching to it for
Javascript/Typescript development. Also has better autocomplete plugins. Vim
plugins just don't seem to have taken advantage of the async features yet.

~~~
fwip
Most of the nvim autocomplete plugins work on vim too.

~~~
phailhaus
Not for TypeScript, and not as fast (in my experience).

------
frou_dh
I like command-lines. I don't like TUIs.

Here's the litmus test for whether a program truly belongs there: Would it
shit the bed if its stdout was a printer?

~~~
TeMPOraL
So you edit with ed? :). Also anything wrapped inside tmux would definitely
defecate if hooked up to printer.

Some jobs are interactive. TUIs ain't bad for those.

~~~
scarmig
That got to me brainstorming what someone might do if they were trying to
write a modern line editor, targeting developers writing in... maybe not Java,
but perhaps Go.

It doesn't seem like anyone has tried to build anything like that before. Most
recent seems to be Rob Pike's sam from the 1980s, which (at one time in the
2000s at least) was the professed favored programming tool by Brian Kernighan
and Bjarne Stroustrup.

~~~
jgtrosh
I have an intuition that any line editor would find its limits quite fast for
most existing code. (After having used ed a bit on regular files I came
across, it's often both surprisingly useful and surprisingly obtuse compared
with Vim.) Now, maybe a semantic structured language would find an amazing CLI
editor. I'm vaguely thinking something like a lisp, or something with tagged
structures. I guess the goal would be repurposing Vim's text objects to
generic programming structures. That's as much as I can muster right now!

------
Topolomancer
One of the most important take-aways of this article: you do not need tons of
plugins! I see this very often in motivated and bright developers who want to
start using `vim`. They copy a humongous config file, install tons of plugins,
and suddenly, something breaks or does not work as expected. In my opinion, it
is much better to start from scratch.

(besides, I have noticed a tendency in myself that is basically 'yak shaving
for vim': the more plugins you have, the more you have to work on their
configuration in order to make sure that they all work as expected...while
this _feels_ very productive, it is actually the opposite of productivity)

------
lucasfcosta
Hello everyone, thanks for all your feedback!

Regarding IDEs and bloatware: here’s a more detailed explanation of that
argument

[https://lucasfcosta.com/2018/08/05/In-Praise-of-
Plaintext.ht...](https://lucasfcosta.com/2018/08/05/In-Praise-of-
Plaintext.html)

They’re not _always_ bloatware, they have meaningful use cases, I just don’t
think most of them are in the domain of software engineering specifically.

I’ll take some time to go through comments in more detail at another time and
address them in the post if they’re relevant to the context.

Thanks again for all the amazing feedback.

------
robzhu
This is why I'm creating a command-line alternative to Photoshop.

~~~
jshevek
I once worked as part of a team which had graphics people who were allergic to
the command line.

Of course there are some things for which Gimp/Photoshop is really necessary,
but it turns out that there is a massive amount of image manipulation that is
better done on the command line than within Photoshop. The people who were
dependent on Photoshop would take endless hours completing the same tasks
which can be done in seconds using the command line.

------
Blaiz0r
I love using nvim as my daily editor, but one thing I get from posts like this
are that the authors rarely have to develop any kind of UI themselves, this
author states they work in JS, but it looks like it's backend node work.

I'd be interested to hear of any other stories from developers that use both
terminal for almost everything but also have to have a web browser open for
development.

The best I do is have my browser and my terminal open 50/50 on one screen, but
this isn't ideal, just a compromise.

------
cphoover
I'm one of the few people who agree with you. I'll bet I can do most things in
vim faster than intellicode or whatever the new hotness is.

~~~
farresito
Java in intellij+ideavim is much faster than in (n)vim, and that comes from
someone who has been using vim for nearly a decade. Intellij is just too good.

~~~
cphoover
Been using Vim for about the same length of time... And the times I have used
those emulators they just haven't been the same. Does the emulator support
VimScript? Macros? Plugins? async jobs like vim8?

The terminal is my IDE I can open a file with a couple of keystrokes, run bash
scripts from inside of my editor and just as easily be back navigating the
terminal.

Maybe I'm missing something, but I don't see how intellij improves any of this
stuff. I'd rather memorize compose-able bash commands, than intellij
keystrokes.

~~~
fiddlerwoaroof
What IntelliJ gives you is code generation and automatic refactoring to make
writing Java less tedious. That being said, the tradeoff is increased resource
usage.

~~~
lghh
> That being said, the tradeoff is increased resource usage.

Which for most developers in a corporate or small business environment is 100%
worth it. Not ever corporate developer has a nice enough computer to run an
IDE, but I bet that at least 95% do.

------
googleanalytics
For people using neovim, I've been impressed by this completion engine:

[https://github.com/neoclide/coc.nvim](https://github.com/neoclide/coc.nvim)

It uses Language Server Protocol and goes quite deep pulling completions, and
can, eg, render function documentation into floating windows (not yet merged
into neovim)

------
major505
Personally I reall like VScode debugger, and pretty much centered my workflow
around it.

Sure, is really usefull to learn the ropes when work from terminal, because
sometimes you will need to remote into a server.

Or even, as happened before, people will give me a shit machine to work from.
I was prograing in C/C++ in payment terminals (you know, credit card
machines), and they give me an old dell with only 4gb to work with.

The default environment was in Eclipse IDE, that usually fell bloated, and was
even worst in this pc. So I just installed vim, make a fell changes in the
.vimrc and I was read to go.

I fell things: I don`t really care about the whole h,j,k,l on vim. I see no
problemas in using the arrow keys. Maybe this was a problem like 20 years ago,
but now keyboards pretty much will always have the arrows, and they will work
just fine. If you use a keyboard with the arrow keys, I really think you like
to complicate things. Sorry, nothing personal.

------
nickjj
I think the biggest win for primarily using a terminal based environment isn't
because Vim or other terminal editors lets you write or edit code that much
faster.

Using command line tools and writing little scripts that you can easily
integrate into Vim or another terminal editor really helps you solve your own
problems that help make you faster at doing what you're doing. It really opens
you up to thinking about how to solve problems in new ways.

Things that might require writing a custom VSCode plugin where you simply
default to "fuck that" become chaining together 5 Unix commands and setting up
a Vim key bind to solve the problem in 15 minutes to do something that will
benefit the next 5 years of editing code or whatever you're writing.

~~~
wvenable
Of course, you can bind terminal commands to keys in VSCode (or virtually any
other environment) just as easily.

Personally I think these terminal vs. IDE discussions always revolve around
straw man arguments and mythical divides. I can chain 5 unix commands together
and use my IDE to navigate through code with my mouse. I don't have to choose
one or the other and then feel superior about excluding a whole branch of
technology.

~~~
nickjj
> Of course, you can bind terminal commands to keys in VSCode (or virtually
> any other environment) just as easily.

But what if those terminal commands need to interact with your editor?

How would you set up a simple VSCode key bind to take the currently selected
text, run a shell script using the selected text as input and then replace
your selected text with the output of the shell script?

With Vim, this kind of mentality is baked into how you work with the editor.
Even as someone who is very new to Vim (about a month) it only took a minute
of Googling to figure it out.

After having used Sublime Text for about half a decade, followed by VSCode for
a year I never even thought to do something like that either. I just took the
easy way out of thinking "yeah I'm not going to make a custom plugin for this,
I'll just settle for some worse implementation that someone else wrote that
does 75% of what I want". But just weeks after using Vim, I'm finding myself
adding all of these little customizations that are specific to things I do
every day. It feels like my editor is working for me, not the other way
around.

> I can chain 5 unix commands together and use my IDE to navigate through code
> with my mouse

I use the mouse in terminal Vim too. I don't really care about what purists
have to say. For certain things I find using the mouse easier, so I use it.

~~~
wvenable
This is what I mean about straw men and mythical divides.

Yes, there is a plugin to VSCode to do exactly that. But it doesn't matter.
Different software has different features and all features are possible
depending on what you care about. Vim is Vim. Vim doesn't have features
because of some GUI vs. command line distinction -- it just has different
features because it's a different product. Nothing stops a GUI IDE like VSCode
from having those same features. And nothing stops you from using GUI windows
and mouse in a desktop version of Vim.

~~~
nickjj
> Yes, there is a plugin to VSCode to do exactly that.

Which plugin does that? Link?

~~~
wvenable
[https://marketplace.visualstudio.com/items?itemName=yhirose....](https://marketplace.visualstudio.com/items?itemName=yhirose.FilterText)

------
ianstallings
This dead argument seems to re-animate itself once a year or so. But my
question is this: Why not learn both the IDE of your choice and how to use
your terminal/vim? No need to arbitrarily limit your own knowledge and
abilities. It just makes you stronger.

------
speedplane
The good development environments now-adays allow you to do everything from
the keyboard and not click on anything. PyCharm being a good example.

------
Improvotter
I want to give vim or emacs a real shot someday. I only really know the basic
stuff and am fine with it. But I feel like I really need very good integration
with the programming languages I work with like Go and Python.

Besides that, I'm looking forward to see when xi-editor [1] finally becomes a
stable alternative to VS Code among others.

[1]: [https://github.com/xi-editor/xi-editor](https://github.com/xi-editor/xi-
editor)

------
qwerty456127
I bloody wish there were a really good TUI toolkit for Python, something like
Visual Basic for DOS but with a bigger selection of more advanced widgets.

~~~
broken_symlink
What about ncurses?

~~~
qwerty456127
As far as I know it neither does window management nor provides widgets
(perhaps it can as Wikipedia says it's "added the form and menu libraries
written by Juergen Pfeifer" in 1.8.8 (M1995) yet there is not a single example
doing this with curses in Python), it just makes it slightly easier to build
your own TUI toolkit on top of it rather than without it.

I know about 3 Python TUI libraries available to the date: urwid, npyscreen
and picotui (the first 2 using curses and the 3-rd one not using it), neither
of them is anything nearly as good as any of the GUI framework I've ever
tried.

What I consider the best UI frameworks I've ever tried are WPF, WinForms,
JavaFX and Swing - if there was something nearly as convenient to use in
Python (or any other reasonably high level language, e.g. I don't mind JVM,
Common Lisp or Ruby) but rendering itself via curses I would hardly ever use
GUI as there would hardly be many valid reasons to besides watching/editing
pictures and videos.

Perhaps if there were a good text-mode web browser featuring full support of
modern JavaScript (which I believe is not really much work to implement for a
person with experience in the area as they wouldn't have to code the entire
JavaScript engine from scratch, all it probably takes is to attach V8 engine
libraries properly and/or implement the entire browser on Node, the problem is
this hardly has market value) we could use React, Angular or something. Many
of the console-dwelling hackers will probably consider this kind of thinking
profanity yet it's a fact most of the people (including those who could prefer
TUIs) don't have time to debug C code and implement low-level stuff.

------
coleifer
Narcissism of small differences. Pointless blogspam. Also, Neovim is much
closer to visual studio than it is to something like nano or whatever.

------
wj
Not specifically related to the article but related to the theme of the
article. I have a web-based dashboard that I created using a ruby gem called
Dashing that was created by Shopify but since discontinued. I'd like to use a
terminal based dashboard instead. Any suggestions?

I came across WTF but don't know Go or see any documentation about building
custom modules.

------
mrath
I am sure the author is a power user of his tools. I tried to use Vim for more
than a simple text editor for few days. I realised that it would very hard to
replicate the productivity of a special purpose IDE(IntelliJ in my case) using
Vim. tmux is great but if you are used to multiple windows or tabs that is
fine as well.

~~~
johnchristopher
After years of using Vim I gave up on the idea of using it as an IDE. It's
really powerful for editing (navigation, searching, etc) but I am too dumb to
do any debugging with it (xdebug, gdb, etc.). Too many panes, not enough
memory slots for shortcuts.

So I tend to use IDE with good support for Vim key bindings.

So VSCode these days and waiting for a good neo vim based IDE.

------
Spearchucker
The world moved from CLIs to GUIs. Guis have not only persisted, they've
improved. If someone insists on using a CLI and nothing else, after all these
years of the world having moved to GUIs, I wonder what prejudice is behind it.

How, reasonably, can all these tools beat a thing like Visual Studio? Must
limit job opportinities too...?

~~~
collyw
Some tasks are better suited to the command line. Others are better in the
terminal.

Package installation lies right in the middle for me. If I know exactly what I
want sudo apt-get install is the quickest and easiest. If I am not sure
exactly what I want its easier to browse around using synaptic.

I can do more complex greps on the command line than most GUI tools will allow
me to use.

~~~
godshatter
I tend to use apt-cache search a lot if I know generally what I want but don't
know the exact package name. It lets you use regular expressions when
searching and you can restrict it to just the package names by giving it the
--names-only switch.

If I'm actually wanting to install a game of some type, but don't know what I
want to try out, then I'll load up synaptic.

------
pulsarpietro
I mean .. use whatever you feel comfortable with, make sure you understand
what you're doing, the terminal is the closest interface to the OS.

I personally use it a lot but this arguments have been going on over (and
over)+ again. And it won't be the last time :-)

.

------
BlackLotus89
I got the feeling that articles like that are multiplying? And many of them
are using a Mac. Up until now I haven't seen anyone having a good setup with
text-browser, office-suite (not ide I mean libreoffi e for the tty), image
viewer (and I know there are quiet a few), pdf viewer,...

So imho it's a bit clickbaity calling this setup (which had nothing new as far
as I' m concernt) "still not using guis".

Maybe the dot files got something interesting...

Edit: Nope they didn't in fact hey are a joke a few alias, neovim, zsh and
tmux (mac specific stuff like brew I didn't look at) one "useful" thing
thought albeit not for me where the reference to xkcd 530 :)

------
huydotnet
Even your terminal emulator is a GUI app itself. Don't say you are not using
GUI app unless you boot to a command line interface directly.

------
amriksohata
I'm not being funny but why do people prefer writing out lines of command line
text versus right click and select in two clicks?

~~~
jshevek
For many people, writing out the command text is faster. Fantastically faster,
when you take advantage of the efficiency improvements like tab completion,
readline hotkeys, aliases, scripts, etc.

And you don't lose time from whatever you do before and after, by taking your
fingers off the keyboard.

~~~
amriksohata
With wireless mice you can move your hand nearer than they keyboard and even
with tab completion navigation between files is hard compared to just a couple
of clicks?

~~~
jshevek
No no, the problem isn't reaching across the desktop. The problem is literally
taking your fingers off of home row. It's fine if you're in a phase of your
activity where you're moving slowly, contemplatively. But if there's a series
of tasks that we want to accomplish and we already know what they are, lifting
your fingers off of home row will slow us down! Wireless vs wired mice have
nothing to do with this.

As far as what is considered to be hard, it depends on the individual.

For many of us that spend a great deal of time on the command line, many
multi-step activities, including those related to file manipulation, become
like a single action. Consider the difference between touch typing and hunting
and pecking. To an experienced secretary, the phrase "to whom it may concern"
can become a single action, executed by the fingers without any thought
whatsoever, while for an inexperienced typist that's 20 individual actions.
Similarly, a whole series of file manipulations, git actions, SSH actions,
become hardwired into our muscle memory and we don't even think about the
steps. We just decide that we're going to do something, and let our fingers
take care of it. This is much easier and faster then manipulating a GUI with a
mouse.

~~~
amriksohata
I would like to see data on this, any studies done?

~~~
jshevek
A healthy skeptic doesn't demand data for claims like "touch typing is faster
than hunt-and-peck".

~~~
amriksohata
A healthy skeptic? Lol what? Anyone who feels they have a point should be able
to back it up with sources or data

~~~
jshevek
No. Reality is not established by publication. You can, and should, observe
some things for yourself.

It is obvious that touch typing is faster than hunting and pecking for most
people who:

\- have 10 fingers

\- have invested sufficient effort to learn touch typing

To demand sources for this is disingenuous.

~~~
amriksohata
I can observe the sun is hot, but doesn't mean I can tell what temperature it
is. I think without data of timings across different applications and uses,
it's hard to prove either side. I am open to both sides having the possibility
of being quicker

------
ilaksh
Take a look at fish shell if you are in the terminal. It can almost read your
mind.

------
kgwxd
What's with capitalizing it vIM? Website, man page, :help, none of those have
it capitalized that way.

~~~
jolmg
Weird, right? You'd think it was a typo, but it was a very consistent typo.
Maybe they did it lowercase, then they `s/vim/vIM/`, hitting CapsLock and
Shift at the same time when they wrote that.

------
hydrogenglow
Dah, What's the point?

