[29291] in Perl-Users-Digest
Perl-Users Digest, Issue: 535 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 19 14:09:39 2007
Date: Tue, 19 Jun 2007 11:09:07 -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 Tue, 19 Jun 2007 Volume: 11 Number: 535
Today's topics:
Assigning another filehandle to STDOUT, using binmode. <a24061@ducksburg.com>
Re: Find replace : Regular expression <noreply@invalid.net>
help with getting pid!! <seema_coma@yahoo.co.in>
Re: help with getting pid!! <glex_no-spam@qwest-spam-no.invalid>
Re: Language Perl (Randal L. Schwartz)
Re: package filename mismatches ? <uri@stemsystems.com>
Re: Passing hash to another script via commandline <blah@blahblah.co.uk>
Re: Passing hash to another script via commandline <blah@blahblah.co.uk>
Re: Passing hash to another script via commandline <noreply@gunnar.cc>
Re: Passing hash to another script via commandline <ts@dionic.net>
Re: Passing hash to another script via commandline <purlgurl@purlgurl.net>
Re: Passing literal with reference? <uri@stemsystems.com>
Re: perl and php <cwilbur@chromatico.net>
RegEx Solution Needed <whiteqt@gmail.com>
Re: RegEx Solution Needed (Steven M. O'Neill)
Re: The Modernization of Emacs: exists already <xah@xahlee.org>
Re: The Modernization of Emacs: not dumb down <xah@xahlee.org>
Re: The Modernization of Emacs: technically superior <xah@xahlee.org>
Re: The Modernization of Emacs: terminology buffer and <xah@xahlee.org>
Re: The Modernization of Emacs: terminology buffer and (Joel J. Adamson)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 19 Jun 2007 16:53:01 +0100
From: Adam Funk <a24061@ducksburg.com>
Subject: Assigning another filehandle to STDOUT, using binmode.
Message-Id: <tnalk4-cua.ln1@news.ducksburg.com>
I'm writing a program that uses File::Find to recurse through the
files and directories specified as command-line arguments, and to call
process_file() on each one.
By default the program prints each file's results to STDOUT, but if I
give it the -d DIRECTORY option, it should print each file's output to
a file in DIRECTORY with ".txt" at the end of the name instead of
".xml". There are a lot of non-English UTF-8 characters in the input
and output.
At the moment, I have the following near the beginning of the program:
binmode (STDOUT, ":utf8");
*OUTPUT = *STDOUT ;
and the following for each input file:
sub process_file {
# find is called with the no_chdir option set
my $input_filename = $_;
my $output_filename = $input_filename;
if ($option{x} || ($input_filename =~ m!\.xml$!i ) ) {
if ($option{d}) {
# drop the ".xml" suffix
$output_filename =~ s!\.xml$!!i ;
# drop the relative path
$output_filename =~ s!^.*/!! ;
# add the new path and suffix
$output_filename = $option{d} . "/" . $output_filename;
$output_filename = $output_filename . ".txt";
open(OUTPUT, ">" . $output_filename);
binmode (OUTPUT, ":utf8");
}
print(STDERR "Reading : ", $input_filename, "\n");
# ... CODE THAT CALLS OTHER SUBROUTINES TO READ THE
# INPUT FILE, PROCESS IT, AND print(OUTPUT ...) A
# LOT OF STUFF
if ($option{d}) {
print(STDERR "Wrote : ", $output_filename, "\n");
close(OUTPUT);
}
}
else {
print(STDERR "Ignoring: ", $File::Find::name, "\n");
}
}
As far as I can tell, this works and cleanly suppresses the "Wide
character" warnings. Is this use of filehandle assignment OK, or am I
likely to run into trouble later?
Also, why is it necessary to set binmode on OUTPUT every time I open
it?
Thanks,
Adam
------------------------------
Date: Tue, 19 Jun 2007 18:01:18 GMT
From: Ala Qumsieh <noreply@invalid.net>
Subject: Re: Find replace : Regular expression
Message-Id: <ORUdi.15213$2v1.4419@newssvr14.news.prodigy.net>
Gunnar Hjalmarsson wrote:
> Ala Qumsieh wrote:
>> Gunnar Hjalmarsson wrote:
>>> Subra wrote:
>>>> $line=~s/(^#.*)__linux__(.*)/$1__linux$2/g;
>>>> $line=~s/(^#.*)LINUX(.*)/$1__linux$2/g;
>>>> $line=~s/(^#.*)[\s]+linux(.*)/$1 __linux $2/g;
>>> That could possibly be written:
>>>
>>> $line =~ s/(^#.*?)(?:__)?linux(?:__)?/$1__linux/gi;
>>
>> you meant this:
>>
>> $line =~ s/(^#.*?)(?:__)?linux(?:__)?/${1}__linux/gi;
>>
>> the OP had it wrong too, and I suspect you just copied/pasted.
>
> Well, no, to be honest I didn't think of it, but I had tested the code
> before posting.
>
> Now, when I play with various alternatives, it seems as if the braces
> are only needed if the string following the dollar-digit variable begins
> with a digit.
You are right. User variables can not start with a digit (only letters or
underscore), so there is no ambiguity with leaving out the braces in the
examples above. My bad.
--Ala
------------------------------
Date: Tue, 19 Jun 2007 10:17:26 -0700
From: seema <seema_coma@yahoo.co.in>
Subject: help with getting pid!!
Message-Id: <1182273446.113924.141150@i38g2000prf.googlegroups.com>
Hi all,
I am new to perl programming, I have return a perl script to get the
pid of all my_app currently running on HP-UX box,
#!/usr/bin/perl
@process_array= `ps -ef | grep my_app | grep -v grep | awk '{print
$2}'`;
foreach $index (@process_array)
{
print $index, "\n";
}
It doesnt give the pid of my_app am I doing some thing wrong here??
Thanks in advance,
------------------------------
Date: Tue, 19 Jun 2007 12:43:30 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: help with getting pid!!
Message-Id: <467815c2$0$496$815e3792@news.qwest.net>
seema wrote:
> Hi all,
>
> I am new to perl programming, I have return a perl script to get the
> pid of all my_app currently running on HP-UX box,
>
> #!/usr/bin/perl
>
> @process_array= `ps -ef | grep my_app | grep -v grep | awk '{print
> $2}'`;
>
> foreach $index (@process_array)
> {
> print $index, "\n";
> }
>
> It doesnt give the pid of my_app am I doing some thing wrong here??
> Thanks in advance,
Well, what does it give you? Look at the output of "ps -ef" and
compare that with what you're printing and adjust as needed.
------------------------------
Date: Tue, 19 Jun 2007 09:23:04 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Language Perl
Message-Id: <86ir9jncbb.fsf@blue.stonehenge.com>
>>>>> "sujal01" == sujal01 <sujal01@gmail.com> writes:
sujal01> Hi,
sujal01> For articles visit:
sujal01> http://www.telepk.com/articles/
For spam visit:
Your web site!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Tue, 19 Jun 2007 18:03:36 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: package filename mismatches ?
Message-Id: <x73b0n95zc.fsf@mail.sysarch.com>
>>>>> "b" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:
b> Commonly, when I make a file Utils/Edit.pm
b> (intended to be used via use Utils::Edit;)
b> I have a good chance of putting
i wouldn't use such generic module names as they may conflict with cpan
names. if these are company (even your own) or project specific modules,
it is a good idea to use a prefix name for them like MyFoo::
b> Now I understand that "use blah"
b> is equivalent to:
b> BEGIN { require Module; import Module LIST; }
yep.
b> Is there a way to make the import fail
b> if the package has not supplied it,
b> so that if I've made my usual bone head mistake,
b> perl will tell me?
not with use by itself. it will silently ignore a failure to find an
import method. also if your module doesn't export anything (typical of
OO and some other modules), then just the module is loaded.
i see two solutions. first, learn to name and store your modules properly
according to their package and file names. this is the proper answer.
the other solution is for you to test if the module was loaded correctly
by accessing something in it or checking the symbol tables, etc. this is
clunky as it has to be done in the using code and each time if you really
want this sort of checking.
the rule about package names and file names is simple. there is NO
REQUIRED RELATIONSHIP between a package name and a file (path) name of a
module. you can have multiple package commands in one file and you can
have multiple files with the same package namespace. only use commands
associate the two by the calling of the import method of a module.
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: Tue, 19 Jun 2007 16:25:23 +0100
From: "IanW" <blah@blahblah.co.uk>
Subject: Re: Passing hash to another script via commandline
Message-Id: <f58sg5$r8i$1$8300dec7@news.demon.co.uk>
"Jürgen Exner" <jurgenex@hotmail.com> wrote in message
news:XoRdi.7443$u65.1117@trndny07...
> It might be easier to use Data::Dumper to convert the hash into a textual
> representation that can readily loaded into perl again
Hi Jue
Thanks for the reply.
If I understand it correctly, doesn't Data::Dumper just convert the hash
into a string representing the hashes structure? In which case, if I tried
to pass that via the command line, the spaces (amongst some other characters
like double quotes) would cause probs when the string is pulled into @ARGV
at the receiving script?
Eg:
use Data::Dumper;
my $d = Dumper(\%data);
my $result = `perl z:/interface.pl $d`;
That would result in only $ARGV[0] only containing "$VAR1". One could put $d
in double quotes, but if there were double quotes in one of the hash values
then it would presumably mess things up again.
Regards
Ian
------------------------------
Date: Tue, 19 Jun 2007 16:26:56 +0100
From: "IanW" <blah@blahblah.co.uk>
Subject: Re: Passing hash to another script via commandline
Message-Id: <f58sj1$rat$1$8300dec7@news.demon.co.uk>
"mattsteel" <matteo_vitturi@virgilio.it> wrote in message
news:1182263032.600752.186580@q69g2000hsb.googlegroups.com...
> Possible workaround: you can try to tie-untie your hash to a file so
> you can pass the filename to the second script which can tie-untie the
> same hash, then.
I was rather hoping avoiding passing data via a file but thanks anyway.
Regards
Ian
------------------------------
Date: Tue, 19 Jun 2007 17:31:28 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Passing hash to another script via commandline
Message-Id: <5dqbbtF35qn5rU1@mid.individual.net>
IanW wrote:
> How do I pass a hash to another script via the command line?
As others have told you, you can't.
However, nothing prevents you from assigning a hashref to @ARGV
directly, i.e. instead of
> my $result = `perl z:/interface.pl \%data`;
you may want to try:
$ARGV[0] = \%data;
do 'z:/interface.pl';
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 19 Jun 2007 16:45:14 +0100
From: Tim Southerwood <ts@dionic.net>
Subject: Re: Passing hash to another script via commandline
Message-Id: <4677fa0a$0$644$5a6aecb4@news.aaisp.net.uk>
IanW wrote:
>
> "Jürgen Exner" <jurgenex@hotmail.com> wrote in message
> news:XoRdi.7443$u65.1117@trndny07...
>
>> It might be easier to use Data::Dumper to convert the hash into a textual
>> representation that can readily loaded into perl again
>
> Hi Jue
>
> Thanks for the reply.
>
> If I understand it correctly, doesn't Data::Dumper just convert the hash
> into a string representing the hashes structure? In which case, if I tried
> to pass that via the command line, the spaces (amongst some other
> characters like double quotes) would cause probs when the string is pulled
> into @ARGV at the receiving script?
>
> Eg:
>
> use Data::Dumper;
> my $d = Dumper(\%data);
> my $result = `perl z:/interface.pl $d`;
>
> That would result in only $ARGV[0] only containing "$VAR1". One could put
> $d in double quotes, but if there were double quotes in one of the hash
> values then it would presumably mess things up again.
>
> Regards
> Ian
I think there is a simple point being missed here.
Why not use Data::Dumper to serialise the data (because that's what it
does), print the result to STDOUT, have the called program read it in from
STDIN to a scalar, then eval the scalar.
In other words, pipe the serialised version of the hash between the two
programs. Very much the "unix way" (TM).
Another way to do it would be to use IPC::Shareable and tie the hash to a
blob of shared memory. All that the callee program needs to know is the
shared memory key id which is trivially passed as an argument.
Probably not a lot efficiency wise as the latter method has to serialise the
data anyway, but it's neat, and potentially bi-directional - ie the callee
can modify the data and have the caller see it.
Cheers
Tim
------------------------------
Date: Tue, 19 Jun 2007 10:35:59 -0700
From: Purl Gurl <purlgurl@purlgurl.net>
Subject: Re: Passing hash to another script via commandline
Message-Id: <EJWdnY-u5f-ZieXbnZ2dnUVZ_hOdnZ2d@giganews.com>
IanW wrote:
> How do I pass a hash to another script via the command line?
> That is, if I do this
> use strict;
> my %data = (
> field1 => 'f1val',
> field2 => 'f2val'
> );
> my $result = `perl z:/interface.pl \%data`;
> and in interface.pl I have the lines:
> use strict;
> my($dataref) = $ARGV[0];
> print $dataref->{'field1'};
> I get the error:
> Can't use string ("%data") as a HASH ref while "strict refs" in use at
> z:/interface.pl line ..
Others have explained why you cannot do this.
Convert your hash to an array, pass your array as arguments,
then recreate your hash in your secondary script.
However, this is a lot of work for nothing. I would simply
create an array, pass the array, then work with array @ARGV
in my secondary script, without creating a new hash.
PRIMARY:
#!perl
%Data = (field1 => 'f1val', field2 => 'f2val', field3 => 'f3val');
system ("perl test2.pl @{[%Data]}");
SECONDARY:
#!perl
for (@ARGV)
{
$Data_Input{$ARGV[$count]} = $ARGV[$count + 1];
$count += 2;
}
delete ($Data_Input{''});
while (($key, $value) = each %Data_Input)
{ print "$key = $value\n"; }
PRINTED RESULTS:
field1 = f1val
field2 = f2val
field3 = f3val
--
Purl Gurl
--
"Then again what can you expect from a fat-assed, champagne swilling,
half-breed just off the Rez?"
- Joe Kline
------------------------------
Date: Tue, 19 Jun 2007 17:52:26 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Passing literal with reference?
Message-Id: <x77ipz96hy.fsf@mail.sysarch.com>
>>>>> "BB" == Brad Baxter <baxter.brad@gmail.com> writes:
BB> Yes, I do realize that about objects, and I expected someone to
BB> mention it. However, I suspect that many more of those are
BB> references to hashes, arrays or whatnot than are references to
BB> scalars, so I don't really think it evens out the ratio much.
BB> (The "ratio" being, of course a figment for expression
BB> purposes. :-)) I don't doubt for a minute that many people pass
BB> references to scalars when it makes sense to do so. But I still
BB> believe that far and away, simple scalars are passed more than
BB> anything else. I didn't think it was that debatable. :-) In
BB> particular, when was the last time (outside of this thread) that
BB> you saw someone pass a literal as \"Hello, world?"
i have done it. not often but i did know it worked and was surprised to
see someone here claim it didn't. the problem with references to
literals is that the data is readonly and can blow up if the sub tries
to modify it.
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: 19 Jun 2007 11:07:49 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: perl and php
Message-Id: <87d4zsj83e.fsf@mithril.chromatico.net>
>>>>> "S" == skywriter14 <sumonsmailbox@gmail.com> writes:
S> Please tell me why there are tons of web sites made with PHP as
S> compared to Perl or any other language, if PHP is worse than
S> Perl and Ruby. How does it survive? Not only the rookies
S> program with PHP, isn't it?
That's pretty much exactly it. Rookies, and people who have other
systems to do the heavy lifting and just want a web interface to a
database system (for instance). Also, if you have shared web hosting,
you're likely to find that mod_php is enabled in Apache but mod_perl
is not, and in that kind of a situation PHP is likely to be less painful.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 19 Jun 2007 10:50:22 -0700
From: Matt White <whiteqt@gmail.com>
Subject: RegEx Solution Needed
Message-Id: <1182275422.410270.246530@i13g2000prf.googlegroups.com>
Hello,
I am in need of an effective regular expression that will capture
multiple values on the same line, not knowing in advance how many
matching values there are. Basically it needs to match strings of 3
digits within a string that contains anything (all on the same line).
I am pretty familiar with regular expressions but I've never tried
anything like this before.
So what I have is a line like:
abc123def456ghi789jkl
I want to end up with a list that looks like:
[123,456,789]
Thanks for your help!
------------------------------
Date: Tue, 19 Jun 2007 18:07:03 +0000 (UTC)
From: steveo@panix.com (Steven M. O'Neill)
Subject: Re: RegEx Solution Needed
Message-Id: <f59607$4pa$1@reader2.panix.com>
Matt White <whiteqt@gmail.com> wrote:
>So what I have is a line like:
>abc123def456ghi789jkl
>
>I want to end up with a list that looks like:
>[123,456,789]
This looks pretty close:
~>perl -ne 'while (m/(\d{3})/g) {print "$1,"}'
abc123def456ghi789jkl
123,456,789,^C
Removing the final "," is left as an exercise for the reader.
--
Steven O'Neill steveo@panix.com
Brooklyn, NY http://panix.com/~steveo/cgi/is-it-friday-yet.html
------------------------------
Date: Tue, 19 Jun 2007 10:04:38 -0700
From: Xah Lee <xah@xahlee.org>
Subject: Re: The Modernization of Emacs: exists already
Message-Id: <1182272678.877166.209640@j4g2000prf.googlegroups.com>
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Aquamacs already does what you want.
A: Aquamacs is a emacs variant based on emacs, for Apple's Macintosh
computers, created in about 2004 by David Reitter. Aquamacs modifies
emacs so that its user interface follows modern (Mac OS X)
conventions. For example, copy, paste, undo shortcuts are cmd-c, cmd-
v, cmd-z. Open file is cmd-o, saving is cmd-s. Close window is cmd-w.
There is a redo command by default, with shortcut cmd-shift-z. By
following a modern user interface, almost all points mentioned in this
article are fixed in Aquamacs. For more info, see: Wikipedia Aquamacs=E2=86=
=97
and Aquamac's home page at: Aquamacs.org =E2=86=97
As a emacs variant, it does help in spreading the idea that emacs user
interface should be modernized. However, a third-party variant
software is irrelevant to the modernization issue.
For example, suppose Microsoft Word remained with its DOS era command
line interface, for example, file is opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load). Suppose Microsoft hired a
third party to release a variant called MS AquaWord. This would not
help Microsoft Word the software itself, and is likely to complicate
the issue around Microsoft Word.
Xah
xah@xahlee.org
=E2=88=91 http://xahlee.org/
------------------------------
Date: Tue, 19 Jun 2007 10:02:44 -0700
From: Xah Lee <xah@xahlee.org>
Subject: Re: The Modernization of Emacs: not dumb down
Message-Id: <1182272564.002509.186650@i13g2000prf.googlegroups.com>
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Why should emacs want to be popular and why should emacs change to
conform the majority? We don't want emacs to be popular. We want
people to adopt emacs, not emacs adopting people.
A: This attitude has plagued unix and computer geekers for decades. In
the early 1990s (DOS and unix), tech geekers would sneer at graphical
menus and mouse, with hordes of reasons how pure text interface, the
command line, and or keyboard operations are sufficient and superior
than graphical user interface or using a mouse. This seems ridiculous
today, but such online forum messages are common.
The reason for these type of attitude, is almost never a sensible
alternative view about the topic in discussion, but a show of machismo
and superiority complex. (perhaps more than 95% of online computing
forum users are males, and majority of them are aged under 25.) The
person who utters such opinion, made sure in the way he writes that he
is a expert in the =E2=80=9Cmore difficult to use=E2=80=9D method or tools =
and would
prefer things not to be =E2=80=9Cdumbed down=E2=80=9D.
It is silly to retort =E2=80=9CWhy should emacs want to be popular?=E2=80=
=9D. It is
like asking =E2=80=9Cwhy do you want to live longer?=E2=80=9D when someone =
is picky
about healthy food, or =E2=80=9Cwhy should you want to look beautiful?=E2=
=80=9D when
someone dresses up. We want to improve software, not taking the
attitude of =E2=80=9Cwe are more complex and unique and superior and we want
to keep dummies out=E2=80=9D.
In software design, occasionally we are tied down with a design
decision, such that it has a popular vs elegant aspect. For example,
suppose we are designing a set of keyboard shortcuts for emacs and we
are faced the question of whether to keep the copy/paste/undo/open etc
with the conventional C/V/Z/O etc keystrokes. Or, we can choose to
sacrifice user's familiarity of conventions but obtain a keyboard
shortcut set that is in some way more consistent, extensible, or
otherwise technically better.
If a design decision comes down to a pure popularity vs elegance and
everything else equal, then the decision might be based on our
philosophical dispositions or the software creator's ultimate goal.
However, it is not proper to pigeon-hole design issues into popularity
vs elegance.
Xah
xah@xahlee.org
=E2=88=91 http://xahlee.org/
------------------------------
Date: Tue, 19 Jun 2007 10:04:01 -0700
From: Xah Lee <xah@xahlee.org>
Subject: Re: The Modernization of Emacs: technically superior
Message-Id: <1182272641.777476.195600@z28g2000prd.googlegroups.com>
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: Emacs's ways are technically superior. It should not change.
A: Emac's user interface, when compared to modern software
application's user interface, is complex and unusual, however, there's
no basis whatsoever of it being actually a superior design with
regards to any sensible metrics. (in fact, much of emacs's user
interface are due to historical reasons. That is, how computers are in
1980s.)
For example, let's consider emacs's system of keyboard shortcuts. For
a keyboard shortcut system, we might judge its quality based on
several aspects. Here are some examples of consideration:
* Is it easy to learn? (is it familiar to most people?)
* Is it easy to type? (is most frequently used commands easy to
type?)
* Is it easy to remember?
* Are more frequently used commands have the easier-to-type
shortcuts that less frequently used commands?
* Are most frequently used commands all have a keyboard shortcut?
* Can the shortcut system somehow be consistent and extensible to
cover other user defined shortcuts?
Emacs's keyboard shortcuts system, somewhat satisfies the last aspect,
but do very bad with respect to all the others. Emacs keyboard
shortcuts are perhaps one of the most difficult to learn among
software, and is also one of the most difficult to remember. The worst
aspect of emacs's keyboard shortcuts, is that it is ergonomically
painful. (Many emacs-using programer celebrities have injured their
hands with emacs. (e.g. Richard Stallman, Jamie Zawinski), and emacs's
Cntl-x keyboard and Meta-x combinations are most cited as the major
turn-off to potential users among programers)
Computer keyboard is a hardware interface, and the mapping of commands
to the key press combinations can be considered from a Operation
Research point of view. The keyboard hardware itself can be designed
with consideration of ergonomics (that's why we have split and curved
keyboards), but consideration of what functions to map to what key
presses is also non-trivial if the software has large number of
functions or if the software is mission critical. Think of it this
way, consider a airplane cockpit, filled with knobs, dials, buttons,
and switches. Now, if your job is to map the airplane control
functions to these switches, what are the things to consider for a
optimal map?
If we take careful consideration on creating a keyboard shortcut
system for emacs, it is actually easy to create a system that are
purely superior in some technical sense than the ad-hoc Emacs's ways.
Aside from keyboard shortcuts system, Emacs's other user interfaces
are also questionable. For example, one major aspect of emacs
operation is that it uses a single window for multiple purposes and
files. Emacs is this way not because of a design decision, but rather
due to historical reasons. Computer resources in the 1980s are very
limited. When emacs is around, graphical system of showing =E2=80=9Cwindows=
=E2=80=9D
is not practically available, and the emacs's method of using the
screen (the textual-based-monitor) for presenting multiple tasks
(=E2=80=9Cbuffers=E2=80=9D) is actually a very advanced user interface desi=
gn not
available in software of that era. When graphical systems becomes
practical in the 1990s, drawing a window takes a lot memory, and
opening multiple windows is slow and inpractical.
Modern software interface (say, post 2000) usually uses one window per
file (or task), and or show a tab if multiple task is to be
represented in a single window. However, in general, emacs doesn't
provide the tabs visual clue and still remained its old way of using a
single window for all files and tasks as its standard operation. As
far as user interface design is considered per se with respect to
today's computing standards, the emacs's way is inferior because it is
less intuitive. Arguably, emacs's operation methods may be more
efficient for expert users. 20 years ago, efficiency for expert users
may out weight the ease of use for majority of average users. But in
today computing era, computers are standard tools in every household,
efficiency and ease of use for general users is as important for
professional users. Even for professional users, it is openly
questionable that emacs's ways of operation induced by its default
user interface allows faster or more efficient operation than a user
interface based on modern software conventions.
Xah
xah@xahlee.org
=E2=88=91 http://xahlee.org/
------------------------------
Date: Tue, 19 Jun 2007 10:01:35 -0700
From: Xah Lee <xah@xahlee.org>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182272495.990807.99110@a26g2000pre.googlegroups.com>
Here are some Frequently Asked Questions about The Modernization of
Emacs.
They are slightly lengthy, so i've separated each item per post. The
whole article can be found at
http://xahlee.org/emacs/modernization.html
------------
Q: The Terminology =E2=80=9Cbuffer=E2=80=9D and =E2=80=9Ckeybinding=E2=80=
=9D is good as they are.
A: The terminology =E2=80=9Cbuffer=E2=80=9D or =E2=80=9Ckeybinding=E2=80=9D=
, are technical terms
having to do with software programing. The term =E2=80=9Ckeybinding=E2=80=
=9D refers to
the association of a keystroke with a command in a technical, software
application programing context. That is to say, a programer =E2=80=9Cbind=
=E2=80=9D a
keystroke to a command in a software application. The term =E2=80=9Cbuffer=
=E2=80=9D
refers to a abstract, temporary area for storing data, in the context
of programing or computer science.
These terms are irrelevant to the users of a software application.
As a user of a text editor, he works with files. The terms =E2=80=9Copened
file=E2=80=9D or =E2=80=9Cuntitled file=E2=80=9D are more appropriate than =
=E2=80=9Cbuffer=E2=80=9D. Since
emacs is also used for many things beside reading files or writing to
files, for example, file management, ftp/sftp, shell, email, irc etc.,
the proper term can be =E2=80=9Cpanel=E2=80=9D, =E2=80=9Cwindow=E2=80=9D, o=
r =E2=80=9Cwork area=E2=80=9D.
And, the term =E2=80=9Ckeyboard shortcut=E2=80=9D refers to typing of a key-
combination to activate a command. It is also more appropriate than
=E2=80=9Cbinding=E2=80=9D or =E2=80=9Ckeybinding=E2=80=9D.
Although concepts like =E2=80=9Cbuffer=E2=80=9D and =E2=80=9Ckeybinding=E2=
=80=9D are seemingly
interchangeable with =E2=80=9Cpanel=E2=80=9D or =E2=80=9Ckeyboard shortcut=
=E2=80=9D, but their
contexts set them apart. This is why in all modern software
application's user documentations, terms like =E2=80=9Cbuffer=E2=80=9D or =
=E2=80=9Ckeybinding=E2=80=9D
are not to be seen but =E2=80=9Cwindows, panes, and keyboard shortcuts=E2=
=80=9D.
The reason emacs uses the technical terminologies throughout is
because when emacs started in the 1970s, there really isn't any other
text editors or even software applications. And, Emacs users consists
of solely computer scientists and programers, and there are not many.
Changes in society are always resisted by old timers, but it is also a
main element behind progress. This terminology issue may seem trivial,
but its importance lies in making emacs palpable to the vast number of
people who ever need to use a computer to write.
Xah
xah@xahlee.org
=E2=88=91 http://xahlee.org/
------------------------------
Date: Tue, 19 Jun 2007 13:06:43 -0400
From: jadamson@partners.org (Joel J. Adamson)
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <87bqfbeuvw.fsf@W0053328.mgh.harvard.edu>
Xah Lee <xah@xahlee.org> writes:
> Here are some Frequently Asked Questions about The Modernization of
> Emacs.
>
> They are slightly lengthy, so i've separated each item per post. The
> whole article can be found at
>
> http://xahlee.org/emacs/modernization.html
> ------------
>
> Q: The Terminology “buffer” and “keybinding” is good as they are.
>
> A: The terminology “buffer” or “keybinding”, are technical terms
> having to do with software programing. The term “keybinding” refers to
> the association of a keystroke with a command in a technical, software
> application programing context. That is to say, a programer “bind” a
> keystroke to a command in a software application. The term “buffer”
> refers to a abstract, temporary area for storing data, in the context
> of programing or computer science.
>
> These terms are irrelevant to the users of a software application.
Bologna.
Every computer user should see himself as a programmer.
> Changes in society are always resisted by old timers, but it is also a
> main element behind progress. This terminology issue may seem trivial,
> but its importance lies in making emacs palpable to the vast number of
> people who ever need to use a computer to write.
I'm a young-timer.
Joel
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
------------------------------
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 535
**************************************
