On Sun, 30 Jan 2022 00:56:47 -0500, 3.BB963 wrote:

>
> ... but I hate to see obsolete code lurking
> around.
>

"Ed" is far from obsolete. It can be a very convenient
tool.

Here is an example of its utility:

https://docstore.mik.ua/orelly/unix3/upt/ch20_07.htm

On 2022-01-29, Marco Moock wrote:
> I started using vim in 2018 and I don't want to miss it. I can do many
> things much faster. I also recommend it to new users, but the need to
> be aware that they need to invest time to learn it.

+1 on recommending vim to new users. It has a steep learning curve but
it's worth it. Knowledge of vim carries over to the navigation keys in
many other programs and (although there are exceptions) there is usually
some form of vi installed on most systems I've worked on.

Besides, there's a certain amount of street cred that comes with using
plain old vim/vi instead of the flashy new hotness.

--
() www.asciiribbon.org | Jeremy Brubaker
/\ - against html mail | јЬruЬаkе@оrіоnаrtѕ.іо / neonrex on IRC

You're dead, Jim. -- McCoy, "Amok Time", stardate 3372.7

On 2022-01-31, 3.BB963 <z24ba74.net> wrote:

> It would be interesting to see what percentage of
> commercial software is dedicated to countering
> everything Stupid Humans and balky hardware can
> possibly do to screw things up ...

Not nearly enough from what I've seen. Fortunately
for Microsoft, they've conditioned people to lower their
expectations of reliability. Lusers will happily reboot,
re-format, and re-install until the cows come home - all
the while proclaiming how _easy to use_ the software is.
(In other words, the screens are pretty.)

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-01-31, Andreas Kohlbach <ank@spamfence.net> wrote:

> On Mon, 31 Jan 2022 01:21:28 -0500, "3.BB963" <z24ba74.net> wrote:
>
>> On 1/30/22 12:25 PM, Tauno Voipio wrote:
>>
>> I had a tiny amount of experience with a PDP-11 ..
>> and I just HATED "ED" :-)
>>
>> There had to be a better way ... and it wasn't long
>> before people found some.
>
> I think the problem was having not enough RAM available for even loading
> a text file. The editor would load only a few lines into RAM at every
> given time.
>
> Only when in the 1980s machines with an abundance of memory (like 64 KB :-)
> hit the markets, some text files could be held in RAM.
>
> The Commodore 64 for example. It can display 40 characters per line, with
> 25 lines. Each character is one byte. That's 1 KB only for the
> screen. Older machines might only had 4 KB RAM in total, 1 reserved for
> the screen, so you start with less than 3 KB. Your program (a text
> editor) has a certain size. There is no space left to keep a complete
> (longer than a few bytes) text file in RAM.

I wrote an editor for my IMSAI before I got floppy disks and CP/M.
It would read a portion of the file from tape into memory, and you
edit that portion. When you asked for a line number farther along
in the file it would write out the portion of memory to the output
tape and read in the next portion, copying part of the file if you
asked for a line sufficiently farther along. It was a bit awkward,
but it worked.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On Mon, 31 Jan 2022 19:01:58 +0000, Charlie Gibbs wrote:

> On 2022-01-31, Andreas Kohlbach <ank@spamfence.net> wrote:
>
>> On Mon, 31 Jan 2022 01:21:28 -0500, "3.BB963" <z24ba74.net> wrote:
>>
>>> On 1/30/22 12:25 PM, Tauno Voipio wrote:
>>>
>>> I had a tiny amount of experience with a PDP-11 .. and I just HATED
>>> "ED" :-)
>>>
>>> There had to be a better way ... and it wasn't long before people
>>> found some.
>>
>> I think the problem was having not enough RAM available for even
>> loading a text file. The editor would load only a few lines into RAM at
>> every given time.
>>
>> Only when in the 1980s machines with an abundance of memory (like 64 KB
>> :-)
>> hit the markets, some text files could be held in RAM.
>>
>> The Commodore 64 for example. It can display 40 characters per line,
>> with 25 lines. Each character is one byte. That's 1 KB only for the
>> screen. Older machines might only had 4 KB RAM in total, 1 reserved for
>> the screen, so you start with less than 3 KB. Your program (a text
>> editor) has a certain size. There is no space left to keep a complete
>> (longer than a few bytes) text file in RAM.
>
> I wrote an editor for my IMSAI before I got floppy disks and CP/M. It
> would read a portion of the file from tape into memory, and you edit
> that portion. When you asked for a line number farther along in the
> file it would write out the portion of memory to the output tape and
> read in the next portion, copying part of the file if you asked for a
> line sufficiently farther along. It was a bit awkward,
> but it worked.

