Re: [dev] Screencasts?

From: Charlie Kester <corky1951_AT_comcast.net>
Date: Mon, 10 Mar 2014 09:29:16 -0700

On Sun 09 Mar 2014 at 12:54:11 PDT Caleb Malchik wrote:
>
>I switched to Linux/cli/dwm from OS X just a few years ago, and since
>the switch I feel the way I do certain basic things is embarrassingly
>inefficient. For example, if I find an article on the web I want to
>come back to, I will copy the URL from the address bar, open a
>terminal window with ctl-shift-enter, type 'vi doc/toread', then
>paste the URL
>at the top of the file. Yes it's still faster than what I would have
>done on OS X, but it feels clunky.
>
>I know enough to come up with my own fixes for a lot of these
>inefficiencies, but I wouldn't be confident that such fixes are
>sensible, and that there isn't a simpler and functionally better
>solution. And the amount of documentation I would have to read to be
>confident that my own solutions are sensible seems overwhelming.

I'm not going to go down the screencast rathole. Instead, I'll simply
point out that the steps you described are scriptable.

Find out how to get the current url from your browser in a script.

Also how to add a line to the beginning of a file (adding it to the end
is easier.)

If your browser doesn't support a custom hotkey you can use to invoke
your script, create one at the system level. The latter choice will
probably require you to find a way to identify and query the running
instance of the browser.

If your browser doesn't support any of this, or if it makes it too
difficult, you might want to count that as a reason to drop it in favor
of one that is more tractable. (Try surf, or uzbl!) That's probably the
best way to evaluate software: does it allow you to quickly knock
together solutions to accomplish custom tasks like this?

The Unix philosophy is that the software which best supports this kind
of ad hoc programming is software that is simple: designed to do one
thing and do it well. But it's also software that is *composable*. If
you seek out and use software that reflects this philosophy, you'll get
the kind of efficiency you want almost automagically.

But beware the siren song of ultimate efficiency! The Unix approach
isn't about achieving perfection, it's about getting the job done. And
that means good enough is usually good enough.

Pay attention when things seem too slow or, in your words, feel too
clunky. That's telling you there's a rough edge you need to smooth
down. But once it's fixed and no longer bothering you, there's really
no need to go on fussing over it.

The idea that someone else might have found a more 'sensible' or more
elegant solution should only concern you if what you've put together on
your own still doesn't feel right.
Received on Mon Mar 10 2014 - 17:29:16 CET