[29320] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 564 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 23 11:10:12 2007

Date: Sat, 23 Jun 2007 08:09:12 -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: 564

Today's topics:
    Re: Adding to a perl script automatically <bik.mido@tiscalinet.it>
    Re: Adding to a perl script automatically <bik.mido@tiscalinet.it>
    Re: File::Find losing one file? (Marc Espie)
    Re: Help: About 'if' structure <openlinuxsource@gmail.com>
    Re: Help: About 'if' structure <openlinuxsource@gmail.com>
    Re: Help: About 'if' structure <rvtol+news@isolution.nl>
    Re: Help: About 'if' structure <mritty@gmail.com>
    Re: How can I overload the build in array type? (Marc Espie)
    Re: How can I overload the build in array type? <mjcarman@mchsi.com>
    Re: Perl Best Practices - Code Formatting. <bik.mido@tiscalinet.it>
    Re: Perl Best Practices - Code Formatting. <bik.mido@tiscalinet.it>
    Re: Perl Best Practices - Code Formatting. <bik.mido@tiscalinet.it>
    Re: Perl Best Practices - Code Formatting. <bik.mido@tiscalinet.it>
    Re: Perl Best Practices - Code Formatting. <bik.mido@tiscalinet.it>
    Re: Perl Best Practices - Code Formatting. <bik.mido@tiscalinet.it>
    Re: Rose Perl Reverse engg problems : Bad File Name <tadmc@seesig.invalid>
    Re: The Modernization of Emacs <borud-news@borud.no>
    Re: The Modernization of Emacs <martin@see.sig.for.address>
    Re: The Modernization of Emacs: terminology buffer and  <borud-news@borud.no>
    Re: The Modernization of Emacs: terminology buffer and  <martin@see.sig.for.address>
    Re: The Modernization of Emacs: terminology buffer and  <borud-news@borud.no>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sat, 23 Jun 2007 16:01:39 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Adding to a perl script automatically
Message-Id: <ml9q731n5ig2qbkddcjroh35tlppbi2eir@4ax.com>

On Thu, 21 Jun 2007 03:20:59 -0700, "MMWJones@googlemail.com"
<MMWJones@googlemail.com> wrote:

>Is there a way of writing a script that will ask the user for a value
>and be able to access the script and put the value in the correct
>place automatically?

Certainly: it's enough to have a script with the capability of
modifying itself. Only, you should do that *very* carefully. Otherwise
I foresee security nightmares waiting in the shadow to haunt you. But
seriously, why don't you hold the values elsewhere, e.g. in a plain
text file if nothing else, and duly update that if needed?

BTW: absolutely *not* required, but from the UI POV this seems a
perfect task for some AJAX thingie...

>If so how would i go about doing this? In a .pl script or .sh script?

 .pl and .sh are nothing but extensions. A perl script certainly *can*
modify the file it's written in. If you want to delegate that business
to an external shell script, then you certainly *can* as well.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 16:13:31 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Adding to a perl script automatically
Message-Id: <71aq73lomap3ac1rmef970iu2183vi9anq@4ax.com>

On 21 Jun 2007 15:15:33 GMT, xhoster@gmail.com wrote:

>> I have a perl cgi script which defines popup_menu and values in the
>> drop down list. More values may be added to this over time. People
>> that don't know much about the script might not want to enter the
>> script and type in values 'manually'.
>
>I think that this is a spectacularly bad idea.  If you want people who
>don't know much about Perl to configure aspects of your Perl program, you
>should make a non-Perl configuration file (or database) for them to use for
>that purpose.

Well, a priori not necessarily: I have a *tiny* script of mine which I
had originally posted at http://perlmonks.org/?node_id=417646 (now
that I look at it... damn, that early habit of mine of using -l too
much!) and with which I tried hard to make it idiot proof for
"maintainers" to add/modify entries at the bottom. It seems to have
worked fine at a location for quite about some time.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 13:11:01 +0000 (UTC)
From: espie@lain.home (Marc Espie)
Subject: Re: File::Find losing one file?
Message-Id: <f5j655$31c3$1@biggoron.nerim.net>

In article <1182450182.548617.152000@c77g2000hse.googlegroups.com>,
seven.reeds <seven.reeds@gmail.com> wrote:
>sub findArticle()
>{
>    if (-f && /\d+.news/)
>    {
>        push(@articles, $_);
>    }
>}