Sounds sort of like the original incarnation of Dec's TECO ("Tape Editor
and Corrector", aka "Text Editor and Corrector")

--
Lew Pitcher
"In Skills, We Trust"

On 2022-01-30, pH <wNOSPAMp@gmail.org> wrote:
> I see the emacs/vi wars have subsided...no emacs warriors commenting here.

Not to mention TECO. :)

--
------------------------------------------------------------------------------
18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
There is no "climate crisis" -- https://climatedepot.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

On 1/31/22 2:01 PM, Charlie Gibbs wrote:
> On 2022-01-31, 3.BB963 <z24ba74.net> wrote:
>
>> It would be interesting to see what percentage of
>> commercial software is dedicated to countering
>> everything Stupid Humans and balky hardware can
>> possibly do to screw things up ...
>
> Not nearly enough from what I've seen. Fortunately
> for Microsoft, they've conditioned people to lower their
> expectations of reliability. Lusers will happily reboot,
> re-format, and re-install until the cows come home - all
> the while proclaiming how _easy to use_ the software is.
> (In other words, the screens are pretty.)

I have exactly one Win box - where I'm working. I use
it to re-compile stuff I've done in Linux (been using
Lazarus/FPC a lot lately). Then I turn it OFF.

What a horrible system. Beauty is NOT Truth there.

MS has apparently invested in the hardware makers
lately - Win-11 both requires rather new chip sets
AND Trusted-Platform-Managment v2.0+ .... a zillion
ought to SUE them ......

Win is FAR beyond fixing. They can only make it worse
and worse.

But it IS pretty ... and that's all Joe User seems to
take into account.

Hmm ... I just wrote a gFortran pgm in Linux - first
real app I've writ in Fortran since the early 80s.
I wonder if it can be compiled in Win (or does it
NEED to be recompiled). Fortran STILL sux when it
comes to string ops and file I/O alas ... but it
wasn't made for that. 'Deffered'/dynamic strings
are a nice improvement though. Managed to write
a fairly compact "Field()" function for grabbing
stuff out of ascii-delimited files like .csv and
Pick-style DBs though ... I like those, quasi-
human-readable. Had to parse the disk records
char-by-char however, using the iostat to tell
where line-breaks and EOF were as the "lines"
could be ANY length and you can't read() into
a deferred string alas ......

Try to find the real strlen() of a fixed-length
string, the real stuff, in Fortran. You can't.
You can use a couple of "trim" functions - but
they cut off trailing spaces before you get your
answer. But what if you WANTED those trailing
spaces ??? Wrote my own, but STILL doesn't keep
those trailing spaces .... ie CHARACTER(Len=80)
with "Hello World " in it. LEN(MyStr)
gives you 80, which is wrong, and any fix-it
trick gives you "Hello World" but not the
length of "Hello World ". Infuriating.

3.BB963 <z24ba74.net> wrote:
> Hmm ... I just wrote a gFortran pgm in Linux - first
> real app I've writ in Fortran since the early 80s.
> I wonder if it can be compiled in Win (or does it
> NEED to be recompiled). Fortran STILL sux when it
> comes to string ops and file I/O alas ... but it
> wasn't made for that. 'Deffered'/dynamic strings
> are a nice improvement though. Managed to write
> a fairly compact "Field()" function for grabbing
> stuff out of ascii-delimited files like .csv and
> Pick-style DBs though ... I like those, quasi-
> human-readable. Had to parse the disk records
> char-by-char however, using the iostat to tell
> where line-breaks and EOF were as the "lines"
> could be ANY length and you can't read() into
> a deferred string alas ......

