[29318] in Perl-Users-Digest
Perl-Users Digest, Issue: 562 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 23 03:10:09 2007
Date: Sat, 23 Jun 2007 00: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 Sat, 23 Jun 2007 Volume: 11 Number: 562
Today's topics:
Re: DBD::AnyData hangs when exporting XML KomsBomb@hotmail.com
Re: FAQ 1.6 What is perl6? <purlgurl@purlgurl.net>
Re: FAQ 1.6 What is perl6? <uri@stemsystems.com>
Re: FAQ 1.7 How stable is Perl? <purlgurl@purlgurl.net>
Re: FAQ 1.7 How stable is Perl? QoS@domain.invalid
new CPAN modules on Sat Jun 23 2007 (Randal Schwartz)
Re: The Modernization of Emacs <eadmund42@NOSPAMgmail.com>
Re: The Modernization of Emacs: terminology buffer and <timr@probo.com>
Re: The Modernization of Emacs: terminology buffer and <timr@probo.com>
Re: The Modernization of Emacs: terminology buffer and <eadmund42@NOSPAMgmail.com>
Re: The Modernization of Emacs: terminology buffer and <eadmund42@NOSPAMgmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 22 Jun 2007 21:25:12 -0700
From: KomsBomb@hotmail.com
Subject: Re: DBD::AnyData hangs when exporting XML
Message-Id: <1182572712.644380.162300@q19g2000prn.googlegroups.com>
On Jun 23, 12:14 am, xhos...@gmail.com wrote:
>
> It is almost surely not a bug in perl itself, but rather it does seem to be
> a bug in the AnyData module. So it is a bug in a module written in Perl,
> but is not a bug in perl. You could contact the maintainers of AnyData
> about it. I tried to dig into it myself, but
I must clear that I love Perl but I have to allow my lover has some
bugs in it. LOL.
I'm very glad to hear it's not a bug in Perl. :-)
> > I only use Windows and I have no idea of it.
> > I also found a STrace package in Perl, but I don't know how to use it.
>
> Thanks for pointing that out. I hadn't known of it before and I'll look
> into it.
I guess the package STrace is a little same with that Linux utility
but it's cross platform. I can't confirm that because I almost didn't
use Linux.
> I've found the problem in AnyData/Format/XML.pm, around line 876:
>
> #$self->{twig}->print;
> #z if ( ( $storage and $file and !($file eq $storage->{file_name}) )
> #z or ( $storage and $file and !$storage->{fh} )
> if ( ( $storage and $file )
> ) {
> $storage->{file_name} = $file;
> close $storage->{fh} if $storage->{fh}; ### Just added by Me
> $storage->{fh} = $storage->open_local_file($file,'o');
> }
>
> $storage->{fh} already holds a locked filehandle, so trying to obtain
> a new filehandle and lock it (which open_local_file does) deadlocks.
I add that line like you did. OK, no dead lock again, but the output
is wrong like "XML::Twig=HASH(0x1d24544)".
> I must say that this adventure didn't make me terribly eager to use AnyData
> in my own programs.
What I'm doing is a utility for myself. So if AnyData will work for
me,
(e.g, by exporting to a string rather than to a file), I will still
use
it.
Whatever, thank you very much for your patient and your time.
------------------------------
Date: Fri, 22 Jun 2007 21:17:02 -0700
From: Purl Gurl <purlgurl@purlgurl.net>
Subject: Re: FAQ 1.6 What is perl6?
Message-Id: <K9qdnZ8aY-0hA-HbnZ2dnUVZ_smonZ2d@giganews.com>
Clenna Lumina wrote:
> Randal L. Schwartz wrote:
>> Purl Gurl wrote:
(snipped)
>>>> "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 Purl> False Gods of Perl around here were screaming their
>>> heads off about, Purl> "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.
> I have have to sort of agree with "Purl" on this one, some what. I have
> seen soem regualars reepatedly tell people not to reinvent whats already
> good and working and accepted. Even if the OP who posted the reinvention
> did a decent job, theres usually aready to way theres already a way to
> do it thats generally accepted.
> But, Larry Wall's own words do seem to add a hint of contradicting to
> soem of the preachings. Yes, it good to use what's workign well and
> accepted and I suport that notion, but if that were always the case,
> then there wouldn't be a Perl6 in the works :)
I will add a courtesy note, Randal is not opposed to reinvention.
Most likely Randal thinks of this as I do, simply developing better
and more efficient methods for any given task.
On Perl 6, my personal opinion is this project is the greatest
historical blunder for Perl's history. Seven years into this
and no closer to being released. Once released, Perl 6 will prove
to be very unpopular. My opinion is Perl 6 porters have wasted
seven years of effort. Their efforts would be better invested
by turning Perl 5 into a lean and mean machine. Perl 6 is already
vaporware; technological advances and consumer needs have already
surpassed what Perl 6 can provide. Perl 6 is a dinosaur.
This preaching about not reinventing the wheel is a result of
mindless peer group pressure. Modules are hot! You MUST use
modules, always, even when not needed. Some of this is many
simply do not know how write code free of modules. Some of
this is "use a module" is a quick answer and a lazy way out
of investing effort into coding; a lack of pride.
Here is an example of how these mindless minions think.
Perl core contains a declaration. This is the "our" declaration
for global variables. This declaration is to fix the broken
strict module. Crazy, yes? Writing perl core to repair a
broken module is inane. Years back, "our" was well accepted
and suggested. Over time, Perl code writers became more lazy
and started using "my" declarations for globals. This is, of
course, incorrect syntax, bad syntax. Nonetheless, discussion
group minions began a campaign of, "you must use 'my' for
every single variable, global or not." This caught on, people
like this idea of less work, less effort, what the heck, let's
declare globals with "my" and forget about "our" declarations.
Use of "our" declarations was useless to begin with, served
no good purpose. Today, nobody makes use of "our" and almost
everyone says, "Never use an our declaration!" End effect
is this "our" declaration is even more useless, if such a
notion could be; perl core contains a worthless function.
Peer group pressure, popularity and an ample amount of
mindless "monkey see, monkey do" thinking leads to these
hypocritical notions we read, Clenna.
People scream at you, "Don't reinvent the wheel!" Larry Wall
declares, "We are reinventing the wheel." However, none object
to this obvious hypocrisy. This "don't reinvent" only applies
when a person sees a chance to seize an opportunity to masturbate
his ego through "yelling" at someone for "reinventing" which
is nothing more than control freak idiocy. None know why you
are not to reinvent the wheel, but all scream to not do this.
"Don't use globals! Don't use an our declaration!" None know
why, no thinking behind this, rather monkey see, monkey do.
The false Gods of Perl scream this, so all the mindless minions
join in on this screaming. They have not a clue why, however.
Perl is seriously falling to the wayside. Professionals do not
like monkey see, monkey do thinking. Professionals expect good
performance, efficiency and constant improvement. Professionals
expect a programming language to keep up, even stay ahead of
advances in technology and especially consumer demands.
Perl is stagnant. Perl has not advanced in years. Perl porters
have abandoned Perl 5 and Perl porters are no closer to releasing
Perl 6 than seven years back. In effect, Perl porters have
abandoned Perl. Today, just a bunch of monkeys chattering and
making a lot of noise but going nowhere, really fast.
Yes, Clenna, our Perl Community has become an icon of hypocrisy
and about all that is left of our Perl Community is a bunch of
control freaks who spend most of their time trolling this group,
which is leading to the demise of this group. This discussion
group is all but dead, just like Perl.
--
Purl Gurl
--
"Then again what can you expect from a fat-assed, champagne swilling,
half-breed just off the Rez?"
- Joe Kline
------------------------------
Date: Sat, 23 Jun 2007 04:56:30 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: FAQ 1.6 What is perl6?
Message-Id: <x7r6o3e0ap.fsf@mail.sysarch.com>
>>>>> "PG" == Purl Gurl <purlgurl@purlgurl.net> writes:
PG> surpassed what Perl 6 can provide. Perl 6 is a dinosaur.
no, you are the moronzilla. you know nothing of software
engineering. you seem to respect larry so are you insulting him too? he
works on perl6 most of his time. but you wouldn't know or really care.
PG> Perl core contains a declaration. This is the "our" declaration
PG> for global variables. This declaration is to fix the broken
PG> strict module. Crazy, yes? Writing perl core to repair a
PG> broken module is inane. Years back, "our" was well accepted
PG> and suggested. Over time, Perl code writers became more lazy
PG> and started using "my" declarations for globals. This is, of
PG> course, incorrect syntax, bad syntax. Nonetheless, discussion
typical crapola from moronzilla, confusing syntax (all perl syntax is
correct for perl syntax) from semantics. my doesn't declare globals
either. my declares lexicals. look that one up.
PG> "Don't use globals! Don't use an our declaration!" None know
PG> why, no thinking behind this, rather monkey see, monkey do.
PG> The false Gods of Perl scream this, so all the mindless minions
PG> join in on this screaming. They have not a clue why, however.
globals are bad and not good in any language. but you wouldn't
understand that anyhow. i write this for others to realize how little
you know.
PG> Yes, Clenna, our Perl Community has become an icon of hypocrisy
PG> and about all that is left of our Perl Community is a bunch of
PG> control freaks who spend most of their time trolling this group,
PG> which is leading to the demise of this group. This discussion
PG> group is all but dead, just like Perl.
so leave the perl community already. no one wants you here but yourself
and you just bitch and moan. whining and stupidity are not wanted
here. learn python instead.
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: Fri, 22 Jun 2007 21:24:37 -0700
From: Purl Gurl <purlgurl@purlgurl.net>
Subject: Re: FAQ 1.7 How stable is Perl?
Message-Id: <9pWdnfN4eekePeHbnZ2dnUVZ_gKdnZ2d@giganews.com>
brian d foy wrote:
> Purl Gurl wrote:
>> PerlFAQ Server wrote:
>>>1.7: How stable is Perl?
>>> Production releases, which incorporate bug fixes and new functionality,
>>> are widely tested before release. Since the 5.000 release, we have
>>> averaged only about one production release per year.
>>> Larry and the Perl development team occasionally make changes to the
>>> internal core of the language, but all possible efforts are made toward
>>> backward compatibility. While not quite all perl4 scripts run flawlessly
>>> under perl5, an update to perl should nearly never invalidate a program
>>> written for an earlier version of perl (barring accidental bug fixes and
>>> the rare new keyword).
>> This makes good sense knowing Perl 6 will break every code
>> and break every module written prior to Perl 6 version.
>> This FAQ needs an inclusion,
>> "Perl 6 will render every prior Perl version program absolutely unstable."
> The FAQ is fine. You will still be able to run Perl 5 programs with
> your Perl 5 interpreter. No one is going to take away Perl 5.
This FAQ is not fine. Full disclosure to readers is not afforded.
Perl 6 has not been released, probably will never be released and,
if released, will prove highly unpopular. No problem, readers do need
to know Perl 6 will break every current Perl program, module and such,
in use today; Perl 6 is dead before release.
> We haven't seen the final form of Perl 6 yet, but the prototypes have a
> Perl 5 mode which can run un-modified Perl 5 code just fine.
Excellent bloatware concept! Perl 6 core will have Perl 5 core embedded.
This should render Perl 6 the slowest interpreter to date and of history.
Bloatware Vaporware, Perl 6 has got to be good shit!
--
Purl Gurl
--
"Then again what can you expect from a fat-assed, champagne swilling,
half-breed just off the Rez?"
- Joe Kline
------------------------------
Date: Sat, 23 Jun 2007 06:27:57 GMT
From: QoS@domain.invalid
Subject: Re: FAQ 1.7 How stable is Perl?
Message-Id: <N33fi.1311$yN.1155@trnddc07>
Purl Gurl <purlgurl@purlgurl.net> wrote in message-id: <9pWdnfN4eekePeHbnZ2dnUVZ_gKdnZ2d@giganews.com>
[snip stuff i dont get]
>Bloatware Vaporware, Perl 6 has got to be good shit!
Geeze girl thats nice talk.
Perl 6 will be fast and stuff.. ya know like way faster.
Personally im looking foward to porting some of my stuff to it.
By the way.. how's the programming language that you make coming along?
------------------------------
Date: Sat, 23 Jun 2007 04:42:13 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sat Jun 23 2007
Message-Id: <JK2nqD.19xJ@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Apache2-ASP-0.18
http://search.cpan.org/~johnd/Apache2-ASP-0.18/
Perl extension for ASP on mod_perl2.
----
Apache2-ASP-1.01
http://search.cpan.org/~johnd/Apache2-ASP-1.01/
Perl extension for ASP on mod_perl2.
----
App-Relate-0.01
http://search.cpan.org/~doom/App-Relate-0.01/
"relate" script backend
----
AutoCons-0.01_04
http://search.cpan.org/~riddle/AutoCons-0.01_04/
Write a Construct file.
----
Bigtop-0.29
http://search.cpan.org/~philcrow/Bigtop-0.29/
A web application data language processor
----
Bot-BB2-0.01
http://search.cpan.org/~avar/Bot-BB2-0.01/
----
Bot-BB2-0.02
http://search.cpan.org/~avar/Bot-BB2-0.02/
----
Bot-BB2-0.03
http://search.cpan.org/~avar/Bot-BB2-0.03/
----
Bundle-Compress-0.01
http://search.cpan.org/~ski/Bundle-Compress-0.01/
installs Compress modules and dependencies
----
Bundle-Compress-0.02
http://search.cpan.org/~ski/Bundle-Compress-0.02/
installs Compress modules and dependencies
----
Business-OnlinePayment-TransFirsteLink-0.04
http://search.cpan.org/~jef/Business-OnlinePayment-TransFirsteLink-0.04/
Transfirst eLink backend for Business::OnlinePayment
----
CGI-Ex-2.16
http://search.cpan.org/~rhandom/CGI-Ex-2.16/
CGI utility suite - makes powerful application writing fun and easy
----
Config-Apt-Sources-0.04
http://search.cpan.org/~iank/Config-Apt-Sources-0.04/
Parse and manipulate apt sources
----
Config-Loader-1.09_02
http://search.cpan.org/~drtech/Config-Loader-1.09_02/
load a configuration directory tree containing YAML, JSON, XML, Perl, INI or Config::General files
----
Config-Loader-1.09_03
http://search.cpan.org/~drtech/Config-Loader-1.09_03/
load a configuration directory tree containing YAML, JSON, XML, Perl, INI or Config::General files
----
DBIx-Perlish-0.26
http://search.cpan.org/~gruber/DBIx-Perlish-0.26/
a perlish interface to SQL databases
----
Digest-MD5-Reverse-1.1
http://search.cpan.org/~blwood/Digest-MD5-Reverse-1.1/
MD5 Reverse Lookup
----
Eludia-07.06.22
http://search.cpan.org/~dmow/Eludia-07.06.22/
----
Eludia-Install-07.06.22
http://search.cpan.org/~dmow/Eludia-Install-07.06.22/
create/backup/mirror Eludia.pm based WEB applications.
----
Email-Address-1.888
http://search.cpan.org/~rjbs/Email-Address-1.888/
RFC 2822 Address Parsing and Creation
----
File-Locate-Harder-0.05
http://search.cpan.org/~doom/File-Locate-Harder-0.05/
when you're determined to use a locate db
----
Finance-Bank-ES-INGDirect-0.03
http://search.cpan.org/~brunodiaz/Finance-Bank-ES-INGDirect-0.03/
Check your INGDirect bank accounts from Perl
----
Geo-Query-0.02
http://search.cpan.org/~retoh/Geo-Query-0.02/
Perl extension for querying geo related data from different sources.
----
Geo-Query-LatLong-0.8007
http://search.cpan.org/~retoh/Geo-Query-LatLong-0.8007/
Uniform interface to query latitude and longitude from a city.
----
HTML-ContentExtractor-0.03
http://search.cpan.org/~jzhang/HTML-ContentExtractor-0.03/
extract the main content from a web page by analysising the DOM tree!
----
KML-PolyMap-1.33
http://search.cpan.org/~ihaque/KML-PolyMap-1.33/
----
Lemonldap-Portal-Session-0.02
http://search.cpan.org/~egerman/Lemonldap-Portal-Session-0.02/
Perl extension for Lemonldap websso
----
List-Filter-0.02
http://search.cpan.org/~doom/List-Filter-0.02/
named, persistent, shared lists of patterns
----
MARC-XML-0.87
http://search.cpan.org/~kados/MARC-XML-0.87/
----
MRTG-Config
http://search.cpan.org/~sscaffidi/MRTG-Config/
Perl module for parsing MRTG configuration files
----
Mail-Abuse-1.026
http://search.cpan.org/~luismunoz/Mail-Abuse-1.026/
Helps parse and respond to miscellaneous abuse complaints
----
Maypole-2.12
http://search.cpan.org/~teejay/Maypole-2.12/
MVC web application framework
----
Net-DNS-0.60
http://search.cpan.org/~olaf/Net-DNS-0.60/
Perl interface to the DNS resolver
----
Net-Lite-FTP-0.52
http://search.cpan.org/~eyck/Net-Lite-FTP-0.52/
Perl FTP client with support for TLS
----
PAB3-3.1.2
http://search.cpan.org/~chrmue/PAB3-3.1.2/
Perl Application Builder / Version 3
----
PAB3-DB-Driver-Mysql-1.0.4
http://search.cpan.org/~chrmue/PAB3-DB-Driver-Mysql-1.0.4/
Perl5 wrapper to the mysql5+ client libary and driver for the PAB3::DB class
----
PAB3-DB-Driver-Postgres-1.0.4
http://search.cpan.org/~chrmue/PAB3-DB-Driver-Postgres-1.0.4/
Perl5 wrapper to the pgsql libary and driver for the PAB3::DB class
----
PAB3-DB-Driver-Sqlite3-1.0.4
http://search.cpan.org/~chrmue/PAB3-DB-Driver-Sqlite3-1.0.4/
Perl5 wrapper to libsqlite3 and driver for the PAB3::DB class
----
POE-Filter-ParseWords-0.01
http://search.cpan.org/~bingos/POE-Filter-ParseWords-0.01/
A POE-based parser to parse text into an array of tokens.
----
Parse-Nessus-Plugin-0.5
http://search.cpan.org/~ralamosm/Parse-Nessus-Plugin-0.5/
OO methods to parse Nessus plugins
----
Regexp-Wildcards-0.05
http://search.cpan.org/~vpit/Regexp-Wildcards-0.05/
Converts wildcard expressions to Perl regular expressions.
----
SOAP-Amazon-S3-0.03
http://search.cpan.org/~karjala/SOAP-Amazon-S3-0.03/
A module for interfacing with Amazon S3 through SOAP
----
Test-Perl-Critic-Progressive-0.02
http://search.cpan.org/~thaljef/Test-Perl-Critic-Progressive-0.02/
Gradually enforce coding standards
----
Text-Compare-1.02
http://search.cpan.org/~stro/Text-Compare-1.02/
Language sensitive text comparison
----
WWW-Facebook-API-v0.3.4
http://search.cpan.org/~unobe/WWW-Facebook-API-v0.3.4/
Facebook API implementation
----
XML-Generator-1.0
http://search.cpan.org/~bholzman/XML-Generator-1.0/
Perl extension for generating XML
----
YAML-LibYAML-0.22
http://search.cpan.org/~ingy/YAML-LibYAML-0.22/
----
YAML-LibYAML-0.23
http://search.cpan.org/~ingy/YAML-LibYAML-0.23/
----
YAML-Syck-0.91
http://search.cpan.org/~audreyt/YAML-Syck-0.91/
Fast, lightweight YAML loader and dumper
----
gtk_new
http://search.cpan.org/~alexe/gtk_new/
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
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!
------------------------------
Date: Sat, 23 Jun 2007 00:11:55 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs
Message-Id: <m3d4zn2o9g.fsf@latakia.dyndns.org>
Bjorn Borud <borud-news@borud.no> writes:
>
> | The idea is to start Emacs once and use it for everything.
>
> ...which is fine as long as you are only fiddling around on one
> machine or you have emacs windows running on all your machines.
Tramp can be used to access files on other hosts. It even supports
multi-hop stuff like 'ssh to $HOST and su to root.'
One thing GNU emacs needs to support is the ability to open a new X or
terminal window via a command. I think Xemacs can already do this.
> also, I make extensive use of the readline and history features when
> fiddling about in the shell. shells have a lot of context if you use
> them effectively. context that isn't easy to transport between the
> shell and emacs -- and it isn't really easy to explain either.
M-x shell, or M-x terminal
--
Robert Uhl <http://public.xdi.org/=ruhl>
That's just 'mostly dead.' What we are concerned with here is 'Pining
for the Fjords' dead. --Mark Urbin
------------------------------
Date: Sat, 23 Jun 2007 05:08:31 GMT
From: Tim Roberts <timr@probo.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <4jap73pfdme1pth2tji1vmd8j9qqss7pcf@4ax.com>
Bjorn Borud <borud-news@borud.no> wrote:
>
>bah, UNIX is not user hostile; it is just selective about its
>friends.
Right. My favorite Unix quote is from the same source (Dennis Ritchie):
Unix is the answer. You just have to phrase the
question very carefully.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
------------------------------
Date: Sat, 23 Jun 2007 05:11:18 GMT
From: Tim Roberts <timr@probo.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <ioap7396t8t792foi7he42fq15n6gmppn4@4ax.com>
Cor Gest <cor@clsnet.nl> wrote:
>Some entity, AKA nebulous99@gmail.com,
>wrote this mindboggling stuff:
>
>> On Jun 22, 6:32 pm, Cor Gest <c...@clsnet.nl> wrote:
>>
>> So now we're expected to go on a filesystem fishing expedition instead
>> of just hit F1? One small step (backwards) for a man; one giant leap
>> (backwards) for mankind. :P
>
>that's M-` Escape-Backtick in a CLI, for you, thank you very much ...
>Function-Keys do not work in in a vt100 terminal.
>
>You really are that shallow, aren't you ? and lazy too, huh ?
Boys, do you really not understand that this is a religious issue? You
can't use arguments and logic to convince someone to convert their
religion, and you can't use arguments and logic to convince someone to
change editors.
Editors are like underwear. We each have our own favorite brand, and
nothing you say will convince me to change mine. Editor, that is. I do
occasionally change my underwear.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
------------------------------
Date: Fri, 22 Jun 2007 23:32:43 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3lkeb2q2s.fsf@latakia.dyndns.org>
Falcolas <garrickp@gmail.com> writes:
>
>> It's Mac OS and Windows which are inconsistent. Emacs has been
>> around since they were mere glimmers in the eye of Jobs & Gates...
>
> Inconsistent? I would have to disagree. They changed paradigms -
> terminal text based interfaces to GUIs. You wouldn't expect a piece of
> software built for a terminal to be backwards compatibility to punch
> card interfaces, would you? Why would a GUI based program limit itself
> to functionality as defined by a terminal application?
You're making the assumption that Mac OS in 1984 offered some textual
capability (textual, since we're discussing text editing) which emacs
did not. It didn't.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A: Top posting
Q: What's the most annoying thing about Usenet?
------------------------------
Date: Sat, 23 Jun 2007 00:04:40 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3hcoz2olj.fsf@latakia.dyndns.org>
Twisted <twisted0n3@gmail.com> writes:
>
> How clunky versus usable an interface to a tool is is for those who
> invest some, but not extraordinary amounts of, time into its use to
> decide. If it requires years of mastery, it is clunky -- period. This
> may be unavoidable if it's something involved in nuclear power plants,
> delicate neurosurgery, or whatever. If it's a text editor, on the
> other hand, it's clearly going to have superior competition in the
> area of usability.
Of course, emacs doesn't take years of mastery. It takes 30, 40
minutes. And a functioning intellect, of course.
Incidentally, a violin requires years of mastery, and is hardly cranky.
Granted, there are few people with the talent to play a violin well.
Maybe an automobile is a better example...
> Besides, ANY interface that involves fumbling around in the dark
> trying to find a light switch is clunky.
That sounds like vi, not emacs.
> Applications that not only eschew normal methods of navigation of the
> interface, but force you to fumble your way between the help and the
> task you're trying to do, are definitely clunky.
a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
its own thing since before there _were_ Mac OS or Windows
b) I believe you've never used the emacs tutorial, which is quite
definitely designed for you _not_ to have to fumble around between
windows
> The interface never improved over that time -- the biggest problem
> consistently being that whenever focus was successfully transferred to
> the document window, the help window was invariably open to the
> instructions for switching windows, so you could never be doing
> something with the document and have the help for that something
> available at a glance.
That doesn't even make sense. Either your memory is faulty, you've
never actually used emacs (something I'm beginning to suspect more and
more) or you're just making things up. If I'm browsing the manual
online, I can switch from said manual to my document buffer without
making the manual scroll to the documentation for switch-to-buffer. In
fact, I am not aware of any package which auto-changes the *info* or
*Help* buffers to reflect the last keyboard command.
> Even though it would be at the price of no full- text search
> capability -- not that I could ever get that to work in emacs
> anyway. There was no apparent way to do a simple substring search and
> click "next match" or "previous match" to navigate among the
> hits...more arcane keypresses would be required, and as soon as it
> showed you the first match inside the help, the keypress documentation
> of course vanished.
Dude, you hit C-s; you're prompted for a search string; you hit C-s to
search for the next match. From line 899 of the tutorial:
>> Now type C-s to start a search. SLOWLY, one letter at a time,
type the word 'cursor', pausing after you type each
character to notice what happens to the cursor.
Now you have searched for "cursor", once.
>> Type C-s again, to search for the next occurrence of "cursor".
If you had actually, you know, actually _read_ it this would not be a
surprise. I hate to be rude, but I just don't see how you could ever
have actually done what you claim to have done.
> Infrequently used commands you can stand to hunt for in menus. When
> you find you use one frequently, you can try to learn the keyboard
> shortcut -- and you can find it without even consulting the help,
> simply by finding the command's menu item.
This is no different from emacs. There's a menu bar; it displays
commands and shortcuts next to them; one can learn to use them instead,
at one's own pace.
> Every time you want to use the command but can't remember the shortcut
> you just find it in the menu and activate it from there, and see the
> shortcut while you're at it, helping to eventually memorize it. And
> the commonest sorts of File and Edit menu items have near-universal
> shortcuts, the big variation tending to be whether Redo is
> shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.
You've actually hit on another advantage of emacs: consider emacs itself
as an operating system hosting multiple applications, in which the vast
majority of commands are the same. I can use the same text-editing
commands for reading & writing emails, reading & writing Usenet posts,
reading & writing code, browsing the web, organising my schedule and so
forth.
The vast majority of what we do on a computer is reading & writing
text--wouldn't it be cool to have a full-fledged text editing
environment always available for that sort of thing? Wouldn't it be
cool not to have one program implement search in one way, and another a
second way, and yet another a third? Wouldn't it be cool to have access
to a proper text editor when editing text on a web page?
> But you can start using it right away with low productivity, and
> increase your productivity with proficiency and learning (optional)
> shortcuts, chiefly those to the commands you happen to use a lot.
That's how I learnt emacs. I was 13, and had only ever used Mac
software up until that point. I had a fairly limited command set
(basically, C-x C-f, C-x C-s & C-x C-c).
> One person elsewhere in this thread even went so far as to suggest
> that to avoid having a similar hurdle with every application you just
> use emacs for everything. If you like being claustrophobically trapped
> in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.
Do you realise that emacs has a GUI these days? I'm writing this in a
70-line window, with gtk+ widgets. Which means full-resolution,
full-colour.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A wealthy man is one who earns $100 a year more than his wife's sister's
husband. --H.L. Mencken
------------------------------
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 562
**************************************
