Learning Lisp

[Anti Quark]

Recently started learning lisp, firstly, I have to admit I really do
love all the paranthesis. But there are other features of my old
language that I do miss.

Is lisp frequently used to develop web pages, if so can I get a easy
to use standalone install to do this? (e.g Wampserver for PHP)

Coming from netbeans I am finding emacs a bit, difficult. I really
don't like having to press the Ctrl button to do almost anything. Is
there a netbeanseque IDE for lisp?

I am really interested in lisp, but when learning a new language
worrying about an IDE should be the least of my worries. Maybe a lisp
plugin for netbeans? xD

On the whole I really like lisp and am eager to learn more.

Thanks for your time

[Pascal J. Bourguignon]

Anti Quark <photon...@gmail.com> writes:


> Recently started learning lisp, firstly, I have to admit I really do
> love all the paranthesis. But there are other features of my old
> language that I do miss.
>
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

Yes. http://www.cliki.net/admin/search?words=web

> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything.

You should map Control the key where Caps Lock usually is. (ie. on the
left of [A]).

> Is there a netbeanseque IDE for lisp?
>
> I am really interested in lisp, but when learning a new language
> worrying about an IDE should be the least of my worries. Maybe a lisp
> plugin for netbeans? xD

You're the netbeans specialist here. (I don't even know what it is).
You're a programmer. What are you waiting to write a lisp plugin for
netbeans?



--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[John Thingstad]

On 05/07/2012 12:44 PM, Anti Quark wrote:
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

I think most lisp developers prefer to write web-interfaces for their
software.
The best web server is probably hunchentoot
http://weitz.de/hunchentoot/
Though could download it from there the best way is to use quicklisp
http://www.quicklisp.org/beta/
In the Lisp REPL write (ql:quickload "hunchentoot")

It's a bit quirky if you are used to PHP, but if you know web
programming (CGI clients in all forms.. including PHP) then you should
pick it up pretty quick.

> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. Is
> there a netbeanseque IDE for lisp?
>

There is no netbean, but there is a Eclipse plug-in called Cusp
http://bitfauna.com/projects/cusp/

Most people just use Emacs with SLIME though as it over all has the best
Lisp interface.

[Alex Mizrahi]

> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

I'm not sure what do you mean by 'standalone', but it's very easy to run
Hunchentoot web server -- it requires like three lines of code.
You can install it with one command if you use quicklisp (and you should).

> Coming from netbeans I am finding emacs a bit, difficult.

LOL. I had to use netbeans today and I find it a bit difficult. Well,
not so much difficult as slow, verbose and buggy.

E.g. Netbeans 6.8 wasn't able to build project edited in Netbeans 7
until I manually deleted file and restarted IDE. The fuck?

> I really
> don't like having to press the Ctrl button to do almost anything.

You don't need to. Ctrl is totally unnecessary for writing code and
using REPL. Emacs isn't different from any other editor when you use CUA
mode.

You only need Ctrl to do things like compile code. Particularly, C-c
C-c. But it's really easy to press it, isn't it? C-c is a common
keybinding for copy/past, BTW.
Anyway, if you're more comfortable with other keybinding you can rebind it.
Or you can use menu. Really, I don't see how it's so much different from
netbeans.

> Is
> there a netbeanseque IDE for lisp?

No. It's a better idea to configure Emacs up to your taste.

What particular things bug you, aside from "it doesn't look like netbeans"?

Copy/paste? Yes, it is different, and thus inconvenient, but you can fix
it via CUA mode. Full CUA messes up C-x which is frequently used, but if
you don't mind using Ctrl-Ins, Shift-Ins, Shift-Del instead of C-c, C-v,
C-x there is also 'partial CUA' which works just fine.

That said, you can try commercial Lisp IDEs -- Allegro CL, Lispworks.
For learning, they are fine.

> I am really interested in lisp, but when learning a new language
> worrying about an IDE should be the least of my worries.

REPL is an important part of Common Lisp experience, and you have to use
somewhat different workflow to utilize it efficiently.
Working with Lisp might be different even if IDE looks like Netbeans.

It's better to embrace it than to fight it.

[Pascal J. Bourguignon]

Alex Mizrahi <alex.m...@gmail.com> writes:

> You don't need to. Ctrl is totally unnecessary for writing code and
> using REPL. Emacs isn't different from any other editor when you use
> CUA mode.
>
> You only need Ctrl to do things like compile code. Particularly, C-c
> C-c. But it's really easy to press it, isn't it?

You don't need to use control in emacs.

Type M-x slime-compile-defun RET instead of C-c C-c (or use the menu as
suggested by C-h f slime-compile-defun RET

You don't need to use control for "cut" "copy" and "paste" in emacs.
Use instead:

M-x kill-region RET ("cut")
M-w or M-x kill-ring-save RET ("copy")
M-x yank RET ("paste")

> C-c is a common keybinding for copy/past, BTW.

[Cthun]

On 07/05/2012 6:44 AM, Anti Quark wrote:
> Recently started learning lisp, firstly, I have to admit I really do
> love all the paranthesis. But there are other features of my old
> language that I do miss.
>
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)
>
> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. Is
> there a netbeanseque IDE for lisp?

Clojure to the rescue then. It's a Lisp that runs on the JVM, has a lot
of web-dev library support (and how! Server-side, client-side, DB
interface, you name it. And can be deployed at Hadoop fairly
painlessly.), and has a netbeans plugin (Enclojure) available.

On the other hand, it's not Common Lisp, so if your Lisp absolutely has
to be Common Lisp, you're out of luck there.

[Daimrod]

Anti Quark <photon...@gmail.com> writes:

> Recently started learning lisp, firstly, I have to admit I really do
> love all the paranthesis. But there are other features of my old
> language that I do miss.
>
> Is lisp frequently used to develop web pages, if so can I get a easy
> to use standalone install to do this? (e.g Wampserver for PHP)

I'm currently using Common Lisp to develop a small website interacting
with a PostgreSQL database and so far it's way better than doing it in
PHP.

> Coming from netbeans I am finding emacs a bit, difficult. I really
> don't like having to press the Ctrl button to do almost anything. Is
> there a netbeanseque IDE for lisp?

It could be worse, you could have to click-click-click everywhere to do
anything though you can still do it if you wish to. Moreover, you can
replace the CapsLock key by Control to make your life better.

> I am really interested in lisp, but when learning a new language
> worrying about an IDE should be the least of my worries. Maybe a lisp
> plugin for netbeans? xD

Learning the basic of emacs isn't a big deal at all, you can do the
tutorial (C-h t) in 20min or less and then your on your way. Plus, there
is already two or three tutorials which explains how to install SBCL +
SLIME. Oh, and you should look at paredit - an emacs minor mode - so you
don't have to worry about the parentheses.

[Alex Mizrahi]

> Learning the basic of emacs isn't a big deal at all, you can do the
> tutorial (C-h t) in 20min or less and then your on your way.

One which teaches to use C-p, C-b and so on instead of cursor keys?
Oh please. This *is* why people think that Emacs is old/hard to
learn/weird/obsolete.

There are only a couple of useful things described there, rest is
obsolete junk.

[Alex Mizrahi]

>> You only need Ctrl to do things like compile code. Particularly, C-c
>> C-c. But it's really easy to press it, isn't it?

> You don't need to use control in emacs.

Technically speaking, yes.

I was talking about what I use myself, though. Going through
command/menu each time would be sort of painful.

Although I didn't bother to learn slime-compile-file keybinding for
quite a while: I do not compile files that often.

People just overestimate how much they need to learn. There is just
handful of commands which are actually required to do development
comfortably.

However Emacs tutorial was written in times when cursor keys were not
common on keyboards and was not updated since. No wonder that newbies
find emacs difficult.

[Daimrod]

Once you understand that it's painless and faster to use the keys on or
around the home row it makes sense. Using the cursor keys is like using
the mouse, you have to leave your home row.

[Rupert Swarbrick]

Right, so you move your right hand to the arrow keys every time you need
to move in a buffer? Or maybe the mouse? How cute.

Rupert

[Tim Bradshaw]

On 2012-05-08 11:27:11 +0000, Alex Mizrahi said:

> One which teaches to use C-p, C-b and so on instead of cursor keys?

Yes, one for people who can type. Quaint, I know.

[Alessio Stalla]

On May 8, 2:23 pm, Rupert Swarbrick <rswarbr...@gmail.com> wrote:

I do, for instance. I even use the mouse from time to time (especially
if it's actually my laptop's touchpad). I've been using Emacs for
years, but never invested much time in learning complex commands or
changing my (undoubtedly poor) typing habits. Most of the time I spend
in front of Emacs, anyway, is really spent thinking, so I don't think
improving my typing speed of a few %s will buy me anything. Even if a
pro typist would be faster with C-foo than with arrow keys, I don't
want to spend time becoming a pro typist in the first place, and I
suspect most programmers are like me in that regard - especially those
that, like me, came to Emacs after other editors (Notepad++, Eclipse,
whatever).

So, yes, from the point of view of a little-more-than-newbie with
Emacs, I do think the tutorial is not fit for most Emacs newbies, as
it wasn't for me. I find Aquamacs' choice of using familiar
Command-... shortcuts to be most sensible; even if when I use it I
keep using C-x C-s, C-w, M-w, C-y, C-_ etc., I don't have any trouble
"teaching" a coworker how to use it. On non-Macs, keyboards often have
rarely used keys that can be used in place of Command for a similar
effect, for example there are often two distinct Control keys, Caps
Lock, and a Windows key which is even placed more or less where
Command is on Mac keyboards.

Alessio

[Pascal J. Bourguignon]

Alessio Stalla <alessi...@gmail.com> writes:

> I do, for instance. I even use the mouse from time to time (especially
> if it's actually my laptop's touchpad). I've been using Emacs for
> years, but never invested much time in learning complex commands or
> changing my (undoubtedly poor) typing habits. Most of the time I spend
> in front of Emacs, anyway, is really spent thinking, so I don't think
> improving my typing speed of a few %s will buy me anything. Even if a
> pro typist would be faster with C-foo than with arrow keys, I don't
> want to spend time becoming a pro typist in the first place, and I
> suspect most programmers are like me in that regard - especially those
> that, like me, came to Emacs after other editors (Notepad++, Eclipse,
> whatever).

http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html

[Alex Mizrahi]

>> There are only a couple of useful things described there, rest is
>> obsolete junk.

> Once you understand that it's painless and faster to use the keys on or
> around the home row it makes sense.

1. It's actually painful to hold ctrl all the time. Even if it's on caps
lock. The thing is, you press it with one finger, little finger that is.

2. It's painful to switch between different keybindings. I'm not going
to spend 100% of my time in Emacs. I also use browser, I use other
people's computers and so on. I want to use same keybindings even if it
is a tiny bit inefficient. After all, I don't switch between moving and
typing all the time.

3. I can go from letter keys to cursor keys without moving a hand on my
laptop. On a larger keyboard it takes fractions of second.

> Using the cursor keys is like using
> the mouse, you have to leave your home row.

No, it's not. It takes order of magnitude less time.

[Alex Mizrahi]

>> One which teaches to use C-p, C-b and so on instead of cursor keys?
> Yes, one for people who can type. Quaint, I know.

Wow, your programming is bottlenecked by your typing speed?

[Alex Mizrahi]

> Right, so you move your right hand to the arrow keys every time you need
> to move in a buffer?

Yeah, but believe me: when you're used to it hands really do it faster
than you can think.
I touch type, maybe not as fast as pro typists, but fast enough for my
purposes. OTOH I don't need to rely on 'home row', I can move my hands
freely, reaching any keys in and combinations.

> Or maybe the mouse?

Mouse is a completely different story, precise positioning of mouse
without taking feedback into account is extremely hard. So it switching
to mouse is order of magnitude slower than reaching some keys. But for
some things mouse is ok.

> How cute.

What isn't cute is RSI you get from typing too much. Maybe you should
learn how to organize your workflow in such a way that milliseconds
spent on moving fingers from home row to cursor keys will be absolutely
insignificant.

I wonder what do you guys do so that you need to type whole day long.

[Alex Mizrahi]

> http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html

Maybe if Yegge typed slower his essays would be shorter and more readable.

But, anyway, there isn't really a need to learn touch typing -- in a few
decades of intensive typing you can pick it up automatically. Not just
letters but all keys you use.

