[29329] in Perl-Users-Digest
Perl-Users Digest, Issue: 573 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 25 09:14:47 2007
Date: Mon, 25 Jun 2007 06:14:11 -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 Mon, 25 Jun 2007 Volume: 11 Number: 573
Today's topics:
Re: The Modernization of Emacs: terminology buffer and <eadmund42@NOSPAMgmail.com>
Re: The Modernization of Emacs: terminology buffer and <eadmund42@NOSPAMgmail.com>
Re: The Modernization of Emacs: terminology buffer and (Rob Warnock)
Re: The Modernization of Emacs: terminology buffer and <dak@gnu.org>
Re: The Modernization of Emacs: terminology buffer and <martin@see.sig.for.address>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 24 Jun 2007 19:42:20 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3k5tszu6b.fsf@latakia.dyndns.org>
Twisted <twisted0n3@gmail.com> writes:
>
>> > Really? None of [navigating a folder window analogue] happens if
>> > you just do the straightforward file-open command, which should
>> > obviously at least provide a navigable directory tree, but
>> > definitely does not.
>>
>> The first does. Really, it does. Fire up emacs (which you've never
>> done before) and type C-x C-f.
>
> Whoa, Nellie. I seem to recall we were discussing the file-open
> command. That was something else, like C-x C-o or something. More
> apples-and- oranges?
Fortunately, emacs has a facility to tell exactly what's bound to a key
sequence. C-h k (or f1 k, if you prefer)followed by that sequence will
display what's bound to it, and the documentation for that function.
C-h k C-x C-o yields:
C-x C-o runs the command delete-blank-lines
C-h k C-x o yields:
C-x o runs the command other-window
C-h k C-x C-f yields:
C-x C-f runs the command find-file
So you can see how cool emacs is, here's the entire output for C-x C-f,
demonstrating how the editor documents itself:
C-x C-f runs the command find-file
which is an interactive compiled Lisp function in `files.el'.
It is bound to <open>, C-x C-f, <menu-bar> <file> <new-file>.
(find-file filename &optional wildcards)
Edit file filename.
Switch to a buffer visiting file filename,
creating one if none already exists.
Interactively, the default if you just type RET is the current directory,
but the visited file name is available through the minibuffer history:
type M-n to pull it into the minibuffer.
Interactively, or if wildcards is non-nil in a call from Lisp,
expand wildcards (if any) and visit multiple files. You can
suppress wildcard expansion by setting `find-file-wildcards' to nil.
To visit a file without any kind of conversion and without
automatically choosing a major mode, use M-x find-file-literally.
>> You will be presented with a prompt
>> something like 'Find file: ~/'; hit tab once; you'll see the message
>> '[Complete, but not unique]'; hit tab again and you will be presented a
>> list of all files in that directory.
>
> Sounds clunky anyway. I don't need a bunch of keypresses to do the
> equivalent in an Explorer-based file-open dialog in a native Windows
> app. Just a double-click.
Generally, you need to scroll, too, as the Windows file widget doesn't
display a lot of files at once.
> Of course, there's an even faster Windows way, if you don't mind not
> seeing lists of possible items:
> Alt, f, o
> Startofname-down-/-Subd-down-/
How is this different from C-x C-f Startofname-tab-Subd-tab? Except
emacs saves you type slashes...
>> If you like 'em, though, just select File:Visit New File. It gives
>> you a platform-default (gtk+, for me) file selector.
>
> Now we're talking about a graphical port instead of stock emacs
> again. :P
That _is_ stock emacs, I assure you.
>> Fortunately, folks brighter than you & I have imagined a nice way for
>> us. It pops up a new Emacs window (pane, if you prefer the
>> terminology) showing a list of all filenames. You could continue
>> typing, or just click on a filename in the window, or hit return
>> while the cursor is on a filename in that window.
>
> Back to discussing a graphical port again.
It's not a port--it's emacs. And save for the click all of the above
works in both a GUI and a console. It's nice working the same way in
multiple places.
> Besides the apples and oranges issue, this amounts to implementing a
> dodgy imitation of a file open dialog anyway. Why bother with such an
> imitation when you can use a natively-GUI editor written for your
> platform and get access to the real thing?
Because it's nice having the same interface no matter what. Because
GUIs come and GUIs go (remember CDE? OpenView?), but emacs will always
be there. Because it's nice being able to fire up emacs and not care
what platform one is running on.
--
Robert Uhl <http://public.xdi.org/=ruhl>
prepBut nI vrbLike adjHungarian! qWhat's artThe adjBig nProblem?
-- Alec Flett
------------------------------
Date: Sun, 24 Jun 2007 19:51:00 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3fy4gztrv.fsf@latakia.dyndns.org>
Twisted <twisted0n3@gmail.com> writes:
>
>> I have two frames open right now: one 80x70, the other around 180x70
>> (characters, not pixels). One isn't split at all; the other is split
>> into four windows, horizontally and vertically.
>
> Then you're obviously not using the One True Emacs I am criticizing,
> which is a console app.
No, the One True Emacs supports GUIs. It has since 1991. Take a look
at <http://linux.softpedia.com/screenshots/Emacs_2.png>.
>> emacs has continued doing its own thing, mostly because that thing is
>> better. The CUA standards (there exists an emacs package if you
>> really want them) are broken and lame--I and most other don't wish to
>> cripple our text editor of choice.
>
> "CUA standards"? I'm sorry, I don't speak Botswanan. If you mean
> Windows standards like for cut, copy, and paste, "broken and lame" is
> obviously in the eye in the beholder, and something 97% of computer
> users are used to is the defacto standard, so it's the other 3% that
> are "broken and lame". ;)
Popularity is no measure of goofness.
> No, we're discussing ... oh, nevermind. It looks like there are
> several utterly different pieces of software that have one thing in
> common - the name "emacs".
That is actually true. There's GNU emacs (the original and still the
best). There's XEmacs (a fork of the same). Then there are a myriad of
ancient emacsen, most particularly Gosling emacs.
However, the only two which matter are GNU emacs and XEmacs. Both have
supported a GUI for 16 years now. I don't have XEmacs installed, so I
cannot tell you if it has the tutorial. I would be truly surprised if
it didn't.
>> Neither is right nor wrong; you're just used to one. The emacs keys are
>> certainly more flexible and powerful, though. Some might consider them
>> right for that reason.
[snip]
> This is also a change from your earlier position that they were, and I
> quote, "broken and lame", assuming you mean the same stock Windoze
> keybindings you meant with the cryptic term "CUA standards".
Not really--they're broken and lame because they are less flexible and
powerful.
How 'bout you actually try using a modern emacs? It'll even support
your chosen operating system.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Better to teach a man to fish than to give him a fish. And if he can't
be bothered to learn to fish and starves to death, that's a good enough
outcome for me. --Steve VanDevender, 1 May 2000
------------------------------
Date: Mon, 25 Jun 2007 02:02:20 -0500
From: rpw3@rpw3.org (Rob Warnock)
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <6IidnRMu2ZPh9eLbnZ2dnUVZ_h2pnZ2d@speakeasy.net>
Robert Uhl <eadmund42@NOSPAMgmail.com> wrote:
+---------------
| However, the only two which matter are GNU emacs and XEmacs.
| Both have supported a GUI for 16 years now. I don't have
| XEmacs installed, so I cannot tell you if it has the tutorial.
| I would be truly surprised if it didn't.
+---------------
It does. And the default startup splash screen
tells you how to access it.
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
------------------------------
Date: Mon, 25 Jun 2007 09:11:07 +0200
From: David Kastrup <dak@gnu.org>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <86fy4gh5kk.fsf@lola.quinscape.zz>
Cor Gest <cor@clsnet.nl> writes:
> Some entity, AKA JackT <jackt123@gmail.com>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
>> We don't care about the 1970 version of Emacs,
>> because of course back then there WAS NO GUI.
>
> But if you are blind as bat, any 2007's GUI is useless.
Have you actually talked to a blind person about that? They often
prefer the GUI applications since they tend to interact better with
screen readers and the accessibility software available for the GUI's
toolkits. Sounds crazy, I know.
Anyway, Emacs plays in a league of its own for blind people due to
Emacspeak.
--
David Kastrup
------------------------------
Date: Mon, 25 Jun 2007 13:40:53 +0100
From: Martin Gregorie <martin@see.sig.for.address>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <onp4l4-s5g.ln1@zoogz.gregorie.org>
Twisted wrote:
> The manuals came with the computers, at no additional charge. It was a
> different time. This isn't going to be true of any separately-
> purchased book or user-made printout concerning emacs. Also, the
> manuals provided a basic introduction for the beginning user. A
> traditional-unix-tool providing anything resembling that would
> genuinely shock me.
>
Oh, so manuals are OK and you'll read them if they are dead trees that
came in the same box as the software, but not if they're HOWTOs, online
documentation or O'Reilly books?
> I distinctly remember Winword circa 2002 not being able to
> retroactively change all of a bunch of like-formatted paragraphs
> easily. Not without delving into VBscript or something, anyway.
>
So you didn't read the free but thick and stodgy Word manual? Styles and
style sheets have been in Word since Word for DOS 5. Changing a style
sheet has always affected all documents that reference it.
>
> Oh, because the implementation (of "reveal codes" and of everything
> else) was awful, not because of any intrinsic flaw in the idea itself.
>
If a word processor, which by definition is provides a WYSIWYG user
interface, can't produce perfectly formatted text by editing a
representation of the finished result then its a deeply flawed program
and not fit for purpose.
By providing 'Reveal codes' and by being designed in such a way as to
force its regular use, Wordperfect reveals itself as being no better
than nrof or tex - its like expecting a user to write postscript source
with a text editor and providing a separate window with a Postscript
viewer to see what the final result will look like.
> Would you want to edit a Web page without being able to hand-hack the
> HTML?
>
Of course not, but HTML isn't anything to do with WYSIWYG and any system
(Coldfusion, Front Page, HTML from Word) that pretends it is WYSIWG is
both useless and perpetrating a fraud.
> What happened to the guys that did all this stuff after it became
> obsolete?
>
It isn't obsolete despite going back a looong way. The hardware and
software was originally developed as Future Series (intended S/360
replacement), was canned in 1970 but resurfaced in the late 80s as
System/38. A second generation appeared as AS/400, was renamed to (I
think) Z-series and are now known as iSeries servers. Its good, reliable
kit and easy to work with if you don't mind programming in RPG.
I know of no better "one size fits all" interface design than that
provided by the OS/400 operating system. Its still called that. Its a
pity the interface style hasn't been emulated by others.
> It would be nice if straightforward macro recording was standard in Windows
> though.
>
It was standard with Win 3.1 and 3.11 and it was bloody useless. Most
people I know tried it once or twice before giving up and writing .BAT
files or putting up with RSI. The problem was that it recorded
keystrokes and mouse clicks. Even minor changes to the screen layout
made it fail and the macros couldn't be edited or parameterised nor made
to prompt for filenames, etc.
You can do better with Gnome, thanks to tcl, but I think most people go
straight to Ruby or stick to plain vanilla shell scripts.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
------------------------------
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 573
**************************************
