[NCLUG] [OT?] Vimium on Chromium on FreeBSD

Chad Perrin perrin at apotheon.com
Fri Nov 5 22:42:50 MDT 2010


On Fri, Nov 05, 2010 at 08:52:40PM -0600, Bob Proulx wrote:
> Chad Perrin wrote:
> > Bob Proulx wrote:
> > > Chad Perrin wrote:
> > > > What would you use for Back and Forward in browser history instead
> > > > of H and L?
> > > 
> > > I switched them with J and K since to me the forward and backward in
> > > history is mentally more of a stack-like queue.  Up (goBack) and Down
> > > (goForward) fit me better.  YMMV.
> > 
> > I tend to think of it as left to right -- because that's how the tabs are
> > visibly arranged, I guess.
> 
> Tabs are not history forward and back though.  Tabs are left and right
> across the top of the browser.  So using left (H) and right (L) for
> tab-left and tab-right make sense to me.  But history forward and back
> and can't be seen on the screen.  So those keys are arbitrary.  They
> could be anything since there isn't positional information on the
> screen display for them.

Oops.  I think I lost track of the topic I was addressing, thinking I was
talking about tabs when I should have been talking about history.

In the case of history, I tend to think of it as left and right --
probably because the arrow buttons on the browser point left and right,
and browsers and Webpages both tend to call the operations of moving to
earlier and later points in the browser history "back" and "forward".

I guess it would more properly be toward me and away from me, starting
from the screen, but those directions are not represented very well in
the browser.

> 
> > Sorry, I don't know of a quick fix for your highlight-and-delete problem.
> 
> I do.  This solves it well enough.  Now that it is working again.
> 
> cat > ~/.gtkrc-2.0 <<EOF
> gtk-key-theme-name = "Emacs"
> EOF
> 
> And then the key style is back to the traditional MIT X model.

Err . . . does this work in the browser?


> 
> > Are you sure that Ctrl Z (undo) won't work for that on MS Windows?
> 
> You are right.  It does work.  I learned something useful today.  I
> wonder if it didn't work in the past when I first ran into it.  (That
> is my story and I am sticking with it.)

I'll take that as an explanation, I guess -- since I would find it
difficult to travel back in time to test it.


> 
> > I'm pretty sure that CUA was specified (and named) by IBM, though
> > Microsoft may well have had input into the process, and uses the heck out
> > of it.
> 
> Wikipedia seems to agree that it was developed by IBM.
> 
>   http://en.wikipedia.org/wiki/IBM_Common_User_Access
> 
> But it lists
> 
>   The Cut command is Shift+Del; Copy is Ctrl+Ins; Paste is Shift+Ins;

I guess MS Windows diverges from the standard a little bit.  Why am I not
surprised?


> 
> > > Code bloat and creeping features is the biggest threat that I see.
> > > For example right now there is a discussion in two different
> > > Debian mailing lists about a base Squeeze installation not fitting
> > > into a 512M partition.
> >
> > Holy cow.  It *has* grown since I stopped using it regularly.
> 
> It is the problem of "The Camel in the Tent" or "If you give a mouse a
> cookie..."  People are always wanting just one more option to 'ls'.
> Or wanting just one more feature to 'cp', as if 'rsync' doesn't have
> enough to go around for everyone plus a few.  Multibyte character
> support and locales are good but costly.  Everything has just
> incrementally grown slowly over time.

There are those who would say this all started with the -v option for the
cat command (speaking of the nose of the camel in the tent -- or at least
the nose of the cat).  I tend to agree with them, in that each tool
should really be designed to do one thing (and do it well).  When you
start letting it do more than one thing, you end up with a problem.

Those extra "features" are really the reason we have stuff like pipes and
redirects.  If you want to do other stuff with your data, pipe it to a
utility that does that other stuff as part of its core purpose; don't add
another unnecessary feature to the tool.


> 
> Of course Firefox isn't in the bare base installation but it provides
> too good of an example to pass up.  Look at Firefox 3.0 which
> introduced a full SQL relational database into their location bar.
> Wow.  Of course there are others that love that feature.  Fortunately
> they did choose a good implementation.  But still...

Doesn't the Awful Bar use SQLite?  That's what I seem to recall.  If it's
using something more substantial to that, I may have to go stick my head
in the over.

Oh, wait -- it's an electric oven.  I guess that won't do much good.

The rapidly increasing code bloat is one of the reasons I'm glad Chromium
finally got ported to FreeBSD; it still *works*, whereas Firefox mostly
kind of pretends to work while sucking up all my system resources.  It
seems like things really started going downhill about the time it changed
its name from Firebird.

I really *loved* the browser when it was called Phoenix.  I still liked
it as Firebird.  As Firefox, I gradually started to hate it.  The only
things I really like about it now are:

* the extension system

* the fact it's open source software

* the fact it's not IE

Aside from the extension system (which is more limited) and the fact the
FreeBSD port is *two* major versions obsolete, I like Chromium more than
Firefox in pretty much every way, including licensing.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.nclug.org/pipermail/nclug/attachments/20101105/b0d604a1/attachment.pgp>


More information about the NCLUG mailing list