[Jumpin' Jehoshaphat]

On 08/05/2012 2:58 PM, Alex Mizrahi wrote:
> 3. I can go from letter keys to cursor keys without moving a hand on my
> laptop. On a larger keyboard it takes fractions of second.
>
>> Using the cursor keys is like using
>> the mouse, you have to leave your home row.
>
> No, it's not. It takes order of magnitude less time.

Where the hell is your mouse? Floating out there among the moons of
Jupiter? Mine is only about as far beyond the cursor keys as those are
beyond the alphabetic keys.

[Tim Bradshaw]

On 2012-05-08 18:29:47 +0000, Pascal J. Bourguignon said:

> http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html
>

When I rule the world[*] one of the first reforms (after all the
obvious tshooting-every-third-person stuff) is going to be to abolish
all the stupid "IT" courses that get taught in school and forcing
people to learn to type, because that's actually a useful skill.

[*] well, of cours, I already technically do, I just made the mistake
of delegating too much so I now have even more stringing-people-up
stuff to do.

[Tim Bradshaw]

On 2012-05-08 18:58:29 +0000, Alex Mizrahi said:

> 2. It's painful to switch between different keybindings. I'm not going
> to spend 100% of my time in Emacs. I also use browser, I use other
> people's computers and so on. I want to use same keybindings even if it
> is a tiny bit inefficient. After all, I don't switch between moving and
> typing all the time.

Your computer doesn't have emacs keybindings everythere? How quaint.

[Tim Bradshaw]

On 2012-05-08 19:01:37 +0000, Alex Mizrahi said:
>
> Wow, your programming is bottlenecked by your typing speed?

The same way my ability to do physics would be bottlenecked if I could
not do arithmetic reliably in my head, yes.

[Alex Mizrahi]

>>> Using the cursor keys is like using
>>> the mouse, you have to leave your home row.

>> No, it's not. It takes order of magnitude less time.

> Where the hell is your mouse? Floating out there among the moons of
> Jupiter? Mine is only about as far beyond the cursor keys as those are
> beyond the alphabetic keys.

It's not so much about distance to mouse as about nature of mouse
movement -- basically, you cannot position cursor without watching it
move. (Unless you're a Counter Strike pro who can headshot as soon as he
sees something.) A process of watching cursor move and coordinating your
hand is much slower than just sending commands to hands. It takes ~100
ms just to see something, latency of human sensory input is significant.
The only way you can do something quickly is to 'buffer' command to
muscles, but it's not possible with actions which require feedback.

[Alex Mizrahi]

>> 2. It's painful to switch between different keybindings. I'm not going
>> to spend 100% of my time in Emacs. I also use browser, I use other
>> people's computers and so on. I want to use same keybindings even if
>> it is a tiny bit inefficient. After all, I don't switch between moving
>> and typing all the time.

> Your computer doesn't have emacs keybindings everythere? How quaint.

I have more-or-less the same keybindings in all programs, including Emacs.

I wonder what do you do when you have to use somebody else's computer,
e.g. if they ask you to fix it. Panic?

[Espen Vestre]

Alex Mizrahi <alex.m...@gmail.com> writes:

> I wonder what do you do when you have to use somebody else's computer,
> e.g. if they ask you to fix it. Panic?

Each time my wife wants me to proof read something she has written in
Word on her machine, I panic. It's not that I never use anything else
than Emacs and Emacs-alikes, but whenever I use a wysiwig text editor
myself, I use Pages on the mac. Pages is a Cocoa program, and thus
understands the most basic Emacs control-key-bindings, which are hard
wired into my spine. But I still struggle with the fact that I have
assigned meta to the left command key on my mac, and thus frequently
quit programs when I feel like doing a "M-q" to fill a paragraph :-)
--
(espen)

[Alex Mizrahi]

>> Wow, your programming is bottlenecked by your typing speed?

> The same way my ability to do physics would be bottlenecked if I could
> not do arithmetic reliably in my head, yes.

Well, I never was good with arithmetic, but I really excelled in physics
in school: I won a number of city-wide physics competitions for children
of my age (and it was a fairly large city full of tech schools, so there
was some competition).

So I guess you meant that arithmetic is pretty much irrelevant for
solving physics problems just like typing is irrelevant for programming :)

That said, I agree that being very slow at typing (or not knowing tools)
might make programming very slow and uncomfortable. (Depending on a kind
of programming, of course -- some complex algorithms might be developed
on paper or even in one's head without any typing at all.)
But past some point, returns diminish to the point of becoming totally
irrelevant.

I even bought IBM Model M keyboard, but I'm afraid the only real effect
is that it sounds way louder and cooler than rubber dome keyboards.
I can only hope this sound stimulates brain activity or something...

[Pascal J. Bourguignon]

Tim Bradshaw <t...@tfeb.org> writes:

> On 2012-05-08 18:29:47 +0000, Pascal J. Bourguignon said:
>
>> http://steve-yegge.blogspot.com.es/2008/09/programmings-dirtiest-little-secret.html
>>
>
> When I rule the world[*] one of the first reforms (after all the
> obvious tshooting-every-third-person stuff) is going to be to abolish
> all the stupid "IT" courses that get taught in school and forcing
> people to learn to type, because that's actually a useful skill.

Well soon enough it won't be that useful.

http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html

[Tim Bradshaw]

On 2012-05-09 13:29:31 +0000, Alex Mizrahi said:

> I wonder what do you do when you have to use somebody else's computer,
> e.g. if they ask you to fix it. Panic?

Espen answered this better than I can.

[Tim Bradshaw]

On 2012-05-09 15:12:59 +0000, Alex Mizrahi said:

> So I guess you meant that arithmetic is pretty much irrelevant for
> solving physics problems just like typing is irrelevant for programming
> :)

No. You might be able to get away at school level without arithmetic
(by which I really mean "being really fluent with numbers") but you get
screwed later on.

I know this because at a slightly different level it's what happened to
me: I was lazy, didn't practice enough boring mathematical methods
stuff, and that lack of fluency came back and bit me later.

[Pascal J. Bourguignon]

I'd suggest a trackIR to move the mouse and click.
http://www.naturalpoint.com/trackir/

With 6 degrees of freedom, you can use yaw and pitch for mouse
movement, forward for click, left for middle click, right for right
click, and you have roll remaining for your own binding.

[Kaz Kylheku]

On 2012-05-09, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> Well soon enough it won't be that useful.
>
> http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html

Not if you're someone who types very fast, but doesn't exhibit brainwaves.

