Life on the Command Line(lenz.unl.edu)
lenz.unl.edu
Life on the Command Line
http://lenz.unl.edu/2011/04/09/life-on-the-command-line.html
31 comments
Then why do I spend many seconds trying to find certain buttons that are right in front of me ("Where the hell did that ordered list button go?") and even longer trying to find buttons that aren't even there?
Terminal-based programs also do make use of color as well as white space and grouping. They do convey information visually. A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).
Terminal-based programs also do make use of color as well as white space and grouping. They do convey information visually. A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).
No one is arguing that guis turn you into some kind of unerring productivity robot instantly navigating through huge sums of interface magically.
The point is that well-designed GUIs can make better use of a large subset of the human brain. Poorly designed ones will not.
And, some tasks are so inherently visual that they're not even up for debate. For example, there simply is no opportunity for a command line tool to enable what Lightroom or Aperture enable. It's simply too visual a task.
The point is that well-designed GUIs can make better use of a large subset of the human brain. Poorly designed ones will not.
And, some tasks are so inherently visual that they're not even up for debate. For example, there simply is no opportunity for a command line tool to enable what Lightroom or Aperture enable. It's simply too visual a task.
Likewise, nobody is saying those kinds of tasks are served better by a terminal program. However, I would argue that adding an autocompleting command line to any of those kinds of programs would make them better, but that is a different point.
The core issue at hand is this: people should really look at the tasks they do and consider whether a command line interface could be beneficial for the task, they might likely be in for a very pleasant surprise if they try it.
The core issue at hand is this: people should really look at the tasks they do and consider whether a command line interface could be beneficial for the task, they might likely be in for a very pleasant surprise if they try it.
[deleted]
GUIs are great for getting responses from the computer. CLIs are great for telling the computer what to do clearly and effectively.
I want a command line that can draw the output graphically. I want a GUI that can be driven through text.
If anyone's ever used Rhino3d, it has a command line at the top of the window. That was probably the single most productivity boosting feature of the entire UI.
I want a command line that can draw the output graphically. I want a GUI that can be driven through text.
If anyone's ever used Rhino3d, it has a command line at the top of the window. That was probably the single most productivity boosting feature of the entire UI.
> A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).
A primary non-example is Ubuntu, where $PS1 is colorless, and `grep --color=auto` is not aliased to `grep`. It is the least user friendly distro if you use the command line.
A primary non-example is Ubuntu, where $PS1 is colorless, and `grep --color=auto` is not aliased to `grep`. It is the least user friendly distro if you use the command line.
It's not quite right to imply that because a command line isn't graphical it isn't using human visual recognition - we still see CLIs.
We still use colour and non-word markup to convey information in CLI programs, such as hashes at the start of lines to indicate headings, or line borders to indicate a 'button', or : to indicate a command, e.g. in VIM.
Many of us use it as if it was a hybrid system - a GUI display controlled by keyboard where possible.
We still use colour and non-word markup to convey information in CLI programs, such as hashes at the start of lines to indicate headings, or line borders to indicate a 'button', or : to indicate a command, e.g. in VIM.
Many of us use it as if it was a hybrid system - a GUI display controlled by keyboard where possible.
> […] gives the skilled UX designer the ability to convey a lot of information without making people think.
What if this is precisely the problem? My guess is that an environment that don't makes you think also tend to discourage learning. This would be sub-optimal in the long term.
More specifically, a GUI environment may be easy to manipulate at first, but if you need anything odd (but dead simple), then you have to find a program to do it for you, or do without it. The CLI, on the other hand, by forcing you to write your commands (suboptimal in the short term), gives you the idea that maybe, just maybe, you could write those 2 or 3 commands in a file so you don't have to type them every time. The next thing you know, you want to automate everything. And you can.
Even more specifically, take me. I use a laptop under Gnu/Linux (for serious work), and a Desktop under Windows (mainly for games and videos). I often download English subtitles for English or American films (I'm not a native speaker). But those subtitles often comes with annotations between brackets for the deaf (things like [Predator growling], [wind blowing]…). I want to get rid of them. That would be one line of sed… But it's for films, and therefore on my Windows desktop. Migrating it to my laptop is tedious, so I haven't written the damn script yet.
What if this is precisely the problem? My guess is that an environment that don't makes you think also tend to discourage learning. This would be sub-optimal in the long term.
More specifically, a GUI environment may be easy to manipulate at first, but if you need anything odd (but dead simple), then you have to find a program to do it for you, or do without it. The CLI, on the other hand, by forcing you to write your commands (suboptimal in the short term), gives you the idea that maybe, just maybe, you could write those 2 or 3 commands in a file so you don't have to type them every time. The next thing you know, you want to automate everything. And you can.
Even more specifically, take me. I use a laptop under Gnu/Linux (for serious work), and a Desktop under Windows (mainly for games and videos). I often download English subtitles for English or American films (I'm not a native speaker). But those subtitles often comes with annotations between brackets for the deaf (things like [Predator growling], [wind blowing]…). I want to get rid of them. That would be one line of sed… But it's for films, and therefore on my Windows desktop. Migrating it to my laptop is tedious, so I haven't written the damn script yet.
An environment shouldn't enforce thinking for the sake of learning. The average user will need to think enough to figure out what to do, they don't need brain-training puzzles as to how to do it.
Many GUIs fail to deliver in the long term, but it is not true in all cases. Take Adobe Photoshop for example; its interface is good enough in the short term to play around and intuitive so that the user can issue a very sophisticated command.
Graphical interface is a huge and blurry combination of science and art, and it still cannot solve every possible problem. Your subtitle editing case is specifically a command-line one - but there are good GUIs that can help you with search-and-replace in text files.
Many GUIs fail to deliver in the long term, but it is not true in all cases. Take Adobe Photoshop for example; its interface is good enough in the short term to play around and intuitive so that the user can issue a very sophisticated command.
Graphical interface is a huge and blurry combination of science and art, and it still cannot solve every possible problem. Your subtitle editing case is specifically a command-line one - but there are good GUIs that can help you with search-and-replace in text files.
> An environment shouldn't enforce thinking for the sake of learning.
I agree. However, I'm not sure the environment should bend over backwards to not make you learn. Probably depends on both the task at hand and the user. If only I could extract some generally useful heuristic…
Photoshop is an inherently graphical application, because (i) it works on images, and (ii) it is essentially an interactive program. If however I suddenly wanted to do automatic image processing, I would very much like to have access to some programmatic interface, most probably batch sub-programs that one could pipe together from the shell.
> Your subtitle editing case is specifically a command-line one
Yep. My point was, those cases exist, though I recognize the GUI is sometimes equally useful, if not outright superior. But the problem of GUI-only environments (and Windows specifically) is that if you don't even know what is a command line, you can't think of CLI tasks as CLI tasks. In my example, my first reflex was "sed", followed by "crap, Windows". On the other hand, a purely GUI user would have a "does a program does this?" reflex if he has any reflex at all.
GUIs make it very hard to combine programs. So in practice, they don't. They don't even tell the user about this concept. Instead, they tell the user that functionality is given from above. If no program does this, you're out of luck. I fear this contributes to the sense of helplessness of many users. CLI, on the other hand, quickly makes very clear that programs can be combined, that 5 lines scripts can be very useful. Sure, there will be a point beyond which one will need the help of a geek friend. But he would at least think of calling her.
Another point where GUIs easily fail hard is user customization. GUI programs tend to embed every functionality, leaving very little for external programs. For instance, Emacs or vi won't replace the built-in editing functionality of Thunderbird or Firefox (barring dedicated extensions). So I'm kinda stuck with the defaults.
I agree. However, I'm not sure the environment should bend over backwards to not make you learn. Probably depends on both the task at hand and the user. If only I could extract some generally useful heuristic…
Photoshop is an inherently graphical application, because (i) it works on images, and (ii) it is essentially an interactive program. If however I suddenly wanted to do automatic image processing, I would very much like to have access to some programmatic interface, most probably batch sub-programs that one could pipe together from the shell.
> Your subtitle editing case is specifically a command-line one
Yep. My point was, those cases exist, though I recognize the GUI is sometimes equally useful, if not outright superior. But the problem of GUI-only environments (and Windows specifically) is that if you don't even know what is a command line, you can't think of CLI tasks as CLI tasks. In my example, my first reflex was "sed", followed by "crap, Windows". On the other hand, a purely GUI user would have a "does a program does this?" reflex if he has any reflex at all.
GUIs make it very hard to combine programs. So in practice, they don't. They don't even tell the user about this concept. Instead, they tell the user that functionality is given from above. If no program does this, you're out of luck. I fear this contributes to the sense of helplessness of many users. CLI, on the other hand, quickly makes very clear that programs can be combined, that 5 lines scripts can be very useful. Sure, there will be a point beyond which one will need the help of a geek friend. But he would at least think of calling her.
Another point where GUIs easily fail hard is user customization. GUI programs tend to embed every functionality, leaving very little for external programs. For instance, Emacs or vi won't replace the built-in editing functionality of Thunderbird or Firefox (barring dedicated extensions). So I'm kinda stuck with the defaults.
Graphical interfaces by definition don't have a chance to communicate with each other, but I'd argue nowadays we have quite strong import/export functionality everywhere, so this problem disappears in most cases.
On another note, you're also stuck with defaults if you happen to use a badly written CLI (takes input from files only, etc).
On another note, you're also stuck with defaults if you happen to use a badly written CLI (takes input from files only, etc).
Given your first paragraphs about forced learning, your last one about how you don't know how to fix your problem in Windows so you just leave it broken is a strange contrast.
If the subtitles are plain text with annotations on their own lines, a one line command will strip them out:
If the subtitles are plain text with annotations on their own lines, a one line command will strip them out:
for /f "delims=" %x in subtitles.txt do @echo %x | @find /V "[" >> subtitles2.txt
That's just a cached thought: "Windows CLI sucks, don't even bother". In hindsight that sounds a bit silly. And I know Bash better (along with sed, grep, find…). Anyway, thank you, I'll try this command.
Nevertheless, I think there is a reason for my erroneous cached thought: the overwhelming emphasis on the GUI.
Nevertheless, I think there is a reason for my erroneous cached thought: the overwhelming emphasis on the GUI.
"What if this is precisely the problem? My guess is that an environment that don't makes you think also tend to discourage learning. This would be sub-optimal in the long term."
imo, we should be thinking about the task we are working on, not the interface we are using to accomplish our task, so the best interface is the one we don't even notice.
imo, we should be thinking about the task we are working on, not the interface we are using to accomplish our task, so the best interface is the one we don't even notice.
I recommend installing Strawberry Perl on Windows machines. It's a great substitute for sed, awk, etc. and is even as powerful as Perl. :)
Use of a computer shouldn't be a visual experience for most tasks. You have a mental model of what's going on, and then poke stuff to verify the model and to affect state.
But when users encounter complexity they'll look for their GUI tool to reach the right standard. GUI approaches don't scale well to complexity. You end up with industries surrounding successful GUI software to help people deal with what is now a constricting user interaction model.
There are other models to consider than GUI or CLI. The Bloomberg model offers discoverable, keyboard-driven interaction but nicely-formatted feedback. It's easy to teach too.
> However, teaching the average person to use a new
> piece of software is near impossible without
> utilizing their incredible brain power for visual
> recognition.
But when users encounter complexity they'll look for their GUI tool to reach the right standard. GUI approaches don't scale well to complexity. You end up with industries surrounding successful GUI software to help people deal with what is now a constricting user interaction model.
There are other models to consider than GUI or CLI. The Bloomberg model offers discoverable, keyboard-driven interaction but nicely-formatted feedback. It's easy to teach too.
GUI tools can scale well for complexity. Just look at how an experienced user can drive CAD or finalcut. It is just a matter of learning the interface, and understanding the domain it targets.
I would argue that the real hurdle to learning is accessing and understanding the documentation. In this respect CLI has the advantage with man pages. With UI the easiest way of understanding is to ask another human, which has obvious limitations.
I would argue that the real hurdle to learning is accessing and understanding the documentation. In this respect CLI has the advantage with man pages. With UI the easiest way of understanding is to ask another human, which has obvious limitations.
> Humans are visual animals, GUI's are a result of our evolutionary history.
Your example isn't really why GUIs are good. Yes, humans are great at navigating a GUI, however all four of those problems are introduced by the GUI to begin with. On a command line, you don't have to scan 1.3 million pixels. You learned where to look the first time you ever used it. You don't have to ignore anything, except maybe your scrollback buffer. You don't have to find any buttons. You don't have to identify a symbolic representation of the task at hand. You do have to know what you're doing, which I'll address later.
And those tasks are NOT done effortlessly. We may pretend it is, but frankly I have a huge problem with the clutter of my GUI. My brain gets tired, often without my realizing it, filtering out all the extraneous crap on my screen. I'm so much more productive with all that out of the way. I've taken to using compiz zoom to clear out all my tabs and taskbars and menus and of course ads and stuff so I can actually focus on the articles I'm reading.
But yes, you do have to know ahead of time how to do what you want to do. There is no representation to guide you, symbolic or otherwise, unless you know how to look for it. What the GUI actually does is the last sentence of your post: GUIs convey information. GUIs let people learn to use something as they go. Without a GUI, there is usually more of an up-front investment into learning how to use a tool. That people are good at navigating GUIs is incidental. People are good at using mechanical devices and language, too.
And as someone who has spent a significant amount of time helping people use windows applications, often the GUI doesn't even matter. They still have to get help to accomplish simple things, and often wind up completely misunderstanding what the GUI is trying to tell them.
> However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
It's not impossible. 20 years ago, before "UX designer" was even a word, plenty of average, non-technical employees used text-based and command-line systems to get work done. Students at my university had no problem using PINE on OpenVMS to read their email. People have the ability to learn command language and program motor memory. It's not even close to impossible.
But learning a formal language rather than a graphical interface is just sufficiently harder that having an easier-to-use GUI gives software vendors a competitive advantage. So in the last 20 years have GUIs have evolved a great deal, and are used even when they don't fully expose the power of the software they're providing, or fail to provide the user all the knowledge necessary to use the software effectively.
Your example isn't really why GUIs are good. Yes, humans are great at navigating a GUI, however all four of those problems are introduced by the GUI to begin with. On a command line, you don't have to scan 1.3 million pixels. You learned where to look the first time you ever used it. You don't have to ignore anything, except maybe your scrollback buffer. You don't have to find any buttons. You don't have to identify a symbolic representation of the task at hand. You do have to know what you're doing, which I'll address later.
And those tasks are NOT done effortlessly. We may pretend it is, but frankly I have a huge problem with the clutter of my GUI. My brain gets tired, often without my realizing it, filtering out all the extraneous crap on my screen. I'm so much more productive with all that out of the way. I've taken to using compiz zoom to clear out all my tabs and taskbars and menus and of course ads and stuff so I can actually focus on the articles I'm reading.
But yes, you do have to know ahead of time how to do what you want to do. There is no representation to guide you, symbolic or otherwise, unless you know how to look for it. What the GUI actually does is the last sentence of your post: GUIs convey information. GUIs let people learn to use something as they go. Without a GUI, there is usually more of an up-front investment into learning how to use a tool. That people are good at navigating GUIs is incidental. People are good at using mechanical devices and language, too.
And as someone who has spent a significant amount of time helping people use windows applications, often the GUI doesn't even matter. They still have to get help to accomplish simple things, and often wind up completely misunderstanding what the GUI is trying to tell them.
> However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
It's not impossible. 20 years ago, before "UX designer" was even a word, plenty of average, non-technical employees used text-based and command-line systems to get work done. Students at my university had no problem using PINE on OpenVMS to read their email. People have the ability to learn command language and program motor memory. It's not even close to impossible.
But learning a formal language rather than a graphical interface is just sufficiently harder that having an easier-to-use GUI gives software vendors a competitive advantage. So in the last 20 years have GUIs have evolved a great deal, and are used even when they don't fully expose the power of the software they're providing, or fail to provide the user all the knowledge necessary to use the software effectively.
it is a task done so fast and effortlessly by the human brain, that we don't even think about it.
It would be more precise to say those are the capabilities of one of the systems that comprise the brain. I think it's a mistake to lump the speed of perception in with the speed of cognition. To put it another way, pointing to the superiority of a gigabit ethernet connection is probably misplaced if it's connected to a microcontroller board running with a 5 MHz clock.
teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition
This is where I fear GUI enthusiasts often go astray: conflating everyday usage of software with the experience of people learning to use it. It is very useful to examine a light switch when you first encounter it, for example, but people quickly adapt to the common use case of flipping the lights on when entering a room without having to look at the light switch. Or in terms of the original article, most of the usage of a mail program is reading and writing messages -- an area where the advantages of icons, buttons, and menus are debatible.
BTW, CLI user are using their visual systems as much as GUI users are. CLI users are merely using a more structured format for their visual input.
It would be more precise to say those are the capabilities of one of the systems that comprise the brain. I think it's a mistake to lump the speed of perception in with the speed of cognition. To put it another way, pointing to the superiority of a gigabit ethernet connection is probably misplaced if it's connected to a microcontroller board running with a 5 MHz clock.
teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition
This is where I fear GUI enthusiasts often go astray: conflating everyday usage of software with the experience of people learning to use it. It is very useful to examine a light switch when you first encounter it, for example, but people quickly adapt to the common use case of flipping the lights on when entering a room without having to look at the light switch. Or in terms of the original article, most of the usage of a mail program is reading and writing messages -- an area where the advantages of icons, buttons, and menus are debatible.
BTW, CLI user are using their visual systems as much as GUI users are. CLI users are merely using a more structured format for their visual input.
Being able to script a program is amazingly powerful, but I find the reason I like terminal-based programs is primarily due to the interface. The interface of a terminal program (both command-line and interactive) is the keyboard, which is a vastly superior input mechanism than the mouse for most things.
Any thought that goes into the interface of a terminal-based program goes toward the keyboard interaction; there isn't a GUI to think about. Because of this, terminal-based interfaces are usually much better than any graphical application.
Any thought that goes into the interface of a terminal-based program goes toward the keyboard interaction; there isn't a GUI to think about. Because of this, terminal-based interfaces are usually much better than any graphical application.
As someone with a severe visual impairment, I use the command line as much as possible. It's easier to see and there is less I need to see. If I can type a command instead of having to hunt for a button, it means I can work that much faster and anything I'm looking at will be text, uncluttered, and high contrast.
From the command line, I can navigate the filesystem, install software, search, edit text, download files, play music, and send email all without even looking at the monitor. Once you're comfortable with it, you can just close your eyes and let your brain and your fingers do all of the work.
From the command line, I can navigate the filesystem, install software, search, edit text, download files, play music, and send email all without even looking at the monitor. Once you're comfortable with it, you can just close your eyes and let your brain and your fingers do all of the work.
The fundamental part of this isn't the CLI/GUI conflict, IMO, it's this paragraph:
For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool
The problem is people building standalone systems that aren't integrated with the whole. For example, most people's primary text editing environment doesn't carry over to their browser, or many GUI cases, their email program.
Solve this problem and the rest of the issues wouldn't be so severe.
For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool
The problem is people building standalone systems that aren't integrated with the whole. For example, most people's primary text editing environment doesn't carry over to their browser, or many GUI cases, their email program.
Solve this problem and the rest of the issues wouldn't be so severe.
I often write emails in Vim, then ggSHIFT-vSHIFT-g"+yALT-TAB CTRL-vTAB ENTER.
And that, my friend, is modern day integration between gVim and GMail on Windows.
And that, my friend, is modern day integration between gVim and GMail on Windows.
Had you used mutt instead of Gmail, you would have simply used: SHIFT-zSHIFT-z. When you want to compose mail in one of these programs, it opens your specified text editor and uses the whatever text you enter as the contents of your message. It works a lot like the 'Intents' feature which has been Android has received so much praise for, only it's decades old.
Actually, there's no reason for this to depend on the cli. In Firefox, there are plugins which give you a button to click under every text box which open your favorite text editor with a buffer already open containing the contents of the text box. Edit the buffer and save, and your changed appear in the text box. (This is, in fact, how I am editing this comment.) On Unix systems, a graphical mail program could easily use a shell call to get text from an external program. The only problem is, this just doesn't really happen. Vendors prefer proprietary interop with their own products rather than more universal interop methods.
Actually, there's no reason for this to depend on the cli. In Firefox, there are plugins which give you a button to click under every text box which open your favorite text editor with a buffer already open containing the contents of the text box. Edit the buffer and save, and your changed appear in the text box. (This is, in fact, how I am editing this comment.) On Unix systems, a graphical mail program could easily use a shell call to get text from an external program. The only problem is, this just doesn't really happen. Vendors prefer proprietary interop with their own products rather than more universal interop methods.
I'm not sure if you're saying that this shows the problem to be solved, or that it shows just how unsolved the problem is...
I've left that as an exercise for the reader.
Personally, I type the above sequence pretty much instantly, though, so... I don't mind: http://screencast.com/t/jw0LFrlBg
Personally, I type the above sequence pretty much instantly, though, so... I don't mind: http://screencast.com/t/jw0LFrlBg
I like.
It appears Google released a command line tool that integrates with its services: http://code.google.com/p/googlecl/
And it's awesome. When it came out, I immediately wrote half-a-dozen little things to work with it, including "whatson" -- an app that lets me do things like "whatson thursday" and have it show me what's on the calendar.
There is a Firefox extension that allows you to edit any text field with any text editor. I forget the name, but a quick Google search should reveal something.
Vimperator can do that. http://vimperator.org/help/vimperator/options.xhtml#%27edito...
"It's all text!", https://addons.mozilla.org/en-US/firefox/addon/its-all-text/
Maybe you should give VMail a shot (http://danielchoi.com/software/vmail.html). I haven't tried it yet, but it looks really interesting for someone used to the Vim keyboard bindings.
I did, it was fine but I totally forgot about it.
He gives the example of _nmh_ for email reading. I've been trying it out all morning. I think the stock _mail_ program seems to be better (although I use alpine on the CL). I need to do extra work to see gmail messages with _nmh_ (not with mail).
>mhshow: don't know how to display any of the contents > (content multipart/alternative in message 2)
Also, the _comp_ command for composing a mail launches vim (unable to stop that) which gives an error on what_next. I tried pico, that works.
Not sure _nmh_ is the way to go today. If I had to use the CL, I'd use _mail_ instead.
He gives the example of _nmh_ for email reading. I've been trying it out all morning. I think the stock _mail_ program seems to be better (although I use alpine on the CL). I need to do extra work to see gmail messages with _nmh_ (not with mail).
>mhshow: don't know how to display any of the contents > (content multipart/alternative in message 2)
Also, the _comp_ command for composing a mail launches vim (unable to stop that) which gives an error on what_next. I tried pico, that works.
Not sure _nmh_ is the way to go today. If I had to use the CL, I'd use _mail_ instead.
you've just shown the fail that is GUI.
alt tab and copy paste seriously?
command line mail clients dont need any of that. you edit it in vim and send it from vim. or you edit it from your email client THROUGH wim and send it also directly.
No utterly long key combo. No app switching. No delay. No complexity. No cut-and-paste.
That is the actual point.
command line mail clients dont need any of that. you edit it in vim and send it from vim. or you edit it from your email client THROUGH wim and send it also directly.
No utterly long key combo. No app switching. No delay. No complexity. No cut-and-paste.
That is the actual point.
I suppose this is what Apple had in mind with their object-oriented, drag-and-drop philosophy for the Mac: a GUI which would allow people to pipe things visually with as much ease as possible, reaching a compromise between the UNIX philosophy and their notion of software design as making things "magic."
Right now, the most impressive achievements (IMO, and YMMV) in that arena come from the Plan 9 community, which is still a far cry from lay person's usage (partly because the Plan 9 community seems to pride itself—as a rule—for being a research OS community rather than the next blockbuster OS).
Right now, the most impressive achievements (IMO, and YMMV) in that arena come from the Plan 9 community, which is still a far cry from lay person's usage (partly because the Plan 9 community seems to pride itself—as a rule—for being a research OS community rather than the next blockbuster OS).
I like that plan 9 has stayed out of the chase for users, but I do think the multi-button mouse interaction model needs to be updated to leverage touch-sensitive surfaces and gesture commands.
[deleted]
A nice essay on this topic by Neal Stephenson.
In the Beginning was the Command Line
http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.sht...
In the Beginning was the Command Line
http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.sht...
> When Ronald Reagan was a radio announcer, he used to call baseball games by reading the terse descriptions that trickled in over the telegraph wire and were printed out on a paper tape. He would sit there, all by himself in a padded room with a microphone, and the paper tape would eke out of the machine and crawl over the palm of his hand printed with cryptic abbreviations. (...) His listeners, many of whom presumably thought that Reagan was actually at the ballpark watching the game, would reconstruct the scene in their minds according to his descriptions.
> This is exactly how the World Wide Web works: the HTML files are the pithy description on the paper tape, and your Web browser is Ronald Reagan. The same is true of Graphical User Interfaces in general.
> This is exactly how the World Wide Web works: the HTML files are the pithy description on the paper tape, and your Web browser is Ronald Reagan. The same is true of Graphical User Interfaces in general.
Last year I decided to get back to basics and to dive into using emacs for as many things as possible. It's been extremely difficult and disorienting at times, but it has a non-quantifiable "feels right" quality to it.
I now find myself trying to do as many things as possible in emacs, but emacs + terminal + browser is extremely powerful. I'm not yet to the point of running a shell (elisp shell or otherwise) in emacs, but this troika is very powerful, and I'm extremely happy with it.
I now find myself trying to do as many things as possible in emacs, but emacs + terminal + browser is extremely powerful. I'm not yet to the point of running a shell (elisp shell or otherwise) in emacs, but this troika is very powerful, and I'm extremely happy with it.
what programs do you use to do things that emacs cant?
That, of course, depends on what you use your computer for, but in my case there are very few programs I don't run inside Emacs: a browser, a pdf and djvu viewer, Mathematica, and a media player. I do use other programs, but mostly run them within Emacs (they're LaTeX, several compilers and interpreters, and a shell).
supress emacs and itll feel right
Sent from my VIM.
Sent from my VIM.
Discovering Ctrl+r (for searching through past commands) was a big jump for me in CLI usability.
You'll also like this little bit I yanked from my .inputrc:
# By default up/down are bound to previous-history and next-history,
# respectively. The following does the same but gives the extra functionality
# where if you type any text (or more accurately, if there is any text between
# the start of the line and the cursor), the subset of the history starting with
# that text is searched.
"\C-p": history-search-backward
"\C-n": history-search-forwardDiscovering that you could so such things in .inputrc was a big lightbulb moment for me.
# not relevant on osx
#$include /etc/inputrc
$if Bash
# append a '/' to show a dir is a dir
set mark-directories on
set mark-symlinked-directories on
# no audible or visual bell
set bell-style none
# use ls -F style highlights for completion
set visible-stats on
# go right to showing multiple options
set show-all-if-ambiguous on
# ctrl-p cycles through options
"\C-p": menu-complete
"\C-x\C-x": exchange-point-and-mark
"\ew": copy-region-as-kill
# easier back and forth by word
"\C-b": backward-word
"\eb": backward-char
"\C-f": forward-word
"\ef": forward-char
$endif
# Two silly macros
#
# Insert double quotes & set cursor between them
"\C-x\"": "\"\"\eb"
#
# Insert single quotes & set cursor between them
"\C-x'": "''\eb"> # silly macros
I get shell access on one of my webhosting companies (DreamHost), so I scp data up to it a lot, but the path is a bit of a pain to type, except for this shortcut:
I get shell access on one of my webhosting companies (DreamHost), so I scp data up to it a lot, but the path is a bit of a pain to type, except for this shortcut:
# ctrl-d ctrl-h is a mnemonic for DreamHost
'\C-d\C-h': login@mysite:login/path/to/mywebsite/data etc.I did not know you could put conditions in inputrc. Useful.
I haven't gone to much further with it, but it is very handy: http://tiswww.case.edu/php/chet/readline/readline.html#SEC11
Better yet, from gentoo's /etc/inputrc:
More importantly, and what most people missed out is that, this history searching works on ALL command line interfaces, including bash shell, ipython, and psql.
Seriously, a command line advocate who doesn't know about this can't be serious.
# map "page up" and "page down" to search history based on current cmdline
"\e[5~": history-search-backward
"\e[6~": history-search-forward
More importantly, and what most people missed out is that, this history searching works on ALL command line interfaces, including bash shell, ipython, and psql.
Seriously, a command line advocate who doesn't know about this can't be serious.
And also, as I learned recently, gdb. That took me by surprise, until I realised that .inputrc does not contain settings for the shell, or any individual CLI program, but for readline.
Yeah, one of the many nice things about fish(the Friendly Interactive SHell) is that it does that automatically.
[deleted]
I've found myself using console applications more and more recently. The only GUI applications I use out of necessity are Firefox, Keepass and VirtualBox. I use the console for everything else: Cmus for music, Newsbeuter for news feeds and podcasts, TaskWarrior for to-do management, Vim for coding, etc. The Ratpoison window manager helps me make the most of screen space and allows me to manage my windows with keyboard commands like GNU Screen.
Unfortunately, I've never found an email client I liked, whether console or GUI, so I just stick to Fastmail's web interface.
Unfortunately, I've never found an email client I liked, whether console or GUI, so I just stick to Fastmail's web interface.
That's me right here. I love Ratpoison, although I think Evilwm is really good as well.
I never liked e-mail in Unix, as I feel the whole MUA/MTA thing is too complicated, so I stick with Gmail (which I backup with Fetchmail to a mbox file).
I never liked e-mail in Unix, as I feel the whole MUA/MTA thing is too complicated, so I stick with Gmail (which I backup with Fetchmail to a mbox file).
There's a problem with that, though: fetchmail won't notice state changes in your mailbox — like, whether an email is read or not, whether you've replied, forwarded it already, etc.
That's why I came to despise the MUA/MTA schism of Unix so much: If I reply to an email on my laptop, I won't know it on my desktop. The only solution is to have a central server you can ssh into. Clunky solution at best.
Solution: use Mutt's semi-new IMAP interface. Nothing is stored locally, and I can see whether I've replied to emails, and I can delete/move emails regardless of the computer I'm currently on.
That's why I came to despise the MUA/MTA schism of Unix so much: If I reply to an email on my laptop, I won't know it on my desktop. The only solution is to have a central server you can ssh into. Clunky solution at best.
Solution: use Mutt's semi-new IMAP interface. Nothing is stored locally, and I can see whether I've replied to emails, and I can delete/move emails regardless of the computer I'm currently on.
I only use e-mail via Gmail, so Fetchmail snarfs everything, even my replies. And another option would be Getmail.
VirtualBox does have a command line interface. You can start up headless images and such pretty easily. You could even start images with a VNC server, and control the machine from your browser. One less visual tool.
Oh, I should clarify, I don't use it as a server or anything like that. I have VirtualBox and a Windows XP image for any University work that requires Windows software. Right now that's, reluctantly, Microsoft Visual Studio.
And I wonder if KeePassX has a CLI. Its GUI current form is clunky.
The key advantages of a command line tool over a gui are power and flexibility.
There's any number of ways I can find and filter files using the find command, and then with xargs I can pipe them all through a sequence of simple operations.
In a typical gui file manager that kind of stuff is just not possible. The possibility space for what you can do is limited by the visual abstractions the original designer came up with for file manipulation. With command line tools that space is virtually infinite.
Often we consider the command line to be for expert users, and consider it our job as system designers to hide it from the rest. But when you consider that most people are able to learn basic calculus at school, a skill that has practical use in real life in only a limited number of professions, why don't we teach people to use the gnu tools at school? A skill that would enable them to use computers in powerful ways for the rest of their lives?
There's any number of ways I can find and filter files using the find command, and then with xargs I can pipe them all through a sequence of simple operations.
In a typical gui file manager that kind of stuff is just not possible. The possibility space for what you can do is limited by the visual abstractions the original designer came up with for file manipulation. With command line tools that space is virtually infinite.
Often we consider the command line to be for expert users, and consider it our job as system designers to hide it from the rest. But when you consider that most people are able to learn basic calculus at school, a skill that has practical use in real life in only a limited number of professions, why don't we teach people to use the gnu tools at school? A skill that would enable them to use computers in powerful ways for the rest of their lives?
"... In a typical gui file manager that kind of stuff is just not possible. The possibility space for what you can do is limited by the visual abstractions the original designer came up with for file manipulation. With command line tools that space is virtually infinite."
whilst i certainly agree with this, i would speculate that 80-90% of the average user's time is spent carrying out a handful of simple operations that are better catered for by guis. for the other 10-20% we have our virtually infinite space: the shell.
whilst i certainly agree with this, i would speculate that 80-90% of the average user's time is spent carrying out a handful of simple operations that are better catered for by guis. for the other 10-20% we have our virtually infinite space: the shell.
This, to me, is exactly the problem with most GUIs. If you're spending 80 percent of your time doing a handful of simple, repeatable operations, you might as well be using a typewriter. Programs that force you to work that way are the worst kind of chains.
But they are limited permanently and may spend hours doing things by hand that could take a moment. A common one is renaming photographs.
Because 90% of the population uses Microsoft Windows?
The biggest issue I have with the text-manipulation capabilities of the CLI is the inability to select text in the prompt with the keyboard. Shift+navigation buttons is standard to do this in GUI text boxes, but the CLI's slightly different notion of the cursor (box v. line caret) comes with the inability to select text keyboardly. How do others solve this problem? Are there e.g. readline replacements that have this capability?
This is why X allows you to copy text by highlighting it, and to paste text by middle clicking. The problem was solved a long time ago. Just grab the mouse and stop being a keyboard elitist.
aptitude install xclip
I map 'xc' to 'xclip' and 'xp' to 'xclip -o' (paste) with shell scripts.
Copy to/from clipboard via pipes.
Though X11 copy/paste works pretty well also. There are the odd occasions where a mouse is the right tool for the job.
I map 'xc' to 'xclip' and 'xp' to 'xclip -o' (paste) with shell scripts.
Copy to/from clipboard via pipes.
Though X11 copy/paste works pretty well also. There are the odd occasions where a mouse is the right tool for the job.
Besides using yank/paste keyboard shortcuts, you can always use screen or tmux copy mode. If you need the output of a command sent to the clipboard, there's several ways, xclip is one of them.
"I find the CLI to be faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible ... that’s a bold series of claims"
besides "easier to understand" (which depends on an individual's experience and knowledge) I thought those were pretty much acknowledged / obvious. Not bold at all.
no?
besides "easier to understand" (which depends on an individual's experience and knowledge) I thought those were pretty much acknowledged / obvious. Not bold at all.
no?
When I am using a Unix based system, there are three graphical programs that I use: X11, Firefox, and Feh. Everything else I do can be accomplished inside of a Xterm.
Do you only use mplayer with the aalib -vo option?
If you are talking about video, I don't play video on the computer.
Unless you keep the app open all the time (I’m assuming you do that because you have the focus of a guided missile), this is a program that you open and close several times a day. So why, oh why, does it take so much time to load?
This is why, even though I disagree with many of the things Apple is doing with the OS, I think Apple is on the right track with the app lifecycle model with Lion. Most computers ship with far more memory than people actually use these days; why should you constantly open and close apps when you can just leave them resident?
Most of the reason people even bother closing apps anymore has less to do with the resource-juggling that made it necessary in the past, and far more to do with workflow and window management.
This is why, even though I disagree with many of the things Apple is doing with the OS, I think Apple is on the right track with the app lifecycle model with Lion. Most computers ship with far more memory than people actually use these days; why should you constantly open and close apps when you can just leave them resident?
Most of the reason people even bother closing apps anymore has less to do with the resource-juggling that made it necessary in the past, and far more to do with workflow and window management.
I was confused with this part. People actually open and close their mail client several times a day ? Is it just closing the window or full app quit ?
For me and people I know, the mail client is the first app open after boot and it is always "open". It takes me less than 2 sec on my 3 year old computer to display new mail.
For me and people I know, the mail client is the first app open after boot and it is always "open". It takes me less than 2 sec on my 3 year old computer to display new mail.
I only check mail every few hours - when I need a break - and only actively correspond with people at the open or close of business. I don't have an open-door attitude at the office either.
A pure CLI is an arbitrary constraint on program design. CLIs and GUIs are not adversaries or mutually exclusive.
I see no evidence that designers are opposed to command interfaces given that many of the graphical programs I use incorporate them where appropriate.
The world isn't black and white. GUIs can be fast and pointing can be faster than typing. In other cases, a written command is fastest way to get exactly what you want.
I see no evidence that designers are opposed to command interfaces given that many of the graphical programs I use incorporate them where appropriate.
The world isn't black and white. GUIs can be fast and pointing can be faster than typing. In other cases, a written command is fastest way to get exactly what you want.
Keyboard is ideal for entering data, but GUI is superior to console for data output and visualization.
It would be perfect solution if all OS/applications would have command line but with visual output. Instead of "menu" at the top, just command line.
There some good modern approaches to this problem, for example gleeBox for control of internet browser is nice way of integration of console style control to GUI application.
It would be perfect solution if all OS/applications would have command line but with visual output. Instead of "menu" at the top, just command line.
There some good modern approaches to this problem, for example gleeBox for control of internet browser is nice way of integration of console style control to GUI application.
I never got into using mh, but have experienced a similar inversion when I switched to mpd, where what was a monolithic interface for playing music was replaced with a broad set of tools that center around the command line. It's exhilarating to enter that kind of environment, I found myself writing dozens of little utilities to control mpd in short order.
One thing I've never found is a decent spreadsheet program that'll run in curses.
Otherwise, terminal + browser gets me through 90% of the day.
Otherwise, terminal + browser gets me through 90% of the day.
Personally, I use R. Importing and exporting CSV files in R is trivially easy (it's what it's made for, after all). Doing transformations on an entire column or row at a time is also very simple.
Import a csv, then take the logarithm of one column and plot that against some transformation of another column? No problem - two lines in R, and still highly readable.
Import a csv, then take the logarithm of one column and plot that against some transformation of another column? No problem - two lines in R, and still highly readable.
I do all the things one might use a spreadsheet for in awk :-).
One might say it's slower then a spreadsheet. I don't know. I can type an one liner awk summation/average, faster then it takes OpenOffice to load. This is to me the most common spreadsheet operation.
For more complex task, I feel that I'm working faster in awk (it's a full blown high level programming language, after all). I'm not sure it it's actually faster or if it's only my opinion though.
I'm happy with this setup.
One might say it's slower then a spreadsheet. I don't know. I can type an one liner awk summation/average, faster then it takes OpenOffice to load. This is to me the most common spreadsheet operation.
For more complex task, I feel that I'm working faster in awk (it's a full blown high level programming language, after all). I'm not sure it it's actually faster or if it's only my opinion though.
I'm happy with this setup.
Financial consultant here. I use Haskell for this kind of thing.
In the event that I need a visual prototype to work with, together with a client or business partner, I don't think it's all that horrible to prototype something in Excel, and later port it to Haskell if necessary. But that's of course because I already, at some point, reinvented the wheel to make this possible. So now I'm mostly just reusing code which I already have available.
In the event that I need a visual prototype to work with, together with a client or business partner, I don't think it's all that horrible to prototype something in Excel, and later port it to Haskell if necessary. But that's of course because I already, at some point, reinvented the wheel to make this possible. So now I'm mostly just reusing code which I already have available.
Awk makes it trivially easy to parse text. How does Haskell handle this parsing task? I am curious because I've always wanted to learn Haskell, mainly because of its lazy evaluation, but hadn't had the time yet. Hope to do it soon.
Out of the box, it might not be the most intuitive text parsing tool indeed. It's trivial, but not immediately intuitive.
That said: strings are lists of chars, and Haskell is strong at pattern matching (esp within lists) in a bunch of different ways, so trivial text parsing tasks are trivial and intuitive in Haskell. For anything slightly more complex, there are regular expression and enumerating libraries which can do the job alright (and efficiently if I may say so).
EDIT: I'm sorry, can you give me an example of a problem so I can give you an example of a solution? :-)
That said: strings are lists of chars, and Haskell is strong at pattern matching (esp within lists) in a bunch of different ways, so trivial text parsing tasks are trivial and intuitive in Haskell. For anything slightly more complex, there are regular expression and enumerating libraries which can do the job alright (and efficiently if I may say so).
EDIT: I'm sorry, can you give me an example of a problem so I can give you an example of a solution? :-)
im using python for this. just cause its simple and it just works.
From what I have used of lotus123, it was quite a decent program. I'm sure you could find a lotus-inspired program somewhere.
Thanks for the tip. MacroCalc seems to fit the bill - http://www.freakout.de/#mc
[haven't tried it yet]
[haven't tried it yet]
Possibly Oleo[1] or Teapot[2]?
[1]: http://www.gnu.org/software/oleo/ [2]: http://www.syntax-k.de/projekte/teapot/
[1]: http://www.gnu.org/software/oleo/ [2]: http://www.syntax-k.de/projekte/teapot/
I end up using Python. In the end it's much more powerful and less error-prone (the oops factor of spreadsheet apps is ginormous). Quality plot, graph and stat modules abound.
Plus it has the advantage of being able to trivially scale in any direction, like refactoring or working on a real database (sqlite) when the dataset grows instead of shoehorning a database into a sheet, or making a module out of it, or integrating it with other random tools.
Plus it has the advantage of being able to trivially scale in any direction, like refactoring or working on a real database (sqlite) when the dataset grows instead of shoehorning a database into a sheet, or making a module out of it, or integrating it with other random tools.
[deleted]
[deleted]
[deleted]
There is always SC. And of course, Google Docs exists.
Tangentially related to post. Don Norman's essay on how command lines are better suited in a graphical world for various reasons. (of course a lot of us here feel this here already).
http://www.jnd.org/dn.mss/ui_breakthrough-command_line_inter...
http://www.jnd.org/dn.mss/ui_breakthrough-command_line_inter...
Most of the programs he describes aren't CLI programs but programs with a Terminal-based GUI.
A real CLI warrior uses sh, ed, and mail. :-)
A real CLI warrior uses sh, ed, and mail. :-)
Obligatory 'real programmers' links:
* http://www.pbm.com/~lindahl/mel.html
* http://xkcd.com/378/
* http://www.pbm.com/~lindahl/mel.html
* http://xkcd.com/378/
Every now and then I have similar complaints, but I don't think it boils down to cli vs. gui - the situation is actually far worse.
Building high quality productivity tools that are able to exceed the expectations of expert users is both difficult and time consuming... and there is almost zero market incentive to accomplish the task properly for consumer-class applications.
[edit] this is not to imply that consumer apps are trivial -- I think I once saw Minsky discuss an early attempt at AI that started by interpreting children's books, thinking that would be easier than understanding journal publications, etc. -- it quickly became clear that the task of parsing a children's story requires an immense store of implicit context and as such, was completely intractable at the time. The challenge of writing 'simple' things like email, text editing, and spreadsheet apps seems related to that.
Building high quality productivity tools that are able to exceed the expectations of expert users is both difficult and time consuming... and there is almost zero market incentive to accomplish the task properly for consumer-class applications.
[edit] this is not to imply that consumer apps are trivial -- I think I once saw Minsky discuss an early attempt at AI that started by interpreting children's books, thinking that would be easier than understanding journal publications, etc. -- it quickly became clear that the task of parsing a children's story requires an immense store of implicit context and as such, was completely intractable at the time. The challenge of writing 'simple' things like email, text editing, and spreadsheet apps seems related to that.
gui vs cli, interesting topic.
i used to use the command line for everything but recently switched to using guis.
switched mainly because gui applications seem nicer to me for completing common desktop tasks, for example listening to music, i can just click the rhythmbox applet and select a song as opposed to something like "mplayer ~/Music/some\ artist/some\ album/*" or manipulating files, it seems a lot nicer to me to be able to pull a file onto my desktop than type out (even with tab-complete) "mv foo ~/Desktop". ofcourse, there are exceptions when using a shell is much easier, for instance if i want to copy a large number of files whose filenames have some similar pattern.
it's also very nice to be able to install some new program and just use it, why should i have to read long poorly written man pages?
at the same time i still use a shell everyday, but as a programming/administration tool.
i used to use the command line for everything but recently switched to using guis.
switched mainly because gui applications seem nicer to me for completing common desktop tasks, for example listening to music, i can just click the rhythmbox applet and select a song as opposed to something like "mplayer ~/Music/some\ artist/some\ album/*" or manipulating files, it seems a lot nicer to me to be able to pull a file onto my desktop than type out (even with tab-complete) "mv foo ~/Desktop". ofcourse, there are exceptions when using a shell is much easier, for instance if i want to copy a large number of files whose filenames have some similar pattern.
it's also very nice to be able to install some new program and just use it, why should i have to read long poorly written man pages?
at the same time i still use a shell everyday, but as a programming/administration tool.
For music, you should try a proper music player, like MPD and ncmpcpp. It has a music database, playlists and all that stuff.
out of curiousity, does MPD/ncmpcpp make use of the shell? if it doesn't then i can't see how it'd be advantageous over a gui music player like rhythmbox
The nice thing about MPD is that it can be controlled by all the clients you want, and MPC (the default client) is excellent for scripting.
OF course, for manual control ncmpcpp - which is ncurses - is easier to use.
OF course, for manual control ncmpcpp - which is ncurses - is easier to use.
Same for me. For example, I like using git gui or tortoisehg when doing complex commits as those tools enable me to find, inspect and select all necessary files faster than typing a command for each file/task. For examining recent log entries or switching branches, pushing etc., I prefer the cli. For complex file tasks I use mc, which is a nice hybrid solution between a gui and a bare cli.
For git, have you tried tig? It has a nice ncurses interface for inspecting commits and doing all sorts of git related things.
Can any of these command line programs connect to Microsoft Outlook email servers? That's the number one problem: at many work places Outlook is entrenched and the Outlook UI is terribly outdated.
As long as Exchange is set up with the imap button checked, mutt works great. I don't know of an open source MAPI connector.
I wouldn't say "great" as far as IMAP goes, as Exchange gets horribly confused when there are multiple connections made to it.
That said, I find offlineimap is a better tool than mutt's built-in IMAP support.
That said, I find offlineimap is a better tool than mutt's built-in IMAP support.
nice example for living the command line idea:
https://addons.mozilla.org/en-US/firefox/addon/instantfox/
I prefer http://yubnub.org/. Yubnub also calls itself 'a command line for the web', but manages that without requiring an add-on
You can do that yourself what whatever site you wish by right-clicking on the search bar on any site an selecting "add keyword for this item".
As i commented over on that site, I wish we could have the best of both worlds. I'd like a UI that did a really good job of integrating command line and GUI features. Not something that just tacks them together. To do this you'd really have to think through the UI from scratch (and yes, I am interesting in trying this myself, but am currently working on other things).
When you think about it, the fact that command-lines are text-only is really just a historical artifact and it's nothing inherent to the notion of command-lines.
When you think about it, the fact that command-lines are text-only is really just a historical artifact and it's nothing inherent to the notion of command-lines.
I completely agree with this, and I'm glad that somebody's writing a series on how to be productive on the command line.
I find Neal Stephenson's 'In The Beginning Was the Command Line' to be a nice overview of why GUIs became the dominant paradigm over the CLI. I understand the desire to be 'user-friendly' to less tech-savvy people, but it's a real shame that we've equated 'functional' with 'has a good-looking graphical front-end'.
Even a few weeks after I began using the CLI (almost) exclusively, I couldn't imagine going back.
I find Neal Stephenson's 'In The Beginning Was the Command Line' to be a nice overview of why GUIs became the dominant paradigm over the CLI. I understand the desire to be 'user-friendly' to less tech-savvy people, but it's a real shame that we've equated 'functional' with 'has a good-looking graphical front-end'.
Even a few weeks after I began using the CLI (almost) exclusively, I couldn't imagine going back.
Most of the interesting GUIs today are web sites, which he uses...
Anyways, I think icons are overrated, and the text hyperlink rules the universe.
Anyways, I think icons are overrated, and the text hyperlink rules the universe.
Its a pity that he is so absolutely wrong about the bike for one of its main use cases: Traveling a reasonably long distance over terrain that is not perfectly flat. A bad analogy weakens what follows unnecessarily.
a bit off-topic, but IS there a command line music player that works the way he illustrates in the article?
mpd
I also just found out that "pianobar" is a cli for Pandora.com.
[deleted]
I resigned from a terminal IM client, because it made me less productive than a GUI client. Additionally, some features were annoying.
> Type pine or mutt (for example), and your mail is before your eyes in the time it takes a graphical user to move their mouse to the envelope icon. Type q, and it’s gone.
Not quite. I need to wait for "fetching message headers". It takes a while. mutt and IMAP.
> Type pine or mutt (for example), and your mail is before your eyes in the time it takes a graphical user to move their mouse to the envelope icon. Type q, and it’s gone.
Not quite. I need to wait for "fetching message headers". It takes a while. mutt and IMAP.
set header_cache="~/.mutt/hcache"
I have more than 10k emails sitting in my inbox and with this option mutt loads the headers in around one second (over the Internet).
And of course I could fetch all the emails in the background and use mutt locally, but I didn't bother yet.
I have more than 10k emails sitting in my inbox and with this option mutt loads the headers in around one second (over the Internet).
And of course I could fetch all the emails in the background and use mutt locally, but I didn't bother yet.
>I resigned from a terminal IM client, because it made me less productive than a GUI client. Additionally, some features were annoying.
Using mibbit or bitlbee with an IRC client works for me.
EDIT: Not mibbit, I meant minbif (http://minbif.im/)
Using mibbit or bitlbee with an IRC client works for me.
EDIT: Not mibbit, I meant minbif (http://minbif.im/)
+ 1 on bitlbee. I use it with weechat-curses.
IM was one of the last graphical applications to go for me (I'm the author of the article). I had the same problem until I discovered bsflite (http://bsflite.sourceforge.net/).
mutt is traditionally used together with a mail transfer agent (MTA) and other software to fetch the e-mail. mutt is only used for reading e-mail, not sending, receiveing or writing, there's other software for that.
There's POP, IMAP and SMTP support in mutt for convinience, but that has to be enabled explicitly at compile time. However, this means that mutt will fetch all the mails when it starts and this is slower than having it already locally fetched.
There's POP, IMAP and SMTP support in mutt for convinience, but that has to be enabled explicitly at compile time. However, this means that mutt will fetch all the mails when it starts and this is slower than having it already locally fetched.
I thought you would use (e.g.) sendmail to get the mail from the server to your local inbox, and then use pine or mutt to manage them?
[deleted]
<Quote>
</Quote>
The Human brain has estimated 2 billions nerves in the V1 & V2 region. Those regions are responsible for rudimentary visual recognition, of objects with different: Form (grouping, orientation, size), Color, Motion, Spatial position. This is one of the most powerful parallel computational systems known to men. It takes humans about 10 milliseconds to recognize an object standing out in those respects (e.g. gray text and one red word).
Why am I putting this down? / What are GUI's good for:
The whole thing took ~40 milliseconds and most importantly: it is a task done so fast and effortlessly by the human brain, that we don't even think about it.
Humans are visual animals, GUI's are a result of our evolutionary history.
I am not stating that GUI's are the fastest way to get the job done. You still have to move the mouse, etc. A skilled Command Line user can get the job done without a 40 milliseconds delay and moving the mouse might take longer than typing the command. However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.
Graying a button out, making it red, green,... gives the skilled UX designer the ability to convey a lot of information without making people think.