Speaking as a terminal addict, I can confirm that I feel infinitely more productive where single-key shortcuts are burned into my brain.
It's true: it takes practice to get used to, but once you've grokked with a shell, you'll understand what true flexibility really is. > Am I the only one who finds that text at a terminal emulator with a > well-chosen monspaced font and good contrast is much, much easier > to read than a graphical representation of the same text (e.g. in a > browser or pdf viewer)? Nope, same here! I even augmented <https://github.com/Alhadis/Menloco> my preferred typeface so its box-drawing characters joined together seamlessly. :-) It looks ace: http://imgur.com/a/DFOQz On 26 August 2016 at 03:15, Russell Hyer <russell.h...@gmail.com> wrote: > That's lucky, still being able to define your environment, I've been > fighting my translation agency to help me actually submit a > translation for a customer (they have a new-fangled GUI that doesn't > work) that a 2-second upload button would solve in under 2-seconds :) > > But, yeah, for most real things, I'm a paper/terminal person. When > things get really messy, that's when you need abstractions like > functions, or objects, or other kinds of abstractions, but being > forced to use someone else's abstraction (ie: one without access to a > programming interface/language) is like not having an interface but > whatever the word is for an interface with swear words attached :) > > Happy hacking, > > Russell > > On 25 August 2016 at 17:39, Peter Schaffter <pe...@schaffter.ca> wrote: > > On Thu, Aug 25, 2016, Tadziu Hoffmann wrote: > >> > Yes, but who is still working with a text terminal? > > > > I, for one. Excluding composing music, 90% of everything I do at > > the computer is done in a terminal emulator. > > > >> Do we do this because we're dinosaurs, too set in our ways > >> to adapt to a new workflow? I prefer to think it's because > >> the shell has proven itself to be a tool of unparalleled > >> power when dealing with unexpected situations. > > > > Precisely. When you combine the unparalleled power with the > > knowledge to use it, the shell provides a better interface for many > > tasks than a GUI. "Better" meaning more efficient, more complete, > > more flexible, more powerful. And faster. Way, way faster. > > > >> > Today most of those features have been subsumed by the GUI. > >> > Different applications have different windows, different > >> > fonts, graphics, all resizable. We have a potpourri of UI > >> > gadgetry barely imagined in those days. Yet the emulator > >> > remains as muscular and complex as ever, > >> > >> Exactly. Things that are better handled by a GUI have been > >> taken over by GUI programs, > > > > This is true. Some activities are better handled by a GUI, others > > are better handled at the command line. For example, if I want to > > delete selected files from a directory and the filenames can't be > > globbed, it's easier to select and delete them by clicking in a > > GUI. OTOH, if the filenames can be globbed, it's more efficient to > > do it from the command line. > > > > The issue, ultimately, isn't whether CLI is superior to GUI, it's > > that using the command line requires study and practice. I'll go > > out on a limb here and say that anyone who dismisses CLI as obsolete > > is speaking from ignorance of the shell. > > > >> > Sadly, for all the advances, documentation has hardly budged, > >> > if indeed it's advanced at all. Even though a good deal of > >> > it is maintained in typeset form, the output predominately is > >> > confined to the application with the poorest text rendering > >> > capability: the VT-100 emulator. > > > > Am I the only one who finds that text at a terminal emulator with a > > well-chosen monspaced font and good contrast is much, much easier > > to read than a graphical representation of the same text (e.g. in a > > browser or pdf viewer)? > > > >> That's not entirely true. It's usually command-line tools > >> that are documented by manpages, and that may be seen as a > >> natural extension of their modus operandi (i.e., accessible > >> from the shell). Many complex interactive GUI applications > >> have no manpage at all (or only a short one listing the > >> available command-line switches) -- but there may be a > >> builtin help system or even entire websites with hundreds > >> of html pages describing the program's operation. > > > > You're not refering to the mom documentation, are you? :) > > > > Levity aside, I wrote the mom documentation in html because > > groff_man(7) wasn't the right tool for the job. I also paid > > attention to how the html rendered in a terminal browser, for the > > legibility reason I mentioned above. > > > > Manpages are the ideal documentation format for programs controlled by > > options at the command line, but are deeply ill-suited to longer, > > more complex documentation. The mom macros do have a manpage, but I > > did not write it and I don't maintain it because, frankly, it isn't > > helpful and no one seems to use it. Helpful manpages do exist for > > groff itself and for pdfmom(1), both of which are invoked at the > > command line with options. So, while not a "complex, interactive GUI > > application", the macroset displays the ideal arrangement you've > > outlined: manpages for CLI invocation, and separate documentation > > for the "program" itself. > > > > -- > > Peter Schaffter > > http://www.schaffter.ca > > > >