[Jumpin' Jehoshaphat]

ALL actions require feedback! I don't want to blindly issue commands to
my computer while not even looking to see if it's gone into Sorceror's
Apprentice mode deleting the wrong files or something.

Besides that, aren't you being a bit inconsistent? First, touch typing
is so great because you can keep your eyes on the screen and see what
the hell you're doing, in context -- then mousing is awful because you
must keep your eyes on the screen?

[Kaz Kylheku]

On 2012-05-09, Jumpin' Jehoshaphat <jj1058...@gmail.com> wrote:
> On 09/05/2012 9:27 AM, Alex Mizrahi wrote:
>>>>> Using the cursor keys is like using
>>>>> the mouse, you have to leave your home row.
>>
>>>> No, it's not. It takes order of magnitude less time.
>>
>>> Where the hell is your mouse? Floating out there among the moons of
>>> Jupiter? Mine is only about as far beyond the cursor keys as those are
>>> beyond the alphabetic keys.
>>
>> It's not so much about distance to mouse as about nature of mouse
>> movement -- basically, you cannot position cursor without watching it
>> move. (Unless you're a Counter Strike pro who can headshot as soon as he
>> sees something.) A process of watching cursor move and coordinating your
>> hand is much slower than just sending commands to hands. It takes ~100
>> ms just to see something, latency of human sensory input is significant.
>> The only way you can do something quickly is to 'buffer' command to
>> muscles, but it's not possible with actions which require feedback.
>
> ALL actions require feedback! I don't want to blindly issue commands to

This may be true, but not all actions have to wait for each piece of feedback
individually before proceeding.

The GUI requires instantaneous real-time feedback, which is different from
*eventual* feedback that the right thing was done as a result of
a sequence of actions.

You cannot queue mouse movements the way you can queue keystrokes.

For instance, if a GUI is lagged, you cannot simply go through the motions
of clicking on something to obtain a context menu, and making a selection
from that menu, and then watch as those actions take place later.

With a keyboard, you can do the equivalent of that, within the limits of your
typing accuracy.

Even if the machine you're working with is sharply responsive, there is still
lag: that in your brain.

Consciousness requires about 500 ms of processing (Benjamin Libet's "Half
Second Delay"). Whatever you think is happening "now" on your computer screen
actually happened about half a second ago.

To conquer the delay, you have to train your subsconscious "device drivers" to
handle events sooner, before consciousness takes place.

Anything that you can react to faster than 500 ms is done without
consciousness. If you react to something in 50 ms, then 450 ms later, you
become aware of what happened, and of course you convince yourself that you
consciously meant to do that. (In fact, you only meant to do that in the
sense that in the past you trained yourself to respond to that event in that
way; that's when the conscious decision was made.)

You will never eliminate all the delay in an inaccurate procedure that requires
corrective feedback. Not to the extent that you can eliminate it in a
procedure that is mostly pure output.

[Jumpin' Jehoshaphat]

On 09/05/2012 8:24 PM, Kaz Kylheku wrote:
> On 2012-05-09, Jumpin' Jehoshaphat<jj1058...@gmail.com> wrote:
>> On 09/05/2012 9:27 AM, Alex Mizrahi wrote:
>>>>>> Using the cursor keys is like using
>>>>>> the mouse, you have to leave your home row.
>>>
>>>>> No, it's not. It takes order of magnitude less time.
>>>
>>>> Where the hell is your mouse? Floating out there among the moons of
>>>> Jupiter? Mine is only about as far beyond the cursor keys as those are
>>>> beyond the alphabetic keys.
>>>
>>> It's not so much about distance to mouse as about nature of mouse
>>> movement -- basically, you cannot position cursor without watching it
>>> move. (Unless you're a Counter Strike pro who can headshot as soon as he
>>> sees something.) A process of watching cursor move and coordinating your
>>> hand is much slower than just sending commands to hands. It takes ~100
>>> ms just to see something, latency of human sensory input is significant.
>>> The only way you can do something quickly is to 'buffer' command to
>>> muscles, but it's not possible with actions which require feedback.
>>
>> ALL actions require feedback! I don't want to blindly issue commands to
>
> This may be true, but not all actions have to wait for each piece of feedback
> individually before proceeding.

They usually do, if you want to avoid and/or recover from mistakes.

Not only that, when actions can be queued up without feedback in between
then those actions should probably be automated with a script, not
entered manually.

> For instance, if a GUI is lagged, you cannot simply go through the motions
> of clicking on something to obtain a context menu, and making a selection
> from that menu, and then watch as those actions take place later.

These aren't the days of 300 baud modem links to 20-hops-away mainframes
anymore. Your system shouldn't be lagged, especially not if it's one
that even has a functioning mouse. If it is, you need to nice some
processes or something.

> With a keyboard, you can do the equivalent of that, within the limits of your
> typing accuracy.

And as likely as not end up with something like "The quick brown fox jlog".

> Even if the machine you're working with is sharply responsive, there is still
> lag: that in your brain.

If that's a problem, the only solution is to automate the task. It will
impede ANY manual task. If the manual task doesn't really require
feedback it doesn't really need to be manual does it?

> To conquer the delay, you have to train your subsconscious "device drivers" to
> handle events sooner, before consciousness takes place.

And this, you claim, is only possible with the keyboard? Then explain
people with much faster reaction times playing first person shooters.
Better yet, explain why the number one rule for proficiency in those
that the good players will tell you over and over again, unanimously, is
"use the mouse and not only the keyboard!".

> You will never eliminate all the delay in an inaccurate procedure that requires
> corrective feedback. Not to the extent that you can eliminate it in a
> procedure that is mostly pure output.

If it's pure output it's either "naturally" typing something you thought
up or else it's something that you can automate. If it's data entry it's
typing. If it's command entry it's scriptable.

[Pascal J. Bourguignon]

Jumpin' Jehoshaphat <jj1058...@gmail.com> writes:

> On 09/05/2012 8:24 PM, Kaz Kylheku wrote:
>> For instance, if a GUI is lagged, you cannot simply go through the motions
>> of clicking on something to obtain a context menu, and making a selection
>> from that menu, and then watch as those actions take place later.
>
> These aren't the days of 300 baud modem links to 20-hops-away
> mainframes anymore. Your system shouldn't be lagged, especially not if
> it's one that even has a functioning mouse. If it is, you need to nice
> some processes or something.

No indeed. But we're still at the time when big companies are made by
convincing people that they need to buy a new computer (or phone or pad)
every year, and this is done by providing for "free" "upgrades" of the
system that are more and more bloated, and provide slower and slower
reaction time. Lag indeed.

>> With a keyboard, you can do the equivalent of that, within the limits of your
>> typing accuracy.
>
> And as likely as not end up with something like "The quick brown fox jlog".

Which is why you use an editor and not just cat(1).

> If it's pure output it's either "naturally" typing something you
> thought up or else it's something that you can automate. If it's data
> entry it's typing. If it's command entry it's scriptable.

And how do you enter the script? What do you think we're doing all day
long? We're PROGRAMMERS!

[Kaz Kylheku]

Right, and that script should be written by clicking the mouse on various
locations of picture of a QWERTY keyboard to avoid any queuing prior
to that script being run. :)

>> For instance, if a GUI is lagged, you cannot simply go through the motions
>> of clicking on something to obtain a context menu, and making a selection
>> from that menu, and then watch as those actions take place later.
>
> These aren't the days of 300 baud modem links to 20-hops-away mainframes
> anymore. Your system shouldn't be lagged, especially not if it's one
> that even has a functioning mouse. If it is, you need to nice some
> processes or something.

And then there is networking.

>> With a keyboard, you can do the equivalent of that, within the limits of your
>> typing accuracy.
>
> And as likely as not end up with something like "The quick brown fox jlog".

In mouse terms, the accuracy of this is astronomical.

>> Even if the machine you're working with is sharply responsive, there is still
>> lag: that in your brain.
>
> If that's a problem, the only solution is to automate the task. It will
> impede ANY manual task. If the manual task doesn't really require
> feedback it doesn't really need to be manual does it?

Writing a novel is just so much typing; so automate it!

Fixing a bug in code: automate it.

An existence proof would go a long way here.

If what I do could be automated, it would be. :)

>> To conquer the delay, you have to train your subsconscious "device drivers" to
>> handle events sooner, before consciousness takes place.
>
> And this, you claim, is only possible with the keyboard? Then explain

Absolutely.

> people with much faster reaction times playing first person shooters.
> Better yet, explain why the number one rule for proficiency in those
> that the good players will tell you over and over again, unanimously, is
> "use the mouse and not only the keyboard!".

Because the way the keyboard control behaves in those games is like a very
dumb mouse.

Yes, a mouse is better than using cursor keys to implement a low-level
simulation of a mouse.

Shooter games do not not have an efficient keyboard interface for easy
selection of targets, because ... doh ... that would, like, be cheating?

An efficient keyboard client for a first person shooter would identify the
vulnerable points of several targets in the visual field and simply let you
[Tab] through them. Or show little numbers or letters next to them so you could
select which ever you want: random access. Moreover, only your foes would be
thus flagged, never your friends.

So imagine entering a scene. There are two of your friends and three foes.
Little targets appear on the heads of the foes, labelled A, B, and C.

All you have to do is type A, B, and C to select each one and shoot.

Moreover, suppose you can just type ABC very fast, and the shooting then
happens later: your crosshairs move to A, shoot. Then to B, shoot. Then to C.
Shoot.

You could play this game with your eyes closed. Just position yourself with
your back in a corner, close your eyes, and type ABC ABC ABC ...

Likewise, the mouse interface of these games could be better also, if the goal
was efficient targetting. It could have "snap to target", the way editors
for graphics have "snap to point".

Freehand graphics: that's one area where the mouse is handy. But for actually
drawing a decent shape, it's horrible. You need a tablet with a stylus. The
mouse is not strictly better for all 2D stuff. Many kinds of CAD tasks work
better with a keyboard, whenever there is a lot of horizontal and vertical
alignment, and a regular grid. A mouse brings next to nothing to PCB layout
for instance.

[Jumpin' Jehoshaphat]

On 09/05/2012 9:25 PM, Pascal J. Bourguignon wrote:
> Jumpin' Jehoshaphat<jj1058...@gmail.com> writes:
>
>> On 09/05/2012 8:24 PM, Kaz Kylheku wrote:
>>> For instance, if a GUI is lagged, you cannot simply go through the motions
>>> of clicking on something to obtain a context menu, and making a selection
>>> from that menu, and then watch as those actions take place later.
>>
>> These aren't the days of 300 baud modem links to 20-hops-away
>> mainframes anymore. Your system shouldn't be lagged, especially not if
>> it's one that even has a functioning mouse. If it is, you need to nice
>> some processes or something.
>
> No indeed. But we're still at the time when big companies are made by
> convincing people that they need to buy a new computer (or phone or pad)
> every year, and this is done by providing for "free" "upgrades" of the
> system that are more and more bloated, and provide slower and slower
> reaction time. Lag indeed.

If you're dumb enough to use Windoze, sure.

>>> With a keyboard, you can do the equivalent of that, within the limits of your
>>> typing accuracy.
>>
>> And as likely as not end up with something like "The quick brown fox jlog".
>
> Which is why you use an editor and not just cat(1).

?? It's not the editor, it's the OS. If more than around 16-32
keystrokes get backlogged, depending on the OS, some tend to get dropped
instead of sent to the application.

>> If it's pure output it's either "naturally" typing something you
>> thought up or else it's something that you can automate. If it's data
>> entry it's typing. If it's command entry it's scriptable.
>
> And how do you enter the script? What do you think we're doing all day
> long? We're PROGRAMMERS!

Entering a script is something that's naturally done by keyboard rather
than by mouse. The discussion was manually entering commands, not code
or data.

[Kaz Kylheku]

On 2012-05-10, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> Jumpin' Jehoshaphat <jj1058...@gmail.com> writes:

>> If it's pure output it's either "naturally" typing something you
>> thought up or else it's something that you can automate. If it's data
>> entry it's typing. If it's command entry it's scriptable.
>
> And how do you enter the script? What do you think we're doing all day
> long? We're PROGRAMMERS!

Why, drag and drop. You have icons on the desktop for all possible characters,
and then you just drag them one by one to the script icon.

--
If you ever need any coding done, I'm your goto man!

[Jumpin' Jehoshaphat]

On 10/05/2012 12:00 AM, Kaz Kylheku wrote:
> On 2012-05-10, Jumpin' Jehoshaphat<jj1058...@gmail.com> wrote:
>> Not only that, when actions can be queued up without feedback in between
>> then those actions should probably be automated with a script, not
>> entered manually.
>
> Right, and that script should be written by clicking the mouse on various
> locations of picture of a QWERTY keyboard

Not unless you're stuck developing on a phone or a pad.

>>> For instance, if a GUI is lagged, you cannot simply go through the motions
>>> of clicking on something to obtain a context menu, and making a selection
>>> from that menu, and then watch as those actions take place later.
>>
>> These aren't the days of 300 baud modem links to 20-hops-away mainframes
>> anymore. Your system shouldn't be lagged, especially not if it's one
>> that even has a functioning mouse. If it is, you need to nice some
>> processes or something.
>
> And then there is networking.

What does that have to do with the responsiveness of the local software
(whether browser, NNTP client, etc. or nonnetworked software) to mouse
input?

Besides, if the network is slow and that's making a browser web app
slow, it's going to be impossible to use without waiting whether you use
the keyboard or the mouse. Until the server response to the previous
input is received and the browser loads new stuff, it won't respond to a
keystroke as you'd expect. You can't queue up keystroke commands to web
apps. (Typing into a form on the webpage, sure, but that's typing into a
local buffer the entire contents of which are sent to the server in one
shot when you hit "send" afterward.)

>>> With a keyboard, you can do the equivalent of that, within the limits of your
>>> typing accuracy.
>>
>> And as likely as not end up with something like "The quick brown fox jlog".
>
> In mouse terms, the accuracy of this is astronomical.

I don't care. It's still not good enough; ergo, the smart thing to do
with an unresponsive system is wait.

>>> Even if the machine you're working with is sharply responsive, there is still
>>> lag: that in your brain.
>>
>> If that's a problem, the only solution is to automate the task. It will
>> impede ANY manual task. If the manual task doesn't really require
>> feedback it doesn't really need to be manual does it?
>
> Writing a novel is just so much typing; so automate it!

That's data entry, not command inputs.

> Fixing a bug in code: automate it.

That's data entry, not (immediately executed) command inputs.

>>> To conquer the delay, you have to train your subsconscious "device drivers" to
>>> handle events sooner, before consciousness takes place.
>>
>> And this, you claim, is only possible with the keyboard? Then explain

>> people with much faster reaction times playing first person shooters.
>> Better yet, explain why the number one rule for proficiency in those
>> that the good players will tell you over and over again, unanimously, is
>> "use the mouse and not only the keyboard!".
>
> Because the way the keyboard control behaves in those games is like a very
> dumb mouse.

Feel free to suggest a superior keyboard interface then. One that
wouldn't be blatant cheating, of course.

> Likewise, the mouse interface of these games could be better also, if the goal
> was efficient targetting. It could have "snap to target", the way editors
> for graphics have "snap to point".

Some of them do, on the lowest difficulty setting; the crosshair may not
snap but the shot still might if it's aimed accurately enough.

Of course, only wusses play on those difficulty levels. ;)

> Freehand graphics: that's one area where the mouse is handy. But for actually
> drawing a decent shape, it's horrible. You need a tablet with a stylus. The
> mouse is not strictly better for all 2D stuff. Many kinds of CAD tasks work
> better with a keyboard, whenever there is a lot of horizontal and vertical
> alignment, and a regular grid. A mouse brings next to nothing to PCB layout
> for instance.

Wrong again. You need snap-to and similar features, as well as ways to
procedurally generate exact shapes such as circles, ellipses, and
regular polygons. On the other hand, it's a lot faster and more
intuitive to position graphics objects with a mouse than by holding down
some direction key and watching it crawl across the screen, plus having
the fun of figuring out how the hell to select something --
tab/shift-tab or similar has problems with imposing an arbitrary and
usually rather unpredictable sequencing on 2D-disseminated things that
probably aren't neatly arranged in reading order on a grid like dialog
box controls; whereas some sort of control-arrow-key type deal for
move-to-next-below, move-to-next-left, etc. has its own problems when
there's a selected object, a close by object off at a 45 degree angle or
so, and maybe a more distant one in an adjacent cardinal direction as
well. The only situation where there's a clear advantage over a mouse is
to select an object completely covered by another object, or an object
so thin that it's nigh-impossible to click on it, or so small you can't
click on it without clicking a control handle that does something other
than just select it. And then what you want it an alternate selection
mechanism *in addition to* standard click-selection. Such as a
(keyboard-and-mouse-enabled) object list you can bring up and choose
from, or a key command to cycle the selection through everything in
Z-order that overlaps the pixel beneath the pointer, or something.

[Madhu]

* Jumpin' Jehoshaphat <jofenu$3vm$2...@speranza.aioe.org> :
Wrote on Thu, 10 May 2012 00:04:14 -0400:

|> No indeed. But we're still at the time when big companies are made
|> by convincing people that they need to buy a new computer (or phone
|> or pad) every year, and this is done by providing for "free"
|> "upgrades" of the system that are more and more bloated, and provide
|> slower and slower reaction time. Lag indeed.
|
| If you're dumb enough to use Windoze, sure.

BS. As far as OS/Distro/Software strategies go Linux, Macs, Windows etc.
are indistinguishable in this regard. Microsoft just happened to
pioneer the revenue model, stanford capital has appropriated, (as with
ajax etc), if you know any exceptions I'd be glad to hear about it.

Most of the time the software is multiplatform, like AOL/Firefox. All
the paychecks in this business are either to breed the next generation
of consumers, or to introduce said bloat and inefficiencies in the
platform that can eventually be monetized. --- Madhu

[nick_keigh...@hotmail.com]

On Wednesday, May 9, 2012 11:23:24 PM UTC+1, Jumpin&#39; Jehoshaphat wrote:
> On 09/05/2012 9:27 AM, Alex Mizrahi wrote:

> >>>> Using the cursor keys is like using
> >>>> the mouse, you have to leave your home row.
> >
> >>> No, it's not. It takes order of magnitude less time.
> >
> >> Where the hell is your mouse? Floating out there among the moons of
> >> Jupiter? Mine is only about as far beyond the cursor keys as those are
> >> beyond the alphabetic keys.
> >
> > It's not so much about distance to mouse as about nature of mouse
> > movement -- basically, you cannot position cursor without watching it
> > move. (Unless you're a Counter Strike pro who can headshot as soon as he
> > sees something.) A process of watching cursor move and coordinating your
> > hand is much slower than just sending commands to hands. It takes ~100
> > ms just to see something, latency of human sensory input is significant.
> > The only way you can do something quickly is to 'buffer' command to
> > muscles, but it's not possible with actions which require feedback.
>
> ALL actions require feedback! I don't want to blindly issue commands to
> my computer while not even looking to see if it's gone into Sorceror's
> Apprentice mode deleting the wrong files or something.

Ah! TECO!

[Alex Mizrahi]

>> So I guess you meant that arithmetic is pretty much irrelevant for
>> solving physics problems just like typing is irrelevant for
>> programming :)

> No. You might be able to get away at school level without arithmetic (by
> which I really mean "being really fluent with numbers") but you get
> screwed later on.

Huh? At school level people work with concrete numbers, but on more
advanced level there are barely any numbers in formulas.

I don't know much above physics above school level, but I've got M.Sc.
applied math degree without being particularly good at arithmetics.
We had only a couple of courses which actually involved arithmetics, and
teachers admitted that they are not just computerized enough.
(Later I've actually developed a program which allowed students to solve
concrete linear optimization problems with numbers (to practice
understanding of the algorithm) without wasting their times on
calculations.)

> I know this because at a slightly different level it's what happened to
> me: I was lazy, didn't practice enough boring mathematical methods
> stuff, and that lack of fluency came back and bit me later.

Math =/= arithmetics.

Essential difference is that arithmetics in mechanical while math is
like puzzle-solving. We can offload the former to computers, but not the
later, as it requires actual thinking.

If you're confusing purely mechanical skills like typing and arithmetics
with problem solving, well, I understand how it bit you.

[Alex Mizrahi]

> ALL actions require feedback! I don't want to blindly issue commands to
> my computer while not even looking to see if it's gone into Sorceror's
> Apprentice mode deleting the wrong files or something.

The difference is that with mouse you need feedback for each action, you
need feedback immediately as it blocks you.

But with keyboards you can issue multiple keypresses at once and look
for results later. So this check can be postponed.

It's pretty much the same difference as between primitive networking
protocol which requires receiving ack packet before sending another one,
thus limiting packet-per-second to 1/round_trip_time; and protocols like
TCP which have multiple packets in flight so that bandwidth of network
can be fully utilized regardless of latency.

> Besides that, aren't you being a bit inconsistent?
> First, touch typing
> is so great because you can keep your eyes on the screen and see what
> the hell you're doing, in context -- then mousing is awful because you
> must keep your eyes on the screen?

No, you're just using straw man shamelessly here.

I never said that touch typing is great and that I want to keep my eyes
on the screen.

But if you want me to elaborate, touch typing is great because it
doesn't require you focusing attention on a particular thing, it gives
you more freedom, and this allows more efficient utilization of resources.

I never said that mouse is awful, it's just a slower compared to keyword
in many cases (but not all). I use mouse wherever speed isn't important,
i.e. for infrequently done actions.

[Jumpin' Jehoshaphat]

On 10/05/2012 4:46 AM, Alex Mizrahi wrote:
>> ALL actions require feedback! I don't want to blindly issue commands to
>> my computer while not even looking to see if it's gone into Sorceror's
>> Apprentice mode deleting the wrong files or something.
>
> The difference is that with mouse you need feedback for each action, you
> need feedback immediately as it blocks you.
>
> But with keyboards you can issue multiple keypresses at once and look
> for results later. So this check can be postponed.

As mentioned in another post, this can be useful for data entry on an
old, cruddy, lagged system or a laggy oldfashioned telnet connection.
For command entry it's just asking for trouble. Enter a directory and
select the third file to be deleted sight-unseen? Er, I don't think so.
What if the third file isn't what you assumed it would be? You could be
misremembering, or other users (if any) may have added or removed or
renamed files in there.

>> Besides that, aren't you being a bit inconsistent?
>> First, touch typing
>> is so great because you can keep your eyes on the screen and see what
>> the hell you're doing, in context -- then mousing is awful because you
>> must keep your eyes on the screen?
>
> No, you're just using straw man shamelessly here.

Don't be ridiculous. I'm just pointing out an inconsistency in the
pro-keyboard-only position.

> I never said that mouse is awful, it's just a slower compared to keyword
> in many cases (but not all). I use mouse wherever speed isn't important,
> i.e. for infrequently done actions.

As do I, for the most part; also for some actions that involve selecting
from large numbers of options (you can acquire from a 2D array much
faster than from a 1D list and much faster with a random-access-ish
selection mechanism than with an arrow-your-way-around mechanism, so
unless the items have names you can select via short unique prefixes...)
and actions in a graphics-manipulation context (Photoshop, mainly).

[Jumpin' Jehoshaphat]

On 10/05/2012 1:05 AM, Madhu wrote:
>
> * Jumpin' Jehoshaphat<jofenu$3vm$2...@speranza.aioe.org> :
> Wrote on Thu, 10 May 2012 00:04:14 -0400:
>
> |> No indeed. But we're still at the time when big companies are made
> |> by convincing people that they need to buy a new computer (or phone
> |> or pad) every year, and this is done by providing for "free"
> |> "upgrades" of the system that are more and more bloated, and provide
> |> slower and slower reaction time. Lag indeed.
> |
> | If you're dumb enough to use Windoze, sure.
>
> BS.

Classic unsubstantiated and erroneous claim.

> As far as OS/Distro/Software strategies go Linux, Macs, Windows etc.
> are indistinguishable in this regard. Microsoft just happened to
> pioneer the revenue model,

Classic illogic. The revenue model for Linux does not depend on the user
buying upgrades.

> Most of the time the software is multiplatform, like AOL/Firefox. All
> the paychecks in this business are either to breed the next generation
> of consumers, or to introduce said bloat and inefficiencies in the
> platform that can eventually be monetized. --- Madhu

Classic paranoia. Where is Mozilla's alleged financial interest in
making people buy the latest and greatest CPU, mobo, and GPU? Kickbacks
from Intel, AMD, ATI, Asus, and nVidia? What's your evidence in support
of your outlandish conspiracy theory, Madhu?

[nick_keigh...@hotmail.com]

but not arithmatic. I did maths and physics at university level and poor arithmatic was no obstacle (there are these things called "calculators" or even "slide-rules")

[Xah Lee]

On May 9, 6:59 am, Espen Vestre <es...@vestre.net> wrote:

time to install ErgoEmacs. Increase your keyboarding efficiency 10
times. Packages also available to make your whole system ErgoEmacs.

Xah

[Tim Bradshaw]

On 2012-05-10 00:58:31 +0000, Jumpin' Jehoshaphat said:

> They usually do, if you want to avoid and/or recover from mistakes.

Well, clearly they don't, sorry. Let's get away from the typing thing:
how many notes a second can a good pianist play? How fast can a
musician who is imprivising play? How are they doing that?

[Alex Mizrahi]

> As mentioned in another post, this can be useful for data entry on an
> old, cruddy, lagged system or a laggy oldfashioned telnet connection.

You didn't understand my point at all. The bottleneck is often in human
sensory input.

But it helps with those 'lagged systems' too. Maybe in your ideal world
computers never go slow, but in reality it isn't the case. Even most
modern systems can go thrashing if something goes awry, and in my
experience it's better to use text console at that time.

Also, if you just happen to need to work with server in California from
Europe you have ~300 ms roundtrip for each packet just due to the speed
of the light. No matter how fast your network is and how fast your
computer it. In command prompt it is noticeable, but not problematic at
all. With GUI it might be more of an issue.

> For command entry it's just asking for trouble. Enter a directory and
> select the third file to be deleted sight-unseen? Er, I don't think so.
> What if the third file isn't what you assumed it would be? You could be
> misremembering, or other users (if any) may have added or removed or
> renamed files in there.

You're strawmanning shit out of this. Not all commands are deleting
files. Shell commands reference file name, but not position.

I can type `cd .. <enter> ls` without checking that cd was correct. In
the worst case I'd have to type it again. It isn't like cd will
accidentally turn to `rm -rf` a.

When I'm typing commands I'm very aware of what they do. So I need
different levels of attention, and I can do cd/ls stuff much faster than
rm -rf. And that's actually great because maybe 90% of commands are like
cd/ls but not rm.

You buffer commands at a rate it makes sense. Even if you call rm, you
can first type the whole thing, and then read it before pressing enter.

So it is:

rm -rf frobla.txt <look that it's correct> <enter>

Not

r <look> m <look> <space> <look> - <look> r <look> f <look> <space>
<look> ...


Got it?

In reality it's more like
1. rm -rf fro<TAB>
2. look whether it was completed, there is a list of options or ...
3. when everything looks OK press enter.

So I'm able to enter a number of semantic units before I need to look at
output, and output doesn't just confirm that I typed stuff correctly,
but also includes response from file system.

Please learn how to use shell before criticizing it.

>> No, you're just using straw man shamelessly here.

> Don't be ridiculous. I'm just pointing out an inconsistency in the
> pro-keyboard-only position.

And who holds that pro-keyboard-only position? A strawman?

> As do I, for the most part; also for some actions that involve selecting
> from large numbers of options (you can acquire from a 2D array much
> faster than from a 1D list and much faster with a random-access-ish
> selection mechanism than with an arrow-your-way-around mechanism, so
> unless the items have names you can select via short unique prefixes...)

If information is textual chances are that incremental search would have
worked better.

> and actions in a graphics-manipulation context (Photoshop, mainly).

Except that graphics professionals use pen tablets. You know why?
They don't require feedback from screen. Pen tablets have absolute
positioning unlike mouses which have relative positioning. This means
that pen tablet reproduces your motion exactly, you don't need to follow
cursor to draw a curve you want.

I have wacom pen tablet which can also work in mouse mode (when no
driver is installed, for example). I tried writing something in mouse
mode and in tablet mode and results were very different. In tablet mode
I can write something just like I write something on paper and it
appears on screen verbatim, In mouse mode writing appears to be totally
fucked up so you need to watch how cursor moves to have anything readable.

[Tim Bradshaw]

On 2012-05-10 09:24:26 +0000, Jumpin' Jehoshaphat said:

> Classic paranoia. Where is Mozilla's alleged financial interest in
> making people buy the latest and greatest CPU, mobo, and GPU? Kickbacks
> from Intel, AMD, ATI, Asus, and nVidia? What's your evidence in support
> of your outlandish conspiracy theory, Madhu?

You know, there's some kind of horror movie script idea here, where it
turns out that some terrible virus of the mind is spreading over the
internet, the victims getting trapped in a loop where they repeat a
small number of stylised phrases, eventually starving to death, to be
found, wormy and decaying, over their keyboards. How will our hero
stop the spread of the plague? Stealing a nuke and destroying the
internet via EMP seems the only option.

Oh: who do you think fund Mozilla? Where does their income come from?
Gosh, what a susprise!

[Tim Bradshaw]

On 2012-05-10 04:04:42 +0000, Kaz Kylheku said:

> Why, drag and drop. You have icons on the desktop for all possible characters,
> and then you just drag them one by one to the script icon.

You think that's a joke, but have you seen any of the maths editors
people use? A lot of them are just like that.

[Jumpin' Jehoshaphat]

On 10/05/2012 7:33 AM, Tim Bradshaw wrote:
> On 2012-05-10 09:24:26 +0000, Jumpin' Jehoshaphat said:
>
>> Classic paranoia. Where is Mozilla's alleged financial interest in
>> making people buy the latest and greatest CPU, mobo, and GPU?
>> Kickbacks from Intel, AMD, ATI, Asus, and nVidia? What's your evidence
>> in support of your outlandish conspiracy theory, Madhu?
>
> You know, there's some kind of horror movie script idea here, where it
> turns out that some terrible virus of the mind is spreading over the
> internet, the victims getting trapped in a loop where they repeat a
> small number of stylised phrases, eventually starving to death, to be
> found, wormy and decaying, over their keyboards. How will our hero stop
> the spread of the plague? Stealing a nuke and destroying the internet
> via EMP seems the only option.

What does that have to do with Lisp, Bradshaw?

> Oh: who do you think fund Mozilla? Where does their income come from?
> Gosh, what a susprise!

I very much doubt it's conditioned on intentionally bloating their
software, Bradshaw.

[Jumpin' Jehoshaphat]

Probably because no standard store-bought keyboard has the alphabet, the
digits, the commonplace punctuation, the Greek alphabet, an integral
sign, dot-in-circle, aleph, square-root sign, del, grad, +/-,
squiggle-equals, not-equals, intersection, union, element-of, ...
symbols and a bunch of extra shift keys for overbar and the like.

So it's either toolbar buttons, an emacsesque bestiary of
impossible-to-memorize-them-all control-key combinations most of which
have no mnemonic connection with what they insert, or typing in verbose
markup like TeX code. (TeX editors sometimes give you the choice between
the toolbar buttons and manually typing in TeX markup. Useful if you
memorize the most commonly needed markup but can then just dig in the
toolbar drop-downs for less-often-used symbols instead of having to task
switch to a cheat-sheet, read some possibly-long string, switch back,
and type it, or copy and paste it.)

[Jumpin' Jehoshaphat]

On 10/05/2012 7:18 AM, Tim Bradshaw wrote:
> On 2012-05-10 00:58:31 +0000, Jumpin' Jehoshaphat said:
>
>> They usually do, if you want to avoid and/or recover from mistakes.
>
> Well, clearly they don't, sorry. Let's get away from the typing thing:
> how many notes a second can a good pianist play?

Data entry, of a sort, not command entry.

[Jumpin' Jehoshaphat]

On 10/05/2012 7:32 AM, Alex Mizrahi wrote:
>> As mentioned in another post, this can be useful for data entry on an
>> old, cruddy, lagged system or a laggy oldfashioned telnet connection.
>
> You didn't understand my point at all.

That is incorrect. I just didn't agree with it.

> The bottleneck is often in human sensory input.

Good FPS players prove you wrong.

> But it helps with those 'lagged systems' too. Maybe in your ideal world
> computers never go slow, but in reality it isn't the case. Even most
> modern systems can go thrashing if something goes awry, and in my
> experience it's better to use text console at that time.

In my experience it's better to fix whatever the problem is (e.g. nice a
process that started hogging the CPU, or restart it if it's not supposed
to occasionally do that, or even debug it and recompile it) than to just
try to carry on regardless.

> Also, if you just happen to need to work with server in California from
> Europe you have ~300 ms roundtrip for each packet just due to the speed
> of the light.

Input to your locally-running browser will not be affected by this.
Stuff typed into a web form will echo promptly and mouse movement won't
be affected. It may just take a while for the response to get back to
you after you click "submit" or a link or whatever.

> No matter how fast your network is and how fast your
> computer it. In command prompt it is noticeable, but not problematic at
> all. With GUI it might be more of an issue.

You're hypothesizing somehow puppetting a GUI that's running on *the
remote machine* rather than using a local client or web browser to
communicate with the server. That would be ... weird. Mostly you use a
web interface to a remote machine these days. If for some reason you
can't (usually because you're the admin trying to remote-fix the machine
after the httpd died) you grit your teeth, ssh into it, and use a
command prompt. So when there's a GUI its mouse/keyboard feedback loop
is local rather than stretching over the network.

>> For command entry it's just asking for trouble. Enter a directory and
>> select the third file to be deleted sight-unseen? Er, I don't think so.
>> What if the third file isn't what you assumed it would be? You could be
>> misremembering, or other users (if any) may have added or removed or
>> renamed files in there.
>
> You're strawmanning shit out of this.

Classic unsubstantiated and erroneous claims.

> Not all commands are deleting files.

That was an example.

> Shell commands reference file name, but not position.

The example was using a program more like dired rather than a command
prompt.

> I can type `cd .. <enter> ls` without checking that cd was correct. In
> the worst case I'd have to type it again. It isn't like cd will
> accidentally turn to `rm -rf` a.

Actually, if there's line noise you never know. ;)

> When I'm typing commands I'm very aware of what they do. So I need
> different levels of attention, and I can do cd/ls stuff much faster than
> rm -rf. And that's actually great because maybe 90% of commands are like
> cd/ls but not rm.

You could still find yourself wasting time, at the very least, if you
wind up taking a wrong turn somewhere while overdriving your headlights,
even if you manage not to crash.

> rm -rf frobla.txt <look that it's correct> <enter>

And if you're in the wrong directory and there are frobla.txts you don't
want to delete as well as ones you do, in different parts of the
filesystem ...

> In reality it's more like
> 1. rm -rf fro<TAB>
> 2. look whether it was completed, there is a list of options or ...
> 3. when everything looks OK press enter.

The GUI equivalent would be to click a file and hit del. You'd have to
look to see that it had acknowledged your click and selected the file
before hitting del, but that's the same as your having to look before
hitting enter.

Where you went off the rails is comparing keystrokes to mouse clicks.
Everything but the "rm" and "enter" parts correspond to one single mouse
click to select the file. The del key supplies those parts (and gives a
confirmation prompt in any decent GUI file manager to boot, as one added
level of safety).

If you're deleting all files of that name under some directory, if
you're using a recent Windoze you'd type frobla into the search box,
wait for it to find everything, then hit ctrl+A DEL. Again one wait.

> Please learn how to use shell before criticizing it.

Classic erroneous presupposition.

>>> No, you're just using straw man shamelessly here.
>
>> Don't be ridiculous. I'm just pointing out an inconsistency in the
>> pro-keyboard-only position.
>
> And who holds that pro-keyboard-only position?

You, Madhu, and Kylheku, at the very least.

>> As do I, for the most part; also for some actions that involve selecting
>> from large numbers of options (you can acquire from a 2D array much
>> faster than from a 1D list and much faster with a random-access-ish
>> selection mechanism than with an arrow-your-way-around mechanism, so
>> unless the items have names you can select via short unique prefixes...)
>
> If information is textual chances are that incremental search would have
> worked better.

Information is often not textual, or not solely textual. Textual
information often lacks short unique prefixes on each item, or one
doesn't quickly remember the one desired. It's faster to recognize a
particular icon, if that's unique to your target, than to recognize a
particular short snippet of text, even if that's also unique, since the
latter is made of nonunique individual letters.

>> and actions in a graphics-manipulation context (Photoshop, mainly).
>
> Except that graphics professionals use pen tablets. You know why?
> They don't require feedback from screen. Pen tablets have absolute
> positioning unlike mouses which have relative positioning. This means
> that pen tablet reproduces your motion exactly, you don't need to follow
> cursor to draw a curve you want.

That's when drawing freehand rather than doing something else, such as
dragging pre-created image fragments around and assembling them in some
manner or applying filters, etc.

There's more sorts of graphics work than you seem to be assuming.

Also, pen tablets are expensive. The last time I saw any in a store the
cheapest was 4-5x the cost of a decent mouse. Not everyone is going to
spring for something like that. Particularly among those who work with
graphics a fair bit but *not* in a capacity where they get paid to do
so, or at least to do so very often.

[Pascal J. Bourguignon]

Jumpin' Jehoshaphat <jj1058...@gmail.com> writes:

>> Writing a novel is just so much typing; so automate it!
>
> That's data entry, not command inputs.

You have a problem pal! Code = Data !!!

[Jumpin' Jehoshaphat]

On 10/05/2012 9:18 AM, Pascal J. Bourguignon wrote:
> Jumpin' Jehoshaphat<jj1058...@gmail.com> writes:
>
>>> Writing a novel is just so much typing; so automate it!
>>
>> That's data entry, not command inputs.
>
> You have a problem pal!

Classic unsubstantiated and erroneous claim.

> Code = Data !!!

And indeed typing in code is a form of data entry. But directly issuing
single-gesture (control-key, mouse-click) commands to be executed
immediately is not really comparable when it comes to the whole "is it a
good idea to do it blind/while the interface display lags behind?" issue.

[Tim Bradshaw]

On 2012-05-10 08:34:29 +0000, Alex Mizrahi said:
>
> Huh? At school level people work with concrete numbers, but on more
> advanced level there are barely any numbers in formulas.

> I don't know much above physics above school level, but I've got M.Sc.
> applied math degree without being particularly good at arithmetics.

Well yes. It turns out that in physics numbers do matter. A very
important skill (which people are explicitly taught) is to be able to
have a feeling for whether something is "reasonable" which can mean
various things, but often means "is it about the right size?" and that
requires, among other things, the ability to get numerical estimates of
stuff very quickly. And although you are almost never doing literal
arithmetic (you're typically just trying to get an answer which is
right to an order of magnitude and some kind of notion of how rough the
answer is), you really can't do this without being pretty competent at
arithmetic, it turns out.

If you want a really good example of this there are several in
Feynman's autobiographical books. Obviously he was better than most.

It's very tempting to say "oh, none of this matters now, you just use a
computer" but that turns out not to be right for reasons I'm too tired
to explain now, but are, I think, well-known.

>> I know this because at a slightly different level it's what happened to
>> me: I was lazy, didn't practice enough boring mathematical methods
>> stuff, and that lack of fluency came back and bit me later.
>

>
> Math =/= arithmetics.

I am aware of the difference. That's why I said "at a slightly
different level".

[Tim Bradshaw]

On 2012-05-10 12:53:39 +0000, Jumpin' Jehoshaphat said:

> Data entry, of a sort, not command entry.

I see. How conveneient for you.

[Tim Bradshaw]

On 2012-05-10 11:32:37 +0000, Alex Mizrahi said:

> In reality it's more like
> 1. rm -rf fro<TAB>
> 2. look whether it was completed, there is a list of options or ...
> 3. when everything looks OK press enter.

And even that is not what people do: they have typed and executed the
whole command before they have time to think. I do this (as I've
discovered), and the interesting thing is that, after a while, although
you do execute things you should not have, you (almost) never do it in
a state where it matters.

[Tim Bradshaw]

On 2012-05-10 12:53:08 +0000, Jumpin' Jehoshaphat said:

> So it's either toolbar buttons, an emacsesque bestiary of
> impossible-to-memorize-them-all control-key combinations most of which
> have no mnemonic connection with what they insert, or typing in verbose
> markup like TeX code. (TeX editors sometimes give you the choice
> between the toolbar buttons and manually typing in TeX markup. Useful
> if you memorize the most commonly needed markup but can then just dig
> in the toolbar drop-downs for less-often-used symbols instead of having
> to task switch to a cheat-sheet, read some possibly-long string, switch
> back, and type it, or copy and paste it.)

I'd guess that you've never typed any significant amount of maths. I
have, and TeX is just enormously faster than any kind of pick-and-drop
thing. Even now, nearly 30 years after doing any large amount of
stuff, and something like 20 years after really even using TeX much, I
can look at even quite complex expressions and type them, and very
often not have to fix anything. It was designed by someoene who typed
maths, and that really shows (troff may be as good, I just never learnt
more than you needed to make a man page).

[Tim Bradshaw]

On 2012-05-10 13:45:41 +0000, Jumpin' Jehoshaphat said:

> And indeed typing in code is a form of data entry. But directly issuing
> single-gesture (control-key, mouse-click) commands to be executed
> immediately is not really comparable when it comes to the whole "is it
> a good idea to do it blind/while the interface display lags behind?"
> issue.

See my earlier message. I make my living typing commands at machines,
in a context where mistakes can be expensive. I type blind all the
time, and so do other people I know (I only discovered this recently by
observing what I do and then asking other people doing the same job).

[Jumpin' Jehoshaphat]

Perhaps, but when it's sometimes "rm -rf", "almost never" isn't going to
be good enough.

[Jumpin' Jehoshaphat]

On 10/05/2012 10:39 AM, Tim Bradshaw wrote:
> On 2012-05-10 13:45:41 +0000, Jumpin' Jehoshaphat said:
>
>> And indeed typing in code is a form of data entry. But directly
>> issuing single-gesture (control-key, mouse-click) commands to be
>> executed immediately is not really comparable when it comes to the
>> whole "is it a good idea to do it blind/while the interface display
>> lags behind?" issue.
>
> See my earlier message. I make my living typing commands at machines, in
> a context where mistakes can be expensive. I type blind all the time,

Why? Are you using old, obsolete, slow equipment or an old, obsolete,
slow network protocol that makes the input/feedback loop take a round
trip to the server and not just complete commands?

[Jumpin' Jehoshaphat]

On 10/05/2012 10:33 AM, Tim Bradshaw wrote:
> On 2012-05-10 12:53:08 +0000, Jumpin' Jehoshaphat said:
>
>> So it's either toolbar buttons, an emacsesque bestiary of
>> impossible-to-memorize-them-all control-key combinations most of which
>> have no mnemonic connection with what they insert, or typing in
>> verbose markup like TeX code. (TeX editors sometimes give you the
>> choice between the toolbar buttons and manually typing in TeX markup.
>> Useful if you memorize the most commonly needed markup but can then
>> just dig in the toolbar drop-downs for less-often-used symbols instead
>> of having to task switch to a cheat-sheet, read some possibly-long
>> string, switch back, and type it, or copy and paste it.)
>
> I'd guess that you've never typed any significant amount of maths.

Then you'd guess wrong.

> I have, and TeX is just enormously faster than any kind of pick-and-drop
> thing.

It is if there's a convenient way to get at infrequently-used stuff you
haven't got memorized. Ideally, a visual way so you can find the symbol
you want by sight and click it. And then if you're starting to use that
one a lot, or a lot in that particular document, you note what it pasted
when you did that and type it the next time.

But if you have to task switch to some cheat sheet (likely a giant
bloated pdf file open in giant bloated Acrobat Reader, bletch) every
time you want to find the code for some symbol you don't remember it
will be much slower than if you can open some palette and click it in
that when you don't remember the code to type.

[Kaz Kylheku]

On 2012-05-10, Jumpin' Jehoshaphat <jj1058...@gmail.com> wrote:
> On 10/05/2012 4:46 AM, Alex Mizrahi wrote:
>>> ALL actions require feedback! I don't want to blindly issue commands to
>>> my computer while not even looking to see if it's gone into Sorceror's
>>> Apprentice mode deleting the wrong files or something.
>>
>> The difference is that with mouse you need feedback for each action, you
>> need feedback immediately as it blocks you.
>>
>> But with keyboards you can issue multiple keypresses at once and look
>> for results later. So this check can be postponed.
>
> As mentioned in another post, this can be useful for data entry on an
> old, cruddy, lagged system or a laggy oldfashioned telnet connection.

You missed the part about there being lag that cannot be eliminated.
Even if your computer's interactive response time is a nanosecond,
there is lag in the brain.

Anything that is blocked on the human having to make a conscious decision is
looking at a 500 millisecond response (Libet's half second delay).

Training to do things unconsciously brings that down, but not to zero.

[Jumpin' Jehoshaphat]

On 10/05/2012 10:59 AM, Kaz Kylheku wrote:
> On 2012-05-10, Jumpin' Jehoshaphat<jj1058...@gmail.com> wrote:
>> On 10/05/2012 4:46 AM, Alex Mizrahi wrote:
>>>> ALL actions require feedback! I don't want to blindly issue commands to
>>>> my computer while not even looking to see if it's gone into Sorceror's
>>>> Apprentice mode deleting the wrong files or something.
>>>
>>> The difference is that with mouse you need feedback for each action, you
>>> need feedback immediately as it blocks you.
>>>
>>> But with keyboards you can issue multiple keypresses at once and look
>>> for results later. So this check can be postponed.
>>
>> As mentioned in another post, this can be useful for data entry on an
>> old, cruddy, lagged system or a laggy oldfashioned telnet connection.
>
> You missed the part about there being lag that cannot be eliminated.

No, *you* missed the part about the proficient FPS players whose mouse
use is not hampered by that lag.

[Kaz Kylheku]

On 2012-05-10, Alex Mizrahi <alex.m...@gmail.com> wrote:
>> ALL actions require feedback! I don't want to blindly issue commands to
>> my computer while not even looking to see if it's gone into Sorceror's
>> Apprentice mode deleting the wrong files or something.
>
> The difference is that with mouse you need feedback for each action, you
> need feedback immediately as it blocks you.

I'm afraid we have been, as I suspected, wasting time responding to Seamus
MacRae, a.k.a. Oxide Scrubber, Series Expansion, etc.

The wacky pseudonym, low intelligence, and overall style give it away.

[Sound Hound]

On 10/05/2012 11:10 AM, Kaz Kylheku wrote:
1> Newsgroups: comp.lang.lisp

1> I'm afraid we have been, as I suspected, wasting time responding to
Seamus
1> MacRae, a.k.a. Oxide Scrubber, Series Expansion, etc.

Who is "Seamus MacRae", Kylheku? There is nobody in this newsgroup using
that alias.

1> The wacky pseudonym, low intelligence, and overall style give it away.

What do your classic erroneous presuppositions have to do with Lisp,
Kylheku?

[Tim Bradshaw]

On 2012-05-10 14:51:11 +0000, Jumpin' Jehoshaphat said:

> Perhaps, but when it's sometimes "rm -rf", "almost never" isn't going
> to be good enough.

It'd good enough if it is below whatever else kills the system, which
it seems to be.

[Tim Bradshaw]

Sorry, what I meant was "type and enter commands without long enough to
become consciously aware of mistakes". The systems can echo fast
enough, I just can't proces the information.

[Tim Bradshaw]

On 2012-05-10 15:10:23 +0000, Kaz Kylheku said:

> I'm afraid we have been, as I suspected, wasting time responding to Seamus
> MacRae, a.k.a. Oxide Scrubber, Series Expansion, etc.

I prefer my brain-eating virus theory, but there's no real difference
in practice.

[Tim Bradshaw]

On 2012-05-10 14:54:50 +0000, Jumpin' Jehoshaphat said:

> It is if there's a convenient way to get at infrequently-used stuff you
> haven't got memorized.

Right, we call that The TeXbook (or the AMSTeX manual, or whatever). I
guess I would have referred to it once a day or so when I typed maths
seriously, may be less. For anything you use that seldom it hardly
matters what it is.

[Tim Bradshaw]

On 2012-05-10 15:50:26 +0000, Tim Bradshaw said:

> For anything you use that seldom it hardly matters what it is.

I take that back: it does not matter what it is *so long as it uses no
screen space*.

[nick_keigh...@hotmail.com]

ever seen a chinese typewriter?

[Jumpin' Jehoshaphat]

On 10/05/2012 11:50 AM, Tim Bradshaw wrote:
> On 2012-05-10 14:54:50 +0000, Jumpin' Jehoshaphat said:
>
>> It is if there's a convenient way to get at infrequently-used stuff
>> you haven't got memorized.
>
> Right, we call that The TeXbook (or the AMSTeX manual, or whatever).

Suffering from reading comprehension problems, Bradshaw? I said "a
convenient way", but you instead suggested copying and pasting from a
large pdf file that

a) consumes multiple megabytes of memory and disk space
b) requires proprietary software such as Acrobat Reader to view properly
c) which is itself bloated and takes ages to start up
d) and then you have to manually scroll through a very long document
looking for desired symbols and then copy and paste the corresponding
codes, rather than simply selecting from a neatly-organized set of
drop-down palettes and the code being pasted into your document
automatically.

[Jumpin' Jehoshaphat]

Your limitations are not everybody's, Bradshaw.

[Jumpin' Jehoshaphat]

For some of us, the goal is to avoid *anything* else killing the system,
Bradshaw.

[Jumpin' Jehoshaphat]

What does your illogical brain-eating virus theory or Kylheku's paranoia
have to do with Lisp, Bradshaw, or even with the digression about mouse
feedback speed?

[Alex Mizrahi]

>> You didn't understand my point at all.
> That is incorrect. I just didn't agree with it.

You replied with completely irrelevant pieces. Either you didn't
understand or you were trolling.

I mentioned reduction of frequency of checks required

>> The bottleneck is often in human sensory input.
> Good FPS players prove you wrong.

OK, what is the bottleneck for them?

I know that FPS players can shot with one mouse motion (and I even
mentioned it previously), but they spend years learning them and they
use special gaming mice.

While a typical person is sloppy, uses a shitty mouse and shitty
settings which make absolute positioning impossible. Hence word 'often'.
Notice it.

Or do you claim that a typical person can click buttons with mouse
without looking?

>> But it helps with those 'lagged systems' too. Maybe in your ideal world
>> computers never go slow, but in reality it isn't the case. Even most
>> modern systems can go thrashing if something goes awry, and in my
>> experience it's better to use text console at that time.
>
> In my experience it's better to fix whatever the problem is (e.g. nice a
> process that started hogging the CPU, or restart it if it's not supposed
> to occasionally do that, or even debug it and recompile it)

Are you retarded? I need a fucking console to kill that fucking process.
Am I supposed to restart it telepathically or something?

It isn't like it happens all the time, but from time to time shit
happens, and console is a much better tool for emergencies.

> Input to your locally-running browser will not be affected by this.
> Stuff typed into a web form will echo promptly and mouse movement won't
> be affected. It may just take a while for the response to get back to
> you after you click "submit" or a link or whatever.

How is that related? Should I use a browser instead of SSH?

>> No matter how fast your network is and how fast your
>> computer it. In command prompt it is noticeable, but not problematic at
>> all. With GUI it might be more of an issue.

> You're hypothesizing

I do not hypothesize (unlike you). Everything I wrote is an actual
experience. I just describe what I did.

> somehow puppetting a GUI that's running on *the
> remote machine*
> rather than using a local client or web browser to
> communicate with the server.

In many cases something like VNC is absolutely required because software
in question can only run locally. There is simply no remote mode.

You cannot make sure that all software is client-server one.

Are you saying there is no need in non-client-server software?

> That would be ... weird. Mostly you use a
> web interface to a remote machine these days.

I never used web interface and never seen anybody using web interface.

> If for some reason you
> can't (usually because you're the admin trying to remote-fix the machine
> after the httpd died)

Yeah, I'm like that admin. I set up servers from scratch, for example.

> you grit your teeth, ssh into it, and use a
> command prompt.

Well, maybe you grit your teeth, but I comfortably use SSH each day.

>> Shell commands reference file name, but not position.

> The example was using a program more like dired rather than a command
> prompt.

Your example was shitty. You intentionally mentioned most shitty
situation to make keyboard look bad.

>> rm -rf frobla.txt <look that it's correct> <enter>
>
> And if you're in the wrong directory and there are frobla.txts you don't
> want to delete as well as ones you do, in different parts of the
> filesystem ...

Does use of mouse prevent this problem? It's totally unrelated.
If you're in wrong directory, you do not look at directory you're using
and there is a file with same name, you're fucked no matter which input
you use.

>> In reality it's more like
>> 1. rm -rf fro<TAB>
>> 2. look whether it was completed, there is a list of options or ...
>> 3. when everything looks OK press enter.

> The GUI equivalent would be to click a file and hit del.

No, you first need to find it visually, which is very problematic in a
directory with many files. You either need to scroll or use incremental
search using keyboard.
Then hit del.
Then confirm that you want to delete whole tree.

rm = del
-rf = confirms deletion of whole tree
fro<TAB> = clicking file

So, same amount of logical units, or actions, but I'll type this command
much faster because you'll have to switch between keyboard and mouse and
look at screen in process.

> You'd have to
> look to see that it had acknowledged your click and selected the file
> before hitting del, but that's the same as your having to look before
> hitting enter.

No, you're ignoring the fact that you need to find file first.

> Where you went off the rails is comparing keystrokes to mouse clicks.
> Everything but the "rm" and "enter" parts correspond to one single mouse
> click to select the file.

No.

> The del key supplies those parts (and gives a
> confirmation prompt in any decent GUI file manager to boot, as one added
> level of safety).

rm also has this confirmation. Surprise! Surprise!

>>> Don't be ridiculous. I'm just pointing out an inconsistency in the
>>> pro-keyboard-only position.

>> And who holds that pro-keyboard-only position?

> You, Madhu, and Kylheku, at the very least.

I don't.

>> If information is textual chances are that incremental search would have
>> worked better.
>
> Information is often not textual, or not solely textual.

It depends on what you're doing.

I'm a programmer, 99% of information I'm working with is textual.

> Textual
> information often lacks short unique prefixes on each item,

It doesn't need to be a prefix, incremental search can find parts in the
middle.

> That's when drawing freehand rather than doing something else, such as
> dragging pre-created image fragments around and assembling them in some
> manner or applying filters, etc.

You can use pen tablet instead of mouse. Surprise!

People who have them often prefer them to mice. Much faster and more
precise.

> Also, pen tablets are expensive. The last time I saw any in a store the
> cheapest was 4-5x the cost of a decent mouse. Not everyone is going to
> spring for something like that. Particularly among those who work with
> graphics a fair bit but *not* in a capacity where they get paid to do
> so, or at least to do so very often.

I agree that mouse is an excellent poor man's choice. You can do
everything with it, but in a slow and sloppy way.

[Alex Mizrahi]

>> In reality it's more like
>> 1. rm -rf fro<TAB>
>> 2. look whether it was completed, there is a list of options or ...
>> 3. when everything looks OK press enter.

> And even that is not what people do:

Depends on 'people' and context. At least I do that. I have a habit of
using <TAB> not only for a speed up (often it's faster to type) but to
verify existence and do a 'spellchecking' (my zsh is configured to fix
typos, but it's not very useful, honestly). And I wait after <TAB> since
completions are often non-unique.

> they have typed and executed the
> whole command before they have time to think. I do this (as I've
> discovered), and the interesting thing is that, after a while, although
> you do execute things you should not have, you (almost) never do it in a
> state where it matters.

Well, I do things like "cd .." without looking, but rarely commands
which do something.

[Alex Mizrahi]

> No, *you* missed the part about the proficient FPS players whose mouse
> use is not hampered by that lag.

I've just imagined proficient FPS players using mouse in Emacs. LOL.

(BTW when those FPS players need to reconfigure keybindings in game up
to their taste they type them in game console with insanely fast speed.
So they know how to use keyboard efficiently wherever it makes sense.
And I bet they'll learn all keybingings they need if they'd actually
need to use Emacs.)

[Tim Bradshaw]

On 2012-05-12 05:36:04 +0000, Jumpin' Jehoshaphat said:

> Suffering from reading comprehension problems, Bradshaw? I said "a
> convenient way", but you instead suggested copying and pasting from a
> large pdf file that

I did? Mine sits on the desk beside the computer.

[Tim Bradshaw]

On 2012-05-12 05:36:48 +0000, Jumpin' Jehoshaphat said:

> Your limitations are not everybody's, Bradshaw.

They are common to all humans. Cats are faster I think, but they don't
use computers.

[Tim Bradshaw]

On 2012-05-12 05:37:18 +0000, Jumpin' Jehoshaphat said:

> For some of us, the goal is to avoid *anything* else killing the
> system, Bradshaw.

Quite. But that's not achievable in a world governed by the laws of
physics, let alone with the hardware and software we're constrained to
use in practice.

[Tim Bradshaw]

On 2012-05-12 08:36:26 +0000, Alex Mizrahi said:

> Depends on 'people' and context.

Yes, I was only commenting on what I've discovered that I do (and since
talked to colleagues about to discover that some of them do the same
thing) - sorry I was vague about that. It was surprising to me, and
even more surprising is how little damage (none that I can see) gets
done as a result. I think this may be related to your "experienced
gamer can do x with the mouse" point in another article: people who do
this all the time, for long enough, get pretty sensitive to when they
need to think before executing the command they've typed and when they
don't.

[Jumpin' Jehoshaphat]

Well, that's even stupider. That requires a printer, toner, and paper,
meaning it actually costs *money* as well as disk space and the need to
muck about with proprietary apps. And then you can't even copy and paste
from it! You have to actually copy manually, turning your head a large
distance to read the next bit of a long, not easily memorized
alphanumeric string, then turning back to the computer and typing a
part, turning to read another bit, turning back and typing that, and so
forth.

Why do you put up with such primitive methods? An irrational hatred for
GUIs? A particularly urgent need for screen real-estate that begrudges
the 16 or so additional rows of pixels (out of, I'd hope, at least 1024
in this day and age) that would be taken up by a toolbar with drop-down
palettes full of symbols?

And if you do begrudge those things, you'd spend your money better
getting a second monitor or even a whole second computer than a printer
and a bunch of ink and paper for it. When not displaying the PDF it
could be used for other things, and instead of costing or avoiding
consuming screen real estate it would give you double what you had. And
you could copy and paste from it, if a second monitor connected to the
same computer.

[Jumpin' Jehoshaphat]

Apparently proficient FPS players are also faster than you. And perhaps
most other humans.

[Jumpin' Jehoshaphat]

On 12/05/2012 4:32 AM, Alex Mizrahi wrote:
>>> You didn't understand my point at all.
>> That is incorrect. I just didn't agree with it.
>
> You replied with completely irrelevant pieces.

Classic unsubstantiated and erroneous claim.

> Either you didn't understand or you were trolling.

Classic erroneous presupposition.

> Or do you claim that a typical person can click buttons with mouse
> without looking?

Without looking at the mouse? Yes. Without looking at the screen? No,
but then a touch typist doesn't need (or want!) to look away from the
screen much anyway.

In any event, a proficient mouse user is a lot faster and more accurate
than a novice like, I assume, you are and anyone else here is who is
sour on mouse use.

>>> But it helps with those 'lagged systems' too. Maybe in your ideal world
>>> computers never go slow, but in reality it isn't the case. Even most
>>> modern systems can go thrashing if something goes awry, and in my
>>> experience it's better to use text console at that time.
>>
>> In my experience it's better to fix whatever the problem is (e.g. nice a
>> process that started hogging the CPU, or restart it if it's not supposed
>> to occasionally do that, or even debug it and recompile it)
>
> Are you retarded?

What does your ridiculous question have to do with the topic at hand,
Mizrahi?

> I need a fucking console to kill that fucking process.

What does your foul language have to do with Lisp, Mizrahi? Of course
you don't; there are graphical process-management tools out there for
those who prefer them. Also, one hopes one only has to nice processes
that are hogging the CPU or otherwise slowing the system down on
infrequent occasions. As for a fix-and-recompile one hopes one only has
to do that *once*, and then the problem won't happen again.

> It isn't like it happens all the time, but from time to time shit
> happens, and console is a much better tool for emergencies.

So you claim, without evidence.

>> Input to your locally-running browser will not be affected by this.
>> Stuff typed into a web form will echo promptly and mouse movement won't
>> be affected. It may just take a while for the response to get back to
>> you after you click "submit" or a link or whatever.
>
> How is that related? Should I use a browser instead of SSH?

If you're complaining about GUIs being lagged by the network you're not
using SSH.

>>> No matter how fast your network is and how fast your
>>> computer it. In command prompt it is noticeable, but not problematic at
>>> all. With GUI it might be more of an issue.
>
>> You're hypothesizing
>
> I do not hypothesize

Classic unsubstantiated and erroneous claim.

> Are you saying there is no need in non-client-server software?

You are confused. We had been discussing UIs slowed down by network lag,
which doesn't affect you when working with purely local software.

>> That would be ... weird. Mostly you use a
>> web interface to a remote machine these days.
>
> I never used web interface and never seen anybody using web interface.

Then you're weird. What can I say?

>> If for some reason you
>> can't (usually because you're the admin trying to remote-fix the machine
>> after the httpd died)
>
> Yeah, I'm like that admin. I set up servers from scratch, for example.
>
>> you grit your teeth, ssh into it, and use a
>> command prompt.
>
> Well, maybe you grit your teeth, but I comfortably use SSH each day.

How can you "comfortably" use anything that forces you to see the work
you're doing through a keyhole instead of in widescreen HD? Which is
what a command prompt does, of course, what with the little-to-no
context it displays while you work. Not to mention forces you to,
instead of hands-on manipulating whatever it is you're working on,
forces you to grunt at a robot in pidgin that will then go and do the
manipulating and hope it doesn't get confused and misunderstand you --
one little typo and the thing will merrily start destroying everything
on the machine systematically (and finish, or do a lot of damage before
the damage crashes it, too fast for you to intervene and stop it).
Unless you have a big job to do that's easily specified as a rote
mechanical action you'll have just as much work to do as doing it
yourself, with a higher likelihood of error and worse potential
consequences of such an error. Actually, you'll have *more* work to do
-- for example, moving a file might, instead of one click and drag
taking a second or so, take fifty or more keystrokes and three or four
seconds.

>>> Shell commands reference file name, but not position.
>
>> The example was using a program more like dired rather than a command
>> prompt.
>
> Your example was shitty.

What does your classic unsubstantiated and erroneous claim have to do
with this debate, Mizrahi?

>>> rm -rf frobla.txt <look that it's correct> <enter>
>>
>> And if you're in the wrong directory and there are frobla.txts you don't
>> want to delete as well as ones you do, in different parts of the
>> filesystem ...
>
> Does use of mouse prevent this problem?

Certainly, since the GUI comes along with it and you can actually see
where the hell you are. With the CLI you're peering through a keyhole.
You may see

local %>

and maybe you're in etc/local and maybe you're in usr/local. With a GUI
you can see at a glance where you are because the files in the directory
you're in are displayed right there on the screen. If you're in the
wrong one you'll probably notice right away by what files are (or
aren't) present.

> It's totally unrelated.

But not uncorrelated. Nor is it uncorrelated with the presence of
confirmation prompts and trash/recycle bins and other useful safeguards.
It's much, *much* less likely that you will accidentally delete when you
meant to do something else, and much, *much* more likely that if you do
anyway you can *un*do it. Wrong directory? You'll probably see that
you're in the wrong place, since you can actually see that place and not
just its name or even a part of its name. Wrong command? It's much
easier to mistype "em foo.txt" as "rm foo.txt" than it is to confuse an
editor icon and a trashcan icon, or to miss the former by a large enough
margin to drop the file on the latter. And then you'll unexpectedly get
an "OK to delete file?" prompt instead of an editor window. And failing
*that* you don't really lose the file unless you're stupid enough to
empty the trash instead of dig the file back out of it that you didn't
mean to drop there!

Sure, for some things, it's slower, but it's also safer, and any decent
system still provides a command prompt and a scripting capability for
tasks that benefit from automation.

> If you're in wrong directory, you do not look at directory you're using

???

>>> In reality it's more like
>>> 1. rm -rf fro<TAB>
>>> 2. look whether it was completed, there is a list of options or ...
>>> 3. when everything looks OK press enter.
>
>> The GUI equivalent would be to click a file and hit del.
>
> No, you first need to find it visually, which is very problematic in a
> directory with many files.

Really? It's a lot easier to spot a distinctive icon and name than just
a distinctive name, and a lot faster to mouse to and click an icon than
to type a name longer than ten or so characters.

Not to mention a GUI gives you the nifty ability to have more than one
"current directory" at a time, instead of having to type a
potentially-long path anytime you need to switch, or perform an
operation involving multiple directories (such as moving files to a
different part of the filesystem).

> So, same amount of logical units, or actions, but I'll type this command
> much faster because you'll have to switch between keyboard and mouse and
> look at screen in process.

Bad comparison. First of all, it's not "same amount of logical units".
Second, you don't have to switch between keyboard and mouse unless it's
a *very large* directory (hundreds of files seems to be the threshold
for when typing part of the name is faster than scrolling to locate the
file). And third, if you're a touch-typist you don't have to look at the
keyboard, for the most part, and don't want to either, so whether you're
typing or not you don't have to look *away from* the screen.

>> You'd have to
>> look to see that it had acknowledged your click and selected the file
>> before hitting del, but that's the same as your having to look before
>> hitting enter.
>
> No, you're ignoring the fact that you need to find file first.

I was assuming you'd already found it, but it's not as if keyboard-only
is better for finding the file either. You can find it in only one way
then: by its name. If you don't know its name you have to invoke search
tools, and at a CLI that tends to mean an arcane syntax and possibly a
trip to the help files to get *that* right before you even can find the
file you want to delete! And then the name might be really long and
awkward to type. And it might have characters in it that tend to give
shells fits: nontypable symbols, percent signs, leading hyphens,
quotation marks, and even spaces tend to cause problems there.

With the GUI you can find the file in any of a number of ways. Type
(some prefix of) the name; scan for it while scrolling with the keyboard
pgdn key; scan while scrolling with the mouse wheel; set a sort order
that makes the file go to the top or bottom of the window and then hit
ctrl+home or ctrl+end (if it's alphabetically first, or larger than any
other file there, or the newest, or the oldest -- deleting the oldest of
some set of logfiles would be a common case); or type a query into a
little search box that works more or less as expected for simple
substring matches but supports more complex queries as well when needed,
such as based on modification time, file contents, or other criteria.

>> Where you went off the rails is comparing keystrokes to mouse clicks.
>> Everything but the "rm" and "enter" parts correspond to one single mouse
>> click to select the file.
>
> No.

Still in denial? Seek help.

>> The del key supplies those parts (and gives a
>> confirmation prompt in any decent GUI file manager to boot, as one added
>> level of safety).
>
> rm also has this confirmation. Surprise! Surprise!

Wrong. It just deletes things without checking first. You can make it
prompt for confirmation, but only by remembering to type something extra
first.

Not to mention all the various ways it can go wrong. Guess what happens
if there's a file named "-rf" in a directory where you use "rm *" or
similar.

>>>> Don't be ridiculous. I'm just pointing out an inconsistency in the
>>>> pro-keyboard-only position.
>
>>> And who holds that pro-keyboard-only position?
>
>> You, Madhu, and Kylheku, at the very least.
>
> I don't.

Classic inconsistency with the rest of your post.

>>> If information is textual chances are that incremental search would have
>>> worked better.
>>
>> Information is often not textual, or not solely textual.
>
> It depends on what you're doing.

Perhaps.

> I'm a programmer, 99% of information I'm working with is textual.

I wear rather more hats here.

>> Textual
>> information often lacks short unique prefixes on each item,
>
> It doesn't need to be a prefix, incremental search can find parts in the
> middle.

You are confused. Tab completion needs a prefix. So does the incremental
search in typical GUI file managers, such as Windoze Explorer.

You seem to be thinking of searching a text file in an editor, which is
not what we were discussing; we were discussing finding files in the shell.

>> That's when drawing freehand rather than doing something else, such as
>> dragging pre-created image fragments around and assembling them in some
>> manner or applying filters, etc.
>
> You can use pen tablet instead of mouse.

If you have a spare $200 lying around, perhaps you can.

> I agree that mouse is an excellent poor man's choice. You can do
> everything with it, but in a slow and sloppy way.

Classic erroneous presupposition. Obviously you've never seen a mouse
wielded by someone truly proficient in its use -- or you've seen bad
mice. Ball mice that haven't had their bearings cleaned in a while,
perhaps. Even a ten-dollar optical mouse from the bargain bin at Office
Depot will outperform *that*.

[Jumpin' Jehoshaphat]

Hardly an excuse for making choices likely to accelerate the process,
like overusing unix's execrable "rm" manually instead of leaving that
for use by heavily-tested-and-debugged scripts, where it belongs. Unix
"rm" is like a nailgun with fully automatic fire and no safety regulator
preventing it from working if something isn't pressed up against it. You
want that held by a robot arm over a conveyor belt cordoned off from any
approach by humans with big signs saying "KEEP CLEAR WHILE EQUIPMENT
OPERATING", humming away with distant supervision making cheap Japanese
cars until someone hits the big red "Emergency Stop" button so
maintenance can be performed safely. You don't want that wielded by the
human hands of a handyman building a house, unless you don't mind seeing
the neighborhood riddled with holes if, in typical human fashion, that
handyman errs.

[Jumpin' Jehoshaphat]

On 12/05/2012 4:58 AM, Alex Mizrahi wrote:
>> No, *you* missed the part about the proficient FPS players whose mouse
>> use is not hampered by that lag.
>
> I've just imagined proficient FPS players using mouse in Emacs. LOL.
>
> (BTW when those FPS players need to reconfigure keybindings in game up
> to their taste they type them in game console with insanely fast speed.
> So they know how to use keyboard efficiently wherever it makes sense.

Has anyone claimed otherwise?

[Tim Bradshaw]

On 2012-05-12 11:05:22 +0000, Jumpin' Jehoshaphat said:

> Well, that's even stupider. That requires a printer, toner, and paper,
> meaning it actually costs *money* as well as disk space and the need to
> muck about with proprietary apps.

You will be shocked to discover that I bought my copy of the TeXbook,
in a shop, in 1987 (amusingly on the flyleaf it has a note pointing to
the UK TeX archive that starts "uk.ac"). And yes, it costs money,
but there's a famous quote about money and time, isn't there?

> And then you can't even copy and paste from it! You have to actually
> copy manually, turning your head a large distance to read the next bit
> of a long, not easily memorized alphanumeric string, then turning back
> to the computer and typing a part, turning to read another bit, turning
> back and typing that, and so forth.

Paper has this wonderful property that you can read it in bed, outside,
and so on, and it has really good characteristics for reading: it might
be that the most recent generation of tablets is getting close to that,
but I suspect they aren't really anywhere near yet. And, of course,
people who make their living typing up mathematical manuscripts don't
have a problem reading something and typing it in again. And for added
value *reading something and writing it out is how you learn it*, while
cutting ans pasting pretty much ensures you never learn. Pretty
quickly you never need to refer to it at all unless you have to write
some particularly hairy macro.

As for screen space: it still matters, especially if (like me) you want
never to have to use anything you can't carry with you: I have no time
for huge screens taking up half a room in my house. It also matters,
if what you do is writing, to have an editor where what you see on the
screen is *just the text* rather than some vast encrustation of obscure
toolbar crap (for writing TeX I typically want just the text with a
preview window beside it being kept up to date by latexmk in the
background, though I am not sure I really want the preview - I'd have
to write more than I currently do to know). Interestingly people are
finally realising this: I don't really use many commercial WP systems,
but I maintain my CV in Pages, and the current version of that has a
pretty decent full-screen mode which has had the courage to just
"waste" most of the screen space by making it black rather than make
lines absurdly long or fill it with spurious buttony cruft.

Well, I'm done with this now.

[Jumpin' Jehoshaphat]

On 12/05/2012 8:10 AM, Tim Bradshaw wrote:
> On 2012-05-12 11:05:22 +0000, Jumpin' Jehoshaphat said:
>
>> Well, that's even stupider. That requires a printer, toner, and paper,
>> meaning it actually costs *money* as well as disk space and the need
>> to muck about with proprietary apps.
>
> You will be

You will let me stay caught up on this thread for more than just a few
minutes at a time!

>> And then you can't even copy and paste from it! You have to actually
>> copy manually, turning your head a large distance to read the next bit
>> of a long, not easily memorized alphanumeric string, then turning back
>> to the computer and typing a part, turning to read another bit,
>> turning back and typing that, and so forth.
>
> Paper has this wonderful property that you can read it in bed, outside,
> and so on,

Not very useful when it's a computer reference so the place where you
need to refer to it is at your desk with your computer within easy
reach. None of those arguable advantages over electronic documents
applies in that case, but all of the disadvantages (no search, no copy
and paste, expensive, bulky to store...) still apply.

> and it has really good characteristics for reading: it might
> be that the most recent generation of tablets is getting close to that,
> but I suspect they aren't really anywhere near yet.

Classic contradiction, and inside a single sentence at that.

> And for added value *reading something and writing it out is how you
> learn it*

It was last century. Nowadays we have superior ways of learning, as we
do other things.

> while cutting ans pasting pretty much ensures you never learn.

You're not making sense. You can see what you just pasted and will
remember it if you find yourself starting to use it frequently.

> Pretty quickly you never need to refer to it at all unless you have to
> write some particularly hairy macro.

Don't be ridiculous. There are thousands of arcane commands, many with
not-very-mnemonic names, for thousands of different symbols and other
things. Unless you never use more than a specific, fixed, narrow subset
of them, you *will not* remember all of the ones you use and sometimes
*will* need to refer to something or have some other method of inserting
a symbol.

> As for screen space: it still matters, especially if (like me) you want
> never to have to use anything you can't carry with you:

If you'd rather live a vagrant-ish life, with a few portable gadgets and
maybe a vehicle but no house or other large, fixed possessions, then
good for you. (Though that isn't very compatible with giant shelves full
of printouts and books!)

Most of us don't mind, or actively like, putting down roots and having a
house and other bulky, non-portable things.

> It also matters, if what you do is writing, to have an editor where what
> you see on the screen is *just the text* rather than some vast
> encrustation of obscure toolbar crap

That "vast encrustation of obscure toolbar crap" is how the rest of us
can find less-frequently-used symbols and commands when we need to use
them in seconds of clicking instead of hours of poring over manuals or
paging through unhelpful help files or even digging through drawers for
a printed cheat-sheet listing thousands of obscure control-key
combinations or command strings.

[Alex Mizrahi]

>>> That is incorrect. I just didn't agree with it.

>> You replied with completely irrelevant pieces.

> Classic unsubstantiated and erroneous claim.

I've substantiated it twice (or thrice?). Re-read what I said and come
back when you understand.

> In any event, a proficient mouse user is a lot faster and more accurate
> than a novice like, I assume, you are and anyone else here is who is
> sour on mouse use.

Classic unsubstantiated and erroneous assumption.

I use mouse when I play those first-person shooters: after all, they
were designed with mouse in mind. I also use mouse for web browsing,
drawing and lots of other things. But I prefer keyboard for file-related
stuff, running commands, writing code and so on.

I really don't get why do you think I'm some mouse-hating zealot. It was
just a great opportunity for you to troll people, wasn't it?

>>> In my experience it's better to fix whatever the problem is (e.g. nice a
>>> process that started hogging the CPU, or restart it if it's not supposed
>>> to occasionally do that, or even debug it and recompile it)
>> Are you retarded?

> What does your ridiculous question have to do with the topic at hand,
> Mizrahi?

Everything you wrote so far has absolutely nothing to do with topic at
hand, Jephosophat. So, why not?

By the way, who allowed you to call me by the last name? I didn't.

>
>> I need a fucking console to kill that fucking process.
>
> What does your foul language have to do with Lisp, Mizrahi?

Retarded people like you annoying me to no end, Jehoshaft. Sorry, I
can't help it.

> Of course
> you don't; there are graphical process-management tools out there for
> those who prefer them.

lolwut, when system is thrashing mouse is barely moving. Good fucking luck.

> Also, one hopes one only has to nice processes
> that are hogging the CPU or otherwise slowing the system down on
> infrequent occasions.

"Hogging the CPU" isn't a problem at all. Thrashing is when kernel
itself 'hogs' a system due to intensive paging or something.
In theory this shouldn't happen, but it happens.

If you had more practice you would know that.

> As for a fix-and-recompile one hopes one only has
> to do that *once*, and then the problem won't happen again.

You don't even understand what I'm talking about... System might be out
of memory for a lots of reasons.

>> How is that related? Should I use a browser instead of SSH?

> If you're complaining about GUIs being lagged by the network you're not
> using SSH.

I compared VNC to SSH. Some programs can work only over VNC or a similar
protocol, so I had a chance to compare these approaches.

>>> You're hypothesizing
>> I do not hypothesize
> Classic unsubstantiated and erroneous claim.

LOL.
I say I have a very concrete experience: system is thrashing, GUI is not
responsive, I go to console and fix problem from it.
Do you claim that it didn't happen?
Do you want me to send you a video of incident or something?

>> Are you saying there is no need in non-client-server software?

> You are confused. We had been discussing UIs slowed down by network lag,
> which doesn't affect you when working with purely local software.

And?

>> Well, maybe you grit your teeth, but I comfortably use SSH each day.
>
> How can you "comfortably" use anything that forces you to see the work
> you're doing through a keyhole instead of in widescreen HD?

My terminal is "widescreen HD".

> what a command prompt does, of course, what with the little-to-no
> context it displays while you work.

Ehm. I see a history which goes a long back. You don't.

> Not to mention forces you to,
> instead of hands-on manipulating whatever it is you're working on,

Whenever I think of something my hands do that. It is was more hands-on
than you can imagine.

Do you experience any communication problem when you talk to people? I
don't. I don't have a problem in communicating with server over SSH.

> Unless you have a big job to do that's easily specified as a rote
> mechanical action you'll have just as much work to do as doing it
> yourself, with a higher likelihood of error and worse potential
> consequences of such an error.

Well, um. Let's say I need to check access rights on file
/home/foo/bar.txt on server quux. I type

ssh quux stat /home/foo/bar.txt

It takes just a couple of seconds to get results.

This is what I would call 'doing it myself' -- I think of something,
translate it to shell language, type and get results.

Please describe how you would do this.

Actually, you'll have *more* work to do
> -- for example, moving a file might, instead of one click and drag

You're missing the fact that you need to find file and place to drag it
to before, which takes a lot of time.

> taking a second or so, take fifty or more keystrokes and three or four
> seconds.

'fifty or more keystokes' includes finding file. You intentionally
compare apples to oranges.

> You may see
>
> local %>
>
> and maybe you're in etc/local and maybe you're in usr/local.

I see full path.

> With a GUI
> you can see at a glance where you are because the files in the directory
> you're in are displayed right there on the screen.

Oh, so you read whole directory list before you do somethihg? How cute.
Yes, it totally makes sense to look at files instead of full directory path.

> Sure, for some things, it's slower, but it's also safer,

It's possible to configure rm to ask always.

> Not to mention a GUI gives you the nifty ability to have more than one
> "current directory" at a time,

I can open many terminals and many terminal tabs.

>> It doesn't need to be a prefix, incremental search can find parts in the
>> middle.
>
> You are confused. Tab completion needs a prefix.

It depends on what you use and how you configured it.
I use zsh which has very sophisticated and configurable completion
system. It can, among other things, do glob expansion:

`cd *890<TAB>` becomes `cd 1234567890/`

> You seem to be thinking of searching a text file in an editor, which is
> not what we were discussing; we were discussing finding files in the shell.

Shell is much more general concept, see here:
http://en.wikipedia.org/wiki/Shell_(computing)

I believe Emacs with dired and stuff can be seen as a shell too, after
all it provides same basic functionality as Windows Shell. And you can
use free-form incremental search in dired.

[Pascal J. Bourguignon]

Tim Bradshaw <t...@tfeb.org> writes:

> Paper has this wonderful property that you can read it in bed,
> outside, and so on, and it has really good characteristics for
> reading: it might be that the most recent generation of tablets is
> getting close to that, but I suspect they aren't really anywhere near
> yet.

Well, the only thing that tablets lack vs. paper, is the energetic
independence. Paper just use whatever light energy you shower it with.
Tablets need a daily reload. Other than that, I prefer to read on
tablet (or computer screen) and I have always prefered it. (Zoom,
choice of font, ease of navigation, not counting copy-and-paste, even on
tablet thru email).


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Alex Mizrahi]

>> They are common to all humans. Cats are faster I think, but they don't
>> use computers.

> Apparently proficient FPS players are also faster than you. And perhaps
> most other humans.

Reaction time was a subject of scientific studies, and results are well
known. See here:

http://en.wikipedia.org/wiki/Mental_chronometry

If you think that FPS players have different reaction time, please cite
a study.

I guess you're mistaken: proficient FPS players are trained to move
controller to exact required position without further feedback. I.e.
once they see something they send commands to muscles to move cursor and
shoot without analyzing picture.

But this is still a subject of reaction time, so time from seeing a
target to shooting is at least 100 ms (likely more).

The difference between you and a professional FPS player is that you
need feedback to position cursor. I.e. you see a target, move a mouse,
check whether you over-shoot or under-shoot, move it again and so on.

So, basically, for them it is 100+ ms. For you it is N * 100 ms where N>1.

Got it, Jehoshaphat?

[John Thingstad]

On 05/12/2012 09:21 PM, Pascal J. Bourguignon wrote:
>
> Well, the only thing that tablets lack vs. paper, is the energetic
> independence. Paper just use whatever light energy you shower it with.
> Tablets need a daily reload. Other than that, I prefer to read on
> tablet (or computer screen) and I have always prefered it. (Zoom,
> choice of font, ease of navigation, not counting copy-and-paste, even on
> tablet thru email).
>

Well a kindle is not backlit. It has a contrast that is better than
newspaper. I have the DX version which has 9.5" screen. Good enough to
read PDF's which is why I wanted it. I only need to recharge it one a
week or so. Electronic ink has the advantage that it doesn't consume
energy except when you change pages which is perfect for reading books.
However it is too slow to really do anything interactive. All the same I
am quite happy with it. In many ways it is better than a book. At least
these heavy things you call handbooks. It weight much less, fits in one
hand, and you can put it down without loosing your page.

[Kaz Kylheku]

On 2012-05-12, Alex Mizrahi <alex.m...@gmail.com> wrote:
>>> They are common to all humans. Cats are faster I think, but they don't
>>> use computers.
>
>> Apparently proficient FPS players are also faster than you. And perhaps
>> most other humans.
>
> Reaction time was a subject of scientific studies, and results are well
> known. See here:
>
> http://en.wikipedia.org/wiki/Mental_chronometry
>
> If you think that FPS players have different reaction time, please cite
> a study.

You're responding to someone who has never written anything that was correct,
and never responded to any point anyone has ever made in a way that showed
understanding. Furthermore, never written a single article that was topical to
the newsgroup in which it was posted. Not a shred of antyhing to do with Lisp
here, etc. Moreover, that someone changes identities more often than underwear
to evade killfiles. The right treatment for this despicable maggot is swift
and total ostracism.

You and I are real people with real credentials; let's talk about something.

What interesting thing have you worked on lately?

[Madhu]

* Alex Mizrahi <4fae84f6$0$284$1472...@news.sunsite.dk> :
Wrote on Sat, 12 May 2012 18:42:44 +0300:

| I believe Emacs with dired and stuff can be seen as a shell too, after
| all it provides same basic functionality as Windows Shell. And you can
| use free-form incremental search in dired.

Emacs "wdired" is more than that. After a C-x C-q, you can edit the
dired buffer like any other emacs buffer --- change names of files,
reedit symbolic links, etc). Then when you (C-c C-c) commit the
changes, wdired will batch the changes and then perform the file system
operations.

Sadly this powerful UI notion of 1) notating changes, 2) batching them
up and 3) actually performing them appears to have lost to the more
crippling "manipulate on representation with immediate effect" idea.

This was most painfully evident when I tried using the much advertised
gnu `parted' program for disk partitioning. All other tools have
traditionally allowed you to build up the partition table and then
commit the changes. On the other hand parted immediately screws up the
filesystem on any command --- following with the top-down "dumb down the
software" investments model

--- Madhu

[Jumpin' Jehoshaphat]

On 12/05/2012 3:35 PM, Alex Mizrahi wrote:
>>> They are common to all humans. Cats are faster I think, but they don't
>>> use computers.
>
>> Apparently proficient FPS players are also faster than you. And perhaps
>> most other humans.
>
> Reaction time was a subject of scientific studies, and results are well
> known. See here:
>
> http://en.wikipedia.org/wiki/Mental_chronometry
>
> If you think that FPS players have different reaction time, please cite
> a study.

You're purposely missing the point, as usual. I'm not claiming the
reaction time is different. I'm claiming the reaction time is not a
problem because you can train your automatic motor memory to perform
actions, even requiring some degree of feedback (hand/eye coordination),
fast enough.

> The difference between you and a professional FPS player

How do you know I'm not one? ;)