[29327] in Perl-Users-Digest
Perl-Users Digest, Issue: 571 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jun 24 21:14:36 2007
Date: Sun, 24 Jun 2007 18:14:15 -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 Sun, 24 Jun 2007 Volume: 11 Number: 571
Today's topics:
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <andreas_eder@gmx.net>
Re: The Modernization of Emacs: terminology buffer and <eadmund42@NOSPAMgmail.com>
Re: The Modernization of Emacs: terminology buffer and <joswig@corporate-world.lisp.de>
Re: The Modernization of Emacs: terminology buffer and <eadmund42@NOSPAMgmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <jackt123@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <cor@clsnet.nl>
Re: The Modernization of Emacs: terminology buffer and <jackt123@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 24 Jun 2007 19:32:21 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182713541.449966.195970@o61g2000hsh.googlegroups.com>
On Jun 24, 8:10 am, Martin Gregorie <mar...@see.sig.for.address>
wrote:
> > Actually, what I prefer in (2D and 3D) visual design apps is the
> > ability to snap to some kind of grid/existing vertices, and to zoom in
> > close. Then small imprecisions in mouse movement can be rendered
> > unimportant.
>
> That might work for visual design apps, but it doesn't for CAD, where
> you may want to point to an arbitrary position with a (scaled) accuracy
> of microns.
I didn't mention that you should be able to zoom and make the grid
fine to whatever limit is reasonable given the application? The issue
being, how accurate is "accurate enough"? Pinpoint precision isn't
possible, unless it's an integer or a functionally derived value like
pi or some arithmetic result of that. Grids are good for getting
rational numbers exactly, and nothing will hit the irrational ones
exactly, save if you can enter a formula for it to use to compute the
point's location to any desired precision. A mouse click (sans grid)
will always introduce some error; the zoom level lets you limit the
magnitude of the error. So does a grid, and to zero if the desired
point is a grid vertex, and to half the grid size more generally.
> The fact remains that mechanical mice do jump when you click them,
> though optical mice are better in this respect.
Ultimately, the button has to be non-mechanical for this sort of thing
to really work. Or else not physically part of the mouse. Being able
to "click" from the keyboard makes sense given such requirements. So
does being able to snap to a grid.
> > The problem of course being the complete exclusion of type 1 users.
>
> Totally untrue.
I'm not talking about in general. I'm talking about the specific sorts
of unixy applications that are under discussion here. Those
emphatically cater solely to type-3s and type-4s, aside from newer
graphical apps for KDE and Gnome, which are emerging as a third group
of type-1-accessible tool alongside Mac applications and Windows
applications.
> Thats not true and never can be: a computer is
> the most complex device the average person will own or use and is likely
> to retain that title for the foreseeable future.
What about the fabrication devices? Oh, but I suppose the "foreseeable
future" has already ended by the time those trickle down to widespread
consumer use.
> I grant you that type 2 users are rare, but I think flight simulators
> may fit this case when used for training.
Anything you have to use to meet some important external goal, I
suppose. But most usually there are options. A programmer needs a text
editor but it need not be emacs. Jobs requiring the use of specific
software (for training, or just on the job) maybe, of which your
example is a subset.
> Not really. What's needed is a single interface that can be used by
> anybody from beginner to expert and that, in the case of an error, shows
> precisely where it got, what caused the action to fail to complete and
> that allows the user to continue from that point without having to
> undo/redo the bits that were successful. Its not easy, but it can be done.
Why do those who have the skills, talent, knowledge, and thus
capability to do this insist on making cruft like emacs then? I've
never seen a classic-unix tool that didn't barf unhelpful and
uninformative error messages at the drop of a hat (just like Windows!)
and present a piss-poor UI, or even no UI at all (unless "usage: blah
blah blah" qualifies as a UI, to which my response is one word. "Non-
interactive.") When the error messages are informative, they're still
cryptic, and only someone with knowledge of the software's internals
has a hope in hell of fixing the problem as a rule. Of course, the
number one rule of interface design is to speak the user's language
and the language of the problem domain, and remain mute (except to
developers invoking debug modes) about the implementation details and
the language of the solution domain. Especially given that a different
version of the same software, nevermind a different app with the same
usage, is probably going to use a different implementation anyway. One
exception can be to expose a specific scripting language for advanced
users to use to automate tasks. Emacs does this, and it's one thing I
don't have a problem with. As long as knowledge of its arcana is not
needed to either do straightforward stuff, or fix the errors that
occur attempting to do straightforward stuff, anyway. If the beginner
can safely ignore the thing's existence (e.g. the VB-based scripting
language in some office and paint programs) it's fine.
> > ROM BASICs and QBasic (on any really ancient microcomputer, and old
> > pre-Windows PCs, respectively; the former came with printed manuals
> > and you could just run prepackaged software from disks very easily;
>
> Hang on: you don't read manuals. You object to using tutorials and to
> buying books, so its a bit precious to claim this example.
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.
> > * The word processor with the usual interface where I can define
> > logical styles, then change them in only one place and affect every
> > pre-existing occurrence retroactively.
>
> Thats been in Word since DOS days and is part of OpenOffice. Its called
> a "style sheet".
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.
> You're thinking of Wordperfect and its 'Reveal Codes' function. That was
> the worst idea I've ever seen in a WP, matched only by the illogically
> arranged set of 12 function keys, each with 4 shifts.
Why?
> It didn't. 'Reveal codes' could only let you inspect the current
> document. Unfortunately it was essential to use it because some input
> sequences could completely mess up the formatting and the only way to
> recover was via 'Reveal codes'. The effect was similar to making a data
> entry clerk use a hex editor on a database to fix keyboarding errors.
Oh, because the implementation (of "reveal codes" and of everything
else) was awful, not because of any intrinsic flaw in the idea itself.
Would you want to edit a Web page without being able to hand-hack the
HTML? Use a GUI builder for Swing without being able to hand-hack the
Java? Thought not.
[Snip description of an advanced-for-its-time interface]
What happened to the guys that did all this stuff after it became
obsolete? Microsoft offer them $300 grand a year to mop floors or sit
in on various board meetings without a vote or something to get them
out of the way, being unable to use their talents competently and
equally unable to stand having them work for a competitor, or worse,
contribute to open source? Or offer a mob type $100 grand once to
whack them maybe?
> > The bog-standard alt, this, that sequences on Windows "come close";
> > they do make the menus display, but otherwise they do exactly what you
> > want, and you can ignore the menus blinking around in your peripheral
> > vision.
>
> No they don't: you can't easily string them together to act as a single
> command and the error diagnosis and reporting is remarkably poor. Same
> goes for Gnome, so I'm not particularly bashing Windows here.
You can string them together manually, or use a keyboard macro
recording and playback tool (they exist, though one doesn't come
standard with Windows; I think maybe one does with MacOS). It would be
nice if straightforward macro recording was standard in Windows
though.
On the other hand, I've not always been 100% sure of that sort of
thing. Even seemingly straightforward search-and-replace can suffer
from Sorceror's Apprentice Syndrome even at the best of times. And if
the thing treats every individual replace as a separate undoable
action instead of the one batch-of-replaces, and has a buffer of only
10 undos, and 13 items match, and one of them was unexpected and
shouldn't have been replaced...
Macro capabilities might be a dream, but macros running amok are a
nightmare. Maybe a real programmability would be better. I think the
scripting language capabilities in some apps provide that, with more
ability to control and constrain it from going into Sorceror's
Apprentice mode, but every app tends to have its own scripting
language and API and no real introduction-to-scripting type stuff,
leading us back to "the emacs problem" -- an arcane interface that
begins and ends in midair, with nowhere for the beginning user to
climb aboard, and differing from application to application so
limiting the value of investing much time in any one of them versus if
a single universal one were used (say Lua, or even elisp, or even
*gag* VB...)
------------------------------
Date: Sun, 24 Jun 2007 22:13:23 +0200
From: Andreas Eder <andreas_eder@gmx.net>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <86645drtzw.fsf@eder.homelinux.net>
Hi Twisted,
>>>>> "Twisted" == Twisted <twisted0n3@gmail.com> writes:
Twisted> * The operating system where you can do powerful stuff with a command
Twisted> line and a script or two, but can also get by without either. (Windows
Twisted> fails the former. Linux fails the latter.)
Twisted> * For that matter, the operating system whose GUI takes the concept
Twisted> behind OLE to its logical conclusion, and lets the user separately
Twisted> choose and configure their text editing, this-editing, that-editing,
Twisted> whosit-viewing, and the like components, and those components are used
Twisted> in building more complex applications. All the alternatives would of
Twisted> course adhere to a common interface for a particular sort of
Twisted> component, of course. (An OO language like Java lends itself to this,
Twisted> what with interfaces and inheritance and dynamic
Twisted> class loading!)
Have a look at Genera, the OS of the Lisp Machines. It offers all
that and much more. Unfortunately it is almost non existent
nowadays.
'Andreas
--
Wherever I lay my .emacs, there's my $HOME.
------------------------------
Date: Sun, 24 Jun 2007 16:52:07 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3zm2pynhk.fsf@latakia.dyndns.org>
Twisted <twisted0n3@gmail.com> writes:
> On Jun 23, 8:35 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
>> Twisted <twisted...@gmail.com> writes:
>>
>> > For an example of the latter, consider opening a file. Can't remember
>> > the exact spelling and capitalization of the file name? Sorry, bud,
>> > you're SOL. Go find it in some other app and memorize the name, then
>> > return to emacs.
>>
>> Once again I am forced to wonder if you have _ever_ actually used
>> emacs. find-file has tab completion: hit tab without anything typed, and
>> it displays _everything_ in the directory; type a few characters to
>> narrow it down; hit tab to complete the filename and be done with it.
>>
>> Or of course you could use directory mode, which enables you to navigate
>> around a directory tree, performing actions on files (including editing
>> them).
>>
>> Then of course there's ido.el, which is even better: type a few
>> characters from anywhere in the name, and it displays files matching
>> those characters.
>
> Really? None of this 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. 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.
> Tab completion is a poor cousin to a real directory tree navigator, as
> I'm sure most would agree.
I wouldn't. There are several directory navigators installed on this
machine, but I never use anything more than bash's tab completion.
If you like 'em, though, just select File:Visit New File. It gives you
a platform-default (gtk+, for me) file selector.
> Even if it will show all matches to a partial name instead of none,
> it's the textual equivalent of navigating a directory tree made into
> menus instead of provided by a proper folder view window. Windows
> users unfortunately have the experience regularly: the notorious Start
> menu. You have to expand submenus to find stuff, and you can't leave
> it idling to do something somewhere else and come back to it because
> it's a menu.
Nope, because of the way emacs works you can stop what you're doing, do
something else and come back to the minibuffer. As an example, while I
was typing the first paragraph, I had find-file running in the
minibuffer (I was checking for the exact prompts and phrases used).
> I can only imagine the pain of trying to navigate an equivalent way in
> an 80x25 box of text information.
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.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Dilbert: Not more than ten minutes ago you beat a man senseless.
Alice: He was senseless before I beat him.
------------------------------
Date: Sun, 24 Jun 2007 16:00:17 -0700
From: "joswig@corporate-world.lisp.de" <joswig@corporate-world.lisp.de>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182726017.459967.67280@m36g2000hse.googlegroups.com>
On 25 Jun., 00:52, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
You guys are all in the wrong newsgroups. Please stay in comp.emacs
when discussing Emacs. Don't cross post.
Not everyone is interested in Emacs discussions.
Thanks.
Follow-up set to comp.emacs.
------------------------------
Date: Sun, 24 Jun 2007 17:19:10 -0600
From: Robert Uhl <eadmund42@NOSPAMgmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m3odj5ym8h.fsf@latakia.dyndns.org>
Twisted <twisted0n3@gmail.com> writes:
>
> Of course, if emacs let you keep THREE windows open and visible at the
> same time, instead of being limited to one or a horizontally split two
> ... and a cramped 80x10 or so each, at that ...
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.
> I'll admit that it didn't USED TO 'eschew normal methods of
> navigation', but at a certain point in time there began to be 'normal
> methods of navigation' and emacs naturally began eschewing them
> promptly and has done so ever since.
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.
> If I haven't, it must be the case that finding this tutorial (or even
> discovering that it exists) was nontrivial, or it wasn't built into
> emacs, one or the other.
When you start emacs in a text console, you see this:
Welcome to GNU Emacs, one component of the GNU/Linux operating system.
Type C-l to begin editing.
Get help C-h (Hold down CTRL and press h)
Emacs manual C-h r
Emacs tutorial C-h t Undo changes C-x u
Buy manuals C-h C-m Exit Emacs C-x C-c
Browse manuals C-h i
Activate menubar F10 or ESC ` or M-`
(`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key.
If you have no Meta key, you may instead type ESC followed by the character.)
A GUI window shows a similar message. Note the 'Emacs tutorial' entry?
Or you could just go to the Help menu, then select 'Emacs Tutorial.'
>> 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.
>
> Apparently because you find the switch second nature, despite its not
> being the obvious (which is ctrl-tab, to switch between documents in
> an MDI app).
Clicking within the document's window isn't obvious?!?
> * OK, time to resort to *gulp* the help.
> * Oh, great, now what did it do? I hit F1 and ...
> * Eh. Try random stuff. Help starts with h. Alt-h? Ctrl-h? ...
> * Oh, right. I seem to remember the help popping up unwanted when I
> tried to backspace over a typo earlier, so I'll just do that.
Ha! f1 and C-h do the exact same thing. You've obviously not used emacs
this millennium.
> WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
> in a cramped little 80x24 grid of letters, numbers, spaces, and
> punctuation with no menus, no concept of a pointing device, and a bad
> attitude.
No, we're discussing emacs, a text editor which runs in both a GUI and a
text console. Which can display images. It's cool like that.
> At least Windows 3.1 had most apps have the same keys for the vast
> majority of commands, and those were the right keys. Emacs has all the
> applications have the vast majority of their commands use the same
> WRONG keys.
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.
>> 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?
>
> Search is usually ctrl+f, type something, hit enter in my experience.
Unless you want regexp search. And if you want to find again it can be
interesting. And maybe the program defaults to case-sensitive or
case-insensitive search...
> And I can use any text editor I want to edit HTML.
You could use Notepad no doubt; you could also use a Turing machine. I
prefer to use a useful tool.
>> 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.
>
> What are you talking about? Clearly not emacs, which is a console app
> for unix systems (with the inevitable MS-DOS ports and others).
No, as I've said over and over and over again, emacs is not what you
think it is. It has a GUI; it has colours; it can display images; it
can use the native widget set. It can even be configured to use native
keybindings, although that way lies madness.
> Some sort of bastardized Windows port I suppose?
Hah! Dude, I don't use Windows--I've better things to do with my life.
--
Robert Uhl <http://public.xdi.org/=ruhl>
With weapons, we are citizens. Without them, we are subjects.
------------------------------
Date: Sun, 24 Jun 2007 23:57:30 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182729450.495841.296140@q69g2000hsb.googlegroups.com>
On Jun 24, 6:52 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> > 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?
> 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.
Emacs, with your C-x C-f:
C-x C-f tab tab ("Startofnameofdirectory somethingElse
otherstuff")
Startofname tab tab ("Subdirectory anotherSubdirectory")
Subd tab tab
Windows:
Alt, f, o ("Startofnameofdirectory somethingElse
otherstuff")
Click-click
or Startofname-down-enter ("Subdirectory anotherSubdirectory")
Click-click
or Subd-down-enter
Worst case (all keyboard): one fewer keypress. Best case (judicious
use of the mouse and smart hand placement, one by left alt and one on
the mouse): five TOTAL gestures.
In particular, C-x C-f tab tab is replaced by alt f o (four down to
three keypresses) or click file, click open (two instead of three
inputs, but you have to locate the File menu from halfway across the
screen with the pointer, so count it as three as well).
Being able to pick an item from a list just by touching the damn thing
instead of typing in a sufficiently long prefix is definitely an
advantage, and if a lot of things share the same 16-character prefix
in a particular directory, the emacs way starts to look SLOW.
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-/
Straight to the subdirectory without waiting for it to display the
parent directory or the root. Same number of inputs. And of course
there's the super-fast
Alt, f, o, C-v, enter
if you happen to have the exact path in the clipboard already. I'd
like to see emacs do that, at least if the text to paste originated
outside emacs. (If I'm doing this in Winword's file open dialog it
could have originated in Notepad, Firefox, or just about anywhere
else, not just Winword.)
> 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
> Nope, because of the way emacs works you can stop what you're doing, do
> something else and come back to the minibuffer.
After spending a while brushing up on my Tibetan, I may or may not
agree, but until I've got some real meaning out of your use of jargon
like "minibuffer", I'll have to pass on this one. Nonetheless, stuff
you can do but can't know you can do without learning Tibetan is
unlikely to be of much help to the average user. :)
> 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. 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?
------------------------------
Date: Mon, 25 Jun 2007 00:32:06 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182731526.329068.101540@c77g2000hse.googlegroups.com>
On Jun 24, 7:19 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> Twisted <twisted...@gmail.com> writes:
>
> > Of course, if emacs let you keep THREE windows open and visible at the
> > same time, instead of being limited to one or a horizontally split two
> > ... and a cramped 80x10 or so each, at that ...
>
> 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. If we're not talking about the same piece of
software (and the one the fanatics evangelize about) then this is
pointless.
> 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". ;)
> When you start emacs in a text console, you see this:
>
> Welcome to GNU Emacs, one component of the GNU/Linux operating system.
>
> Type C-l to begin editing.
>
> Get help C-h (Hold down CTRL and press h)
> Emacs manual C-h r
> Emacs tutorial C-h t Undo changes C-x u
Really? That is not what I recall seeing. Are you talking about emacs-
the-text-mode-editor, or emacs-the-hybrid-somethingorother-when-you-
happen-to-run-it-from-the-command-prompt-on-unix? Because I've been
discussing the former.
> Buy manuals C-h C-m
How crass.
First I've seen anything open source/"free" software that makes sales
pitches at you. Mostly I've only seen that with closed-source Windows
"free"ware loaded with adware, and with shareware that nags you to
register or otherwise spend money with its author. And with actual
paid products, particularly those from Intuit which act as Intuit's
front-line salesmen by trying to constantly upsell you and sell stuff
to your friends and relatives. Er, thanks but no thanks. (I don't
personally spend a dime on any Intuit products. I unfortunately know
people who do. One version of some accounting software of theirs even
spammed all of a user's email contacts, by God. Where are those
Russian spammer-targeting hitmen when you need them?)
> Activate menubar F10 or ESC ` or M-`
Definitely not the stock text-mode emacs I've had my runins with in
the past, but some kind of hybrid or offshoot, then.
> Clicking within the document's window isn't obvious?!?
Clicking within the document's window is obvious but doesn't work,
unless you're using something other than vanilla emacs at least. It
did of course work in MS-DOS Edit, later versions.
> No, we're discussing emacs, a text editor which runs in both a GUI and a
> text console. Which can display images. It's cool like that.
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". Anyone can dodge or seem to rebut a
criticism of one of them by describing how another of them isn't like
that. :P
> > At least Windows 3.1 had most apps have the same keys for the vast
> > majority of commands, and those were the right keys. Emacs has all the
> > applications have the vast majority of their commands use the same
> > WRONG keys.
>
> 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.
The Windows keys are familiar to 97% of the population. Some might
consider them right for that reason.
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".
> > Search is usually ctrl+f, type something, hit enter in my experience.
>
> Unless you want regexp search. And if you want to find again it can be
> interesting.
I rarely want regexp search, and if I want it I can use Notetab, a
notepad replacement with tabbed MDI and yes, regexp search. A few tabs
and a space keypress to turn it on after ctrl+f.
As for "find again" hitting enter additional times is the usual
method, in Notetab, Notepad, and elsewhere.
> > And I can use any text editor I want to edit HTML.
>
> You could use Notepad no doubt; you could also use a Turing machine. I
> prefer to use a useful tool.
Painting it as a choice between Notepad and emacs is the fallacy of
false dichotomy. There's Notetab (useful, but non-free) and lots of
(sometimes free) other text editors (for Windows and for other
platforms).
Some specialize in HTML editing the way Eclipse's built-in editor
specializes in Java editing (and with plugins, can be made to
specialize in, say, C instead).
> No, as I've said over and over and over again, emacs is not what you
> think it is. It has a GUI; it has colours; it can display images; it
> can use the native widget set. It can even be configured to use native
> keybindings, although that way lies madness.
One thing I agree on regarding emacs is the phrase "that way lies
madness". I'm amending that belief to include participating in Usenet
discussions about emacs, as well as actually trying to use emacs.
Given that everyone seems to mean a distinct piece of software by the
term "emacs" it's a wonder anything coherent can be said about "emacs"
at all. Actually, the one constant to emerge in all of this is C-h
being associated with accessing the help in all of these various
emacses. And we all know that that results in backspace doing
surprising things for a text editor. :P
> Hah! Dude, I don't use Windows--I've better things to do with my life.
Xemacs then, or whatever they're calling the bolted-on-an-X-GUI-and-
the-rivet-job-shows-from-1000-paces version these days.
------------------------------
Date: Mon, 25 Jun 2007 00:48:47 -0000
From: JackT <jackt123@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182732527.577903.63600@q75g2000hsh.googlegroups.com>
On Jun 25, 12:32 am, Twisted <twisted...@gmail.com> wrote:
>
> It looks like there are
> several utterly different pieces of software that have one thing in
> common - the name "emacs"...
>
> > When you start emacs in a text console, you see this:
> >
> > Welcome to GNUEmacs, one component of the GNU/Linux operating system.
> > Get help C-h (Hold down CTRL and press h)
> > Emacsmanual C-h r
> > Emacstutorial C-h t Undo changes C-x u
>
> Really? That is not what I recall seeing. Are you talking aboutemacs-
> the-text-mode-editor, oremacs-the-hybrid-somethingorother-when-you-
> happen-to-run-it-from-the-command-prompt-on-unix? Because I've been
> discussing the former.
Everyone now uses http://www.gnu.org/software/emacs/
or a minor derivative of it.
Its official distribution FTP location is
http://ftp.gnu.org/pub/gnu/emacs/
And for the Windows port, the official FTP is here
http://ftp.gnu.org/pub/gnu/emacs/windows/
We don't care about the 1970 version of Emacs,
because of course back then there WAS NO GUI.
- JackT
------------------------------
Date: 25 Jun 2007 00:56:23 +0000
From: Cor Gest <cor@clsnet.nl>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <87wsxsam2w.fsf@telesippa.clsnet.nl>
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.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that fails to satisfy read the HyperSpec, woman frig or Tuxoharata
mailpolicy @ http://www.clsnet.nl/mail.php
------------------------------
Date: Mon, 25 Jun 2007 01:03:06 -0000
From: JackT <jackt123@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182733386.404922.24200@w5g2000hsg.googlegroups.com>
On Jun 25, 12:56 am, Cor Gest <c...@clsnet.nl> wrote:
> Some entity, AKA JackT <jackt...@gmail.com> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
No need to be insulting.
>
> > We don't care about the 1970 version ofEmacs,
> > because of course back then there WAS NO GUI.
>
> But if you are blind as bat, any 2007's GUI is useless.
>
You may have missed part of the discussion.
Today's GNU emacs will still run with most of its features
(even keyboard-driven text-drawn menu) when you run
it on a GUI-less environment.
At the same time, today's GNU emacs, when run on a GUI,
will be able to pop up file-selection menus, display colors, etc. etc.
- JackT
------------------------------
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 571
**************************************