Reading char by char is the hard way. You can read a line by chunks in a
loop using nonadvancing I/O, and build up a deferred-length string with
concatenation and reallocation on assigmnent (along the lines of:
"line = line // line_part", where line is deferred length and line_part is
fixed length); the size keyword (e.g., "read(...,size=ll,...) line_part")
in the read statement will give you the actual number of characters read,
so when you hit EOR, the last bit can be added with
"line = line // line_part(:ll)".

> Try to find the real strlen() of a fixed-length
> string, the real stuff, in Fortran. You can't.
> You can use a couple of "trim" functions - but
> they cut off trailing spaces before you get your
> answer. But what if you WANTED those trailing
> spaces ??? Wrote my own, but STILL doesn't keep
> those trailing spaces .... ie CHARACTER(Len=80)
> with "Hello World " in it. LEN(MyStr)
> gives you 80, which is wrong, and any fix-it
> trick gives you "Hello World" but not the
> length of "Hello World ". Infuriating.

Fortran is not C; don't expect it to behave the same. If you really
need significant trailing spaces, you can always simulate a C-style
string by sticking a char(0) into MyStr after the last significant space
(assuming there's room); then len(MyStr) is still 80 (or whatever) and
trim_len(MyStr) - 1 is the strlen(MyStr) you are looking for. (This
trick works for opening files in Fortran whose names have significant
trailing blanks--evil practice--on operating systems that expect C-style
strings for file names.)

--
John Wingate Mathematics is the art which teaches
johnww@tds.net one how not to make calculations.
--Oscar Chisini

On 2022-02-01, 3.BB963 <z24ba74.net> wrote:

> On 1/31/22 2:01 PM, Charlie Gibbs wrote:
>
>> On 2022-01-31, 3.BB963 <z24ba74.net> wrote:
>>
>>> It would be interesting to see what percentage of
>>> commercial software is dedicated to countering
>>> everything Stupid Humans and balky hardware can
>>> possibly do to screw things up ...
>>
>> Not nearly enough from what I've seen. Fortunately
>> for Microsoft, they've conditioned people to lower their
>> expectations of reliability. Lusers will happily reboot,
>> re-format, and re-install until the cows come home - all
>> the while proclaiming how _easy to use_ the software is.
>> (In other words, the screens are pretty.)
>
> I have exactly one Win box - where I'm working. I use
> it to re-compile stuff I've done in Linux (been using
> Lazarus/FPC a lot lately). Then I turn it OFF.

I run WinXP under VirtualBox for work stuff.

> What a horrible system. Beauty is NOT Truth there.

Whether Windows could be considered beautiful is open
to discussion. IMHO it is butt-ugly. We do agree,
though, that there is no Truth there.

> MS has apparently invested in the hardware makers
> lately - Win-11 both requires rather new chip sets
> AND Trusted-Platform-Managment v2.0+ .... a zillion
> ought to SUE them ......

Ah, the latest in an ongoing series of events - the last
one was when they tried to turn UEFI into a mechanism to
make it impossible to run anything but Windows.

> Win is FAR beyond fixing. They can only make it worse
> and worse.

That depends on your point of view. As far as M$ is concerned,
it's working perfectly and getting better all the time.

> But it IS pretty ... and that's all Joe User seems to
> take into account.

