[29307] in Perl-Users-Digest
Perl-Users Digest, Issue: 551 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 21 21:10:12 2007
Date: Thu, 21 Jun 2007 18:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 21 Jun 2007 Volume: 11 Number: 551
Today's topics:
Re: Assigning another filehandle to STDOUT, using binmo <rvtol+news@isolution.nl>
Re: FAQ 1.6 What is perl6? <purlgurl@purlgurl.net>
Re: How can I use the string variable expansion for OO <ilias@lazaridis.com>
Re: How can I use the string variable expansion for OO <uri@stemsystems.com>
Re: MASON getting arguments. <noreply@gunnar.cc>
Re: MASON getting arguments. <xicheng@gmail.com>
Re: Passing hash to another script via commandline <tadmc@seesig.invalid>
Re: Passing hash to another script via commandline <jurgenex@hotmail.com>
Re: Passing hash to another script via commandline <veatchla@yahoo.com>
Re: Perl Best Practices - Code Formatting. <thoughtstream@gmail.com>
Re: Perl Best Practices - Code Formatting. usenet@DavidFilmer.com
Re: Perl Best Practices - Code Formatting. <asuter@cisco.com>
Re: Perl Best Practices - Code Formatting. <asuter@cisco.com>
Re: The Modernization of Emacs <iddw@hotmail.com>
Re: The Modernization of Emacs: terminology buffer and <kaldrenon@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <kaldrenon@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <garrickp@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <kaldrenon@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <mkb@incubus.de>
Re: The Modernization of Emacs: terminology buffer and <notbob@nothome.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 22 Jun 2007 01:36:28 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Assigning another filehandle to STDOUT, using binmode.
Message-Id: <f5f96s.1g0.1@news.isolution.nl>
Adam Funk schreef:
> Is using binmode the most correct way to suppress those annoying "Wide
> character" warnings?
What is annoying about them? The just mean that you need to fix your
program.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Thu, 21 Jun 2007 13:20:02 -0700
From: Purl Gurl <purlgurl@purlgurl.net>
Subject: Re: FAQ 1.6 What is perl6?
Message-Id: <zqSdnZ-92LLpQOfbnZ2dnUVZ_umlnZ2d@giganews.com>
Randal L. Schwartz wrote:
> Purl Gurl wrote:
>>> "We're really serious about reinventing everything that needs
>>> reinventing." --Larry Wall
>> Now hold on there just a minute! A few days back some of the childish
>> False Gods of Perl around here were screaming their heads off about,
>> "not reinventing the wheel."
>> I'll be damn, there is Larry Wall confessing to "reinventing the wheel."
> I've never told people not to reinvent the wheel, if I was absolutely sure
> they were completely familiar with the wheel they were reinventing.
> In this case, I'm pretty sure that Larry is familiar with the wheel
> he is reinventing. Heck, he invented most of it in the first place.
> Put your "wand of unjustified comparisons" back in its sheath.
* pouts *
But I so enjoy beating the boys about their heads and shoulders
with my magic wand.
Besides, I was not referring to you, although this seems so.
I am referring to these boys around who believe Perl to be
a sacred golden calf which should absolutely never be touched.
How many wheels have you, Randal, reinvented? I bet you have
lost count having reinvented so many wheels, all of which are
for the betterment of the Perl Community.
My spell checker wants to change your name to "Vandal."
--
Purl Gurl
--
"Then again what can you expect from a fat-assed, champagne swilling,
half-breed just off the Rez?"
- Joe Kline
------------------------------
Date: Fri, 22 Jun 2007 00:56:25 -0000
From: Ilias Lazaridis <ilias@lazaridis.com>
Subject: Re: How can I use the string variable expansion for OO "$self->attribute"
Message-Id: <1182473785.267268.318960@p77g2000hsh.googlegroups.com>
On Jun 22, 1:15 am, Uri Guttman <u...@stemsystems.com> wrote:
> >>>>> "IL" == Ilias Lazaridis <i...@lazaridis.com> writes:
>
> IL>http://www.tu-chemnitz.de/docs/perldoc-html/overload.html
>
> perldoc.perl.org has all the docs and so does your own perl
> installation.
>
> IL> btw: can I actually overload the "@" and "%", too - thus my custom
> IL> Array/Hash class is used?
>
> overloading is for operators, tie (perldoc perltie) is for replacing
> variables with an OO implementation.
I've looked at this (giving first relevant search hit for 'perltie'):
http://www.tu-chemnitz.de/docs/perldoc-html/perltie.html#Tying-Arrays-array%2c-tying
but I cannot see how I can overload / tie the default array to
MyArray, e.g. with a statement like:
use array 'MyArray';
my @data = ('peter', 'paul');
@data->isa('MyArray'); #=> returns true
.
--
http://dev.lazaridis.com/lang/wiki/PerlOO
------------------------------
Date: Thu, 21 Jun 2007 22:15:56 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How can I use the string variable expansion for OO "$self->attribute"
Message-Id: <x7y7idq7hf.fsf@mail.sysarch.com>
>>>>> "IL" == Ilias Lazaridis <ilias@lazaridis.com> writes:
IL> http://www.tu-chemnitz.de/docs/perldoc-html/overload.html
perldoc.perl.org has all the docs and so does your own perl
installation.
IL> btw: can I actually overload the "@" and "%", too - thus my custom
IL> Array/Hash class is used?
overloading is for operators, tie (perldoc perltie) is for replacing
variables with an OO implementation.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Thu, 21 Jun 2007 22:15:01 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: MASON getting arguments.
Message-Id: <5e04njF36blicU1@mid.individual.net>
bpatton wrote:
> I know that all the values passed into a module are in @_
They aren't. All the values passed to a _sub_ are in @_.
> assume @_ looks like [ c , 3 , d , 4 ]
Do you mean ( 'c', 3, 'd', 4 ) ?
> But between
> <%args>
> $a => 1;
> $b => 2;
> </%args>
<%args> and </%args> is not Perl code, AFAIK.
> How do I get the variables $a and $b and their values when they may
> not have been passed in?
Sorry, I'm lost.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Thu, 21 Jun 2007 20:32:53 -0000
From: Xicheng Jia <xicheng@gmail.com>
Subject: Re: MASON getting arguments.
Message-Id: <1182457973.605689.36910@q69g2000hsb.googlegroups.com>
On Jun 21, 4:05 pm, bpatton <bpat...@ti.com> wrote:
> I know that all the values passed into a module are in @_
> assume @_ looks like [ c , 3 , d , 4 ]
ITYM: "passed into a Mason component"
> But between
> <%args>
> $a => 1;
> $b => 2;
no trailing semi-colon please..
> </%args>
>
> How do I get the variables $a and $b and their values when they may
> not have been passed in?
$a is 1 and $b is 2 by default. check the following link.
http://www.masonbook.com/book/chapter-2.mhtml#TOC-ANCHOR-9
Regards,
Xicheng
------------------------------
Date: Thu, 21 Jun 2007 17:22:53 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Passing hash to another script via commandline
Message-Id: <slrnf7luht.din.tadmc@tadmc30.sbcglobal.net>
l v <veatchla@yahoo.com> wrote:
> Purl Gurl wrote:
>> * SCREAMS *
> Oh look, another mindless, senseless, and ignorant post from the Purl Gurl.
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==================================================================
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 21 Jun 2007 22:54:53 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Passing hash to another script via commandline
Message-Id: <1lDei.9703$gI4.6760@trndny06>
l v wrote:
> Purl Gurl wrote:
>> How the Hades could you childish twits have the slightest hint
>> of what data to expect beyond what is concisely stated by an
>> author? You do not. "Bad assumption" my smelly foot. I have made
>> no bad assumption by restricting my code to only those parameters
>> stated.
Actually I agree with Purl Gurl. The OP did in fact ask how to pass those
paramaters which he named explicitely.
However I believe the solutions offered so far stop half way. After all, we
do know already which parameters to pass (the OP named then explicitely),
therefore it is just as well to just hardcode them in the callee, i.e. in
interface.pl.
Just add
my %data = (
field1 => 'f1val',
field2 => 'f2val'
);
my($dataref) = \%data;
to interface.pl and now $dataref is a reference to a hash containing exactly
the desired data as specified by the OP.
Much easier, no messy data passing, no IPC, ...
jue
------------------------------
Date: Thu, 21 Jun 2007 18:18:32 -0500
From: l v <veatchla@yahoo.com>
Subject: Re: Passing hash to another script via commandline
Message-Id: <137m1p2b0oa9vee@news.supernews.com>
Jürgen Exner wrote:
> l v wrote:
>> Purl Gurl wrote:
>>> How the Hades could you childish twits have the slightest hint
>>> of what data to expect beyond what is concisely stated by an
>>> author? You do not. "Bad assumption" my smelly foot. I have made
>>> no bad assumption by restricting my code to only those parameters
>>> stated.
>
> Actually I agree with Purl Gurl. The OP did in fact ask how to pass those
> paramaters which he named explicitely.
>
> However I believe the solutions offered so far stop half way. After all, we
> do know already which parameters to pass (the OP named then explicitely),
> therefore it is just as well to just hardcode them in the callee, i.e. in
> interface.pl.
>
> Just add
> my %data = (
> field1 => 'f1val',
> field2 => 'f2val'
> );
> my($dataref) = \%data;
> to interface.pl and now $dataref is a reference to a hash containing exactly
> the desired data as specified by the OP.
> Much easier, no messy data passing, no IPC, ...
>
> jue
>
>
Jurgen
I would have normally agreed with you and Purl Gurl. However Purl's
lashing out towards Tad's post reminding of good programming
considerations was uncalled for and abusive IMO. Had Tad's response not
been aimed at a Purl post, I believe Purl nor the poster would not
lashed out. There are at times which Purl has useful posts, but does
not take constructive criticism well.
In an office environment, a reminder by a coworker to consider spaces on
the input data would have been welcomed and rewarded with a "thank you
for the reminder". Purl's response was to kicked the coworker in the
shin and throw a tantrum by yelling and screaming.
I can't speak for the OP, but I bet the OP thought "thank you for the
reminder". Or after a few minutes of "why doesn't this work", said the
same.
--
Len
------------------------------
Date: Thu, 21 Jun 2007 20:40:31 -0000
From: "damian@conway.org" <thoughtstream@gmail.com>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <1182458431.641563.8840@g37g2000prf.googlegroups.com>
Asim Suter wrote:
> I was readingPerlBest Practices by RespectedDamianConway
> and he rather strongly advices using K&R style of code format as opposed to
> BSD style or GNU style.
Strongly? When on pages 8&9 where I write:
"...the particular code layout style you ultimately decide upon
does not matter at all!"
Or on page 11, where I write:
"...there is nothing wrong with the BSD or GNU styles of
bracketing.
If you, and your developers, find that verticallt aligned
brackets
improve your comprehension of code, then use them instead."
In the pages between those two quotes it's true that I do present two
arguments in favour of K&R style bracing...two arguments that I
personally found compelling. But I felt that the actual presentation
of
those arguments was quite balanced and unemotive.
> > [ In Amazon reviews this advice was not very well received ]
Advice on deeply irrational religious issues so rarely is. ;-)
> OTOH inDamianConway's classic "Object OrientedPerl", he chooses to use
> BSD style in the book.
>
> Change of heart Mr. Conway ?
Yes. Or rather: a change of head.
That was actually the whole point of the book. Rather than just
sticking
with the style I had habitually adopted from my first programming
teacher, I looked at the arguments in favour of various possible style
and
then made a conscious decision based on my analysis of the comparative
advantages and drawbacks of each.
In this case, I found the benefits of K&R style slightly outweighed
those of BSD, and also outweighed the cognitive cost of retraining my
eye and fingers.
So I changed my habit.
brian d foy also admirably clarified my goals (which I will expand
upon here):
> That is, Damian is offering one way to do things, but the real goal is
...also to encourage you to recognize that our coding habits have
consequences in that they can enhance or diminish the robustness
and
maintainability of the code we create, to illustrate that
particular
styles are not inherently right or wrong, to demonstrate that
their
benefits and drawbacks can be assessed rationally, to explore the
arguments pro and con a wide range of common Perl practices, to
make
"default" recommendations based on those explorations, and finally
(on the basis of all the preceding steps) to suggest that, above
all,
you need...
> to agree within your team how you want to do things and the be
> consistent in applying your decisions.
Damian
------------------------------
Date: Thu, 21 Jun 2007 21:45:48 -0000
From: usenet@DavidFilmer.com
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <1182462348.130635.90000@g37g2000prf.googlegroups.com>
On Jun 20, 10:01 pm, "Asim Suter" <asu...@cisco.com> wrote:
> Change of heart Mr. Conway ?
That's DOCTOR Conway to you, bub.
BTW, thank you, Damian, for this MOST EXCELLENT book. If someone
comes to me and says, "I want to learn Perl - can you recommend a good
book?" I always say that it doesn't matter much which book you read
first (any number of Perl introductory texts are fine) but _PBP_
should always be the second book that you read (and you should re-read
it every few months or so).
I only wish the book had been published years earlier, before I had
adopted so many bad habits!
--
The best way to get a good answer is to ask a good question.
David Filmer (http://DavidFilmer.com)
------------------------------
Date: Thu, 21 Jun 2007 15:10:47 -0700
From: "Asim Suter" <asuter@cisco.com>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <1182463848.501733@sj-nntpcache-2.cisco.com>
"damian@conway.org" <thoughtstream@gmail.com> wrote in message
news:1182458431.641563.8840@g37g2000prf.googlegroups.com...
> Asim Suter wrote:
>
>> I was readingPerlBest Practices by RespectedDamianConway
>> and he rather strongly advices using K&R style of code format as opposed
>> to
>> BSD style or GNU style.
>
> Strongly? When on pages 8&9 where I write:
>
> "...the particular code layout style you ultimately decide upon
> does not matter at all!"
>
> Or on page 11, where I write:
>
> "...there is nothing wrong with the BSD or GNU styles of
> bracketing.
> If you, and your developers, find that verticallt aligned
> brackets
> improve your comprehension of code, then use them instead."
>
> In the pages between those two quotes it's true that I do present two
> arguments in favour of K&R style bracing...two arguments that I
> personally found compelling. But I felt that the actual presentation
> of
> those arguments was quite balanced and unemotive.
>
>
>> > [ In Amazon reviews this advice was not very well received ]
>
> Advice on deeply irrational religious issues so rarely is. ;-)
>
>
>> OTOH inDamianConway's classic "Object OrientedPerl", he chooses to use
>> BSD style in the book.
>>
>> Change of heart Mr. Conway ?
>
> Yes. Or rather: a change of head.
>
> That was actually the whole point of the book. Rather than just
> sticking
> with the style I had habitually adopted from my first programming
> teacher, I looked at the arguments in favour of various possible style
> and
> then made a conscious decision based on my analysis of the comparative
> advantages and drawbacks of each.
>
> In this case, I found the benefits of K&R style slightly outweighed
> those of BSD, and also outweighed the cognitive cost of retraining my
> eye and fingers.
>
> So I changed my habit.
>
>
> brian d foy also admirably clarified my goals (which I will expand
> upon here):
>
>> That is, Damian is offering one way to do things, but the real goal is
>
> ...also to encourage you to recognize that our coding habits have
> consequences in that they can enhance or diminish the robustness
> and
> maintainability of the code we create, to illustrate that
> particular
> styles are not inherently right or wrong, to demonstrate that
> their
> benefits and drawbacks can be assessed rationally, to explore the
> arguments pro and con a wide range of common Perl practices, to
> make
> "default" recommendations based on those explorations, and finally
> (on the basis of all the preceding steps) to suggest that, above
> all,
> you need...
>
>> to agree within your team how you want to do things and the be
>> consistent in applying your decisions.
>
>
> Damian
>
Thank you Damian ( Dr Conway ) for the book and this reply.
I wish we all had the book a few years back :-)
Regards.
Asim
------------------------------
Date: Thu, 21 Jun 2007 15:11:44 -0700
From: "Asim Suter" <asuter@cisco.com>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <1182463905.807210@sj-nntpcache-2.cisco.com>
<usenet@DavidFilmer.com> wrote in message
news:1182462348.130635.90000@g37g2000prf.googlegroups.com...
> On Jun 20, 10:01 pm, "Asim Suter" <asu...@cisco.com> wrote:
>
>> Change of heart Mr. Conway ?
>
> That's DOCTOR Conway to you, bub.
Amen.
>
> BTW, thank you, Damian, for this MOST EXCELLENT book. If someone
> comes to me and says, "I want to learn Perl - can you recommend a good
> book?" I always say that it doesn't matter much which book you read
> first (any number of Perl introductory texts are fine) but _PBP_
> should always be the second book that you read (and you should re-read
> it every few months or so).
>
> I only wish the book had been published years earlier, before I had
> adopted so many bad habits!
>
>
> --
> The best way to get a good answer is to ask a good question.
> David Filmer (http://DavidFilmer.com)
>
------------------------------
Date: Thu, 21 Jun 2007 14:40:14 -0700
From: Dave Hansen <iddw@hotmail.com>
Subject: Re: The Modernization of Emacs
Message-Id: <1182462014.621775.176460@u2g2000hsc.googlegroups.com>
On Jun 21, 9:49 am, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> Twisted <twisted...@gmail.com> writes:
>
> > Given that in its out-of-the-box configuration it's well-nigh unusable
> > without a printed-out "cheat sheet" of some kind, of the sort that
> > were supposed to have died out in the 80s, getting it customized poses
> > something of a catch-22 for anyone trying to get started using it.
>
> I don't see that. C-h t is your friend if you're starting out. The
> only keystrokes a user really needs to remember are C-x C-s and C-x C-c;
> everything else simple text editing needs works as expected (arrow keys,
> backspace and so forth). Granted, text-mode is friendlier than
I'm not so sure C-h t is anybody's friend anymore. Every version of
Emacs that I've used since 1984 has supported the arrow and page up/
down keys. And every version of the tutorial that I've read (the
latest just a couple years back) insists on starting the user out with
C-f, C-b, C-p, C-n, C-V, and ESC-V, with some lame explanation like
"touch-typists shun the arrow and page keys, and besides, they might
not be supported on the next terminal you use." Like ESC, I suppose.
Furrfu.
Regards,
-=Dave
------------------------------
Date: Thu, 21 Jun 2007 20:10:18 -0000
From: Kaldrenon <kaldrenon@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182456618.763414.219080@g4g2000hsf.googlegroups.com>
Feel free to disagree with what I'm about to say. I know that this
thread would be far, FAR shorter if OP hadn't been instigating
disagreement, but so far most of the discourse has been polite, so I'm
going to say what I'm thinking.
I think there are far too many people in all camps (the Emacs camp,
the vi* camp, and the GUI/IDE/point-and-click-and-make-
everything-"user-friendly" camp) who look at this disagreement as a
debate in which they Are Right, and the members of the other two camps
Are Wrong. There are billions of people in this world, and even if you
ignore the ones who don't need to use a text editor or word processor
on a regular basis, you end up with a VERY large number of people. And
people are different. We think differently, we all have different
things that come to us naturally, different things that are tricky but
learn-able, and different things that we'll never be able to do
without a manual open in front of us.
There are a lot of people for whom emacs is easy to learn, logical to
use, and the way it is set up (or at least the way -they- set it up)
is so natural to them that they'll never be as productive anywhere
else. But there are also a lot of people for whom emacs doesn't click,
who can give it a genuine try but still not catch on, and even once
they learn enough to muddle through, they'll always work better in
Word, or in an IDE.
But I think there's something else to it, and it's part of why I think
the emacs faithful swear by it so fiercely, even if it does seem a
daunting tool to master.
I don't think anyone can make the argument that any (past or current)
graphics-based editor is as efficient when being used to its fullest
as a text-based editor. It's basic math - it takes measurably more
time to move a hand to the mouse, move/click the mouse, and more the
hand back to the touch-typing position than it does to execute even a
moderately complex series of keystrokes. Maybe not large amounts of
time -per action-, but it doesn't take too long for it to add up if
you spend a lot of time editing.
Contrast the time saved by not having to reposition one's hands, the
extensibility, and customization against the learning curve of an
interface that doesn't exactly throw its controls at the user, and
here's the conclusion I think results: graphical interfaces are -
easier- to develop some proficiency with, but proficiency with emacs
pays of far more in the long run.
And if you disagree with me, or if you think I expressed my point
poorly (I'm good that that), all you need to do is ask Steve Yegge his
thoughts on emacs.
-Andrew
------------------------------
Date: Thu, 21 Jun 2007 20:13:06 -0000
From: Kaldrenon <kaldrenon@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182456786.515889.40590@c77g2000hse.googlegroups.com>
> I don't think anyone can make the argument that any (past or current)
> graphics-based editor is as efficient when being used to its fullest
> as a text-based editor.
Clarifying - this part of the claim assumes a fairly similar feature
set, naturally.
------------------------------
Date: Thu, 21 Jun 2007 13:31:54 -0700
From: Falcolas <garrickp@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182457914.940791.224080@n2g2000hse.googlegroups.com>
On Jun 21, 2:10 pm, Kaldrenon <kaldre...@gmail.com> wrote:
> I don't think anyone can make the argument that any (past or current)
> graphics-based editor is as efficient when being used to its fullest
> as a text-based editor. It's basic math - it takes measurably more
> time to move a hand to the mouse, move/click the mouse, and more the
> hand back to the touch-typing position than it does to execute even a
> moderately complex series of keystrokes. Maybe not large amounts of
> time -per action-, but it doesn't take too long for it to add up if
> you spend a lot of time editing.
>
> Contrast the time saved by not having to reposition one's hands, the
> extensibility, and customization against the learning curve of an
> interface that doesn't exactly throw its controls at the user, and
> here's the conclusion I think results: graphical interfaces are -
> easier- to develop some proficiency with, but proficiency with emacs
> pays of far more in the long run.
I have to point out, that this makes the assumption that the most oft-
used commands in a GUI editor are not as easily accessed from the
keyboard as they are in a terminal editor.
I took a moment to look at the gui editor which has been made
available to me, and short of the "remove leading spaces" commands, I
do not need to remove my hands from the keyboard if I do not want to.
Your statement holds true if, and only if, a user does not take full
advantage of the keyboard commands. But if we're talking about
experienced users in both cases, then that's not an issue, is it?
------------------------------
Date: Thu, 21 Jun 2007 20:35:35 -0000
From: Kaldrenon <kaldrenon@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182458135.048992.179340@p77g2000hsh.googlegroups.com>
On Jun 21, 4:31 pm, Falcolas <garri...@gmail.com> wrote:
> Your statement holds true if, and only if, a user does not take full
> advantage of the keyboard commands. But if we're talking about
> experienced users in both cases, then that's not an issue, is it?
Granted. I suppose my claim should have been more specifically about
the means of interaction, and not about the tool being used. After
all, Emacs 22.1 has fairly complete point-and-click support, even
though I suspect more people use the keyboard as their primary input.
------------------------------
Date: Thu, 21 Jun 2007 22:41:34 +0200
From: Matthias Buelow <mkb@incubus.de>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <5e063mF35d3v6U1@mid.dfncis.de>
Kaldrenon wrote:
> I don't think anyone can make the argument that any (past or current)
> graphics-based editor is as efficient when being used to its fullest
> as a text-based editor.
Actually, I think the argument can be made:
``We’ve done a cool $50 million of R & D on the Apple Human Interface.
We discovered, among other things, two pertinent facts:
* Test subjects consistently report that keyboarding is faster than
mousing.
* The stopwatch consistently proves mousing is faster than
keyboarding.''
(from http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index.html )
However, at least for me, heavy mousing is stressful to the wrist, so I
prefer to keep my hands on the keyboard (even though I use a trackball,
which greatly reduces the strain for me).
I also think that while intuitive cursor positioning and text selection
operations may be faster with a mouse, complex operations (like on the
shell or complex editor commands) are impractical through a pure
point+click interface.
------------------------------
Date: Thu, 21 Jun 2007 15:49:51 -0500
From: notbob <notbob@nothome.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <5ZSdnYAchqLyeefbnZ2dnUVZ_vqdnZ2d@comcast.com>
On 2007-06-21, Kaldrenon <kaldrenon@gmail.com> wrote:
> Feel free to disagree with what I'm about to say.
[...]
> And if you disagree with me, or if you think I expressed my point
> poorly....
I think you expressed it well. I'll add that using one does not
necessarilly exclude using the other. I tend to use whatever makes
the job easiest FOR ME! ...be it a gui or the command line. Also,
ease of learning emacs has absolutely zero to do with mental prowess
and not everyone using it is a code whiz. Except for some html and
shell scripting, I do almost zero developement because it bores me to
freakin' tears. That's not to say I can't like the command line and
emacs.
All types of user interface have their pros and cons and it's
senseless to limit one's self to one or the other. Some tasks benefit
from using both simultaneously, acad and gimp/p-shop being prime
examples. Sure, everyone loves the camaraderie of belonging to a
group. That's just being human. But, choosing a preference doesn't
require fanatical loyalty to the exclusion of all other options, or at
least it shouldn't. Use the one that's best for the job.
nb
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 551
**************************************
