how to install wireless n.i.c. on FreeBSD 9.1

[Polytropon]

On Mon, 1 Sep 2014 18:00:46 -0400, kpneal at pobox.com wrote:
> The advantage of gvim, aside from using different settings for colors and
> fonts, is that vim/gvim handles damn-that's-huge huge files very, very
> well. We're talking a couple of seconds to open a multi-million line file.
> And boy is is responsive. 

It's dependencies for installation also are acceptable.



> The catch is the lines must be normal length. If you have text in an MVS
> dataset (with fixed size blocks), and you convert EBCDIC to ASCII with dd,
> AND you don't have the line lengths in sync between MVS and dd, then what
> you get is a file that only has one line but that line is millions of
> characters long. Don't do that.

This requires an additional step of inserting a line break
every n characters (where n often is 80, but for data files
often more).

By the way, there's _one_ feature that I didn't find in gvim,
and especially in regards of column-oriented data files, this
would be really helpful: a real COLUMN RULER on top.

As a grown-old mainframe person, I'm thinking about something
like this:

|...+....1....+....2....+....3....+....4....+....5....+....6

Something that you would recognize from ISPF/PDF or SEU.

It could also look like this:

         1         2         3         4         5         6
----+----0----+----0----+----0----+----0----+----0----+----0

Or this:

....+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6

Is there a way to add this to gvim? Ideally it should accomodate
to the "set nowrap" or "set wrap" setting (lines longer than the
window width are either wrapped or scrolled horizontally). It
should be shown on top of the current view (no matter how far you
are into the file vertically).

Any idea?



> I used to use nvi/vi for simply large files until our admin contacted me
> about the ongoing space issues in "/var/tmp". Oops. Now if I want to look
> at those files in nvi I use the "-F" option.

Yes, this directory is used by vi, and it's not subject to the
automatic cleaning of /tmp.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...