Sad but true. :-(

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

John Wingate <johnww@tds.net> wrote:

> trim_len(MyStr) - 1 is the strlen(MyStr) you are looking for. (This
^^^^^^^^

Arrgh! len_trim, of course!

--
John Wingate Mathematics is the art which teaches
johnww@tds.net one how not to make calculations.
--Oscar Chisini

Am Montag, 31. Januar 2022, um 15:50:02 Uhr schrieb Jeremy Brubaker:

> On 2022-01-29, Marco Moock wrote:
> > I started using vim in 2018 and I don't want to miss it. I can do
> > many things much faster. I also recommend it to new users, but the
> > need to be aware that they need to invest time to learn it.

I started in 2018 and I only know a few features - but they are enough
to edit text files much faster than my workmates using nano or Visual
Studio Code.

> +1 on recommending vim to new users. It has a steep learning curve but
> it's worth it. Knowledge of vim carries over to the navigation keys in
> many other programs and (although there are exceptions) there is
> usually some form of vi installed on most systems I've worked on.
>
> Besides, there's a certain amount of street cred that comes with using
> plain old vim/vi instead of the flashy new hotness.

I tried Visual Studio Code, my workmates use it, but I hate it. My
teachers in school also use it, but they didn't convinced me at all.

On 2/1/22 1:09 PM, John Wingate wrote:
> 3.BB963 <z24ba74.net> wrote:
>> Hmm ... I just wrote a gFortran pgm in Linux - first
>> real app I've writ in Fortran since the early 80s.
>> I wonder if it can be compiled in Win (or does it
>> NEED to be recompiled). Fortran STILL sux when it
>> comes to string ops and file I/O alas ... but it
>> wasn't made for that. 'Deffered'/dynamic strings
>> are a nice improvement though. Managed to write
>> a fairly compact "Field()" function for grabbing
>> stuff out of ascii-delimited files like .csv and
>> Pick-style DBs though ... I like those, quasi-
>> human-readable. Had to parse the disk records
>> char-by-char however, using the iostat to tell
>> where line-breaks and EOF were as the "lines"
>> could be ANY length and you can't read() into
>> a deferred string alas ......
>
> Reading char by char is the hard way. You can read a line by chunks in a
> loop using nonadvancing I/O, and build up a deferred-length string with
> concatenation and reallocation on assigmnent (along the lines of:
> "line = line // line_part", where line is deferred length and line_part is
> fixed length); the size keyword (e.g., "read(...,size=ll,...) line_part")
> in the read statement will give you the actual number of characters read,
> so when you hit EOR, the last bit can be added with
> "line = line // line_part(:ll)".

I considered using a larger buffer ... but unscrambling
and properly re-combining lines looked so complicated that
it was just easier and cheaper to char-by-char. Got that
down to a very few lines. Fortunately what I was reading
wasn't "gigantic", so char-by-char was still not a time
problem. The exercise was to convert a "sparse" ascii-
delimited DB (two MV levels with a six-field header)
into a kind of csv easy to import into MySql or a
spreadsheet). Not terribly ambitious, but it was my
first Fortran pgm in 30+ years after all. Would
have been much easier in Python or Pascal or even
'C' ... but ......

>> Try to find the real strlen() of a fixed-length
>> string, the real stuff, in Fortran. You can't.
>> You can use a couple of "trim" functions - but
>> they cut off trailing spaces before you get your
>> answer. But what if you WANTED those trailing
>> spaces ??? Wrote my own, but STILL doesn't keep
>> those trailing spaces .... ie CHARACTER(Len=80)
>> with "Hello World " in it. LEN(MyStr)
>> gives you 80, which is wrong, and any fix-it
>> trick gives you "Hello World" but not the
>> length of "Hello World ". Infuriating.
>
> Fortran is not C; don't expect it to behave the same.

I don't. However I wanted to accomplish a given task
and that required bending Fortran just a bit, get it
to do a little of what it really wasn't meant to do.
In short, make it a bit more flexible. Considered
making my own null-terminated strings so the true
length, including any xtra spaces at the end, would
be easy to find.

I kinda rate languages by the "CAN you get there from
here" criteria ... preferably "CAN" in a fairly straight
and un-infuriating fashion. For text, Fortran rates
pretty low. For number-stuff though ....

Oh, weird issue. gFortran under Linux .. the executable
is like 380kb ... but compiled using gFortran in Winders
it's like 1.7mb. Versions are almost the same. Looked
to see if it was a bunch of debug stuff being put in
there but nothing obvious and actually the Linux
compilation used the -Wall option which should have
included MORE debug stuff. Another reason not to use
Winders more than necessary.

> If you really
> need significant trailing spaces, you can always simulate a C-style
> string by sticking a char(0) into MyStr after the last significant space

Yep, as discussed. It DOES work ... but you have to be
careful because changing the string content can put the
spaces back in at the end.

> (assuming there's room); then len(MyStr) is still 80 (or whatever) and
> trim_len(MyStr) - 1 is the strlen(MyStr) you are looking for. (This
> trick works for opening files in Fortran whose names have significant
> trailing blanks--evil practice--on operating systems that expect C-style
> strings for file names.)

I like the old Pascal-style strings that put the length
in the first byte (maybe a few bytes in latter versions).
Then you know right up-front ... don't even have to scan
through looking for a null.

But Pascal is Pascal and Fortran is Fortran.

On 2/1/22 1:16 PM, John Wingate wrote:
> John Wingate <johnww@tds.net> wrote:
>
>> trim_len(MyStr) - 1 is the strlen(MyStr) you are looking for. (This
> ^^^^^^^^
>
> Arrgh! len_trim, of course!
>

Arrgh ! NOT ! There are significant trailing spaces in
the files I was processing. Len_Trim() chops them all
off. Found an ugly way around it, but still ...

IMHO, only use allocatable strings in modern Fortran.
Saves a ton of headaches.

As some have said, Fortran is good at what it's good
at. But, for fun and educational purposes I decided
to make it do what it wasn't so good at. You learn
a lot that way.

On 2/1/22 1:11 PM, Charlie Gibbs wrote:
> On 2022-02-01, 3.BB963 <z24ba74.net> wrote:
>
>> On 1/31/22 2:01 PM, Charlie Gibbs wrote:
>>
>>> On 2022-01-31, 3.BB963 <z24ba74.net> wrote:
>>>
>>>> It would be interesting to see what percentage of
>>>> commercial software is dedicated to countering
>>>> everything Stupid Humans and balky hardware can
>>>> possibly do to screw things up ...
>>>
>>> Not nearly enough from what I've seen. Fortunately
>>> for Microsoft, they've conditioned people to lower their
>>> expectations of reliability. Lusers will happily reboot,
>>> re-format, and re-install until the cows come home - all
>>> the while proclaiming how _easy to use_ the software is.
>>> (In other words, the screens are pretty.)
>>
>> I have exactly one Win box - where I'm working. I use
>> it to re-compile stuff I've done in Linux (been using
>> Lazarus/FPC a lot lately). Then I turn it OFF.
>
> I run WinXP under VirtualBox for work stuff.

A perfecty valid approach. I too have a virtual
XP ... albeit under KVM. Getting the VM to write
to disk space where Linux can GET at it is a bit
fiddly in both VM systems alas.

However I wanted my little app to compile/run
for sure in Win-10, and I'm not gonna pay for
a Win-10 merely to run in a VM. so ...

And Win-11 ... it's extortion-ware.

>
>> What a horrible system. Beauty is NOT Truth there.
>
> Whether Windows could be considered beautiful is open
> to discussion. IMHO it is butt-ugly. We do agree,
> though, that there is no Truth there.

They've never REALLY improved it. They made it
LOOK nicer, lots more eye-candy, but the underlying
code seems not to have changed very much since NT.

I heard somewhere that NT was the last version a
single person could hold in his head and see how
tweaking 'A' could affect 'X' 'Y' and 'Z'. Then
that guy retired :-)

>> MS has apparently invested in the hardware makers
>> lately - Win-11 both requires rather new chip sets
>> AND Trusted-Platform-Managment v2.0+ .... a zillion
>> ought to SUE them ......
>
> Ah, the latest in an ongoing series of events - the last
> one was when they tried to turn UEFI into a mechanism to
> make it impossible to run anything but Windows.

Yep :-) Didn't take long for everybody to work
around all that.

