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 >