You know that your regexp is wrong, right ? It will catch up more
stuff than you want because:
- . stands for `any character', not just .
- you don't anchor it at all.

This expr will also catch stuff like
this42anewsletter
which might or might not be what you want...


------------------------------

Date: Sat, 23 Jun 2007 21:36:01 +0800
From: "Amy Lee" <openlinuxsource@gmail.com>
Subject: Re: Help: About 'if' structure
Message-Id: <pan.2007.06.23.13.36.01.208320@gmail.com>

Thank you very much~

I have solved my problem.


------------------------------

Date: Sat, 23 Jun 2007 21:37:09 +0800
From: "Amy Lee" <openlinuxsource@gmail.com>
Subject: Re: Help: About 'if' structure
Message-Id: <pan.2007.06.23.13.37.09.411990@gmail.com>

And Furthermore, if I wanna use "OR", how to accomplish it in perl?

Amy


------------------------------

Date: Sat, 23 Jun 2007 16:22:29 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Help: About 'if' structure
Message-Id: <f5jhkc.10o.1@news.isolution.nl>

Amy Lee schreef:
> And Furthermore, if I wanna use "OR", how to accomplish it in perl?

Go and read perlop. Now. 

-- 
Affijn, Ruud

"Gewoon is een tijger."


------------------------------

Date: Sat, 23 Jun 2007 14:33:30 -0000
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: Help: About 'if' structure
Message-Id: <1182609210.203086.144840@n60g2000hse.googlegroups.com>

On Jun 23, 9:37 am, "Amy Lee" <openlinuxsou...@gmail.com> wrote:
> And Furthermore, if I wanna use "OR", how to accomplish it in perl?

 .... did you think Tad and I pointed you at the `perldoc perlop`
documentation for the heck of it?

You've run out of free fish.  Time to learn how to fish.

Paul Lalli



------------------------------

Date: Sat, 23 Jun 2007 13:13:34 +0000 (UTC)
From: espie@lain.home (Marc Espie)
Subject: Re: How can I overload the build in array type?
Message-Id: <f5j69u$31c3$2@biggoron.nerim.net>

In article <467b863b$0$8753$ed2619ec@ptn-nntp-reader02.plus.net>,
bugbear  <bugbear@trim_papermule.co.uk_trim> wrote:
>I don't think I've *ever* seen a use of operator
>overleading in C++ (which I was exposed to for a
>good while) that made the code clearer or better.

You've probably not been exposed to sparse matrices or expression
templates, two areas where overloading [] may lead to clearer code...


------------------------------

Date: Sat, 23 Jun 2007 14:13:49 GMT
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: How can I overload the build in array type?
Message-Id: <xU9fi.177596$_c5.73984@attbi_s22>

On 6/22/2007 3:09 AM, Ilias Lazaridis wrote:
> 
> is there a similar module to overload the classes of build in types
> (like array), something like:
> 
>     use typeoverload
>         '@' => 'My::Array',
>         '%' => 'My::Hash';
>         # etc
>     ...

You can't overload sigils but you can use tie() to create your own
implementation of the built in data types.

Run "perldoc perltie" for more info.

-mjc



------------------------------

Date: Sat, 23 Jun 2007 15:09:57 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <gl6q739bk3r6hac8ur6mpikhl1hgf17k3b@4ax.com>

On Wed, 20 Jun 2007 22:01:28 -0700, "Asim Suter" <asuter@cisco.com>
wrote:

>I was reading Perl Best Practices by Respected Damian Conway
>and he rather strongly advices using K&R style of code format as opposed to 
>BSD style or GNU style.

/me too. It also seems to be the one recommended in

  perldoc perlstyle

>OTOH in Damian Conway's classic "Object Oriented Perl", he chooses to use 
>BSD style in the book.
>
>Change of heart Mr. Conway ?

Well, you know that RWE's quote about consistency? Damian may have
just been smart enough to change his mind.

>I know people feel strongly about code layout/format and "bracing 
>technology" - I would like to know
>what folks are using in their scripts and modules.

I adhere more or less strictly with perlstyle guidelines except for
(i) cuddled else's - when I use else clauses at all, that is, rarely,
(ii) some less generous horizontal whitespace, e.g. around simple
assignments.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 15:11:45 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <ku6q73h7oue8s902515jmgi5dl8nun9k6g@4ax.com>

On Thu, 21 Jun 2007 15:11:11 +0200, "Petr Vileta"
<stoupa@practisoft.cz> wrote:

>> PS: It does not matter - but I find BSD style more appealing.
>
>I prefer BSD style too because by me this is better readable for human.

I must not be human then because I find it plain confusing - sometimes
looking like a single line of code followed by a bare block. Hey, I
never claimed I were!


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 15:17:03 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <r47q73piaff27tda45gnov1er1iokcku26@4ax.com>

On Fri, 22 Jun 2007 12:10:20 -0700, "Wayne M. Poe"
<louisREMOVE@REMOVEh4h.com> wrote:

>Personally I find a greator problem in working with code that uses one 
>or more differnce intent spacings (I tend to use 3, but have worked with 
>people who prefer 4, 5 or even 8, and soemtiems they are raw spaces and 
>soemtiems raw tabs.

Yep, and then there' a *fantastic* PM freak exposing his "arguement in
favor of tabs" at <http://perlmonks.org/?node_id=576936>.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 15:23:29 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <ob7q73l2blbg92ms9iint3n7m0iva6rvt2@4ax.com>

On Thu, 21 Jun 2007 12:11:58 -0500, brian d  foy
<brian.d.foy@gmail.com> wrote:

>Don't forget to read the beginning of the preface, where Damian says:
>
>"This book doesn't try to offer *the* one true universal and unequivocal
>set of best practices."
>
>and
>
>"What this book offers instead is *a* set of best practices".

Yep, the whole subject of BP has always been and continues to be
highly controversial. I'm just noticing that today on top of the
"Daily Best" nodelet @ PM there's an article entitled "Returning
undef: The point I would like Damian to reconsider", which you can
read at <http://perlmonks.org/?node_id=622766>. I've not had the time
to dig through the thread, but at first sight it seems to comprise an
active discussion with many links perhaps to similar ones.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 15:29:53 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <cr7q73lo6456o6ug5fvbalrbfeqb6mskb8@4ax.com>

On 22 Jun 2007 13:00:56 GMT, Abigail <abigail@abigail.be> wrote:

>What always amazes me is dat discussions about coding standards always
>rapidly focusses on layout nitpicks and other trivial things.
>
>I don't care whether code I inherit use K&R bracing style, or BSD bracing
>style, or whether is uses 3 or 4 space indent, or whether it uses single
>or double quotes to delimit constant strings.

But you're *Abigail*: to quote from BrowserUk's article about code
readability at <http://perlmonks.org/?node_id=592715>,

: When I first encountered the long lamented Abigail-II's code on PM, it
: looked strange to my eyes. And despite that there are quite a few of
: his guidelines that I do not follow, and disagree with his reasoning,
: I always find his code eminently readable. Even when that code is
: performing the often complex manipulations for which he is famous, the
: consistency of his code layout makes spending time exploring his code
: a joy.
: 
: And of all the stylistic elements of his code that make that so, his
: liberal--too liberal in a few places for my tastes--and consistent use
: of horizontal whitespace ranks very high on the list of things that
: make it so readable. In large part, this is the inspiration behind my
: liberal use of horizontal whitespace. I attempted to code with
: consistency of layout long before I encountered Perl, but I've
: modified my coding style since using Perl to incorporate more
: horizontal whitespace and this has reflected back into my coding in
: other languages.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 15:40:44 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <j38q73p1ntbufvlu1172al6dfkpt7evgh9@4ax.com>

On Fri, 22 Jun 2007 12:17:50 -0700, "Vronans"
<vronans@nowheresville.spamwall> wrote:

>No offense, but it's difficult to ignore "trivial formatting" when you 
>cannot even use proper quoting delimiters. I think you have bene asked 
>countless times to fix that. There are some basic stanards one -should- 
>adhere too, or at least try to stay close to. Standard quoting falls 
>right into that catagory so why not stop breaking news reader quote 
>processing abroad? 

While I sort of agree with you, Abigail's skills and precious
contributions overweight too much the slight inconvenience for me to
really care. OTOH I'm much more disturbed by the habit of another
regular here, with whom I've already complained to no avail, about
writing *everything* lowercase. Funnily enough $Larry wrote about the
subject:

: --
: It's a bit like the folks who start posting on the Net and affect not to
: capitalize anything. Eventually, most of them come back to the point where
: they realize occasional capitalization is useful for efficient communication.
: - L. Wall, from "Larry Wall, the Guru of Perl".


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Sat, 23 Jun 2007 08:32:32 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Rose Perl Reverse engg problems : Bad File Name
Message-Id: <slrnf7q87g.gpr.tadmc@tadmc30.sbcglobal.net>

Michele Dondi <bik.mido@tiscalinet.it> wrote:
> On Wed, 20 Jun 2007 08:22:18 -0700, ebandook@gmail.com wrote:
>
>>I am trying to reverse engineer a *test* perl module using rational
                                    ^^^^^^
                                    ^^^^^^
>>rose.


> It is very clear to see what the code does. Although it is not very
> clear why it does it,


For testing, of course.  :-)


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"


------------------------------

Date: 23 Jun 2007 16:18:28 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs
Message-Id: <m3abuqdaa3.fsf@borud.not>

[Twisted <twisted0n3@gmail.com>]
| 
| > I have observed similar opinions in other non-computer-freaks.  people
| > who see the computer only as a tool and are only interested in getting
| > the job done.  they have a surprising preference for Linux.
| 
| But not emacs, I'll bet. I think emacs appeals to people who like
| dealing with the mechanics of emacs or fiddling with and extending the
| darn thing. But most people just want to get the job done, and the
| editor or other tools they use have to get out of the way and simply
| let them work.

no, Emacs is not among the applications they use.  nor are any IDEs or
compilers.  I don't think Emacs is that relevant to these users since
what they do is mostly word-processing, spreadsheets, mail and web
browsing.  Emacs is not really targeted at Word processing as
such. (although that doesn't stop some people from thinking that it
would be a good idea to turn Emacs into a wordprocessing application
with support for graphics, mixed fonts etc.)

I use Emacs for creating documents, but this is very different since I
use LaTeX and I'm a programmer, so it is very conventient for me to
use a system that allows me to treat documents like code (with respect
to revision control systems etc).  outside academia or the technical
community, not that many use LaTeX, but I have seen it in the past.

-Bjørn


------------------------------

Date: Sat, 23 Jun 2007 16:00:20 +0100
From: Martin Gregorie <martin@see.sig.for.address>
Subject: Re: The Modernization of Emacs
Message-Id: <a5pvk4-sfq.ln1@zoogz.gregorie.org>

Joel J. Adamson wrote:
> Xerox PARC (not Apple nor MIcrosoft) excelled in helping computers fit
> in to how people already lived, not the other way around.
>
I've never got my hands on a genuine Xerox. About the nearest to that I 
managed was an ICL PERQ back in 1980, with a portrait-mode black and 
white screen and a three button mouse. That was the first GUI I saw 
(next was an Apple Lisa in 1984). The PERQ was dead easy to use after 
about 5 minutes instruction.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |


------------------------------

Date: 23 Jun 2007 16:45:53 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m34pkyd90e.fsf@borud.not>

[Twisted <twisted0n3@gmail.com>]
| You end up having to memorize the help, because *you can't
| have arbitrary parts of the help and your document open side by side
| and be working on the document*. All because you can't simply tab or
| click to the document.

yes you can.  you even have a lot of choice as to how you want to do
it and it even works on the simplest of text terminals (which is
useful when you are on the road and only have a computer with a
browser availabe and you've had the foresight to set up the Mindterm
SSH applet on a machine so you can log in and edit code from anywhere
in the world).

I use multiple frames on-screen most of the time.  either to edit and
view multiple files at once or to edit different locations of the same
file.  if you're a programmer it is often useful to be able to do
this.  you can look at more than one file at the same time, have
documentation up on screen etc.

| At minimum, you have to *memorize* some arcane key controls for
| switching panes ... er, "windows", that are totally unintuitive and
| unlike what is normally used.

following the built-in tutorial in Emacs I understood how to
manipulate buffers and split windows in various ways.  there are
basically three commands you need to know.  one of them is used to
switch between active buffers in a given window, so it is not specific
to splitting.

it took me minutes to learn and within days I didn't even think about
what I was doing -- I was just using the features.

I think you fail to understand the approach.  if you know an editor
like VI or Emacs properly you have a much bigger bag of tricks, that
are applicable to a wide range of scenarios, than what is encouraged
by GUI intensive editors.  and you don't think of them as "tricks".
it is just the way you edit text.

| Oops. The interface design is a nightmare. The most basic requirement,
| that it be easy to have the help open side by side with your document
| and switch back and forth and navigate inside the help easily, is
| broken. If you have to consult the help just to navigate the help or
| to switch focus between document and help, then you're trapped, and
| that is what happens with emacs.

why don't you learn Emacs before you say what it can and can't do?
it is so frustrating to debate editors with people who haven't even
bothered to make a minimal effort to at least spend a day or two
learning it.

let's look at Word and word processing.  how long does it take you to
learn Word properly?  to understand how to efficiently edit large
documents, automate common tasks, use the built-in features for
helping you organize documents?


-Bjørn


------------------------------

Date: Sat, 23 Jun 2007 15:36:31 +0100
From: Martin Gregorie <martin@see.sig.for.address>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <konvk4-oaq.ln1@zoogz.gregorie.org>

BartlebyScrivener wrote:
> On Jun 22, 3:47 pm, Twisted <twisted...@gmail.com> wrote:
> 
>> If it requires years of mastery, it is clunky
> 
> Well, now you keep harping on this, but it's just not true.
> 
> I use vim myself, but for purposes of this argument it doesn't matter.
> If you take the Vim tutorial and use the help (which appears in a
> split window anytime you want it), you can use Vim like any other text
> editor within a day or so, especially if you use Cream, which is set
> up to hold your Windows hands and act like any other Windows text
> editor on the surface. But if you use Vim for YEARS you get better and
> faster and more efficient precisely BECAUSE of its arcane
> capabilities. If you are going to keep your hands on the keyboard
> where they belong, if you REALLY want to go fast, then there's no
> alternative to having complex key commands, which become second nature
> over time, and take the place of repetitive, totally inefficient
> mousing around.
> 
> You might enjoy this. Especially the link to an old essay called
> "Interface Zen"
> 
> http://tinyurl.com/2da3om
>
A good reference. Thanks.

I like Interface Zen - much sense there.

However, there's a case he missed, probably through never using a CAD 
system. All the good ones can be driven either by mouse, or by 
non-chorded key sequences or any combo the user likes. The essence of 
CAD is very accurate pointing but all too many mice move slightly when 
clicked. Fortunately a decent CAD system offers the possibility of 
purely pointing with the mouse and doing everything else with the other 
hand on the keyboard. The result is both fast and extremely accurate.

An interface design point that nobody has yet mentioned here is that 
there are four different types of user that map onto a grid:

		casual	dedicated
untrained	1	2
expert		3	4

I first ran across grid this in "Design of Man-Computer Dialogs" by 
James Martin and its been very useful in systems interface design.

The problem with almost all current GUIs is that they are aimed at types 
1 and 3 users - this certainly applies to Windows, OS X and Gnome 
desktops with the emphasis on type 1. vi and microEmacs, OTOH, are aimed 
at type 3 and 4 users.

Where does emacs fit on this grid? My guess would be 3 and 4.

Its very difficult indeed to design an interface that suits both 
untrained and expert users. About the closest I've seen have been 
keyboard driven menu structures which have been designed so the user can 
build their own "command sequences" that traverse menu levels without 
showing the menus, as long as items are selected correctly from each 
level. Many CAD systems approximate to this but I've yet to see a 
graphical desktop, IDE, or editor menu structure that came close.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |


------------------------------

Date: 23 Jun 2007 17:08:19 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3vedebtek.fsf@borud.not>

[Falcolas <garrickp@gmail.com>]
| 
| I guess ultimately I'm trying to argue the point that just because a
| tool was written with a GUI or on Windows does not automatically make
| it any less a productive tool than a text based terminal tool. Even in
| windows, you can use the keyboard to do all of your work, if you learn
| how (thanks to the magic of the alt key).

as I see it, the debate isn't whether GUI tools are inferior per se,
but whether Emacs is inferior since it has its own interaction
concepts that do not map 1:1 to GUI conventions of Windows and OSX.

the point I am trying to get across is that Emacs (and vi) is its own
niche, and that if you want to improve them, there are more important
things than fiddling around with superficial details (like keybindings
-- which you can customize to your own liking anyway).

for Emacs it would be far more helpful if the Lisp-implementation was
replaced with one that is more efficient and Common Lisp-like.
(indeed several friends of mine would like to see Emacs done in Common
Lisp, and I seem to have some memory of such a project existing
somewhere).

-Bjørn


------------------------------

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 564
**************************************


home help back first fref pref prev next nref lref last post