Getting around the requirement for 8000-series
cpu's and a TPM 2.x chip may be a tad more
difficult, but not un-doable. As there are
tons of sub-8000s out there doing good cheap
duty and nobody wants to fork out for a TPM
chip ... BET there will be fixes REAL SOON,
assuming everybody doesn't just sue the shit
out of MS.

Hopefully this will drive more people over to
the -IX universe.

I see MS is quietly "Linux-izing" bits of their
OS. I fear that at some point, as their code
spreads around and it gets integrated into
important software, they'll claim de-facto
ownership of Linux/BSD. They CAN afford
the lawyers ...

I was gonna load Visual Studio onto my Win box
today. Actually scrolled-down into the "accept"
message ... and found all the stuff about them
spying on your work and system. Clicked the
"Do NOT Agree" button and the installer
seemed shocked ....

LONG back there was a company selling "un-copyable"
floppy disks. Their trick was that they actually
burned a little laser-hole at a certain spot on
the disk and their shell you put your install pgm
in knew how to avoid it. Someone, Phillipe Kahn
I think, offered a REWARD to the first person who
could crack their wunnerful system. There was a
winner within a week and the company kinda just
disappeared shortly after :-)

>> Win is FAR beyond fixing. They can only make it worse
>> and worse.
>
> That depends on your point of view. As far as M$ is concerned,
> it's working perfectly and getting better all the time.

