[29311] in Perl-Users-Digest
Perl-Users Digest, Issue: 555 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 22 14:14:17 2007
Date: Fri, 22 Jun 2007 11:14: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 Fri, 22 Jun 2007 Volume: 11 Number: 555
Today's topics:
Re: The Modernization of Emacs: terminology buffer and <borud-news@borud.no>
Re: The Modernization of Emacs: terminology buffer and <borud-news@borud.no>
Re: The Modernization of Emacs: terminology buffer and <borud-news@borud.no>
Re: The Modernization of Emacs: terminology buffer and <borud-news@borud.no>
Re: The Modernization of Emacs: terminology buffer and <keramida@ceid.upatras.gr>
Re: The Modernization of Emacs: terminology buffer and <eadmund42@NOSPAMgmail.com>
Re: The Modernization of Emacs: terminology buffer and <garrickp@gmail.com>
why we need perl6 if we have parrort? <sonet.all@msa.hinet.net>
Re: why we need perl6 if we have parrort? <brian.d.foy@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 22 Jun 2007 16:38:37 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3fy4k836a.fsf@borud.not>
[Twisted <twisted0n3@gmail.com>]
|
| I think it is quite relevant. Clunky computer interfaces may not be so
| dramatically dangerous, but they certainly can hamper productivity.
| Between Windows bugs and gratuitous misfeatures (e.g. DRM) and Unix
| clunkiness, billions of dollars of potential productivity is lost
| worldwide every *month*.
bah, UNIX is not user hostile; it is just selective about its
friends.
-Bjørn
------------------------------
Date: 22 Jun 2007 16:52:28 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m37ipw82j7.fsf@borud.not>
[Robert Uhl <eadmund42@NOSPAMgmail.com>]
|
| Why should the ignorant decide? Do you leave the decision of what great
| art is to 3 year olds and their doting parents? Do you leave the
| decision of what great food is to the ignorant, unwashed,
| McDonald's-devouring masses? Why then do you leave the decision of
| what's a useful interface to those with insufficient experience?
Robert does have a point; however, one needs to take into account that
it is very difficult to judge the quality of an interface if it is one
that is very familiar to you or if the inner workings are obvious to
you. this is why programmers often make bad UI designers: we are
intimately familiar with the inner workings, and to us it is okay if
the UI is just a thin layer on top of a system we've made.
(I'd say the web is a better showcase for this. there seems to be no
end to the number of websites that have awkward interaction modes.
nor do people seem particularly shy about adding "just one more" thing
to an already crowded interface -- because they're blind to the wall
of complexity it presents to the occasional user).
editors like Emacs is not something which is designed for the casual
user, so what the casual user thinks is irrelevant. (also note that
the definition of "casual user" has changed).
-Bjørn
------------------------------
Date: 22 Jun 2007 17:30:53 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m31wg480r6.fsf@borud.not>
[Kaldrenon <kaldrenon@gmail.com>]
|
| I don't think anyone can make the argument that any (past or current)
| graphics-based editor is as efficient when being used to its fullest
| as a text-based editor. It's basic math - it takes measurably more
| time to move a hand to the mouse, move/click the mouse, and more the
| hand back to the touch-typing position than it does to execute even a
| moderately complex series of keystrokes. Maybe not large amounts of
| time -per action-, but it doesn't take too long for it to add up if
| you spend a lot of time editing.
a lot of IDE's are getting quite good and you don't have to mouse
around all that much. I think the main reason I stick to Emacs is
because I use it for a wider range of tasks -- not just programming.
also, the IDE's I've used in the past were sluggish and for some
reason the font-rendering was really hard to get right (if at
all). when you spend the majority of your waking hours editing text,
interactive response time and "editing ergonomics" matter a lot.
this reminds me that it is probably time to give IDEs another chance.
it has been a couple of years since the last time I tried a couple for
Java.
-Bjørn
------------------------------
Date: 22 Jun 2007 17:37:06 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3vedg6lwd.fsf@borud.not>
[Falcolas <garrickp@gmail.com>]
|
| I took a moment to look at the gui editor which has been made
| available to me, and short of the "remove leading spaces" commands, I
| do not need to remove my hands from the keyboard if I do not want
| to.
well, that depends on the editing features you use. I use a lot of
features I am not consciously aware of, so if I were to list what I
require from an editor, I would have trouble enumerating them.
I can't even tell you what keys they are bound to because I just use
them instinctively. the same goes for VI. (VI having the added
benefit of a really systematic way to organize editing actions into a
sort of a matrix (a useful metaphor I was made aware of by an "expert
VI user" who showed me how to make some editing operations more
efficiently))
having people who are good at efficient editing show you some tricks
really pays off btw. I can't bear to watch other people edit text
because they are doing so much manual labor that could have been
avoided if they had just bothered to learn more effective editing
habits.
-Bjørn
------------------------------
Date: Fri, 22 Jun 2007 18:25:57 +0300
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <87tzt01056.fsf@kobe.laptop>
On 21 Jun 2007 16:52:17 +0200, Bjorn Borud <borud-news@borud.no> wrote:
> on my tombstone will say
> "here lies the last Emacs user on earth. M-x rip".
Hahaha! Very good one :-)
------------------------------
Date: Fri, 22 Jun 2007 11:28:34 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3wsxv3nlp.fsf@latakia.dyndns.org>
Falcolas <garrickp@gmail.com> writes:
>
> Being a primarily windows user, I have to question your assertion that
> using ctrl-f for find causes a "mental context switch". For me, in 90%
> of the windows applications, finding something is as simple as ctrl-f,
> the phrase, hit enter. Not terribly different from your set of
> commands. The biggest difference is that if I need to use a Find
> feature I might not often use, I have a visual interface to all the
> related search functions. On the other hand, a terminal program would
> necessitate a memory search at best, or a trip to the help pages at
> worst.
That's the advantage of a well-organised set of commands. If you want
to use regexp search, you have to look at the dialogue box and click on
a checkbox--which would be a context switch.
That's even assuming that your editor _offers_ regexp search. If emacs
didn't have it, I could add it, and it'd be just as much part of the
editor as if it were included...
> The best part of my windows knowledge is that it's transferable to
> most (all?) of the applications I work with. Find is usually ctrl-f.
> Undo is ctrl-z. Save is ctrl-s, yadda yadda. Such knowledge is rarely
> transferable from terminal programs in my experience -- what may be
> true for one program (emacs) is wildly different in another program
> (vi), and useless in yet another (pico).
Consistency is nice. That's be why the emacs are found throughout
Unix. In fact, for a long time Netscape used emacs bindings on Macs and
Windows. Among these bindings are C-a to go the beginning of a line,
C-e to go to the end, C-k to kill from point to the end of the line, M-b
and M-f to move forward and back by word and so forth.
It's Mac OS and Windows which are inconsistent. Emacs has been around
since they were mere glimmers in the eye of Jobs & Gates...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Just because I'm not doing anything, doesn't mean I have nothing to do!
--Ellen Winnie
------------------------------
Date: Fri, 22 Jun 2007 11:05:16 -0700
From: Falcolas <garrickp@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182535516.594974.243910@q69g2000hsb.googlegroups.com>
On Jun 22, 11:28 am, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> That's the advantage of a well-organised set of commands. If you want
> to use regexp search, you have to look at the dialogue box and click on
> a checkbox--which would be a context switch.
Again, you are assuming that the editor isn't set up in a way which
allows this to be done from the keyboard.
ctrl-f, alt-e, type, enter
> That's even assuming that your editor _offers_ regexp search. If emacs
> didn't have it, I could add it, and it'd be just as much part of the
> editor as if it were included...
One advantage I'm more than happy to cede to you - the current program
I use is closed source and not extensible. Though, I'm sure that there
are editors for windows/mac/xwindows which are as extensible as emacs.
> 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?
------------------------------
Date: Fri, 22 Jun 2007 23:32:22 +0800
From: "sonet" <sonet.all@msa.hinet.net>
Subject: why we need perl6 if we have parrort?
Message-Id: <f5gq36$rme$1@netnews.hinet.net>
If every dynamically languages (such as Perl6 and Python...)
will convert to PIR and automatically converted inside Parrot to
PBC (Parrot Bytecode).
1.Why we need perl6 ? We can learn how to coding in PIR direct.
2.Why not convert perl5 to PIR (convert to Parrot bytecode)?
------------------------------
Date: Fri, 22 Jun 2007 11:29:27 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: why we need perl6 if we have parrort?
Message-Id: <220620071129271306%brian.d.foy@gmail.com>
In article <f5gq36$rme$1@netnews.hinet.net>, sonet
<sonet.all@msa.hinet.net> wrote:
> If every dynamically languages (such as Perl6 and Python...)
> will convert to PIR and automatically converted inside Parrot to
> PBC (Parrot Bytecode).
>
> 1.Why we need perl6 ? We can learn how to coding in PIR direct.
For the same reason we have Java instead of programming in Java
bytecode: higher level languages condense higher level concepts into
keywords that represent a lot of behind-the-scenese lower-level code.
> 2.Why not convert perl5 to PIR (convert to Parrot bytecode)?
Some people were working on that with PONIE (Perl On New Interpreter
Image), but those are also the same people doing Perl 6 / parrot
things.
There's a lot more to Perl 6 than just using parrot for its interpreter.
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
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 555
**************************************
