Editor speed contest?
Matt Gregory
past week. You can record yourself playing it and there's this
totally insane web page of people racing to get the fastest times
going through the mazes with inhuman mouse and keyboard input
accuracy (if you're curious the link is http://www.planetquake.com/sda/ )
It inspired me to wonder if anyone has ever held a contest to
complete a certain editing task in the fewest number of vi or
emacs keystrokes. That might actually be educational.
Tim Hammerquist
> It inspired me to wonder if anyone has ever held a contest to
> complete a certain editing task in the fewest number of vi or
> emacs keystrokes. That might actually be educational.
I once amazed one of my programming instructors by swapping one
line of code for the one below it. In vi, this was "ddp". It
never struck me as that impressive, but as the instructor was
used to Notepad and editors with similar bindings, his amazement
seemed more appropriate.
The optimized Notepad keystrokes to perform the same operation
(near as I can tell) would be 8 or more in number, 6 of which
would be in chords. I'm pretty sure Emacs could do it in less,
but they'd have the chords in common. ;)
Cheers,
Tim Hammerquist
--
M-x induce-carpal-tunnel-syndrome
-- Greg Bacon
Brian Inglis
<t...@vegeta.ath.cx> wrote:
five:
<home><shift-down><ctrl-X/shift-delete><down><ctrl-V/shift-insert>
I'm on a contract where decent tool installation is not allowed!
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
GoogleFox
CRiSP can do it in two: <Keypad-Plus><Down><Ins> assuming default
bindings. Of course if I write a macro I can do it in 1..but I guess
that would be cheating?
Kenny McCormack
GoogleFox <goo...@crisp.demon.co.uk> wrote:
...
>CRiSP can do it in two: <Keypad-Plus><Down><Ins> assuming default
>bindings. Of course if I write a macro I can do it in 1..but I guess
>that would be cheating?
Um, there are three kinds of people in the world...
Matt Gregory
> On 1 Aug 2003 15:21:32 -0700 in comp.editors, Tim Hammerquist
> <t...@vegeta.ath.cx> wrote:
>
>
>>Matt Gregory graced us by uttering:
>>
>>>It inspired me to wonder if anyone has ever held a contest to
>>>complete a certain editing task in the fewest number of vi or
>>>emacs keystrokes. That might actually be educational.
>>
>>I once amazed one of my programming instructors by swapping one
>>line of code for the one below it. In vi, this was "ddp". It
>>never struck me as that impressive, but as the instructor was
>>used to Notepad and editors with similar bindings, his amazement
>>seemed more appropriate.
ddp always impresses me. xp, too, but not as much because I would
have to count moving the cursor with that one.
>>The optimized Notepad keystrokes to perform the same operation
>>(near as I can tell) would be 8 or more in number, 6 of which
>>would be in chords. I'm pretty sure Emacs could do it in less,
>>but they'd have the chords in common. ;)
>
>
> five:
> <home><shift-down><ctrl-X/shift-delete><down><ctrl-V/shift-insert>
Well, I would count that as 8 and then some for the chords :-)
> I'm on a contract where decent tool installation is not allowed!
Well, I can install whatever I want, but I'm unemployed so take
your pick :-)
Ok, let's try this. Pretend you're going to win something really
awesome, like one of these:
http://www.mcphee.com/amusements/current/09500ss.html
How fast can you do the following edit using whatever editor you
want, assuming the cursor is at the home position:
before:
-- cut here ------
|1.1| Red And Black
|1.2| Green And Orange
|1.3| White And Blue
*1.1* Red And Black
Blah Blah Blah Blah Blah Blah Blah Blah
Blah Blah Blah Blah Blah Blah Blah
*1.2* Green And Orange
Foo Foo Foo Foo Foo Foo Foo Foo
Foo Foo Foo Foo Foo Foo Foo Foo Foo
Foo Foo Foo Foo Foo Foo Foo Foo Foo Foo
*1.3* White And Blue
Bar Bar Bar Bar Bar
Bar Bar Bar Bar Bar Bar Bar
Bar Bar Bar
-- cut here ------
after:
-- cut here ------
1.1 |red-and-black|
1.2 |green-and-orange|
1.3 |white-and-blue|
1.1 *red-and-black*
Blah Blah Blah Blah Blah Blah Blah Blah
Blah Blah Blah Blah Blah Blah Blah
1.2 *green-and-orange*
Foo Foo Foo Foo Foo Foo Foo Foo
Foo Foo Foo Foo Foo Foo Foo Foo Foo
Foo Foo Foo Foo Foo Foo Foo Foo Foo Foo
1.3 *white-and-blue*
Bar Bar Bar Bar Bar
Bar Bar Bar Bar Bar Bar Bar
Bar Bar Bar
-- cut here ------
Simon Strandgaard
In VIM I use these assignments:
SHIFT+arrow_up => swap with line above
SHIFT+arrow_down => swap with line below
See implementation here:
http://www.vim.org/tips/tip.php?tip_id=321
--
Simon Strandgaard
uws
Hi all,
I've used VIM to accomplish the above.
(NOTE: indentation prepended for your reading comfort)
FIRST PART: start on the first character and hit:
qqxExwP$pguu:s/ /-<CR>f-2r 0jq@q@@
The original:
|1.1| Red And Black
|1.2| Green And Orange
|1.3| White And Blue
will turn into:
1.1 |red-and-black|
1.2 |green-and-orange|
1.3 |white-and-blue|
SECOND PART: To advance to the next line, hit j. After that, hit:
qqxExwPi<CR><Esc>guu:s/ /-<CR>$pkJ2}jq@q@@
... so that:
*1.1* Red And Black
Blah [snip]
will turn into:
1.1 *red-and-black*
Blah [snip]
Just a quick way to do it :) Total numbers (I've added underscores after each
group of 5 characters to make counting easier).
- first part: qqxEx_wP$pg_uu:s/_ /-<CR>f_-2r 0_jq@q@_@j
- goto next line: j
- second part: qqxEx_wPi<CR><Esc>_guu:s_/ /-<CR>_$pkJ2_}jq@q_@@
Without modifier keys (shift, ctrl, meta): 32 + 1 + 32 = 65
With modifier keys: 65 + 7 = 72
^-- capital letters and
the colon : key.
Happy Vimming!
mvrgr, Wouter
P.S. Maybe this can even be done faster by automating the double `qqxExwP'
and `guu:s/ /-<CR>' parts.
--
:wq mail u...@xs4all.nl
who's gonna take it like this? :: no way :: you are, you are -- gomez
Tim Hammerquist
> Tim Hammerquist <t...@vegeta.ath.cx> wrote:
>>Matt Gregory graced us by uttering:
>>> It inspired me to wonder if anyone has ever held a contest to
>>> complete a certain editing task in the fewest number of vi or
>>> emacs keystrokes. That might actually be educational.
>>
>>I once amazed one of my programming instructors by swapping one
>>line of code for the one below it. In vi, this was "ddp". It
>>never struck me as that impressive, but as the instructor was
>>used to Notepad and editors with similar bindings, his
>>amazement seemed more appropriate.
>>
>>The optimized Notepad keystrokes to perform the same operation
>>(near as I can tell) would be 8 or more in number, 6 of which
>>would be in chords. I'm pretty sure Emacs could do it in less,
>>but they'd have the chords in common. ;)
>
> five:
> <home><shift-down><ctrl-X/shift-delete><down><ctrl-V/shift-insert>
Those were the same strokes I used, but I count each key as a key
stroke, even though they're in chords.
> I'm on a contract where decent tool installation is not allowed!
Ditto. In my department we're required to use CodeWright, which
is nice, but I still wish we could install Vim...
> Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Cheers!
Tim Hammerquist
--
C++: an octopus made by nailing extra legs onto a dog
-- unknown
Matt Gregory
> Just a quick way to do it :) Total numbers (I've added underscores after each
> group of 5 characters to make counting easier).
>
> - first part: qqxEx_wP$pg_uu:s/_ /-<CR>f_-2r 0_jq@q@_@j
> - goto next line: j
> - second part: qqxEx_wPi<CR><Esc>_guu:s_/ /-<CR>_$pkJ2_}jq@q_@@
Hey, nice guu command! I didn't know about that one. I like that line
splitting move, too.
> Without modifier keys (shift, ctrl, meta): 32 + 1 + 32 = 65
> With modifier keys: 65 + 7 = 72
> ^-- capital letters and
> the colon : key.
>
> Happy Vimming!
>
> mvrgr, Wouter
>
> P.S. Maybe this can even be done faster by automating the double `qqxExwP'
> and `guu:s/ /-<CR>' parts.
Ok, I tried that and did it in 50 keys. I recorded the entire edit
of the first part and used it for the second part, then I recorded the
edit on the second part. I used <CR> instead of 0j. I don't have
gdefault set, though. We'll have to speak to the judging panel to see
if that's allowed :-)
qqxExwi<CR><ESC>P$pguu:s/ /-/g<CR>kJ<CR>q2@q
qaj@q}q2@a
41 = 31 + 10 without modifiers
9 = 6 + 3 modifiers
--
50 keys (48 with gdefault)
I think maybe the test needs to be a little bit longer. I think I
should have used more randomness in the paragraphs and section titles
for realism.
Matt Gregory
uws
I <F46Xa.3515$kP6...@newsread2.news.atl.earthlink.net>, Matt Gregory skrev:
> uws wrote:
>> qqxEx_wP$pg_uu:s/_ /-<CR>f_-2r 0_jq@q@_@j
>> j
>> qqxEx_wPi<CR><Esc>_guu:s_/ /-<CR>_$pkJ2_}jq@q_@@
> qqxExwi<CR><ESC>P$pguu:s/ /-/g<CR>kJ<CR>q2@q
> qaj@q}q2@a
We're both totally fscked up, don't you think? ;-)
> Hey, nice guu command! I didn't know about that one. I like that line
> splitting move, too.
Thanks ;) It was just a late-night try after a couple of alcoholic drinks.
Your 2@q (below) and repeating it for the next part is pretty well thought
of..
mvrgr, Wouter
--
:wq mail u...@xs4all.nl
if this is right :: i'd rather be wrong :: rather be blind -- incubus
Thomas Dickey
> CRiSP can do it in two: <Keypad-Plus><Down><Ins> assuming default
> bindings. Of course if I write a macro I can do it in 1..but I guess
> that would be cheating?
on my keyboard that is 3 keypresses rather than 2.
--
Thomas E. Dickey <dic...@radix.net> <dic...@herndon4.his.com>
http://dickey.his.com
ftp://dickey.his.com
Kenny McCormack
Thomas Dickey <dic...@saltmine.radix.net> wrote:
>GoogleFox <goo...@crisp.demon.co.uk> wrote:
>
>> CRiSP can do it in two: <Keypad-Plus><Down><Ins> assuming default
>> bindings. Of course if I write a macro I can do it in 1..but I guess
>> that would be cheating?
>
>on my keyboard that is 3 keypresses rather than 2.
Hence my comment about there being 3 kinds of people in the world...
Jahagirdar Vijayvithal S
> How fast can you do the following edit using whatever editor you
> want, assuming the cursor is at the home position:
>
>
> before:
> -- cut here ------
heres another solution clocking at 63 characters
:%s/\([|*]\)\(.*\)[|*]\( *\)\(\w.*\w\)/\2\3\1\4\1
:g/\*/norm guu
Matt Gregory
> [messed up all quotations]
>
> I <F46Xa.3515$kP6...@newsread2.news.atl.earthlink.net>, Matt Gregory skrev:
>
>>uws wrote:
>>
>>>qqxEx_wP$pg_uu:s/_ /-<CR>f_-2r 0_jq@q@_@j
>>>j
>>>qqxEx_wPi<CR><Esc>_guu:s_/ /-<CR>_$pkJ2_}jq@q_@@
>>
>>qqxExwi<CR><ESC>P$pguu:s/ /-/g<CR>kJ<CR>q2@q
>>qaj@q}q2@a
>
>
> We're both totally fscked up, don't you think? ;-)
lol...No way! I think this has a lot of potential! What better
way to become a better vimmer? Because, vim, it's not just an
editor, it's a practiced skill! :-)
I think I might set up a webpage for this! I'll have to think
for awhile about how badly I want to do that, though. :-)
Cheers,
Matt Gregory
Jussi Jumppanen
> CRiSP can do it in two: <Keypad-Plus><Down><Ins> assuming default
> bindings. Of course if I write a macro I can do it in 1..but I guess
> that would be cheating?
Not forgetting that this is CRiSP emulating the timeless Brief
editor keymappings :)
Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, Emacs, etc) FTP Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com
Paul Shirley
<jus...@zeusedit.com> writes
>GoogleFox wrote:
>>
>> Tim Hammerquist <t...@vegeta.ath.cx> wrote in message
>
>> CRiSP can do it in two: <Keypad-Plus><Down><Ins> assuming default
>> bindings. Of course if I write a macro I can do it in 1..but I guess
>> that would be cheating?
>
>Not forgetting that this is CRiSP emulating the timeless Brief editor
>keymappings :)
The same ones I'm using in JED. Some things never go out of fashion ;)
--
Paul Shirley: email anti-spammed
Jussi Jumppanen
> Ok, I tried that and did it in 50 keys. I recorded the entire edit
> of the first part and used it for the second part, then I recorded the
> edit on the second part. I used <CR> instead of 0j. I don't have
> gdefault set, though. We'll have to speak to the judging panel to see
> if that's allowed :-)
>
> qqxExwi<CR><ESC>P$pguu:s/ /-/g<CR>kJ<CR>q2@q
> qaj@q}q2@a
>
> 41 = 31 + 10 without modifiers
> 9 = 6 + 3 modifiers
> --
> 50 keys (48 with gdefault)
Use Brief keymapping this how I did this:
Change the first line using a keyboard macro as follows:
Key Description
=============================================
F7 start macro recoding
Alt+C start column mark
<left arrow> mark '|' character
<minus keypad> cut '|' character
<Ctrl + right arrow>
<Ctrl + right arrow>
<Ctrl + right arrow>
<Ctrl + right arrow> move cursor to first '|'
<insert keypad> insert the first '|' character
<Ctrl + left arrow>
<Ctrl + left arrow> move cursor to second '|'
Alt+C start column mark
<left arrow> mark '|' character
<minus keypad> cut '|' character
<end keypad> move to end of line
<insert keypad> insert second '|' character
<home>
<line down>
F8 stop macro recoding
Total 19 keys including navigation to record macro.
Do the remaining lines using a combination of macro
playback and down arrow as follows:
<f8>
<f8>
<line down>
<f8>
<line down>
<line down>
<line down>
<line down>
<f8>
<line down>
<line down>
<line down>
<line down>
<f8>
Total 14 keys including navigation
Total key strokes 14+19 = 33
Matt Gregory
> Total 14 keys including navigation
>
> Total key strokes 14+19 = 33
Hmmmm, that doesn't look bad, but did you lowercase the initial letters
of the three words and convert the spaces between them to dashes? I'm
not familiar with BRIEF at all.
uws
> uws wrote:
>> [messed up all quotations]
>> I <F46Xa.3515$kP6...@newsread2.news.atl.earthlink.net>, Matt Gregory skrev:
>>>uws wrote:
>>>>qqxEx_wP$pg_uu:s/_ /-<CR>f_-2r 0_jq@q@_@j
>>>>j
>>>>qqxEx_wPi<CR><Esc>_guu:s_/ /-<CR>_$pkJ2_}jq@q_@@
>>>qqxExwi<CR><ESC>P$pguu:s/ /-/g<CR>kJ<CR>q2@q
>>>qaj@q}q2@a
>> We're both totally fscked up, don't you think? ;-)
> lol...No way! I think this has a lot of potential! What better
> way to become a better vimmer? Because, vim, it's not just an
> editor, it's a practiced skill! :-)
VIM's more. It's not even just a way of life, It's The Way Of Life [tm]!
> I think I might set up a webpage for this! I'll have to think
> for awhile about how badly I want to do that, though. :-)
Sign me up for your contests.
mvrgr, Wouter
--
:wq mail u...@xs4all.nl
but i must be too dumb to be proud :: coz i waited -- our lady peace
Antony
Not quite, you missed a bit. For replacing
|1.1| Red And Black
...
*1.1* Red And Black
...
with
1.1 |red-and-black|
...
1.1 *red-and-black*
...
Using Vim, try
:g/\d/s/\v([|*])(.*)\1( *)(.*)/\2\3\1\L\4\1/|s/\a\zs /-/g<CR>
And that's 58 chars :-) But I don't think you'll beat a
macro with a regex in this particular case (too bad Peppe is
on holiday).
Antony
Vlad Tepes
...
> Using Vim, try
>
> :g/\d/s/\v([|*])(.*)\1( *)(.*)/\2\3\1\L\4\1/|s/\a\zs /-/g<CR>
>
> And that's 58 chars :-) But I don't think you'll beat a
> macro with a regex in this particular case (too bad Peppe is
> on holiday).
It's fragile, but this is the shortest I've come up with:
:g/\F/norm xExwPf r-f r-$pVu
29 characters, including the trailing <cr>. If you count shifts, it
would be more. The \F regex class is of course dependent on your
settings for isfname, but it's a little shorter than '|\|\*' and it
probably works.
--
Vlad
Peter Lee
Matt> How fast can you do the following edit using whatever editor
Matt> you want, assuming the cursor is at the home position:
C-M-% ^\(.\)\([0-9]+\.[0-9]+\)\(.\)\( +\)\(.*\) RET \2\4\1\5\3 RET
,----
`----
Antony
> Antony <ad_sc...@postmaster.co.uk> wrote:
>
> ...
>
> > Using Vim, try
> >
> > :g/\d/s/\v([|*])(.*)\1( *)(.*)/\2\3\1\L\4\1/|s/\a\zs /-/g<CR>
> >
> > And that's 58 chars :-) But I don't think you'll beat a
> > macro with a regex in this particular case (too bad
> > Peppe is on holiday).
>
> It's fragile, but this is the shortest I've come up with:
>
> :g/\F/norm xExwPf r-f r-$pVu
That's short. You could even condense this a little more.
:g/\d/norm!xExwPf r-;.$pVu<CR>
I always like to use :norm!, just in case. 27 chars now.
That Vu is nifty.
> 29 characters, including the trailing <cr>. If you count
> shifts, it would be more. The \F regex class is of course
> dependent on your settings for isfname, but it's a little
> shorter than '|\|\*' and it probably works.
I used \d in my regex above. Works for the example.
Antony
Thomas Dickey
I assumed that, but since there were no followups, decided it was too subtle.
Jussi Jumppanen
> Hmmmm, that doesn't look bad, but did you lowercase the initial
> letters of the three words and convert the spaces between them
> to dashes?
That will teach me to not fully read the e-mail before replying. I
had another go and to do the extra work takes 17 keys in the macro
by adding extra key strokes to do the following:
start marking
move end of line
lower case marked area
with the macro playback still taking 19 key stokes.
Total key strokes 17+19 = 36
But as you have probably guessed this still does not convert the ' '
to the required underscore. This last task would have been possible
in the original Brief by using a search and replace within the
definition of the macro (probably 3 - 4 key stokes).
But I ran the test using Zeus running Brief emulation and unfortunately
Zeus does not handle search and replace with a macro as well as the
original Brief :(
> I'm not familiar with BRIEF at all.
Brief was a very early programmer's editors for the MS-DOS system
written by Underware, later sold to Borland where it was promptly
killed off :(
These days there are lots of editors that still emulate the the Brief
keymappings, some better than others.
Vlad Tepes
> Vlad Tepes wrote:
>
> > Antony <ad_sc...@postmaster.co.uk> wrote:
> > >
> > > :g/\d/s/\v([|*])(.*)\1( *)(.*)/\2\3\1\L\4\1/|s/\a\zs /-/g<CR>
> > >
> > > And that's 58 chars :-) But I don't think you'll beat a
> > > macro with a regex in this particular case (too bad
> > > Peppe is on holiday).
> >
> > It's fragile, but this is the shortest I've come up with:
> >
> > :g/\F/norm xExwPf r-f r-$pVu
>
> That's short. You could even condense this a little more.
>
> g/\d/norm!xExwPf r-;.$pVu<CR>
>
> I always like to use :norm!, just in case. 27 chars now.
> That Vu is nifty.
Nice.
Silly of me to forget the period, and the semicolon is
re-added to my vim vocabulary.
I think we managed quite well, even if Peppe is away on
holiday. :-)
--
Vlad
Antony
> Antony <ad_sc...@postmaster.co.uk> wrote:
>
> > That's short. You could even condense this a little more.
> >
> > g/\d/norm!xExwPf r-;.$pVu<CR>
> >
> > I always like to use :norm!, just in case. 27 chars now.
> > That Vu is nifty.
> Nice.
>
> Silly of me to forget the period, and the semicolon is
> re-added to my vim vocabulary.
>
> I think we managed quite well, even if Peppe is away on
> holiday. :-)
:-) Well, here's a vanilla vi version for good measure.
oxExwPf r-f r-$p:s/.*/\L&<C-V><CR>/^[|*]<C-V><CR>@q<Esc>"qdd@q
44 chars; that's pretty good going. Unfortunately `;.'
doesn't seem to work inside a macro in HP Vi. I also need to
use a regex to lower-case the line. With the maps I already
have for vi, I would save 16 chars. So that we be 28 chars
with my personal setup.
We can also use this technique in Vim:
qqxExwPf r-;.$pVu/^\W<CR>@qq
1122222333333224455555 667
For those who don't use Vim:
1 Start recording a macro
2 Move * or |
3 Change spaces to -
4 Change the line to lower-case
5 Find the next line (<CR> means hit enter)
6 Loop the macro
7 Stop recording
Ooh, down to 25 chars :-)
Antony
Matt Gregory
> :-) Well, here's a vanilla vi version for good measure.
>
> oxExwPf r-f r-$p:s/.*/\L&<C-V><CR>/^[|*]<C-V><CR>@q<Esc>"qdd@q
>
> 44 chars; that's pretty good going. Unfortunately `;.'
> doesn't seem to work inside a macro in HP Vi. I also need to
> use a regex to lower-case the line. With the maps I already
> have for vi, I would save 16 chars. So that we be 28 chars
> with my personal setup.
>
> We can also use this technique in Vim:
>
> qqxExwPf r-;.$pVu/^\W<CR>@qq
> 1122222333333224455555 667
>
> For those who don't use Vim:
> 1 Start recording a macro
> 2 Move * or |
> 3 Change spaces to -
> 4 Change the line to lower-case
> 5 Find the next line (<CR> means hit enter)
> 6 Loop the macro
> 7 Stop recording
>
> Ooh, down to 25 chars :-)
That's pretty damn good. I'm working on a website for this. Can
I rip everyone-in-this-thread's entries to use on the site, or is
that uncool? How should I credit people, with the name in their
email, their actual email (doubtful), or the name they use to sign
their messages (which some people don't do)? Maybe I should start
from scratch with a new contest and not include this contest, but
I learned quite a bit from this contest and I would like to include
it as the first contest.
I want to make like a ranking table. I was also thinking about
making humorous sports-like commentary for the entries, but I think
that would be too much work, especially in the long run.
Matt Gregory
uws
> That's pretty damn good. I'm working on a website for this. Can
> I rip everyone-in-this-thread's entries to use on the site, or is
> that uncool?
It's fine with me. I didn't win :( However, I like you to put the time the
competitors sent in their solution. Even although usenet is not a realtime
medium, but readers can see who stole my ideas ;-)
> How should I credit people, with the name in their
> email, their actual email (doubtful), or the name they use to sign
> their messages (which some people don't do)?
I think Wouter <uws(at)xs4all(dot)nl> will be okay (with me at
least).
> I want to make like a ranking table. I was also thinking about
> making humorous sports-like commentary for the entries, but I think
> that would be too much work, especially in the long run.
Like I said before, you're a very sick person. ;-P
daag(); Wouter
--
:wq mail u...@xs4all.nl
you're a boy and i'm a girl :: protection -- massive attack
Matt Gregory
> I <CB8Ya.713$vo2...@newsread1.news.atl.earthlink.net>, Matt Gregory skrev:
>
>>That's pretty damn good. I'm working on a website for this. Can
>>I rip everyone-in-this-thread's entries to use on the site, or is
>>that uncool?
>
>
> It's fine with me. I didn't win :( However, I like you to put the time the
> competitors sent in their solution. Even although usenet is not a realtime
> medium, but readers can see who stole my ideas ;-)
Good idea, I will do that. And I freely admit to stealing your
ideas :-)
>
>
>>How should I credit people, with the name in their
>>email, their actual email (doubtful), or the name they use to sign
>>their messages (which some people don't do)?
>
>
> I think Wouter <uws(at)xs4all(dot)nl> will be okay (with me at
> least).
Ok. I think maybe the contests can be run entirely in c.e,
and I'll post the results with people's permission.
>>I want to make like a ranking table. I was also thinking about
>>making humorous sports-like commentary for the entries, but I think
>>that would be too much work, especially in the long run.
>
>
> Like I said before, you're a very sick person. ;-P
I'm going to do the sports commentary for the first contest
just because you said that :-D ...it will be funny...well,
to me at least.....yeah, maybe you're right :-)
Matt Gregory
Jahagirdar Vijayvithal S
> Ok. I think maybe the contests can be run entirely in c.e,
> and I'll post the results with people's permission.
the emacs group ?
Regards
Jahagirdar Vijayvithal S
Antony
> [...]
>
> qqxExwPf r-;.$pVu/^\W<CR>@qq
> 1122222333333224455555 667
>
> [...]
> 6 Loop the macro
^^^^^^^^^^^^^^^^^
Duhh. Of course this only works if you use the viminfo file
and have previously edited posts in this thread.
Dumbass
Peppe
> with
> Using Vim, try
Well, sometimes challenges can wait :-)
While not beating the macros (which was amusing to watch - I pretty much
went through the same reconciderations to reach essentially the same
commands), here is a shorter ex version with a somewhat weird approach:
:g/\d/s/\v(.).*( |\a$)/\L&\1/|&|s/\v[*|](.*) /\1-/g|&<CR>
Still, doing the hyphens first, then shuffling the * and | characters
individually leads to a shorter solution:
:g/\d/s/\> /-/g|s/\v([|*])(.*( |\a$))/\L\2\1/|&<CR>
Peppe [caught up at last]
--
se nocp cpo=BceFsx!$ sh=/bin/sh hid bs=2 ic scs hls ai isf-== hi=100
filetype plugin indent on | syn on | se lz ls=2 ru so=4
cno <C-A> <C-B>
omap S V/\n^-- $\\|\%$/<CR>
Antony
Not weird, clever! That's going to be very tough to beat.
Here it is in one ex command:
:%s/\v(.)(\A*)\1( *)(.*) (.*) (.*)/\L\2\3\1\4-\5-\6\1<CR>
and a shorter version:
:g/1/s/\> /-/g|s/\v(.)( +)(.*)/\2\1\L\3\1/|s/.<CR>
but it's much less interesting than your approach. (OT: I
wish there were a 'verymagic' option.)
Antony
Antony
> > > > How fast can you do the following edit using whatever
> > > > editor you want, assuming the cursor is at the home
> > > > position:
> > > > before:
> > > > -- cut here ------
> > > <SNIP>
> > > heres another solution clocking at 63 characters
> > > :%s/\([|*]\)\(.*\)[|*]\( *\)\(\w.*\w\)/\2\3\1\4\1
> > > :g/\*/norm guu
> > >
> > :g/\d/s/\v([|*])(.*)\1( *)(.*)/\2\3\1\L\4\1/|s/\a\zs /-/g<CR>
>
> > And that's 58 chars :-) But I don't think you'll beat a
>
> :g/\d/s/\v(.).*( |\a$)/\L&\1/|&|s/\v[*|](.*) /\1-/g|&<CR>
>
> Still, doing the hyphens first, then shuffling the * and | characters
> individually leads to a shorter solution:
>
> :g/\d/s/\> /-/g|s/\v([|*])(.*( |\a$))/\L\2\1/|&<CR>
Crap. I think we all went off-topic way back. We seem to be
measuring in characters, not seconds. The longer, simpler,
less error-prone solutions are probably lots quicker.
Antony
Peppe
> Peppe wrote:
> > While not beating the macros (which was amusing to watch
> > - I pretty much went through the same reconciderations to
> > reach essentially the same commands), here is a shorter
> > ex version with a somewhat weird approach:
> > :g/\d/s/\v(.).*( |\a$)/\L&\1/|&|s/\v[*|](.*) /\1-/g|&<CR>
> > Still, doing the hyphens first, then shuffling the * and
> > | characters individually leads to a shorter solution:
> > :g/\d/s/\> /-/g|s/\v([|*])(.*( |\a$))/\L\2\1/|&<CR>
> Not weird, clever! That's going to be very tough to beat.
> Here it is in one ex command:
> :%s/\v(.)(\A*)\1( *)(.*) (.*) (.*)/\L\2\3\1\4-\5-\6\1<CR>
> and a shorter version:
> :g/1/s/\> /-/g|s/\v(.)( +)(.*)/\2\1\L\3\1/|s/.<CR>
Neat.
> but it's much less interesting than your approach. (OT: I
> wish there were a 'verymagic' option.)
I think the 'verymagic' option has been proposed a number of times on
the vim/vim-dev lists. One reason not to add it is for scripts, both
for backwards compatibility and maintainability.
I think a lot of distributed scripts would break if a user does not like
vim to be 'magic'. The help entry for this discourages turning it off,
but this is just one example. Another one that can blow up your
carefully crafted :substitute commands is the 'gdefault' option.
Keeping all sorts of options in check to perform a simple task
consistantly correct can be a real pain.
Peppe
Peppe
> Crap. I think we all went off-topic way back.
Has this started getting to you? :-)
> We seem to be
> measuring in characters, not seconds.
Actually the OP was referring explicitly to the fewest number of key
strokes.
> The longer, simpler,
> less error-prone solutions are probably lots quicker.
Sure. I think any solution in this thread relies on very specific input.
Still, the solutions and approaches brought forward has probably been a
real eye-opener to someone out there.
Peppe
Antony
> Antony wrote:
> >
> > but it's much less interesting than your approach.
> > (OT: I wish there were a 'verymagic' option.)
>
> I think the 'verymagic' option has been proposed a number
> of times on the vim/vim-dev lists.
Oh good. For once it's not just me :-) You have to type and
read way too many backslashes. I think it's a real usability
problem.
> One reason not to add it is for scripts, both for
> backwards compatibility and maintainability.
Yeah sure, however ...
> I think a lot of distributed scripts would break if a
> user does not like vim to be 'magic'. The help entry for
> this discourages turning it off, but this is just one
> example. Another one that can blow up your carefully
> crafted :substitute commands is the 'gdefault' option.
>
> Keeping all sorts of options in check to perform a simple
> task consistantly correct can be a real pain.
... scripts should not inherit their environment from the
user's personal settings. Would it be too hard to implement
that scripts run with default settings?
Antony
Antony
> Antony wrote:
>
> > Crap. I think we all went off-topic way back.
>
> Has this started getting to you? :-)
Well yeah! I know I do it. I wan't to stop it. It bugs my
wife too :-)
> > We seem to be
> > measuring in characters, not seconds.
>
> Actually the OP was referring explicitly to the fewest
> number of key strokes.
`Referring': yes, `explicitly': no -- the subject line says
speed (even though the text of the post said fewest
keystrokes). To me that implies minimal effort: I think that
is what the OP was getting at, really. To reduce the effect
interference of the user interface on the process of thought
-> text is what's most important, in my opinion. For example
I find ex commands + completion + wild menu to be far
quicker than mouse + gui menu even though I have to make
many more keypresses.
> > The longer, simpler, less error-prone solutions are
> > probably lots quicker.
>
> Sure. I think any solution in this thread relies on very
> specific input. Still, the solutions and approaches
> brought forward has probably been a real eye-opener to
> someone out there.
Hopefully, though It's a shame that this group is so
vim-dominated sometimes. It would be nice to hear more from
users of other editors on this sort of thing. Reducing
keystrokes is a good thing, but I'm sure that e.g. emacs
users have interesting ways of approaching editing tasks
that I could learn from.
Antony
Jahagirdar Vijayvithal S
> I find ex commands + completion + wild menu to be far
> quicker than mouse + gui menu even though I have to make
> many more keypresses.
Regards
Jahagirdar Vijayvithal S
--
Now where did i keep that mouse...
Matt Gregory
> Peppe wrote:
>
> > Antony wrote:
> >
> > > We seem to be
> > > measuring in characters, not seconds.
> >
> > Actually the OP was referring explicitly to the fewest
> > number of key strokes.
>
> `Referring': yes, `explicitly': no -- the subject line says
> speed (even though the text of the post said fewest
> keystrokes). To me that implies minimal effort: I think that
> is what the OP was getting at, really. To reduce the effect
> interference of the user interface on the process of thought
> -> text is what's most important, in my opinion. For example
> I find ex commands + completion + wild menu to be far
> quicker than mouse + gui menu even though I have to make
> many more keypresses.
Although it does make sense to strive for minimal effort and
fastest editing timewise, I was definitely thinking about
fewest keystrokes, regardless of how much time and effort it
takes to come up with those keystrokes. I wish you could
watch those Quake movies, they are frickin' hilarious. People
exploit little bugs and quirks in the software to shave seconds
off of their times. For example, they've figured out that
strafing, jumping, and twisting the mouse all at the same time
is faster than just straight running. On certain maps, if you
approach some slope at a certain speed and move with perfect
accuracy, you can jump to an impossible place and skip half
the map. They've even analyzed how much of a velocity boost
each monster's attack damage gives you and they make certain
jumps that way. It's just fascinating to me how complex
software really is and how many different ways there are to do
things. I couldn't help but wonder if text editing could be
made into a contest as amusing as the Quake contests. Perl
would probably make another good contest, although I don't
know very much Perl.
> > > The longer, simpler, less error-prone solutions are
> > > probably lots quicker.
> >
> > Sure. I think any solution in this thread relies on very
> > specific input. Still, the solutions and approaches
> > brought forward has probably been a real eye-opener to
> > someone out there.
>
> Hopefully, though It's a shame that this group is so
> vim-dominated sometimes. It would be nice to hear more from
> users of other editors on this sort of thing. Reducing
> keystrokes is a good thing, but I'm sure that e.g. emacs
> users have interesting ways of approaching editing tasks
> that I could learn from.
Jahagirdar had a good idea to crosspost between this group
and an emacs group.
I'm making a webpage for this to glorify people's efforts,
but it's going to end up being a lot of work. I don't know
if I'll post it or not. All the keystrokes have to be
translated into some HTML equivalent, and using the <X>
notation of Vim is kind of a pain because it turns into
<X> Using things like <left-arrow> for the cursor
keys seems kind of excessive, too. It would be nice to use
some Unicode equivalents or something so that one character
maps to one keystroke, but that would probably be too
confusing (then again, we're talking about Vi and Emacs
users) and probably wouldn't be compatible with all browsers.
I think I need to come up with a way to automate it, then it
might be ok.
Matt Gregory
Peppe
> Peppe wrote:
> > Antony wrote:
> Yeah sure, however ...
Just to be pedantic, I guess you also mean this to apply to functions
defined in scripts. I don't think you actually want this.
It might make sense for some options like 'magic' and 'gdefaults', while
I think that others like 'equalalways' and 'splitbelow' should not be
changed from the users preference.
For better or worse, I doubt the situation will change.
GoogleFox
> In article <bgjtjp$qem$2...@news1.radix.net>,
> Thomas Dickey <dic...@saltmine.radix.net> wrote:
> >GoogleFox <goo...@crisp.demon.co.uk> wrote:
> >
> >> CRiSP can do it in two: <Keypad-Plus><Down><Ins> assuming default
> >> bindings. Of course if I write a macro I can do it in 1..but I guess
> >> that would be cheating?
> >
> >on my keyboard that is 3 keypresses rather than 2.
>
> Hence my comment about there being 3 kinds of people in the world...
Look if I could count I wouldnt be using this computer now would I.
And anyway...I have a great desire to win...so I can do it with ESP.
Now for my next trick...
can your editor wash the dishes?
can your editor read webnews?
Hint: one of those is a trick question
Tim Hammerquist
> Now for my next trick...
>
> can your editor wash the dishes?
> can your editor read webnews?
>
> Hint: one of those is a trick question
I'm stumped. I use neither of the following, but I've seen Gnus
and I've seem Emacs wash dishes, so which is the trick question?
;)
Tim Hammerquist
--
Once you can accept the universe as matter expanding into nothing
that is something, wearing stripes with plaid comes easy.
-- Albert Einstein
Antony
> GoogleFox graced us by uttering:
> > Now for my next trick...
> >
> > can your editor wash the dishes?
> > can your editor read webnews?
> >
> > Hint: one of those is a trick question
>
> I'm stumped. I use neither of the following, but I've
> seen Gnus and I've seem Emacs wash dishes, so which is
> the trick question?
>
> ;)
>
> Tim Hammerquist
Antony
Tim Hammerquist
> Tim Hammerquist wrote:
> > GoogleFox graced us by uttering:
> > > Now for my next trick...
> > >
> > > can your editor wash the dishes?
> > > can your editor read webnews?
> > >
> > > Hint: one of those is a trick question
> >
> > I'm stumped. I use neither of the following, but I've seen
> > Gnus and I've seem Emacs wash dishes, so which is the trick
> > question?
> >
> > ;)
>
Yeah, I've seen Vim dish soap.
And I've seen the kitchen sink app known as Emacs.
That's why I was stumped.
...that and my explicit winking smiley. ;)
Cheers!
Tim Hammerquist
--
Yes I know you can see it in MSIE,
but you could feed MSIE a banana and it would think it was HTML
-- Jeff Zucker in comp.lang.perl.misc
Antony
> Antony graced us by uttering:
> > Tim Hammerquist wrote:
> > > GoogleFox graced us by uttering:
> > > > Now for my next trick...
> > > >
> > > > can your editor wash the dishes?
> > > > can your editor read webnews?
> > > >
> > > > Hint: one of those is a trick question
> > >
> > > I'm stumped. I use neither of the following, but I've seen
> > > Gnus and I've seem Emacs wash dishes, so which is the trick
> > > question?
> > >
> > > ;)
> >
> > http://www.vim.org/trivia.php
>
> Yeah, I've seen Vim dish soap.
> And I've seen the kitchen sink app known as Emacs.
> That's why I was stumped.
>
> ...that and my explicit winking smiley. ;)
>
> Cheers!
> Tim Hammerquist
Ah I see. I took you literally when you said you'd seen
Emacs wash dishes.
Antony
Tim Hammerquist
> Tim Hammerquist wrote:
>
> > Antony graced us by uttering:
> > > Tim Hammerquist wrote:
> > > > GoogleFox graced us by uttering:
> > > > > can your editor read webnews?
> > > > >
> > > > > Hint: one of those is a trick question
> > > >
> > > > I'm stumped. I use neither of the following, but I've
> > > > seen Gnus and I've seem Emacs wash dishes, so which is
> > > > the trick question?
> > > >
> > > > ;)
> > >
> > > http://www.vim.org/trivia.php
> >
> > Yeah, I've seen Vim dish soap.
> > And I've seen the kitchen sink app known as Emacs.
> > That's why I was stumped.
> >
> > ...that and my explicit winking smiley. ;)
>
> wash dishes.
Have you ever tried
M-x wash-dishes
inside Emacs? I haven't, but if Emacs up and started washing my
dishes, I shouldn't be the least bit surprised! :)
Of course, if that ever happened, I might actually consider
switching editors. And then.... let's not think about it.
Tim Hammerquist
--
...it's fairly surprising how long a system will stay up when you remove all
the executables, most of the libraries, and trash a filesystem or two.
-- Simon, BOFH: No Service Therefore No Denial
Malcolm Dew-Jones
: Matt Gregory graced us by uttering:
: > It inspired me to wonder if anyone has ever held a contest to
: > complete a certain editing task in the fewest number of vi or
: > emacs keystrokes. That might actually be educational.
: I once amazed one of my programming instructors by swapping one
: line of code for the one below it. In vi, this was "ddp". It
: never struck me as that impressive, but as the instructor was
: used to Notepad and editors with similar bindings, his amazement
: seemed more appropriate.
: The optimized Notepad keystrokes to perform the same operation
: (near as I can tell) would be 8 or more in number, 6 of which
: would be in chords. I'm pretty sure Emacs could do it in less,
: but they'd have the chords in common. ;)
Sure, but calling `ddp' three is cheating, since it doesn't work in insert
mode, and doesn't leave you in insert mode if that is where you started.
In general you need at least four, <esc>ddp, and that assumes you
don't care if you have left insert mode afterwards.
Also, your description of notepad doesn't use the mouse. Using the mouse
we need
mouse-grab -- I would judge this equivalent to 2
ctrl-x -- 2
mouse-position -- I would judge this equivalent to 1
ctrl-v -- 2
total "keys strokes" 7 - and that exact sequence allows any number of
visible lines to be repositioned anywhere on the currently visible portion
of the file with no additional key strokes.
$0.02
Antony
Me: (OT: I wish there were a 'verymagic' option.)
Peppe: I think the 'verymagic' option has been proposed
a number of times on the vim/vim-dev lists.
[...]
One reason not to add it is for scripts, both
for backwards compatibility and maintainability.
Me: ... scripts should not inherit their environment
from the user's personal settings. Would it be
too hard to implement that scripts run with
default settings?
Peppe: Just to be pedantic, I guess you also mean this
to apply to functions defined in scripts. I
don't think you actually want this.
It might make sense for some options like
'magic' and 'gdefaults', while I think that
others like 'equalalways' and 'splitbelow'
should not be changed from the users preference.
Well, that depends doesn't it? I think this is a tricky
issue. I think you are probably right, and this is perhaps a
distinction between `scripting' and `programming'. I guess
it works okay in practice, but I think having to check
&cpoptions and &gdefault and &iskeyword etc. in every script
to be a bit of a problem. Ah, sod it. I guess you could just
write a function to do this for you if you wanted. Forget
it, I haven't slept properly for days, I'm mumbling now, and
I'm off-topic again!
Antony
Antony
> * Antony <ad_sc...@postmaster.co.uk>:
> > I find ex commands + completion + wild menu to be far
> > quicker than mouse + gui menu even though I have to make
> > many more keypresses.
>
> how do we map mouse moments and clicks to number of
> characters? ;) Regards
> Jahagirdar Vijayvithal S
Well, I mapped the pressing of a button on a keyboard to the
pressing of a button on a mouse :-)
Antony
Malcolm Dew-Jones
: Jahagirdar Vijayvithal S wrote:
: > * Antony <ad_sc...@postmaster.co.uk>:
: > > I find ex commands + completion + wild menu to be far
: > > quicker than mouse + gui menu even though I have to make
: > > many more keypresses.
: >
: > how do we map mouse moments and clicks to number of
: > characters? ;) Regards
: > Jahagirdar Vijayvithal S
: Well, I mapped the pressing of a button on a keyboard to the
: pressing of a button on a mouse :-)
: Antony
It's a judgement call in which non-mouse users will never agree with mouse
users.
It seems to me that non-mouse users often complain about moving their
hands from the keyboard to the mouse, and how inefficient this is. But a
mouse user doesn't do that. You type (and use keystrokes), and then you
edit (and use the mouse), just like you likely insert and edit in seperate
stages in vi.
When you edit then your hands are positioned to efficiently use the mouse.
One hand enters commands (which are really single keystrokes, not two,
since one finger is permanently on the command/ctrl/alt key) and the other
hand drives the mouse.
The mouse efficiency also depends greatly on the correct positioning of
the window relative to the screen. Non-mouse users typically do not
position the windows correctly for efficient mouse use, though I must
admit this is harder to do in x-windows as the mouse is typically not
anchored by the edge of the screen.
On windows or on a mac you can position the window to anchor the menus,
the text and/or the scroll bars to the edge of the screen so that the
mouse movement does not need to be accurate to (never the less)
accurately control the widgets, select the menus, or to make line
orientated text selections easily.
$0.02
P.S. an old but previously well known book on forth explains why line mode
editors are better then screen mode editors.
Tim Hammerquist
> Tim Hammerquist (t...@vegeta.ath.cx) wrote:
> > I once amazed one of my programming instructors by swapping
> > one line of code for the one below it. In vi, this was
> > "ddp". It never struck me as that impressive, but as the
> > instructor was used to Notepad and editors with similar
> > bindings, his amazement seemed more appropriate.
> >
> > The optimized Notepad keystrokes to perform the same
> > operation (near as I can tell) would be 8 or more in number,
> > 6 of which would be in chords. I'm pretty sure Emacs could
> > do it in less, but they'd have the chords in common. ;)
>
> you don't care if you have left insert mode afterwards.
With all due respect, that would be "at least three". If one
starts from command mode and executes the command "ddp", one is
thereafter left in command mode. If one starts from insert mode,
one would prefix the "<Esc>" as noted, and suffix an 'i' when
done.
> Also, your description of notepad doesn't use the mouse.
This is a vi tip. Why would I use a mouse? ;)
> Using the mouse we need
>
> mouse-grab -- I would judge this equivalent to 2
[...]
> mouse-position -- I would judge this equivalent to 1
I would judge these as equivalent to at least 5 each, but I can
cram a lot of keystrokes into the time it takes to grab a
mouse/trackball :)
Cheers!
Tim Hammerquist
--
We are not allowed human names,
as it may infringe upon human rights.
-- Model 803-D-RP-DM497-3-C ("Pero"), "Metropolis"
Otto Wyss
Sorry for the late entry to this subject, I'm just reading through old
messages and couldn't resist.
> > In general you need at least four, <esc>ddp, and that assumes
> > you don't care if you have left insert mode afterwards.
>
> With all due respect, that would be "at least three". If one
> starts from command mode and executes the command "ddp", one is
> thereafter left in command mode. If one starts from insert mode,
> one would prefix the "<Esc>" as noted, and suffix an 'i' when
> done.
>
Assuming that command and insert mode are equally divided (which
probalby isn't true) it would get an average of 4.
So I'm quiet happy with my own editor (see
"http://wxguide.sourceforge.net/indexedit.html") it does
<ctrl-l><ctrl-x><down><ctrl-v> ;-)
O. Wyss
--
See "http://wxguide.sourceforge.net/" for ideas how to design your app.
Tim Hammerquist
> Tim Hammerquist <t...@vegeta.ath.cx> wrote:
> > > In general you need at least four, <esc>ddp, and that
> > > assumes you don't care if you have left insert mode
> > > afterwards.
> >
> > With all due respect, that would be "at least three". If one
> > starts from command mode and executes the command "ddp", one
> > is thereafter left in command mode. If one starts from insert
> > mode, one would prefix the "<Esc>" as noted, and suffix an
> > 'i' when done.
>
> Assuming that command and insert mode are equally divided (which
> probalby isn't true) it would get an average of 4.
Agreed. But most often IME I'm already in command mode, as
that's when the hjkl keys move the cursor into position. YMM(and
probably does)V.
> So I'm quiet happy with my own editor (see
> "http://wxguide.sourceforge.net/indexedit.html") it does
>
> <ctrl-l><ctrl-x><down><ctrl-v> ;-)
You use the ARROW KEYS?! ;)
Cheers!
Tim Hammerquist
--
It makes sense to me. But then, I'm the guy that originally proposed it. :-)
-- Larry Wall in <1999031217...@wall.org>
Otto Wyss
> > So I'm quiet happy with my own editor (see
> > "http://wxguide.sourceforge.net/indexedit.html") it does
> >
> > <ctrl-l><ctrl-x><down><ctrl-v> ;-)
>
> You use the ARROW KEYS?! ;)
>
:-?! Well only if my hands were on the keyboard. If I hold the mouse I'd
do
<select line><right-click cut><position cursor><right-click paste>
or maybe I'd use both hands and do
<select line><ctrl-x><position cursor><ctrl-v>
Thore B. Karlsen
wrote:
>> > So I'm quiet happy with my own editor (see
>> > "http://wxguide.sourceforge.net/indexedit.html") it does
>> >
>> > <ctrl-l><ctrl-x><down><ctrl-v> ;-)
>>
>> You use the ARROW KEYS?! ;)
>>
>:-?! Well only if my hands were on the keyboard. If I hold the mouse I'd
>do
You use the mouse when you're editing text?
--
Be seeing you.
Piotr Zielinski
Pephaps I don't get it, but I really don't understand this widespread
myth that the mouse shouldn't be used _at_all_ in efficient text
editing. I think that, as a pointing device, a mouse is better than a
keyboard, which makes it useful, for example, for copying text between
different windows/frames.
Piotr
Otto Wyss
Yes, always when it's easier than with the keyboard. You don't seriously
question the use of the mouse for selecting text etc, do you?
Thore B. Karlsen
<n01+...@NOSPAMcl.cam.ac.uk> wrote:
You use windows when you're editing text? Sorry. :)
I use the mouse sometimes, but mostly when I'm in inferior text editors
(like Visual Studio's editor) or in word processors. I can't recall the
last time I used the mouse in Vim.
--
Be seeing you.
Vlad Tepes
>> You use the mouse when you're editing text?
>
> Yes, always when it's easier than with the keyboard. You don't seriously
> question the use of the mouse for selecting text etc, do you?
Can't speak for Thore, but I've been using my computer for several hours
today, and I have yet to touch my mouse. I think I used it yesterday.
Cheerio,
--
Vlad
Otto Wyss
> Otto Wyss <w...@users.sourceforge.net> wrote:
> >
> > Yes, always when it's easier than with the keyboard. You don't seriously
> > question the use of the mouse for selecting text etc, do you?
>
> Can't speak for Thore, but I've been using my computer for several hours
> today, and I have yet to touch my mouse. I think I used it yesterday.
>
Well I can imaging using the keyboard for long times when I type in new
code but I also remember only using the mouse when I search the net for
info's. Well the point is if one wants to use the mouse it should be
possible and if one wants to use keyboard equally. When I designed my
editor I've tried to allow as many as possible action with both while
still trying to stay as simple as possible. I can say you that's not an
easy task and I'm not sure if I was successful.
Mikolaj Machowski
It depends on editor. With Vim with proper 'clipboard' settings
you can use system clipboard for yanking and pasting text. No need to
mouse. Maybe in other applicatiions. I am often using mouse to select
text eg in Konq, switch to Vim and everything else with keyboard.
m.
--
LaTeX + Vim = http://vim-latex.sourceforge.net/
Learn Touch Typing with Vim? Oui. Ja. Yes. Tak:
http://vim.sourceforge.net/script.php?script_id=461
vim.pl - http://skawina.eu.org/mikolaj
Vlad Tepes
> Vlad Tepes <min...@start.no> wrote:
>> Otto Wyss <w...@users.sourceforge.net> wrote:
>> >
>> > Yes, always when it's easier than with the keyboard. You don't seriously
>> > question the use of the mouse for selecting text etc, do you?
>>
>> Can't speak for Thore, but I've been using my computer for several hours
>> today, and I have yet to touch my mouse. I think I used it yesterday.
>>
> Well I can imaging using the keyboard for long times when I type in new
> code but I also remember only using the mouse when I search the net for
> info's.
Oh, but I use the keyboard for browsing too; when in the console, I use
lynx with vi-keys and "text-fields needs activation"; great! When
browsing in a gui, I use opera which I have set up to use vi-keys for
jumping between links too; want to go to a link to the left? Press h.
Up? k etc. Email? Mutt with vi-ish keybindings. News? Slrn with (some)
vi-keys. Filemanager? vifm (vifm.sf.net, -- it still has some problems,
but I like it a lot. Works together with vim. Even modified the sources
to suit me a little better). Shell? zsh with vi-keys. Info documents?
pinfo, also with vi-keys. Controlling windows, bringing up terminals
and run-program boxes are also done with the keyboard. I've gone to
great lengths to avoid the mouse.
> Well the point is if one wants to use the mouse it should be
> possible and if one wants to use keyboard equally.
Most people find it easier to work with a mouse (not having to think
about which key does what frees some cognitive resources), so
a successful editor should definitely support it.
> When I designed my editor I've tried to allow as many as possible
> action with both while still trying to stay as simple as possible.
> I can say you that's not an easy task and I'm not sure if I was
> successful.
Then your editor could be a compromise between ease of use and features.
Perhaps it would be a good idea to do one or the other, not both at the
same time. But I don't know. I haven't tried your editor.
I chose to use vim and do the other things, not only because they were
easy, but because they were hard... ;-)
Regards,
--
Vlad
Matej Cepl
> Yes, always when it's easier than with the keyboard. You don't seriously
> question the use of the mouse for selecting text etc, do you?
I do -- because any using of the mouse makes you loose concentration on
typing. Therefore, you have to add to the speed of selecting text also
time for looking for mouse, leaving the home position on the keyboard
and setting fingers into their proper position -- mouse doesn't look so
good afterwards.
Matej
--
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
Paul Shirley
<min...@start.no> writes
>Otto Wyss <w...@users.sourceforge.net> wrote:
>> Thore B. Karlsen <s...@6581.com> wrote:
>>> w...@users.sourceforge.net
>>>
>>> You use the mouse when you're editing text?
>>
>> Yes, always when it's easier than with the keyboard. You don't seriously
>> question the use of the mouse for selecting text etc, do you?
...its hardly ever quicker with the mouse if you use good key bindings
(BTW that includes buffer/window to buffer cut&paste), even when you
ignore the time taken grabbing the mouse.
Especially when I have to wake up my wireless mouse every time ;)
>Can't speak for Thore, but I've been using my computer for several hours
>today, and I have yet to touch my mouse. I think I used it yesterday.
I find the scroll wheel on mine indispensable when web browsing and
playing Wolf ET gets it used for a few hours a day. And as the drivers
improve I'm switching from mouse to my keyboards scroll wheel!
I have no use for it while programming or handling mail&news.
--
Paul Shirley: email anti-spammed
Antony
> [...]
>
> I find the scroll wheel on mine indispensable when web
> browsing and playing Wolf ET gets it used for a few hours
> a day. And as the drivers improve I'm switching from
> mouse to my keyboards scroll wheel!
>
> [...]
Even IE lets you use <Space> and <S-Space> for scrolling.
:-)
Antony
Tim Hammerquist
> > You use the mouse when you're editing text?
>
> Yes, always when it's easier than with the keyboard. You don't
> seriously question the use of the mouse for selecting text etc,
> do you?
I don't question the use of the mouse for selecting text in my
GUI web browser, but I'm not editing that. Occasionally I'll
incorporate text from websites in my mails or articles, and for
that I'll use the mouse to select the text, and the keyboard to
paste in to my mail/news/everything editor, which is always Vim.
Tim Hammerquist
--
We all know linux is great...it does infinite loops in 5 seconds.
-- Linus Torvalds
Tim Hammerquist
>
> :-?! Well only if my hands were on the keyboard. If I hold the
> mouse I'd do
My hands are on my keyboard 97% of the time. That 3% is when I'm
reading <http://theregister.co.uk/> or
<http://nuklearpower.com/>.
Mail: mutt with vi keybindings; editing in vim
News: slrn with vi keybindings; editing in vim
Shell: zsh w/ vi keybindings; editing in vim
All editing: (g)vim
Even when I run inside the GUI (X11), these console apps are
opened up inside xterms. All programs launched by hotkeys. All
app/screen/vtty switching done by hotkeys.
In a non-websurfing 8-hour computer use period, I probably use
the mouse an average of 1 minute.
It's how I justify the batteries for my cordless mouse. :)
Cheers,
Tim Hammerquist
--
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
-- Peter J. Schoenster
Tim Hammerquist
"A mouse is a device used to point
at the xterm you want to type in."
...and that's if <Alt-Tab> doesn't work. ;)
Tim Hammerquist
--
Did I mention that I can't tell you how to get rich?
If I could, I'd be rich, and not here.
-- Martien Verbruggen in comp.lang.perl.misc
Alan Connor
>
>
> Piotr Zielinski graced us by uttering:
>> Thore> You use the mouse when you're editing text?
>>
>> Pephaps I don't get it, but I really don't understand this
>> widespread myth that the mouse shouldn't be used _at_all_ in
>> efficient text editing. I think that, as a pointing device, a
>> mouse is better than a keyboard, which makes it useful, for
>> example, for copying text between different windows/frames.
>
> "A mouse is a device used to point
> at the xterm you want to type in."
>
> ...and that's if <Alt-Tab> doesn't work. ;)
>
Right on!
As for copying text between windows, I use screen as my window manager
and it has yank and paste capabilities that do not require any plastic
rodents.
In a lot of cases you can just copy between windows by opening the file
with :n in vi , closing it, then opening that file in a new window.
One of these days I'm going to find a decent graphical browser with good
keybindings and feed my mouse to the nearest cat!
That is, if I can FIND it :-)
> Tim Hammerquist
> --
> Did I mention that I can't tell you how to get rich?
> If I could, I'd be rich, and not here.
> -- Martien Verbruggen in comp.lang.perl.misc
Alan C
--
take control of your mailbox ----- elrav1 ----- http://tinyurl.com/l55a
Paul Shirley
<ad_sc...@postmaster.co.uk> writes
In Mozilla the cursor keys do the job nicely *AFTER* I've pointed at the
right frame. Before that they're effect is totally unpredictable. Just
works out easier to hold onto the mouse after doing the pointing ;)
Jahagirdar Vijayvithal S
variables and similar stuff) split the window with one showing the code
and the other showing the error messages (variable x used before
declaration ...) and its much faster to do ",<l-click> <l-click>
<m-click>" when you are running vim in console mode
Regards
Jahagirdar Vijayvithal S
* Thore B Karlsen <s...@6581.com>:
Paul Shirley
<FILTER...@india.ti.com> writes
>I find the rodent useful when cleaning up the code ( declaration of
>variables and similar stuff) split the window with one showing the code
>and the other showing the error messages (variable x used before
>declaration ...) and its much faster to do ",<l-click> <l-click>
><m-click>" when you are running vim in console mode
In a real programmers editor that all happens automagically. I'm using
JED in Brief mode, I press F10 to invoke make, a window split for
compiler output appears (if it didn't already exist), Ctrl-N takes my
edit window & the error window to the first error ready for editing.
Ctrl-N steps forward through errors, Ctrl-P steps back.
Why on earth would I want to complicate 'F10,Ctrl-N' by using a mouse? I
don't even resize or navigate buffer windows with it. If you need the
mouse maybe its time to try another editor, this sort of bad UI is why I
don't use Crisp for instance.
(In the past that first Ctrl-N wasn't needed, today I carry on working
during an asynchronous compile - don't want my edit point changing till
I'm ready;)
Matej Cepl
> In a real programmers editor that all happens automagically. I'm using
> JED in Brief mode, I press F10 to invoke make, a window split for
> compiler output appears (if it didn't already exist), Ctrl-N takes my
> edit window & the error window to the first error ready for editing.
> Ctrl-N steps forward through errors, Ctrl-P steps back.
Of course, that vim can do the same -- :he quickfix.
Jason Creighton
Frankly, I've found this whole thread quite silly, because we're
counting *keystrokes*, not *speed*. If you sit down and think about it
for 10 minutes, I'm sure you could dream up a low number of keystrokes
for any (well, almost any) editor. Just like Perl golf.
But, if you do it the first way that you think of, _then_ how long would
it take? [note: I'm not talking about the "swap lines example here". I'm
talking about the original example that was something like "lowercase
here, remove these funny symbols, etc, etc"]
Jason Creighton
Antony
Jason Creighton wrote:
> [...]
>
> Frankly, I've found this whole thread quite silly,
> because we're counting *keystrokes*, not *speed*. If you
> sit down and think about it for 10 minutes, I'm sure you
> could dream up a low number of keystrokes for any (well,
> almost any) editor. Just like Perl golf.
>
> But, if you do it the first way that you think of, _then_
> how long would it take? [note: I'm not talking about the
> "swap lines example here". I'm talking about the original
> example that was something like "lowercase here, remove
> these funny symbols, etc, etc"]
Well, okay. I don't disagree too much with this: I posted
something similar a while back (after getting sidetracked
with Vim `golf'); the OP confirmed that he was after the
fewest number of keystrokes. As you say, the first idea that
comes into your head is probably quickest. But as the tasks
get longer and more complicated it probably pays off to sit
down and think of a good, _correct_ solution, so that you
don't waste time fixing the bits where your edit went wrong.
It's interesting to note that in the example given in this
thread, the most simple, straightforward and probably most
error-free approach with Vim is to use macro recording. This
also resulted in the fewest number of keystrokes.
Also, in defense of this sort of thing: it can give you new
ideas about ways in which to edit. A broader repertoire of
editing techniques can only be a good thing when you `do it
the first way that you think of.'
Antony
Jussi Jumppanen
> Thore> You use the mouse when you're editing text?
>
> Pephaps I don't get it, but I really don't understand this widespread
> myth that the mouse shouldn't be used _at_all_ in efficient text
> editing.
The reason the mouse will always be slower and more cumbersome
than the keyboard is the mouse is designed to work at a resolution
of screen pixels, whereas the keyboard works with a resolution of
characters and lines.
Yet the task of editing raw text deals exclusively with characters
and lines, meaning this task is made naturally and effortlessly
with a keyboard. Without thinking you are using a device that maps
to the same granularity of the text document.
But when trying to do the same with a mouse, not only does you hand
need to leave the keyboard, but now a great deal of thought and
physical agility is required to map from the pixel resolution of
the mouse to the character and line resolution of the document.
I have worked with a large number of programmers who can only operate
with a mouse. On occasion I have had to bite my tongue to stop from
laughing, as I watch them take two, three maybe more attempts to mark
an intricate text area using the mouse :)
> I think that, as a pointing device, a mouse is better than a
> keyboard, which makes it useful, for example, for copying text between
> different windows/frames.
The pointing device is generally easier to operate, and is much better
for editing documents with similar granularity (ie graphics).
But I have yet to see anyone use a mouse to edit text, faster than
someone with a set of well trained keyboard hands.
Jussi Jumppanen
Author of: Zeus for Windows (All new version 3.90 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com
Jussi Jumppanen
> In a real programmers editor that all happens automagically. I'm using
> JED in Brief mode, I press F10 to invoke make, a window split for
> compiler output appears (if it didn't already exist), Ctrl-N takes my
> edit window & the error window to the first error ready for editing.
> Ctrl-N steps forward through errors, Ctrl-P steps back.
>
> Why on earth would I want to complicate 'F10,Ctrl-N' by using a mouse?
IMHO the Brief keymap is a real work of art :)
There have been times when I have had to edit something without
the use of the Brief keymap, and it is times like these you realize
how powerful it really is.
Of course the same could be said for almost all of the programmer
editor keyboard mappings, but personally I still think the Brief
keymap is something very special :)
Paul Shirley
<jus...@zeusedit.com> writes
>The pointing device is generally easier to operate, and is much better
>for editing documents with similar granularity (ie graphics).
Its also useful in overcoming deficiencies in GUI environments. I find
it more productive to remove the deficiencies, either by avoiding the
GUI or choosing better tools. Example: I don't copy text between
multiple windows or apps, I load all the documents into one editor
instance and use the keyboard to swap between documents, no need to
point at anything.
Jason Creighton
ad_sc...@postmaster.co.uk (Antony) wrote:
Right: Every so often I try to read through :help quickref to get the
commands in my mind, so when I'm editing something I'll think "Hey, I
want to change from here to the end of this quoted string. I could use
ct" here!" [or some such command]
Plus it's interesting to see what, eg, Brief keymappings can do. I
always like it when the non-vi people come out of the woodwork to show
us what their editor can do. I find it interesting to contrast different
approaches.
Jason Creighton
Brian Masinick
> Frankly, I've found this whole thread quite silly, because we're
> counting *keystrokes*, not *speed*. If you sit down and think about it
> for 10 minutes, I'm sure you could dream up a low number of keystrokes
> for any (well, almost any) editor. Just like Perl golf.
>
> But, if you do it the first way that you think of, _then_ how long would
> it take? [note: I'm not talking about the "swap lines example here". I'm
> talking about the original example that was something like "lowercase
> here, remove these funny symbols, etc, etc"]
>
> Jason Creighton
On one hand, what you say is true. Perhaps the discussion is getting
a bit carried away to the extreme in terms of various methods and
keystrokes to do certain things. The discussion has had some value,
though. We've had some pretty good examples of regular expressions
that some lurkers may not have realized were even possible. We've
seen that there are many ways to accomplish any given task, and we've
seen that the editing tools that are available are extremely flexible,
so in that context, the discussion has not been a complete waste of
time, not for quite a few people, apparently.
--
Brian Masinick
mailto:masi...@yahoo.com
Jahagirdar Vijayvithal S
>
> But, if you do it the first way that you think of, _then_ how long would
> it take? [note: I'm not talking about the "swap lines example here". I'm
> talking about the original example that was something like "lowercase
> here, remove these funny symbols, etc, etc"]
>
> Jason Creighton
From what I have seen
At one extreme, some manually change/create the code *always*
At the other extreme some take hours to write a script to generate the
necessary code
And some where in between are those use a mix of manual coding scripting
and using macros/regexp/editor features to get the work done.
While the first wont benefit from this exercise the other two would
surely do.
Antony
> [...]
>
> Plus it's interesting to see what, eg, Brief keymappings
> can do. I always like it when the non-vi people come out
> of the woodwork to show us what their editor can do. I
> find it interesting to contrast different approaches.
Indeed. What are the Brief keymappings like? I've often
heard that Brief is highly though of, but I've never heard
anyone describe the specifics. I guess I could google, but
it would perhaps be more instructive to get a feel for the
editor from people that actually use it.
Antony
Jussi Jumppanen
> Indeed. What are the Brief keymappings like? I've often
> heard that Brief is highly though of, but I've never heard
> anyone describe the specifics. I guess I could google, but
> it would perhaps be more instructive to get a feel for the
> editor from people that actually use it.
My love for the Brief keyboard mapping dates back to the original
Brief editor that ran on O/S2 and MS-DOS. I am sure that most other
passionate Brief users also ran this original console based editor.
The Brief editor just did things really well. It had a well
designed keyboard mapping, amazing undo redo, a great scripting
engine, did amazing window buffer management (ie split windows,
multiple file buffer etc) and it also had some really well thought
out ideas about cut, copy and paste (ie used the num-keypad).
For the platforms that it ran it was the best and was truely
way ahead of it's time.
Unfortunately Brief died when Borland purchases the product at
version 3.10 and discontinued it one version later.
Today there are many editors that can reproduce the brief key
mapping which are quite simple:
Alt + W - file save
Alt + O - file save as
Alt + S - search
etc..
but Brief was always more than just a set of keyboard mappings.
Jussi Jumppanen
Author of: Zeus for Windows (All new version 3.90 out now)
"A humble clone of the Brief editor..."
Home Page: http://www.zeusedit.com
Paul Shirley
<jus...@zeusedit.com> writes
>Today there are many editors that can reproduce the brief key mapping
>which are quite simple:
>
> Alt + W - file save
> Alt + O - file save as
> Alt + S - search
> etc..
>
>but Brief was always more than just a set of keyboard mappings.
>
The key thing about the mappings is that all the common actions are just
1 keystroke away and mostly on the alpha keys so there's little finger
movement involved.
People love Brief because of all the other things it did, things like
scripting that most Un*x editors supported but no other DOS ones did.
The actual bindings are just a really nice bonus that feel like what a
touch typist would invent.
What really killed it was Windows co-opting of the Alt key for system
use. Using Brief mode in Visual Studio is a frustrating experience.
Which is why I run JED with menus disabled (to regain the alt key;)