Yes, the PRICE keeps going up, the built-in SPYWARE
keeps delivering more and IDIOTS keep PAYING ... so,
yes, a Great Success .........

>> But it IS pretty ... and that's all Joe User seems to
>> take into account.
>
> Sad but true. :-(

All most people want to do is surf videos and
Twit/Insta/Face ... and so long as Winders makes
that seem easy they'll stick with it without
a second thought. M$ loves them.

Linux/BSD require a 3-digit IQ ... and that
bars half the population right there.

And Apple fools ... gee, what can I say about them ?
They LOVE to be ripped-off. The latest shiny expensive
model is what they yearn for - status. Had to set up
a bunch of iPads recently - mail and a few other
things ... WHAT A PAIN ! They BURIED the relevant
settings way deep - and some were "contextual" and
didn't show up until you did some other stuff.

After all these years, 99.99+ percent are just going
to be "users" without the slightest grasp, or desire
to grasp, the nuts and bolts that lie beneath. This
is not going to change. It's like with cars ... ask
people "how does a car work" and they'll say "You
start it up and it goes". The despised Johnny
Greasemonkees are light-years ahead of them ...

On 2/1/22 2:42 PM, Marco Moock wrote:
> Am Montag, 31. Januar 2022, um 15:50:02 Uhr schrieb Jeremy Brubaker:
>
>> On 2022-01-29, Marco Moock wrote:
>>> I started using vim in 2018 and I don't want to miss it. I can do
>>> many things much faster. I also recommend it to new users, but the
>>> need to be aware that they need to invest time to learn it.
>
> I started in 2018 and I only know a few features - but they are enough
> to edit text files much faster than my workmates using nano or Visual
> Studio Code.
>
>> +1 on recommending vim to new users. It has a steep learning curve but
>> it's worth it. Knowledge of vim carries over to the navigation keys in
>> many other programs and (although there are exceptions) there is
>> usually some form of vi installed on most systems I've worked on.
>>
>> Besides, there's a certain amount of street cred that comes with using
>> plain old vim/vi instead of the flashy new hotness.
>
> I tried Visual Studio Code, my workmates use it, but I hate it. My
> teachers in school also use it, but they didn't convinced me at all.

Faster than nano ? I have SEVERE doubts.

Certainly not NICER than nano.

And VCS is the other extreme - it's not MEANT to tweak
config files and shell scripts.

On 2022-02-04, 25.BZ942 wrote:
> On 2/1/22 2:42 PM, Marco Moock wrote:

>>> On 2022-01-29, Marco Moock wrote:
>>>> I started using vim in 2018 and I don't want to miss it. I can do
>>>> many things much faster. I also recommend it to new users, but the
>>>> need to be aware that they need to invest time to learn it.
>>
>> I started in 2018 and I only know a few features - but they are enough
>> to edit text files much faster than my workmates using nano or Visual
>> Studio Code.
>>
> Faster than nano ? I have SEVERE doubts.

You have SEVERE doubts that editing with vim can be faster than nano?

For someone with no knowledge of how to use vim, sure. There is a reason
"How do I exit vim?" is a thing. But for someone who actually knows how
to use vim? There is no way I can see any non-trivial editing task *not*
being faster in vim. And even non-trivial editing tasks are likely to be
at least just as fast using vim, if not faster.

-- () www.asciiribbon.org | Jeremy Brubaker /\ - against html mail |
јЬruЬаkе@оrіоnаrtѕ.іо / neonrex on IRC

Work smarter, not harder, and be careful of your speling.