Why Emacs vs Vi(m) ?
Steve
There are other programmer's editors that match/rival either editor for
editing power......free, and nonfree.
Steve
stevesusenet AT yahoo DOT com
The Java Resource Dump
http://www.geocities.com/beforewisdom/Tech/Java/index.html
Steve's Tech Links:
http://www.geocities.com/beforewisdom/Tech/index.html
-------------------------------------------------------
"Rancor is an outpouring of a feeling of inferiority"
- Jose' Ortega y Gasset
--------------------------------------------------------
David Kastrup
> Why do the "editor wars" in usenet always translate to "Emacs vs. Vi(m)"?
>
> There are other programmer's editors that match/rival either editor
> for editing power......free, and nonfree.
Such as? I know of no editor even approaching the power, extent and
flexibility of Emacs. And there are very few around that have the
keyboard efficiency and "lean and mean" aspect of basic vi that
manages to make wagonloads from its basic command set.
Things like
:g/^/0m
are usually not available from ordinary editors unless a special
command has been implemented for them.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
David Kastrup
> Why do the "editor wars" in usenet always translate to "Emacs vs. Vi(m)"?
>
> There are other programmer's editors that match/rival either editor
> for editing power......free, and nonfree.
Such as? I know of no editor even approaching the power, extent and
flexibility of Emacs. And there are very few around that have the
keyboard efficiency and "lean and mean" aspect of basic vi that
manages to make wagonloads from its basic command set.
Things like
:g/^/m0
Shyamal Prasad
Steve> Why do the "editor wars" in usenet always translate to
Steve> "Emacs vs. Vi(m)"? There are other programmer's editors
Steve> that match/rival either editor for editing power......free,
Steve> and nonfree.
No, there aren't. There's emacs, the much inferior vi, and then
there's a bunch of wannabe "editors" that I'm not even going to
consider looking at because they obviously cannot be even half as good
as vi. Why waste your time looking at alternative editors when you
already have the One True Editor?
M-x all-hail-emacs
Cheers!
Shyamal
Jym Dyer
> vs. Vi(m)"?
=v= I don't really recall Vim being mentioned; on Usenet it's
generally "Emacs vs. vi," and that's because Usenet's grounded
in Unix. On other systems, it's Emacs vs. *their* native
editor.
=v= So the basic issue is whether or not one is using whatever
junk came with the system or whether one has seen the light.
HTH,
HAND,
<_Jym_>
Per Abrahamsen
> Why do the "editor wars" in usenet always translate to "Emacs vs. Vi(m)"?
The are the opposite ends of the scale. Emacs is everything that is
good, while vi is purest form of evil. All other editors are
somewhere in between these extreme positions.
Steve
> Steve <add...@bottom.of.post.nospam.com> writes:
>
> > Why do the "editor wars" in usenet always translate to "Emacs vs. Vi(m)"?
> >
> > There are other programmer's editors that match/rival either editor
> > for editing power......free, and nonfree.
>
> Such as? I know of no editor even approaching the power, extent and
> flexibility of Emacs.
I've never had good luck communicating on that issue with other emacs
devotees.
Usually if I name an editor that approaches the editing power of
emacs, and if the person bothers giving the editor(s) I mention a fair
evaluation they will call the whole argument "moot" if they can find
one feature.....however obscure.....that emacs has over the other
editor.
The fact that the other tools are in the same arena in terms of
editing power, are easier to learn, easier use, and are easier to
customize is _dismissed_ if it doesn't have the twiddle_twaddle mode
that emacs does.
Emacs has a lot of power, but that is no longer unique.
I think Emacs could regain total supremacy if the ease of
customization could be improved upon.
Steve
David Kastrup
> David Kastrup <David....@t-online.de> wrote in message news:<x5bs8x9...@tupik.goethe.zz>...
> > Steve <add...@bottom.of.post.nospam.com> writes:
> >
> > > Why do the "editor wars" in usenet always translate to "Emacs vs. Vi(m)"?
> > >
> > > There are other programmer's editors that match/rival either editor
> > > for editing power......free, and nonfree.
> >
> > Such as? I know of no editor even approaching the power, extent and
> > flexibility of Emacs.
>
> I've never had good luck communicating on that issue with other emacs
> devotees.
>
> Usually if I name an editor that approaches the editing power of
> emacs, and if the person bothers giving the editor(s) I mention a
> fair evaluation they will call the whole argument "moot" if they can
> find one feature.....however obscure.....that emacs has over the
> other editor.
We just recently had a discussion of that sort in de.comp.editoren
where someone claimed that NEdit could do everything that Emacs could.
Whenever somebody came up with a particular feature of Emacs that he
found indispensible to his work, the NEdit proponent either claimed
that in theory it should be possible to make NEdit do something
similar, or he declared that the particular feature was not required
in an editor, or that he had never needed it himself, and so nobody
else should ever have had the urge to use it.
> The fact that the other tools are in the same arena in terms of
> editing power, are easier to learn, easier use, and are easier to
> customize is _dismissed_ if it doesn't have the twiddle_twaddle mode
> that emacs does.
>
> Emacs has a lot of power, but that is no longer unique.
>
> I think Emacs could regain total supremacy if the ease of
> customization could be improved upon.
You mean like having an "Options" menu where you can set/save the
basic options, and which directs you to a hierarchical "Customize"
menu for the more complicated customization tasks?
Luis Fernandes
Steve> Why do the "editor wars" in usenet always translate to
Steve> "Emacs vs. Vi(m)"? There are other programmer's editors
Steve> that match/rival either editor for editing
Steve> power......free, and nonfree.
But no one uses ed for software development.
David Kastrup
I have to admit to just recently having made some trivial changes to
some config file with ed, started from within an su command inside of
an eshell in an Emacs window. When you know that your TERM is not
something sane, ed still is nice to have.
Paul Jarc
> But no one uses ed for software development.
I do. But not much. I've also used less and ed for reading and
composing mail. But not much.
paul
J. Fischer
>steves...@yahoo.com (Steve) writes:
>
>> Usually if I name an editor that approaches the editing power of
>> emacs, and if the person bothers giving the editor(s) I mention a
>> fair evaluation they will call the whole argument "moot" if they can
>> find one feature.....however obscure.....that emacs has over the
>> other editor.
IMO the problem is that you want to compare editors. However, Emacs
isn't an editor, actually it's an IDE for elisp and you can program
virtually everything in elisp just as in any other full programming
language. There are lots of Emacs users around and some of them do
programming in elisp. Every program they have written will be
considered as an editing feature of Emacs.
>
>We just recently had a discussion of that sort in de.comp.editoren
>where someone claimed that NEdit could do everything that Emacs could.
>
Yes, but as plain ASCII editor of course, not as programming language.
Unfortunately this never became clear.
>Whenever somebody came up with a particular feature of Emacs that he
>found indispensible to his work, the NEdit proponent either claimed
>that in theory it should be possible to make NEdit do something
>similar, or he declared that the particular feature was not required
>in an editor, or that he had never needed it himself, and so nobody
>else should ever have had the urge to use it.
The whole point was whether or not a feature could be seen as an
editing feature. There is no *exact* definition of what an editor is,
but some of the Emacs features mentioned in the discussion refered to
above were well off the road.
>> The fact that the other tools are in the same arena in terms of
>> editing power, are easier to learn, easier use, and are easier to
>> customize is _dismissed_ if it doesn't have the twiddle_twaddle mode
>> that emacs does.
Exactly. Perhaps I had better claimed that Jedit could do everything
Emacs can do, because via Java plugins it actually could - it wouldn't
however be a comparison of editors but of programming languages, i.e.
Java vs. elisp, where many folks would prefer Java, I think.
>> Emacs has a lot of power, but that is no longer unique.
>>
>> I think Emacs could regain total supremacy if the ease of
>> customization could be improved upon.
Not to mention that the clumsy handling of Emacs comes rather close to
driving a tank, but a very old one.
-- Jörg
Jym Dyer
=v= While other editors are extensible, the value of that
feature is more theoretical than practical when only a handful
of extensions have been written. Emacs is way ahead of the
pack in that regard. Also, as far as I know there is no
other editor (extensible or not) that's been ported to as
many platforms.
<_Jym_>
David Kastrup
> David Kastrup wrote:
>
> >steves...@yahoo.com (Steve) writes:
> >
> >> Usually if I name an editor that approaches the editing power of
> >> emacs, and if the person bothers giving the editor(s) I mention a
> >> fair evaluation they will call the whole argument "moot" if they can
> >> find one feature.....however obscure.....that emacs has over the
> >> other editor.
>
> IMO the problem is that you want to compare editors. However, Emacs
> isn't an editor, actually it's an IDE for elisp
This is complete and utter crap. You might as well call an editor
written and extensible in C a mere "IDE for C".
> and you can program virtually everything in elisp just as in any
> other full programming language.
And your point is? The main purpose of Emacs is not programming in
Elisp, but editing. That it is extensible in Elisp does not bear on
that.
> There are lots of Emacs users around and some of them do programming
> in elisp. Every program they have written will be considered as an
> editing feature of Emacs.
Any feature that is available to the normal Emacs user under a normal
Emacs installation when editing, yes, is an editing feature of
Emacs. That it came about by some Emacs users having done Elisp
programming is irrelevant.
> >We just recently had a discussion of that sort in de.comp.editoren
> >where someone claimed that NEdit could do everything that Emacs
> >could.
> >
>
> Yes, but as plain ASCII editor of course, not as programming
> language. Unfortunately this never became clear.
Please stop lying like a politician. The features discussed were all
features that arise when dealing with plain ASCII text.
> >Whenever somebody came up with a particular feature of Emacs that
> >he found indispensible to his work, the NEdit proponent either
> >claimed that in theory it should be possible to make NEdit do
> >something similar, or he declared that the particular feature was
> >not required in an editor, or that he had never needed it himself,
> >and so nobody else should ever have had the urge to use it.
>
> The whole point was whether or not a feature could be seen as an
> editing feature. There is no *exact* definition of what an editor
> is, but some of the Emacs features mentioned in the discussion
> refered to above were well off the road.
preview-latex is an editing feature concerning the visual
representation of LaTeX, a plain ASCII input format. The ability to
call compiler or grep or similar and have the possibility of jumping
to error locations in plain ASCII input (like C programs are) is an
editing feature. Indentation schemes are editing features. Easy
browsing of directories in order to find your plain ASCII input files
is an editing feature. The ability to edit news articles is an
editing feature. Your attempt to call everything "not an editing
feature" that your personal preferred editor does not provide remains
as ridiculous as ever.
> Exactly. Perhaps I had better claimed that Jedit could do everything
> Emacs can do, because via Java plugins it actually could - it
> wouldn't however be a comparison of editors but of programming
> languages, i.e. Java vs. elisp, where many folks would prefer Java,
> I think.
Nonsense. When comparing what editors "can do", please refrain from
hypothetically implementable features, and restrict yourself to actual
implemented ones. The question is not what an editor could do once
you extend it with some self-written stuff in its respective extension
language. It is what it does without requiring programming by the
user.
J. Fischer
>"J. Fischer" <jf...@yahoo.de> writes:
>
>
>Please stop lying like a politician. The features discussed were all
>features that arise when dealing with plain ASCII text.
>
There are always several different things that come up when
dealing with plain ASCII text files. E.g. for creating a program you
will need not only an editor but also a compiler and a debugger.
Similiarily for the creation of scientific works with LaTeX you will
need not only an editor but also a compiler and a previewer.
Your argumentation was right from the start that Emacs is such a
powerful editor because it can serve as a kind of previewer, too,
while editing your text.
>> Exactly. Perhaps I had better claimed that Jedit could do everything
>> Emacs can do, because via Java plugins it actually could - it
>> wouldn't however be a comparison of editors but of programming
>> languages, i.e. Java vs. elisp, where many folks would prefer Java,
>> I think.
>
>Nonsense. When comparing what editors "can do", please refrain from
>hypothetically implementable features, and restrict yourself to actual
>implemented ones. The question is not what an editor could do once
>you extend it with some self-written stuff in its respective extension
>language.
Why should this be my problem. Nedit is not at all `extensible' as
Emacs is by which it is exactly understood what you describe above,
i.e. adding stuff written in elisp.
(Oh, it is already there, of course. ;-)
> It is what it does without requiring programming by the
>user.
In contrast Nedit provides a macro language as feature that allows
_the_user_to_automate_editing_tasks_ - not more, not less.
(This is very different from elisp, Java or other programming
languages.)
--Jörg
Steve
> where someone claimed that NEdit could do everything that Emacs could.
> Whenever somebody came up with a particular feature of Emacs that he
> found indispensible to his work, the NEdit proponent either claimed
> that in theory it should be possible to make NEdit do something
> similar,
I mean no insult or sarcasm by this comment.........really, but that
is ironic as that is one of the standard responses I get from emacs
users who are doctrainaire emacs users. If I point out something
another editor or ide has that emacs doesn't I am told I can extend or
customize emacs all I want to.
> You mean like having an "Options" menu where you can set/save the
> basic options, and which directs you to a hierarchical "Customize"
> menu for the more complicated customization tasks?
Again no offense or sarcasm meant. The customization tool you talk of
is atrocious and of little help. It has a very wordy, busy interface.
Most of the time the options are written is such a way that you have
to be an expert in emacs to understand what you are choosing which
goes against the whole point. People with that level of knowledge can
just set things for themselves.
I find it easier to use my .emacs file and look up the functions I
need then use the custom utility.
That facility could be improved by converting it over to a full GUI
tabbed dialong box with brief explanations ( no more then 1 line) next
to each gui control for the option that would label the option in the
mindset "what change you will see if you choose this".
The help groups for emacs are filled with stories of people spending
hours figuring out how to change a font, a color, a default frame size
etc. Thats common and there is something wrong with that.
Those are trivial tasks in other applications with GUI interfaces.
Part of the trouble is that design descisions, selection of defaults
etc etc favor the emacs expert leaving the burden of tweaking to the
new person.
I think it should be the other way around. The experts are more
suited toward the tweaking( which they will do anyway ). They have a
body of knowledge already. Asking the non expert user to do a massive
amount of tweaking frustrates them and drives them away from emacs.
Steve
> IMO the problem is that you want to compare editors. However, Emacs
> isn't an editor, actually it's an IDE for elisp and you can program
> virtually everything in elisp just as in any other full programming
> language.
True. There are also other very powerful editors out there that are
really multipurpose IDEs out there. They can interface with compilers
from all sorts of technologies, they have syntax/indentation packages
for all sorts of technologies, they can be extended and they even
interface with debuggers.
Many of them are easier to learn, use and customize/exten then emacs.
Maybe if every programmer fell off of the face of the Earth emacs
would survive as a mail reader, news reader and/or a latex word
processor.
Many of the people I have known discover emacs because they are
interested in a programming tool.......code editors with more features
then a pico or a notepad.
The other multipurpose IDEs aside, there are editors out there ( just
editors ) that do all or the lion's share of the set of code editing
tasks/features that emacs has and does them in a friendlier way.
Emacs could to, but a large chunk of the emacs community is unwilling
to change. These folks tend to be very intelligent and they have a
stock of answers ready to tell someone why it is rational to not have
a file dialog as a default in a compile process or that it really is
smart to have the font changer in a mouse menu in the obvious place of
a shift - left click.
David Kastrup
> David Kastrup <David....@t-online.de> wrote in message
> > We just recently had a discussion of that sort in de.comp.editoren
> > where someone claimed that NEdit could do everything that Emacs could.
> > Whenever somebody came up with a particular feature of Emacs that he
> > found indispensible to his work, the NEdit proponent either claimed
> > that in theory it should be possible to make NEdit do something
> > similar,
>
> I mean no insult or sarcasm by this comment.........really, but that
> is ironic as that is one of the standard responses I get from emacs
> users who are doctrainaire emacs users. If I point out something
> another editor or ide has that emacs doesn't I am told I can extend or
> customize emacs all I want to.
Actually, the typical response is more like "does this do what you
want?" and a short Elisp snippet.
You can ridicule the religion behind barnraising all you like, but at
the end of the day, the barn is there. Beats talking about
skyscrapers.
David Kastrup
> True. There are also other very powerful editors out there that are
> really multipurpose IDEs out there. They can interface with compilers
> from all sorts of technologies, they have syntax/indentation packages
> for all sorts of technologies, they can be extended and they even
> interface with debuggers.
>
> Many of them are easier to learn, use and customize/exten then emacs.
>
> Maybe if every programmer fell off of the face of the Earth emacs
> would survive as a mail reader, news reader and/or a latex word
> processor.
>
> Many of the people I have known discover emacs because they are
> interested in a programming tool.......code editors with more features
> then a pico or a notepad.
>
> The other multipurpose IDEs aside, there are editors out there ( just
> editors ) that do all or the lion's share of the set of code editing
> tasks/features that emacs has and does them in a friendlier way.
>
> Emacs could to, but a large chunk of the emacs community is unwilling
> to change. These folks tend to be very intelligent and they have a
> stock of answers ready to tell someone why it is rational to not have
> a file dialog as a default in a compile process or that it really is
> smart to have the font changer in a mouse menu in the obvious place of
> a shift - left click.
Where are all these superior editors? According to you, the only
imaginable reason for Emacs predominance would be masochism.
Steve
> We just recently had a discussion of that sort in de.comp.editoren
> where someone claimed that NEdit could do everything that Emacs could.
> Whenever somebody came up with a particular feature of Emacs that he
> found indispensible to his work, the NEdit proponent either claimed
> that in theory it should be possible to make NEdit do something
> similar, or he declared that the particular feature was not required
> in an editor, or that he had never needed it himself, and so nobody
> else should ever have had the urge to use it.
I think the point of those discussions that keeps getting missed is
that emacs can be a pain in the ass to deal with, even for people who
have used it for a while, and that it doesn't have to be that way.
Jym Dyer
> missed is that emacs can be a pain in the ass to deal with,
> even for people who have used it for a while, and that it
> doesn't have to be that way.
=v= Well, that seems to be your own opinion, but I don't see
a whole bunch of people chiming in with agreement. I fired
up the Emacs tutorial at some point in 1979 and have used it
nearly every day since, and have *never* found it to be a pain
in the ass.
<_Jym_>
(Well, to be perfectly honest, I had some apprehension when I
got started with TECO macros, which took me a week or so to get
a handle on. That's not really germane to today's Emacs.)
J. Fischer
>
>That facility could be improved by converting it over to a full GUI
>tabbed dialong box with brief explanations ( no more then 1 line) next
>to each gui control for the option that would label the option in the
>mindset "what change you will see if you choose this".
>
>The help groups for emacs are filled with stories of people spending
>hours figuring out how to change a font, a color, a default frame size
>etc. Thats common and there is something wrong with that.
>
>Those are trivial tasks in other applications with GUI interfaces.
>
>Part of the trouble is that design descisions, selection of defaults
>etc etc favor the emacs expert leaving the burden of tweaking to the
>new person.
>
Well, the bigger part of the trouble is IMO that Emacs is designed as
text console editor w/o GUI. Notice that it necessarily has to,
because Unix has no graphics (you can use an external graphics system
like X, but this isn't part of Unix - this is different from Mac's or
Windows).
To quote a long-time Vim user here, the `GUI'-stuff added later on is
only for those poor folks that believe they need such things, where it
is clearly more efficient to use the keyboard.
This probably applies to Emacs, too. I think there will be seen no
need to improve things like user interface or ease of use. Emacs
advocates believe that Emacs is easy to use, has a well designed user
interface and lets you get your work done more efficiently than other
editors do.
--Jörg
David Kastrup
> David Kastrup wrote:
>
> >"J. Fischer" <jf...@yahoo.de> writes:
> >
> >
> >Please stop lying like a politician. The features discussed were all
> >features that arise when dealing with plain ASCII text.
> >
>
> There are always several different things that come up when
> dealing with plain ASCII text files. E.g. for creating a program you
> will need not only an editor but also a compiler and a debugger.
> Similiarily for the creation of scientific works with LaTeX you will
> need not only an editor but also a compiler and a previewer.
>
> Your argumentation was right from the start that Emacs is such a
> powerful editor because it can serve as a kind of previewer, too,
> while editing your text.
Adding WYSIWYG features is not really acting as "a kind of previewer"
since it has quite a different user interface. A previewer is
something working on pages of documents, preview-latex works on single
phrases and formulas, bits and pieces. This makes it as different
from a previewer in concept and access as an interpreter is from a
compiler. Even if an interpreter might internally use just-in-time
compilation.
Anyhow, this was only a single example out of dozens for
editing-related features. It is typical for your style of discussion
to pretend there was just a single counterexample to your claims.
David Kastrup
> This probably applies to Emacs, too. I think there will be seen no
> need to improve things like user interface or ease of use.
Please talk out of higher located orifices. The last major revisions
of Emacs were very much concerned with user interface improvements.
> Emacs advocates believe that Emacs is easy to use,
Nope, but the power/fuzz ratio is still pretty good.
> has a well designed user interface
Then why would they keep improving it? Or add things like
viper-mode, cua-mode and the like?
> and lets you get your work done more efficiently than other editors
> do.
And you can bet your sweet mother about that one. Learning Emacs may
not be an optimally streamlined experience, but boy, does it pay off.
Lars Magne Ingebrigtsen
> We just recently had a discussion of that sort in de.comp.editoren
> where someone claimed that NEdit could do everything that Emacs could.
> Whenever somebody came up with a particular feature of Emacs that he
> found indispensible to his work, the NEdit proponent either claimed
> that in theory it should be possible to make NEdit do something
> similar, or he declared that the particular feature was not required
> in an editor, or that he had never needed it himself, and so nobody
> else should ever have had the urge to use it.
While there are fanatics out there that claim that other, lesser
editors are just as good as The One True Editor, we just have to
remind ourselves of one single, simple fact: They are wrong and we
are right.
Don't pander to these fanatics. Emacs is The One True Editor!
--
(domestic pets only, the antidote for overdose, milk.)
la...@gnus.org * Lars Magne Ingebrigtsen
Glyn Millington
> Please talk out of higher located orifices.
It might help to be more specific about this - no need for slimy
excretions on a religious newgroup!
Glyn
Dave Pearson
> I think the point of those discussions that keeps getting missed is that
> emacs can be a pain in the ass to deal with, even for people who have used
> it for a while, and that it doesn't have to be that way.
What am I missing then? I first fired up emacs, on OS/2, in 1994 or 1995
(can't remember when now) and have been using it on various platforms ever
since. Out of all the editing and development environments I've used, and
I've used quite a few, I've found it to be the least "pain in the ass" to
deal with.
Seriously, what could I change in emacs that would make life with emacs less
of a pain in the rear end?
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
Steve
> > I think the point of those discussions that keeps getting
> > missed is that emacs can be a pain in the ass to deal with,
> > even for people who have used it for a while, and that it
> > doesn't have to be that way.
>
> =v= Well, that seems to be your own opinion, but I don't see
> a whole bunch of people chiming in with agreement.
Maybe not in this particular iteration of this time warn debate.
However, other people in this conversation have made references to
other iterations of this debate where people were trying to make the
point above with comparing emacs to other editors.
If you are an emacs user like I am who reads emacs and editor forums
you have seen arguments about this issue.
If not, google provides.
J. Fischer
>
>Don't pander to these fanatics. Emacs is The One True Editor!
>
Doesn't sound fanatic this, does it :-)
Jym Dyer
> is designed as text console editor w/o GUI.
=v= Why is this a problem? GUIs wreck people's wrists. The
basic functionality of GUI controls are already in Emacs, work
without needing a mouse, work *better* than GUI controls right
out of the box, and are customizable to work however you want
them to be.
<_Jym_>
Jym Dyer
> Doesn't sound fanatic this, does it :-)
=v= As it is pro-Emacs, no, it doesn't. Only infidels who
use the False Editors are fanatics. We are simply enlightened.
<_Jym_>
David Kastrup
With all due reference, the keybindings of Emacs (most important
operations are spread over (C-b C-n C-p C-f) are much more designed
for wrecking wrists than those of vi ( h j k l ).
Steve
> Where are all these superior editors? According to you, the only
> imaginable reason for Emacs predominance would be masochism.
I didn't say that, you wrote it.
If you are interested in looking at how other editors accomplish
similar tasks in emacs I invite you to take a look at google.
As I wrote previously I will not mention specific editors, because I
have been in similar conversations before and I have learned my
lessons from them.
Mentioning specific editors usually turns into a rhetorical gift for
emacsen who are unwilling to open their minds. Any feature no matter
how small, that emacs has and is not found in the "other editor" is
louldy echoed and used as justification for dismissing the issue that
emacs' interface can be improved.
Steve
Steve
I disagree. I mean no personal offense, but the statement above
reflects a lack of knowledge about GUI design and exploitation of that
design.
Yes, it is faster to hit a well remembered key binding then it is to
go all the way up to a drop down menu and scroll around looking for
it.
However, that is not what drop down menus are used for.
Drop down menus are mneomic and display devices for seldom used
commands. They relieve the user of having to remember these commands.
For the seldom instance when they want them the user can scroll
through the well laid drop down system to find and execute that
command.........often faster then searching for a key binding or a
"how to" in a help system.
Context ( mouse menus ) are for frequently used commands.
The mouse is down there with you, in your code, by your hand where you
can bring up the option you want fast, faster then you can with a key
stroke without the burden of memorizing/knowing a key binding. At
most two clicks and a subtle motion that is far easier on your tendons
then many keybinded commands used frequently.
Steve
Steve
> Well, the bigger part of the trouble is IMO that Emacs is designed as
> text console editor w/o GUI.
Yes. Exactly.
The GUI Gnu Emacs 21 is a great example of a GUI designed for and by a
CLI users.
1. You have to have hold a modifier key down to even see a context
menu.
2. mouse-3 ( right click ) instead of having a context menu is used
to
place a mark so it can be cut with later mouse clicks
3. c-mouse ( holding ctrl plus right clicking ) instead of having
edting
commands on the context menus has the mode menu on them which is
often
populated with commands you aren't going to be used as often.
The whole point of a mouse is anathema to 1-3.
1. A mouse is supposed to avoid/reduce the need to move another hand
to the
keyboard.
2. A mouse negates the thinking behind #2( setting marks, regions).
The
point of the mouse is that you just drag it to select/isolate a
region.
3. A mouse is used to bring frequently used commands down to you via
context
menu so you do not have to go up to the menu and that you can fire
these
commands off quickly, easily by having a menu by your hand with you
down
in the code. Many of the mode menus don't have such commands as
compared
to cut, copy, paste and other editing commands.
> Notice that it necessarily has to,
> because Unix has no graphics (you can use an external graphics system
> like X, but this isn't part of Unix - this is different from Mac's or
> Windows).
I think the CLI interface to emacs is excellent.
One thing that hasn't gotten through to a lot of old school unix
people is that the same rules that are smart in a pure shell
environment aren't always smart translated into X/GUI environmemnts.
Its a different ballgame.
Martin Thornquist
> Drop down menus are mneomic and display devices for seldom used
> commands. They relieve the user of having to remember these commands.
> For the seldom instance when they want them the user can scroll
> through the well laid drop down system to find and execute that
> command.........often faster then searching for a key binding or a
> "how to" in a help system.
And your point being? I've infrequently used the Emacs menus when
working with a mode I didn't know, and have always found what I was
looking for, as far as I remember.
> The mouse is down there with you, in your code, by your hand where you
> can bring up the option you want fast, faster then you can with a key
> stroke without the burden of memorizing/knowing a key binding. At
> most two clicks and a subtle motion that is far easier on your tendons
> then many keybinded commands used frequently.
I vigorously disagree. Just moving the hand from the keyboard to the
mouse and back takes far more time than to punch a key binding, and
using the mouse arguably makes the worst strain on the arms. That's
why I've seriously customized my FVWM to the point where I really only
use mouse for browsing, a very few GUI apps, and the occasional game.
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
Kai Großjohann
> 1. You have to have hold a modifier key down to even see a context
> menu.
I agree that this might appear unfortunate. However, it was
discussed amongst the Emacs community, and the overall opinion was
that mouse-3 should not invoke a context menu.
Maybe it would be a good idea to have a user option which provides
both. I will suggest it to the Emacs developers.
> 2. mouse-3 ( right click ) instead of having a context menu is used
> to place a mark so it can be cut with later mouse clicks
Note that mouse-3 once already copies the region. Hitting mouse-3 a
second time then kills it. In both cases, the region can be pasted
somewhere else with mouse-2.
> 3. c-mouse ( holding ctrl plus right clicking ) instead of having
> edting commands on the context menus has the mode menu on them which
> is often populated with commands you aren't going to be used as
> often.
Hm. Indeed. If `cut' was on the context menu, the regular mouse-3
wouldn't be needed anymore.
Can you suggest other things (besides `cut') which could be on the
context menu?
My idea is to suggest two new features. The first feature is to
allow the users to say that the context menu should be on mouse-3.
The second feature is to add more items to the context menu (and
maybe to remove some).
> 1. A mouse is supposed to avoid/reduce the need to move another hand
> to the keyboard.
Ah, yes. And if you require a modifier for the context menu, you do
need a hand on the kbd. I understand.
> 2. A mouse negates the thinking behind #2( setting marks, regions).
> The point of the mouse is that you just drag it to select/isolate a
> region.
Well, Emacs offers both. Dragging also selects a region.
> 3. A mouse is used to bring frequently used commands down to you via
> context menu so you do not have to go up to the menu and that you
> can fire these commands off quickly, easily by having a menu by your
> hand with you down in the code. Many of the mode menus don't have
> such commands as compared to cut, copy, paste and other editing
> commands.
Right. It is a really good idea to have a better context menu. As
an example, I tried C-down-mouse-3 on an article in a Gnus summary
buffer, and the resulting menu appeared to be quite useless.
But there are many modes in Emacs. So it is a big job to correct all
the menus. Don't expect it to be done soon.
Can you suggest another program (editor) which has nice context menus?
And what to do to see the niceties there? (Maybe the context menu is
more interesting in certain circumstances than in others.)
kai
--
A large number of young women don't trust men with beards. (BFBS Radio)
David Kastrup
> steves...@yahoo.com (Steve) writes:
>
> > 1. You have to have hold a modifier key down to even see a context
> > menu.
>
> I agree that this might appear unfortunate. However, it was
> discussed amongst the Emacs community, and the overall opinion was
> that mouse-3 should not invoke a context menu.
>
> Maybe it would be a good idea to have a user option which provides
> both. I will suggest it to the Emacs developers.
Why make it an option?
> > 2. mouse-3 ( right click ) instead of having a context menu is used
> > to place a mark so it can be cut with later mouse clicks
>
> Note that mouse-3 once already copies the region. Hitting mouse-3 a
> second time then kills it. In both cases, the region can be pasted
> somewhere else with mouse-2.
Note that mouse-3's current functionalty currently only uses "click".
When you select something from a context menu, you do it by dragging.
So the obvious solution would be to have the old functionality when
you click without moving, but if you drag down, you get a context
menu.
Steve
> steves...@yahoo.com (Steve) writes:
>
> > 1. You have to have hold a modifier key down to even see a context
> > menu.
>
> I agree that this might appear unfortunate. However, it was
> discussed amongst the Emacs community, and the overall opinion was
> that mouse-3 should not invoke a context menu.
>
> Maybe it would be a good idea to have a user option which provides
> both. I will suggest it to the Emacs developers.
I've been working on my own mouse customization, but I am doing this
at the same time as I am learning lisp so it might be a few more weeks
:)
> Can you suggest other things (besides `cut') which could be on the
> context menu?
The customization I am working on has a context menu that includes:
- basic text editing ( cut, copy, paste ) commands as choices
- "mode menu", a choice that expands to whatever mode specific context
menu
would have been there before the modification
- many of the "region" operations ( comment in/out, narrow in/out,
upcase,
downcase, etc....things for manipulating text in a general sense
- "rectangle" menu - expands to another context menu holding
- cut,copy, delete rectangle
- insert string ( string-insert-rectangle )
- fill w/ string ( string-rectangle )
- open rectangle
- "start rectangluar drag"
The last one is to be determined. Ideally I would like mouse-1 to be
normal
selection and mouse-3( mouse-down or mouse-drag events ) to
automatically start rectangular selection ( using Kim Storm's good
rectangle functions). I would like the user to be able to make such a
rectangle selection, move the mouse away from it, have it stay put,
and have the user fire off the context menu with a "mouse click" event
( down and up ) on mouse-3.
>
> My idea is to suggest two new features. The first feature is to
> allow the users to say that the context menu should be on mouse-3.
> The second feature is to add more items to the context menu (and
> maybe to remove some).
Thats smart. Its impossible to please eveyone. If I am not whining
someone else will be. The way out is to make customization easy (
point and click) so people can do what they want without without
bothering anyone else.
> But there are many modes in Emacs. So it is a big job to correct all
> the menus. Don't expect it to be done soon.
I understand that all to well from working on my own little hard coded
mouse customization :)
>
> Can you suggest another program (editor) which has nice context menus?
> And what to do to see the niceties there? (Maybe the context menu is
> more interesting in certain circumstances than in others.)
I could name a few, but the one that would be the best would be visual
slickedit
http://slickedit.com/purchase/pu_regtrial.php
Its a proprietary and expensive editor, but they do a lot of
innovative things with laying out emacs style power features to the
user.
You can get a free demo copy that lasts 30 days for ms windows or
forever for linux ( saving files is disabled ).
They have nice context menus:
- mouse-1 ( left mouse button ) does normal selection ( by rows )
- double clicking mouse-1 selects the word
- triple clicking mouse-1 selects the line
- mouse-2 ( middle button ) just pastes whatever was selected last
mouse-3 is where the interesting stuff is
- it toggles between 2 context menus.
You get a simple menu with the basic
editing commands ( cut,copy,past, shift selection right/left,
inserts)
if you have text selected while clicking ( mouse down and mouse up )
mouse-3.
If you click mouse-3 ( mouse down and mouse up) without anything
selected you get a much larger menu that includes:
- some mode specific commands
- options for going to a variables/functions definition or
reference
- various search operations
- spell checks
What is the most powerful feature is that both of the mouse-3
context menus
have an option at the bottom called "edit this menu". If you click
it
you get a dialog box with a scrollable list of commands, including
user
defined macros that you can point/click to have put on or removed
from
the mouse menu.
Its a good editor to look at. It has many emacs style power
features,
but they are innovative with laying them out in a very accessible
way.
( Craig Finniseth's site claims it started out as emacs, but it is
written in C and extended with Slick-C, their homegrown version
of C)
Thanks for listening. I feel like a bit of an ass now for whining
so loud.
Take it as love of emacs. I get frustrated when people turn away
from
emacs because of learning curve and UI issues.
STeve
Kai Großjohann
> Note that mouse-3's current functionalty currently only uses "click".
> When you select something from a context menu, you do it by dragging.
> So the obvious solution would be to have the old functionality when
> you click without moving, but if you drag down, you get a context
> menu.
I don't think that this is a good idea. All the other menus you can
use two ways: either you press the button (menu appears), move the
mouse, release the button (menu disappears). Or you click the button
(menu appears), move the mouse, click the button again (menu
disappears).
Your suggestion means that only one way works to invoke that menu.
David Kastrup
> David Kastrup <David....@t-online.de> writes:
>
> > Note that mouse-3's current functionalty currently only uses "click".
> > When you select something from a context menu, you do it by dragging.
> > So the obvious solution would be to have the old functionality when
> > you click without moving, but if you drag down, you get a context
> > menu.
>
> I don't think that this is a good idea. All the other menus you can
> use two ways: either you press the button (menu appears), move the
> mouse, release the button (menu disappears). Or you click the button
> (menu appears), move the mouse, click the button again (menu
> disappears).
>
> Your suggestion means that only one way works to invoke that menu.
So you would prefer it that no way (without additional keys) works to
invoke the menu?
Luis Fernandes
dk> Luis Fernandes <e...@ee.ryerson.ca> writes:
>> But no one uses ed for software development.
dk> I have to admit to just recently having made some trivial
dk> changes to some config file with ed,
What is the output of "echo $EDITOR" or "echo $VISUAL" in your shell,
please?
David Kastrup
Usually
gnuclient -p [ 21490+uid ]
The port number is explicitly specified so that editing calls from an
su command can still find the right Emacs to contact.
Kai Großjohann
> So you would prefer it that no way (without additional keys) works to
> invoke the menu?
My suggestion was to make a user option allowing to choose between
two behaviors:
(1) mouse-3 does what it does now, C-down-mouse-3 invokes context menu
(2) down-mouse-3 invokes context menu
My assumption was that the new context menu includes everything the
old menu had, perhaps in a submenu.
So if people choose (1), they lose nothing. If they choose (2), they
lose the copy/cut with clicks. But that can be done with mouse-1, too.
David Kastrup
> David Kastrup <David....@t-online.de> writes:
>
> > So you would prefer it that no way (without additional keys) works to
> > invoke the menu?
>
> My suggestion was to make a user option allowing to choose between
> two behaviors:
>
> (1) mouse-3 does what it does now, C-down-mouse-3 invokes context menu
>
> (2) down-mouse-3 invokes context menu
>
> My assumption was that the new context menu includes everything the
> old menu had, perhaps in a submenu.
>
> So if people choose (1), they lose nothing. If they choose (2), they
> lose the copy/cut with clicks. But that can be done with mouse-1, too.
How do you cut with mouse-1? How do you selection a second region
end point with mouse-1?
Why is your suggestion of only getting a context menu without
modifiers when completely sacrificing copy/cut functionality
preferable to being able to have both context menu and copy/cut?
Jym Dyer
> a lack of knowledge about GUI design and exploitation of that
> design.
=v= Hello? I use GUIs all the time; just about everyone does
these days. I daresay I've pretty much figured out how they
work, what's a good design, what isn't, etc.
> Drop down menus are [mnemonic] and display devices for seldom
> used commands. They relieve the user of having to remember
> these commands.
=v= Well, actually "File" and "Edit" tend to be frequently-used
commands, but otherwise, yeah, sure, of course. The menu bar
on Emacs works exactly the same way, though, plus with Emacs you
also have command-completion, a low-bandwidth and wrist-friendly
way to do exactly the same thing.
> The mouse is down there with you, in your code, ...
=v= Maybe. You might've clicked elsewhere. You might've moved
the cursor out of the way so you can actually see the code. And
you generally need to move the mouse cursor to just exactly the
right spot in the code to get the click to figure out the right
context, of course.
> ... by your hand where you can bring up the option you want
> fast, faster then you can with a key stroke without the burden
> of memorizing/knowing a key binding. At most two clicks and
> a subtle motion that is far easier on your tendons then many
> keybinded commands used frequently.
=v= "At most two clicks and a subtle motion" repeated a few
hundred times a day, in addition to aforementioned positioning
movements. This is exactly why RSI cases have skyrocketed, in
direct proportion to the adoption of GUIs.
=v= Given that, given the worldwide epidemic of damaged wrists,
fingers, arms, and shoulders, I'd say you vastly exaggerate the
"burden" of memorizing key bindings. Especially with ^H-m handy
to assist the memory.
=v= Of course, it also helps quite a bit that the keybindings
follow some sort of mnemonic. After GUIs wreck their wrists,
a lot of people learn the keyboard shortcuts (the fact that
they're called "shortcuts" ought to be clue-by-four here).
You learn that Shift-Insert will paste and Ctrl-Insert will
copy (gosh, *that* makes a whole lot of sense), or you can try
the ^X/^Y/^Z thing.
<_Jym_>
Steve
> > I mean no personal offense, but the statement above reflects
> > a lack of knowledge about GUI design and exploitation of that
> > design.
>
> =v= Hello? I use GUIs all the time; just about everyone does
> these days. I daresay I've pretty much figured out how they
> work, what's a good design, what isn't, etc.
No offense, maybe this does not apply to you personally, but there is
a difference between knowing enough to being able to use a thing and
knowing enough to use that thing is such a way as to take full
advantage of the underlying concept/design.
I can use a gun as a weapon by pistol whipping my enemies, but I am
not taking advantage of the design and concept of a gun as a weapon
unless I shoot the thing.
> =v= Maybe. You might've clicked elsewhere. You might've moved
> the cursor out of the way so you can actually see the code. And
> you generally need to move the mouse cursor to just exactly the
> right spot in the code to get the click to figure out the right
> context, of course.
How is that any different from needing to set a mark and make a region
to operate on a bit of text?
IMHO, its quicker, easier, and fewer steps to simply drag a mouse.
> =v= "At most two clicks and a subtle motion" repeated a few
> hundred times a day, in addition to aforementioned positioning
> movements. This is exactly why RSI cases have skyrocketed, in
> direct proportion to the adoption of GUIs.
I don't believe this to be true. All the literature I have ever seen
about carpal tunnel syndrome has focused on keyboard use and the
ergonomics of wrist placement to use the keyboard extensively without
trashing your tendons.
I tend to believe keyboards are *the* hazarad, as my wrists hurt if I
spend a few days developing in a CLI app.
I could be wrong about this.
If you have hyperlinks to several well designed studies by reputable
authorities ( NIH etc ) please share them.
BTW, what is "=v=" all about?
Steve
Steve
> How do you cut with mouse-1? How do you selection a second region
> end point with mouse-1?
You don't. You do normal selection ( by rows ) with mouse-1 ( left
mouse button), then you click mouse-3 ( right mouse button), get a
context menu with "Cut" at the top ( followed by paste, delete ), and
then you cut.
Most KDE/CUA style guis work like this. That doesn't make it the best,
necessarily, but it is what people expect.
I know that sounds awful, but conventions have utility.
I worked my way through college in a busy nightschool computer lab
that supported pure cli unix, vms, dos, and a little windows 3.1. The
applications ranged from simple desktop apps, to hardcore engineering
and programming apps.
I had to help people with at all.
It was a challenge for a lot of people to simply start and quit apps
they didn't know. You had to know the magic incantation even to quit
the app or save a file. Every app did it differently.
After the lab converted to windows ( and many apps with it ) people
could at least open an app ( clicking an icon or a menu choice ),
open a file, save a file, and even do some rudimentry editing without
even knowing anything about the application.
GUIs could have been done in a lot of ways, but the fact that having
drop downs and drop downs with "File, edit, ....tools, ....Help.. etc"
as a convention made apps that followed that convention much easier to
use.
The mouse config I suggested above takes advantage of those existing
conventions.
Believe it or not, I actually witnessed several people in my office
click on mouse-3 in gnu emacs 21 and quickly (prematurely ) conclude
that emacs did not have context menu support. One guy was a 15 year
cli emacs veteran who programs in common lisp......he wasn't a fool or
a short attenion spanned windows user.
> Why is your suggestion of only getting a context menu without
> modifiers when completely sacrificing copy/cut functionality
> preferable to being able to have both context menu and copy/cut?
I don't think anything is being sacraficed.
There is my answer to your question above.
The current mouse-3 config takes away from one of the points of having
a mouse.
You don't have to set marks, points, and regions with a mouse. You
just drag the thing. That is what mice were made for.
If enough people really like being able to exchange the point and mark
with a mouse click that feature could be moved to S-mouse-3. Better
yet, it could be one of the choices on the mouse-3 context menu,
"Exchange point & mark", or it can be invoked with a double click
event.
The current set up only lets you do one thing with mouse-3.
One of these alternatives could let you do several other things with
mouse-3 without dragging the keyboard into it.
As previously mentioned, most people used to GUIs expect.......and are
accustomed to having a context menu at mouse-1.
To me that is enough. Excanging the point and mark with a mouse is an
innovation.......but enough of one to go against a very established
convention that users expect and a convention that offers much more
utility in return.
Thats my opinion.
Other people may prefer other things.
I think the best soloution would be to use the defacto GUI conventions
as a default, but give people options to easily customize tthe mouse
and the drop down menus.
Steve
Good idea for starting a new thread.
If I had to make the single most important point about GUI desigin,
IMHO, it would be that what worked best for CLI design may not work
best for GUI design.
Raffael Herzog
Steve wrote:
> IMHO, its quicker, easier, and fewer steps to simply drag a mouse.
I don't agree. When using the mouse, I have to see where it
is. And it's certainly not where I expect it to be, because
I certainly moved it out of the way at some point (OK, now I
made Win-Key-Home putting my cursor in the lower right cor-
ner of the screen, so since I did this, it's most probably
there).
Using the keyboard, I don't have to see where the cursor is.
I just *know* it. This allows me to work faster than I can
see. Furthermore, the mouse can only be moved. This is like
moving a text cursor with only the cursor keys... how
inefficient! ;-)
An example: I want to move the cursor three paragraphs up.
With the mouse, I have to show the computer where this pa-
ragraph starts. With the keyboard I just tell my computer
"go three paragraphs up" and it then shows me, where it is.
Don't get me wrong, I like the mouse and I often use it, but
not, if I'm writing code (or anything else), which is what I
do about 75% of the time I spend on the computer.
> I don't believe this to be true. All the literature I have ever seen
> about carpal tunnel syndrome has focused on keyboard use and the
> ergonomics of wrist placement to use the keyboard extensively without
> trashing your tendons.
Well, I experienced it. Then I started to use a trackball,
now it's OK. (Oh, I use a "<censored> Natural Keyboard", of
course)
cu,
Raffi
--
=> Neu im Usenet? Fragen? http://www.use-net.ch/usenet_intro_de.html <=
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.
Raffael Herzog - her...@raffael.ch - http://www.raffael.ch - ICQ #67961355
Galen Boyer
> IMHO, its quicker, easier, and fewer steps to simply drag a mouse.
One of the few times I like the mouse over the keyboard is when I need
to highlight an arbitrary piece of text. Somewhere in the middle of,
say a sentence to somewhere in the middle of some other sentence.
Getting to an arbitrary area seems easier to point there. Other than
that, I am already doing everything with the keyboard so any small
efficiency that might be had from using the mouse is overshadowed by
having to move my hand to the mouse.
Plus, the mouse is quite less efficient in number of steps that one
would have to perform to get the amount of power you have in the
keyboard.
When I'm doing anything in Emacs, I'm constantly hitting C-l. I could
probably bind some mouse stroke to that, but then I just limited what
other things I could do with the mouse. So, my next option would be to
have some menu structure come up that had the function (recenter)
available by mouse. I maybe could have it somewhere in the top level
menu, but I might even have to drill to a submenu if I was going to
allow for all the things I might want to do while mousing my way around
Emacs. By the time I finally got the menu to recenter what I was
reading, I would have lost my concentration on what I was reading. With
C-l, it is completely habit and I don't consciously have to tell myself
to do it. It just happens. Same sort of thing with C-v. I can sort of
get that with using the scrollbars, but then I have to take my mind off
of what I'm doing and actually watch the mouse.
I guess thats the main drawback with the mouse. You have the added
distraction of needing to watch the pointer.
--
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.
Kai Großjohann
> How do you cut with mouse-1?
You can use the context menu from down-mouse-3. And then, there's
mouse-sel.el which allows you to hold down mouse-1 and simultaneously
click mouse-3. I wonder if it possible to keep that functionality.
> How do you selection a second region end point with mouse-1?
Other programs don't have this, either. But it's one additional
thing that you lose that I forgot. Sorry.
> Why is your suggestion of only getting a context menu without
> modifiers when completely sacrificing copy/cut functionality
> preferable to being able to have both context menu and copy/cut?
Well, it's a trade-off. Either make the context menu more obscure
and provide useful mouse-3 functionality, or make the context menu
normal but lose some mouse-3 functionality.
It's all a user option anyway...
Kai Großjohann
> When I'm doing anything in Emacs, I'm constantly hitting C-l.
I'm similar (but not the same). I use mouse-drag.el. It's really
nifty. You don't lose any mouse functionality, but you gain
something.
Of course, mouse-drag.el is not the same as C-l, but then C-l is not
the mouse way.
People with wheel mice will probably use those...
Steve
> One of the few times I like the mouse over the keyboard is when I need
> to highlight an arbitrary piece of text. Somewhere in the middle of,
> say a sentence to somewhere in the middle of some other sentence.
> Getting to an arbitrary area seems easier to point there.
Thats one of the things I like as well. I can just drop down
anywwhere I want.
> When I'm doing anything in Emacs, I'm constantly hitting C-l. I could
> probably bind some mouse stroke to that, but then I just limited what
> other things I could do with the mouse.
I see you point. I would use a keystroke for something like that as
well.
Most of my mouse use during coding is to select large chunks of text,
white space, or comobos of both to do a lot of region, rectangle
editing. T
Steve
> > IMHO, its quicker, easier, and fewer steps to simply drag a mouse.
> I don't agree. When using the mouse, I have to see where it
> is. And it's certainly not where I expect it to be, because
> I certainly moved it out of the way at some point (OK, now I
> made Win-Key-Home putting my cursor in the lower right cor-
> ner of the screen, so since I did this, it's most probably
> there).
Thats an interesting statement. I have read several people write it.
I have never had that problem. I have never needed to move the mouse
out of the way. I have never been conscious of needing to find it
either. I just grab it without thinking and plop it down where I need
it.
Differnt styles of editing I guess.
>
> > I don't believe this to be true. All the literature I have ever seen
> > about carpal tunnel syndrome has focused on keyboard use and the
> > ergonomics of wrist placement to use the keyboard extensively without
> > trashing your tendons.
>
> Well, I experienced it. Then I started to use a trackball,
> now it's OK. (Oh, I use a "<censored> Natural Keyboard", of
> course)
Me too :). Relax, somehow I think it is one of those things they
bought from someone else :)
Per Abrahamsen
> That facility could be improved by converting it over to a full GUI
> tabbed dialong box with brief explanations ( no more then 1 line) next
> to each gui control for the option that would label the option in the
> mindset "what change you will see if you choose this".
That would be customize-browse. However, that does not change the
fact that Emacs has a awesome number of options, and finding the right
one will be hard. The "top-10" most popular customizations are easily
available from the options menu, but there need to be an intermediate
level between that menu, and customize browse.
Part of the problem is that Emacs is everything to all people, so it
is difficult to find the "typical" user. What we really need isn't
fancy GUI buttons (it is a sad thing that so many people believe good
user interfaces are a question of selecting eye-candy widgets), but
volunteers who will write task oriented tutorials with inline
customize controls.
Per Abrahamsen
> To quote a long-time Vim user here, the `GUI'-stuff added later on is
> only for those poor folks that believe they need such things, where it
> is clearly more efficient to use the keyboard.
Actually, Emacs has the most efficient mouse based cut&paste of any
editor I have used. This makes it harder to learn (since it _is_
unlike any other application, except xterm), but easier to use. This
is a common problem, how do we optimize easy-of-use
vs. ease-of-learning? Emacs here optimizes for the first. XEmacs for
the later, they have more conventional but less useful mouse bindings.
For menus and tool bars, you may be right. Appart from the top level
menu bar which is rather conventionel, the menu bar entries for
subsystems tend to be designed for completenes. That is certainly the
case for Gnus. I suspect Emacs developers think of the menu bar as a
quick reference for the keybindings. I certainly do.
In some cases Emacs will use dialogs instead of the minibuffer if you
use menu commands. Dialogs are easy-to-learn but very hard-to-use.
Ask anyone who works profesionally with HCI issues. So this also
indicates that the Emacs menu bars are not designed to be used, but
only as a teaching tool.
The tool bars in Emacs seem totally useless to me, hence I disables
it. However, that is true for the tool bars for all other
applications I have used. Again, I suspect that like me, other Emacs
developers haven't really got the idea behind a tool bar yet.
> This probably applies to Emacs, too. I think there will be seen no
> need to improve things like user interface or ease of use.
Weird, given the huge changes there have been between Emacs 17
(termcap), 18 (primitive X11), 19 (real X11), 20 (customize) and 21
(sound and graphics, tool bars, reworked menu bar).
> Emacs advocates believe that Emacs is easy to use, has a well
> designed user interface and lets you get your work done more
> efficiently than other editors do.
We know that, however we also know it can be better.
Per Abrahamsen
> While there are fanatics out there that claim that other, lesser
> editors are just as good as The One True Editor, we just have to
> remind ourselves of one single, simple fact: They are wrong and we
> are right.
>
> Don't pander to these fanatics. Emacs is The One True Editor!
Finally a voice of reason!
Thank you, Lars, for always being calm, level-headed, rational and
unbiased in these issues.
It is wrong to try to play into the wild fantasies of people who would
claim that the Earth is flat, that a descendent of vi can be a text
editor, or that any application is a competitor to The One at any
level. These people need our concern, our pity, as well as stronger
medication. Not theoretical discussions of the very axioms that
defines the world.
Per Abrahamsen
> Lars Magne Ingebrigtsen wrote:
>
>>
>>Don't pander to these fanatics. Emacs is The One True Editor!
>>
>
> Doesn't sound fanatic this, does it :-)
Of course not. Stating an obvious truth can at most be said to be
redundant, never fanatical.
Kai Großjohann
> I have never needed to move the mouse out of the way.
Since I started to use unclutter, I didn't have to do that, either.
But without unclutter, it's really awful: if you use the mouse to do
something, the mouse pointer will be near the cursor, and that's just
where you look. I don't like the mouse pointer obscuring some
character that I want to look at.
Jym Dyer
> to use a thing and knowing enough to use that thing [in] such a
> way as to take full advantage of the underlying concept/design.
=v= One of the reputed benefits of GUIs is for the naïve user to
be able to easily grasp the underlying concept/design. I don't
think I've personally failed to grasp it. My main issue with
GUIs is that they often require repetitious actions with no way
to automate them, which is kind of the whole point of using a
computer. Some allow you to automate tasks, though the means of
doing so is rarely consistent from application to application.
>> you generally need to move the mouse cursor to just exactly
>> the right spot in the code to get the click to figure out the
>> right context, of course.
> How is that any different from needing to set a mark and make
> a region to operate on a bit of text?
=v= Detail work. Some of the hardest work with a mouse is to
get the cursor to exactly the right place. With Emacs, I could
use the mouse to get somewhere nearby (if I need to) and use
arrow keys or the appropriate commands (helped greatly by the
context-aware nature of Emacs) to get exactly where I want to.
> IMHO, its quicker, easier, and fewer steps to simply drag a
> mouse.
=v= The dragging operation is the one that hurts wrists the
most. With Emacs I can set a mark and then move the mouse, or
not, or use arrow keys, or the context-aware commands, etc.,
whatever combination works best for me at a given time. I can
move over to another buffer or frame or application without
losing the context and having to do the operations all over
again. Also, I can do multiple selects (the kill buffer)
without some monstrous extraneouw application firing up and
only working for certain applications.
>> [The need for hundreds of mouse movements] is exactly why
>> RSI cases have skyrocketed, in direct proportion to the
>> adoption of GUIs.
> If you have hyperlinks to several well designed studies by
> reputable authorities ( NIH etc ) please share them.
http://www.google.com/search?q=RSI+mouse
<_Jym_>
Jym Dyer
> design may not work best for GUI design.
=v= That may be an important point, but I wouldn't ever call
Emacs an example of "CLI design."
<_Jym_>
Galen Boyer
> Galen Boyer <galen...@hotpop.com> writes:
>
>> When I'm doing anything in Emacs, I'm constantly hitting C-l.
>
> I'm similar (but not the same). I use mouse-drag.el. It's really
> nifty. You don't lose any mouse functionality, but you gain
> something.
Yeah, I've got that enabled, I haven't found it useful enough to hang
out with just the mouse though.
Maybe someone's working on some Emacs minibuffer keyboard that has
completion (driven by mouse clicks) that let you point and click your
way to words, sentences quickly? :-)
> Of course, mouse-drag.el is not the same as C-l, but then C-l is not
> the mouse way.
Yeppers. I probably haven't just spent enough time with the mouse to
find out how I could do what I already do on the keyboard with the
mouse. I do know what I use it for. When I use it I'm always impressed
with how much more powerful I find the Emacs mouse functionality than the
windows mouse functionality but it still doesn't make me use it all that
often.
> People with wheel mice will probably use those...
Does anybody have a nice setup where they use speedbar and maybe ecb
with a wheelmouse?
Thien-Thi Nguyen
> The question is not what an editor could do once you extend it with some
> self-written stuff in its respective extension language.
the question is what limits users self-impose when open to the universe that
is emacs. the answers are, of course, individual. when people say "it cannot
be done" it is like saying "i have not yet tried" (to find out if someone else
has done it ;-).
thi
Thien-Thi Nguyen
> These people need our concern, our pity, as well as stronger medication.
sleep dep works, too.
M-x nodoze!
thi
Nix
> Such as? I know of no editor even approaching the power, extent and
> flexibility of Emacs.
The EPM editor for OS/2 (and some mainframe OSes?) tried to do the Emacs
trick, with a programming language and so on; but the language and
pritimives weren't flexible enough (and was also nasty; a variant of
REXX) so most of the editor was not written in it.
But it was the editor I jumped to Emacs (19.34, at the time) from.
> And there are very few around that have the
> keyboard efficiency and "lean and mean" aspect of basic vi that
> manages to make wagonloads from its basic command set.
Agreed.
--
`There's something satisfying about killing JWZ over and over again.'
-- 1i, personal communication
Nix
> Exactly. Perhaps I had better claimed that Jedit could do everything
> Emacs can do, because via Java plugins it actually could - it wouldn't
> however be a comparison of editors but of programming languages, i.e.
> Java vs. elisp, where many folks would prefer Java, I think.
Wouldn't you lose emacs's *runtime*-modification capability?
(Also, Java is a terribly clumsy language for this sort of thing.
Algol-style languages don't handle being loaded in pieces and redefined
arbitrarily very well at all. It pains me to say it, but even Visual
Basic would fit the job better.)
Nix
> In contrast Nedit provides a macro language as feature that allows
> _the_user_to_automate_editing_tasks_ - not more, not less.
So does Emacs, of course (but more ;} )
Bu it works as long as the `automation' is no more complex than
`repetition'. As soon as you get more complex, you start having to pile
cruft onto the language to handle it; keep going down that road and
you'd end up with a horrible deformed monster which might have
Turing-completeness but nobody could use it properly, and not even its
mother could love it, because it would have evolved like Perl did but
never had any intention of being a generalized programming language.
(You can't evolve programming languages, not really. You need a
*design*.)
By contrast, Emacs has the generalized language there already.
It is almost always a mistake, when adding a language to something,
to make it `as simple as necessary but no simpler', because your
spec will change and the language will be broken. Make it a full
programming language with customized hooks to the outside world
and all that can bitrot and get ugly is those hooks. (And I won't
say *that* hasn't happened to elisp!)
Nix
> "J. Fischer" <jf...@yahoo.de> writes:
>
>> This probably applies to Emacs, too. I think there will be seen no
>> need to improve things like user interface or ease of use.
>
> of Emacs were very much concerned with user interface improvements.
Yes, but I sort of see what he's driving at.
The part of the UI that experienced Emacs users *use* is, while not
purely textual, very simple and totally devoid of editing widgets.
(Now some of us who hate graphical clutter think that this is a huge
advantage... I note that the people who cry `make Emacs more graphical'
never think about, say, blind users... I wonder what percentage of the
Emacs userbase is blind, actually? Emacspeak should be a *huge* selling
point for it but nobody ever seems to mention it.
I mean, I've seen blind people try to use MS Word and it's a horrible
sight to behold. Emacspeak is a joy in comparison.)
>> has a well designed user interface
>
> Then why would they keep improving it? Or add things like
> viper-mode, cua-mode and the like?
viper-mode is very nice, but it's hardly a UI simplification: vi's user
interface is even worse than Emacs's. cua-mode *is* useful, I can see
that (even though I never use it and would prefer an emacs-mode for all
the other editors I use which aren't powerful enough for such).
But we really, really need a replacement for customize which
- gets fonts right (mainly an XEmacs thing I think; XEmacs fonts are
rather complicated and customize doesn't understand them properly)
- writes Lisp that a human could plausibly have written, so that
users can look in their custom-file to see how to do something in
Lisp that they just did with customize
- is less cluttered and disjointed (but this is hard to do because
the defcustom forms that write it really *are* disjointed)
>> and lets you get your work done more efficiently than other editors
>> do.
>
> And you can bet your sweet mother about that one. Learning Emacs may
> not be an optimally streamlined experience, but boy, does it pay off.
Agreed. The only downside is that the Law of Computer System Purchasing
(`The default configuation sucks') comes into play...
I mean, I've now got >100K of *customization*; you shouldn't really need
all that to make an editor usable. (But perhaps my definition of `usable'
is rather extreme.)
Barry Fishman
> But we really, really need a replacement for customize which
>
> - gets fonts right (mainly an XEmacs thing I think; XEmacs fonts are
> rather complicated and customize doesn't understand them properly)
>
> - writes Lisp that a human could plausibly have written, so that
> users can look in their custom-file to see how to do something in
> Lisp that they just did with customize
>
> - is less cluttered and disjointed (but this is hard to do because
> the defcustom forms that write it really *are* disjointed)
>
Amen.
> I mean, I've now got >100K of *customization*; you shouldn't really need
> all that to make an editor usable. (But perhaps my definition of `usable'
> is rather extreme.)
I've kept mine pruned to 6 lines, although I did write my own
color pallette code (about 13 lines including comments) to integrate
with customize's way of setting face attributes without having to
create the faces first. I would probably remove those 6 lines if I
felt like taking the time to track what they did through the Emacs
sources and be sure of what I could do in ELisp to replace them.
I tried several times to go the other way and use customize to do as
much as it could before resorting to my own lisp code, but always
ended giving up in frustration. Even if I could get past this first
pass of 'customization', I suspect the problems with adding my own
pieces would be far more difficult. Customize really creates the same
"wired" environment in Emacs, that I use Emacs to avoid.
Much of the attempts to change Emacs to make it easier to use by
point-and-grunters has had a negative effect on the more traditional
approach to doing things. Adding customize code often replaces the
few simple remarks usually given about how to set up the packages with
ELisp. Customize needs to have well defined ways of interoperating
with ones own ELisp code. Now it seems to make things more complex.
Even a dumb Windows or Java resource file would be as flexable as the
stuff customize produces and also be more readable. What is the
benefit if the code produced by Customize is to be assumed
untouchable?
I'm not unsympathetic to the difficulties new users face in learning
Emacs. But a good part of Emacs's benefits come from what you can do
with a little knowledge of ELisp. When an Emacs user now comes to
this point they are faced with a .emacs file filled with a large
amount of customize babble which they are warned not to touch. If
they have any sense of programming style, of course they will want to
change it! What a horrible introduction to ELisp.
In childhood development we find it important to ween babies from
their point-and-grunt stage and teach them simple sentences as soon as
possible. Literacy is something one does not postpone or put off,
unless you are trying to create a permanent under-class.
Customize seems to be a step toward building an Emacs under-class;
people who use Emacs but are continually having their lack of
knowledge of ELisp made evident.
There is nothing particularly difficult about ELisp, that someone who
is literate enough to want to use an editor can't learn. Learning a
language involves exposure to its proper use. This is not something
one gets when all the simple stuff has been replaced by customize
crap.
(Oops, this is *alt.religion.emacs*)
Of course ELisp could be taught in the schools, but this would bring
about protests from parents who see this is a conflict between church
and state. The people of the C++, Java, or even Dylan religions would
feel outrage. One can try to explain that ELisp is different, and
that Emacs embraces these other languages, and even supports their
practices better than editors written by their narrow minded
proponents.
Of course this would be in vain. If these people could just see Emacs
really is the one true way!
I have programmer friends who I can talk to freely about all things
except Lisp. They will argue or agree about abortion, gun rights,
belief in god, C++, Microsoft, whatever. But if I even mention Lisp
they just mumble something nasty under their breath and refuse to
discuss it. And they haven't even heard of 'comp.lang.lisp'!
> `There's something satisfying about killing JWZ over and over again.'
> -- 1i, personal communication
Lets not dwell on it!
Nix
> I fired
> up the Emacs tutorial at some point in 1979
I read this sort of thing and realise how *long* Emacs has been going
for... I'm not actually sure whether it's older than I am or not, but it
must be close to it. I only met Emacs in 1995 and only started to *use*
it in '97... but I've been hooked and a total (X)Emacsophile ever since.
Does anyone know exactly when in 1976 Emacs began?
> nearly every day since, and have *never* found it to be a pain
> in the ass.
I've frequently found it to be such --- and fixed the things that were
annoying me so that they stopped doing so.
Do *that* with another editor.
(Well, you can: but with other editors you generally have to recompile
them at least.)
> (Well, to be perfectly honest, I had some apprehension when I
> got started with TECO macros, which took me a week or so to get
> a handle on. That's not really germane to today's Emacs.)
A good thing too: I feel Lisp is of more general utility :)
--
Steve
> Much of the attempts to change Emacs to make it easier to use by
> point-and-grunters has had a negative effect on the more traditional
> approach to doing things.
Thats ironic, IMHO, because I think this happens *because* the emacs
community tries to hold on to tradition.
I don't know if this is the case, but the customization facility looks
like it is trying to avoid the use of regular pop up dialog boxes, be
backward compatiable with the cli emacs, and avoid what emacs people
would think of as
"dumbing down the options"
All three of these things is a move to hold on to tradition.
I've used editors that customize as much and more then the customize
utility and it isn't a mess. First they use tabbed pane dialog boxes
to fit a lot in a small space and keep it organized. Second they keep
the captions simple and non busy. They describe the option in terms
of what the user will see happen in the editor. For more complex
editors this isn't always understandable by a begginer, but it looks
less cluttered and more clear then emacs customize.
Such dialog boxes aren't backward compatiable with the cli emacs, but
I think people who the cli would be happy with a list of lisp
functions they could stick in their .emacs sort of what the ntemacs
faq does.
> I'm not unsympathetic to the difficulties new users face in learning
> Emacs. But a good part of Emacs's benefits come from what you can do
> with a little knowledge of ELisp.
I've observed an intern in our office who was a new emacs user. He
did what I did and other people in our office did. He read well
commented .emacs files and copied what he liked. His view ( and mine
) that this was far quicker, and easier then dealing with customize.
> Customize seems to be a step toward building an Emacs under-class;
> people who use Emacs but are continually having their lack of
> knowledge of ELisp made evident.
So what?
I've used visual slickedit for 3 years. It has a comparable set of
programming features to emacs ( sorry, no usenet reader, mail client,
or tex processor ) and it is all laid out very well with a gui based
customization system that succeed where emacs customize failed. I
have never needed to know the extension language, because the editor
provided all I could want. I've used it for about a half dozen
different technologies and some complex projects.
If emacs comes up with a good customization facility, improves in
other areas, and lays out things well people will not need to know
lisp to get fair amounts of complex work done.
>
> There is nothing particularly difficult about ELisp, that someone who
> is literate enough to want to use an editor can't learn.
Maybe. The first time I tried learning lisp was as a new programmer
in college. It was a nightmare. I've picked up studying it again,
after several years of professional programming. Now, lisp is just
different instead of a nightmare. My point, people who are used to
programming and used to lisp might overestimate how friendly it is to
other people.
> (Oops, this is *alt.religion.emacs*)
>
> Of course ELisp could be taught in the schools, but this would bring
> about protests from parents who see this is a conflict between church
> and state. The people of the C++, Java, or even Dylan religions would
> feel outrage. One can try to explain that ELisp is different, and
> that Emacs embraces these other languages, and even supports their
> practices better than editors written by their narrow minded
> proponents.
A lot of people view the emacs and lisp communties as narrow minded.
I've spend a lot of time using emacs, using C, using C++, perl, java
and now I am learning lisp as a hobby. I've done a lot of
development in windows and in the last two years have been working
with *nix.
I've noticed that a lot of people in the unix community are very
hostile or snobbish ( false? ) towards Java and other new
technologies. I can't figure it out.
Thien-Thi Nguyen
> If emacs comes up with a good customization facility, improves in
> other areas, and lays out things well people will not need to know
> lisp to get fair amounts of complex work done.
when people eventually are at the point of getting (more than) fair amounts of
complex work done, they are typically writing lisp anyway. lisp is unfair
like that.
> I've noticed that a lot of people in the unix community are very
> hostile or snobbish ( false? ) towards Java and other new
> technologies. I can't figure it out.
sometimes its difficult to find the beginnings of the circle.
thi
J. Fischer
>I've frequently found it to be such --- and fixed the things that were
>annoying me so that they stopped doing so.
>
>Do *that* with another editor.
There might be no need to do so.
--Jörg
Oliver Scholz
> Barry Fishman <barry_...@att.net> wrote in message
>
>> Much of the attempts to change Emacs to make it easier to use by
>> point-and-grunters has had a negative effect on the more traditional
>> approach to doing things.
>
> Thats ironic, IMHO, because I think this happens *because* the emacs
> community tries to hold on to tradition.
This is not true at all. Neither the developers nor the larger part of
the community are conservative, as far as I can tell.
> I don't know if this is the case, but the customization facility looks
> like it is trying to avoid the use of regular pop up dialog boxes, be
> backward compatiable with the cli emacs, and avoid what emacs people
> would think of as
> "dumbing down the options"
>
> All three of these things is a move to hold on to tradition.
>
> I've used editors that customize as much and more then the customize
> utility and it isn't a mess. First they use tabbed pane dialog boxes
> to fit a lot in a small space and keep it organized. Second they keep
> the captions simple and non busy. They describe the option in terms
> of what the user will see happen in the editor. For more complex
> editors this isn't always understandable by a begginer, but it looks
> less cluttered and more clear then emacs customize.
Tabbed pane dialog boxes are just eyecandy. I do not say this is
bad. I like eyecandy very much and I want a shiny good-looking
GTK-Emacs in the future, with anti-aliased faces and a face-sensitive
fill-function. But eyecandy and beginner-friendliness or ease of use
are quite different things. Please, do not throw them together.
As soon as a future Emacs allows to access the toolkit via
Lisp-functions someone can add all kind of GUI-stuff everywhere very
easily. Most of it could be done by simply hacking widget.el.
(Personally I like the textual appearance of the current widget.el
very much, but that is a matter of taste.)
Besides, are you aware, that customize creates it's groups on the fly?
Thus it is possible that, say, one and the same variable is part of
different groups. And it allows such nifty things like
`customize-apropos'. AFAICU this plays a role in the design of
`customize'.
As for your second point: I think, I do not understand what you
mean. Could you please give an example?
> Such dialog boxes aren't backward compatiable with the cli emacs,
Erm, why not?
[...]
> I've observed an intern in our office who was a new emacs user. He
> did what I did and other people in our office did. He read well
> commented .emacs files and copied what he liked. His view ( and mine
> ) that this was far quicker, and easier then dealing with customize.
This is not so much a technical issue, it is a social issue. The
Emacs-community tends to recommend hacking your .emacs. Experienced
Emacs-users tell their padawans to do so, Emacs-related web-sites tell
you to do so, posters in the Emacs-newsgroups tell you to do so, every
commentary section in a library tells you to do so and the EmacsWiki
tells you to do so. Customize could implement the most sophisticated
and most "user friendly" (I hate that term) interface in the world,
this will not change as long as the community does not change.
>> Customize seems to be a step toward building an Emacs under-class;
>> people who use Emacs but are continually having their lack of
>> knowledge of ELisp made evident.
This is not true. Why do you think it is?
Do I use customize? No, except for things I do not want to save. But
that is because hacking my .emacs is a hobby for me. (It is a
religious act, too.)
[...]
> If emacs comes up with a good customization facility, improves in
> other areas, and lays out things well people will not need to know
> lisp to get fair amounts of complex work done.
I think, it has yet to be proved that people need to know Lisp for
this right now.
[...]
> Maybe. The first time I tried learning lisp was as a new programmer
> in college. It was a nightmare. I've picked up studying it again,
> after several years of professional programming. Now, lisp is just
> different instead of a nightmare. My point, people who are used to
> programming and used to lisp might overestimate how friendly it is
> to other people.
O.k. But it is worth mentioning that for non-programmers Emacs-Lisp in
particular is a very friendly language. Especially with the excellent
introduction to Emacs Lisp, which is targeted at such people.
[...]
> A lot of people view the emacs and lisp communties as narrow minded.
And this is not fair at all. Note: most Emacsers-devotees, myself
included, can get terribly bored, when someone talks about "Emacs is
not user-friendly" without ever explaining what that means and _how_
the supposed shortcomings could be fixed (at least in form of the
general outline of a design concept).
But from lurking in emacs-devel I got the impression that improving
the user interface is very high on the priority list in the
Emacs-Olymp. RMS Kronides himself seems to have an eye on that.
There was recently a thread on gnu.emacs.help starting with
<420976de.02062...@posting.google.com> that is significant
for this. A large part was a stupid flame war about so called
"user-friendliness". But there were subthreads seriously discussing
possible improvements for Emacs, too. You can see there what kind of
postings invoke flames wars and what kind of postings invoke serious
discussion.
> I've spend a lot of time using emacs, using C, using C++, perl, java
> and now I am learning lisp as a hobby. I've done a lot of
> development in windows and in the last two years have been working
> with *nix.
> I've noticed that a lot of people in the unix community are very
> hostile or snobbish ( false? ) towards Java and other new
> technologies. I can't figure it out.
Does Java still count as a "new" technology?
-- Oliver
--
15 Thermidor an 210 de la Révolution
Liberté, Egalité, Fraternité!
David Kastrup
> David Kastrup <David....@t-online.de> writes:
>
> > Luis Fernandes <e...@ee.ryerson.ca> writes:
>
> >> What is the output of "echo $EDITOR" or "echo $VISUAL" in your shell,
> >> please?
> >
> > Usually
> > gnuclient -p [ 21490+uid ]
> >
> > The port number is explicitly specified so that editing calls from an
> > su command can still find the right Emacs to contact.
>
> And may I ask how you do prevent files opened this way from being opened
> read-only?
Who said I do? It's mostly for reading purposes.
If you need to write, use tramp.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Greg Menke
>
> > I've noticed that a lot of people in the unix community are very
> > hostile or snobbish ( false? ) towards Java and other new
> > technologies. I can't figure it out.
Thats because most of the time "new technology" isn't all that new,
instead just repackaged/prettified stuff from 10-20 years ago. Or
more charitably, its more or less evolved and enhanced. Whats
particularly new & innovative about Java?
I guess the evolution of hardware giving the average end user
unbelievable amounts of ram and cpu grunt and disk space is a
considerable change, but software hasn't changed all that much since
the Atari/Commodore/AppleII days- its gotten bigger & fancier, and
wastes a lot more cpu cycles and ram but fundamentally it doesn't do
all that much more.
Having the Internet be as widespread as it is probably makes it a big
change also, though its hardly new. There are certainly more
examples, though I can't think of any "new" language that is truly
different. Except for maybe Intercal.
Gregm
Kai Großjohann
> Tabbed pane dialog boxes are just eyecandy.
Recently, somebody posted a package to gnu.emacs.sources that does
tabs. So the eyecandy has come closer :-)
Barry Fishman
> Barry Fishman <barry_...@att.net> wrote in message
>
>> Much of the attempts to change Emacs to make it easier to use by
>> point-and-grunters has had a negative effect on the more traditional
>> approach to doing things.
>
> Thats ironic, IMHO, because I think this happens *because* the emacs
> community tries to hold on to tradition.
>
What is wrong with tradition? Tradition is not equivalent to
stagnation. A tradition give a philosopy a set of reference points
on which ideas can be judged, and changes can be fully apprecated.
> I don't know if this is the case, but the customization facility looks
> like it is trying to avoid the use of regular pop up dialog boxes, be
> backward compatiable with the cli emacs, and avoid what emacs people
> would think of as
> "dumbing down the options"
I don't think customize uses its approach because of any dislike for
pop up dialogs. It seems to be an attempt to add such features within
the context of current emacs functionality. I don't think you would
get objections if someone provided a GTK or Windows like widgets, if
there was some way to preserve portability to the wide range of Emacs
host environments. If one needs to update their customization when
running emacs through a telnet window, there still needs to be some
way provided.
Even someone like myself, who doesn't like 'wired' gadget based
environment, has no problems with providing such environments. I
only object to them being shoved down my throat. I would even use
it if didn't play havoic with other parts of my configuration.
>> Customize seems to be a step toward building an Emacs under-class;
>> people who use Emacs but are continually having their lack of
>> knowledge of ELisp made evident.
>
> So what?
I guess, to me it is ultimately a moral issue. When you start
thinking of people in stereotypes, you are doomed to wasting talent.
Sure some people will pick up an ELisp manual, read the sources and
become experts. But most people's focus in elsewhere, and they are
better served by an environment that they can build up competence
a little at a time.
Currently the big step in learning Emacs is in learning ELisp.
Unfortunately, it occurs early on in ones exposure to Emacs.
Customization serves two purposes. It delays the need to get
productive in ELisp. It also allows simple changes in ones
configuration to be made without hand editing your .emacs file, or
looking up the ELisp code you need to type into the scratch buffer.
But customization brings on 'wiredness'. Its a fixed set of changes
which you discover by exploring a set of alternatives expressed in
widgets and pull down menus. They are only a set of alternatives
someone has picked in advance.
Yes, Emacs can take this approach from Microsoft and Java, and bodily
graft it into Bmacs. But what about what is being thrown away.
I am not an expert on user interfaces, and have far less exposure too
them than the 'customize' developers. However, Emacs already has
already implemented features which can be use to make its
customization package far more frendly to Emacs's existing users.
When one uses ilisp-mode, the idea of editing a defun and having it
updated in your source file is not unusual. It is not dependent on
any special templating of your source files. A customize packages
could let you do just that, if you wanted to edit the elisp code
yourself. It could also replace the defun with (nicely readable)
boilerplate generated by its menu/widget mode.
Customize could also provide a well documented set of 'customize
conventions' on how it would add to the users .emacs setup. For
example, one could have a "~/ecustom" directory where specific elisp
files would be created and updated. Customize could by default put
its new elisp code there, and the user could hand edit these files
(following some minimal set of conventions) without fearing that the
customization code would be confused. Even if the user had a
different file layout, customize could still find the proper defun to
change, wherever it existed.
Someone could let customize set up their basic configuration, and then
hand change any special features themselves. They would be able to read
and understand the code customize generated. It could serve as an
example of good elisp code.
Customize could also be smart enough to remove code when the original
default behavior is to be restored, and remove configuration files
when they no longer have content.
>> There is nothing particularly difficult about ELisp, that someone who
>> is literate enough to want to use an editor can't learn.
>
> Maybe. The first time I tried learning lisp was as a new programmer
> in college. It was a nightmare. I've picked up studying it again,
> after several years of professional programming. Now, lisp is just
> different instead of a nightmare. My point, people who are used to
> programming and used to lisp might overestimate how friendly it is to
> other people.
I find the 'CL' extensions to emacs make available the more loop
oriented constructs which are more natural to people from non-lisp
backgrounds.
With the predomanance of 'C' like linguistic structure in many of the
more popular languages, Lisp does require a bit of getting use to.
But ultimately its just that. Creating a Emacs programmed in a C or
Java like language would require giving up or reconstructing a lot of
features which are well understood in lisp.
My bias is that Emacs would be better of evolving toward a Common
Lisp based implementation language, where parts could be shared with
stand alone programs run in a variety of Common Lisp environments.
As it is much defstruct based common lisp code can be run in Emacs
without changes.
A couple of years ago, I found myself in the position that I needed
to be fluent in about 6 different computer languages to do my job. It
wasn't that each of these languages had some overwhelming strength
that I need to use it. It was that each had overwelming deficiencies,
that prevented me from using it for other tasks. If found myself
writing the same program in 3 or 4 different languages.
As an exercise, I started programming some of these tasks in common
lisp, and found that I was no longer continually faced with the
linguistic barriers of these application specific languages. The fact
that I was spending most of my time in one language made many things
simpler. But I was faced with the sometimes more difficult task of
finding or writing the interface specific API's that came with the
other languages. The issue was more about what code was already
available than it was about how to implement some feature just beyond
the reach of the languages simple syntax. Again simplifying simple
activities made the more complex activities even more difficult.
I liked the idea that with Common Lisp I could stick to one language,
and concentrate on getting better at it.
>> (Oops, this is *alt.religion.emacs*)
>>
>> Of course ELisp could be taught in the schools, but this would bring
>> about protests from parents who see this is a conflict between church
>> and state. The people of the C++, Java, or even Dylan religions would
>> feel outrage. One can try to explain that ELisp is different, and
>> that Emacs embraces these other languages, and even supports their
>> practices better than editors written by their narrow minded
>> proponents.
>
> A lot of people view the emacs and lisp communties as narrow minded.
The Emacs community seem to me to be more open than most to looking at
divergent ideas. For example, despite the reputation of VI among
Emacs users, several people have taken the trouble to implement VI
bindings in Lisp and consider its impact on Emacs general behavior.
This code is even included in the Emacs distribution.
Emacs was even ported, and is supported on Windows, which is not
exactly the FSF's favorite OS.
>
> I've spend a lot of time using emacs, using C, using C++, perl, java
> and now I am learning lisp as a hobby. I've done a lot of
> development in windows and in the last two years have been working
> with *nix.
>
> I've noticed that a lot of people in the unix community are very
> hostile or snobbish ( false? ) towards Java and other new
> technologies. I can't figure it out.
Java is not an new technology. Java was intended to provide a
reliable language for internet applications, and not be a experimental
platform for new computer science ideas. It is an implementation of
current technology in a language with an intentially constrained set
of features. The one thing that it has that is not part of some
common lisp (that I know of) is a security mechanism intended to allow
untrusted (semi-compiled) code to be loaded and run without the worry
about viruses. I don't think this is something that couldn't be added
to a lisp environment, although I am not an expert. Java makes this a
basic part of the language which probably makes holes easier to locate
and fix.
The bigest problem the free software community has with Java is the
licencing issues. This has not stopped the GCC development group
from trying to produce a java of their own.
The Emacs developers seem to be moving toward a guile (Scheme) base
platform. Guile seems to be looking at Java as one of their source
languages, so at some point you might be able to extend Emacs using
Java. This does not seem like much of a rejection.
The Lisp community does not some of the constraints Java puts on the
programmer and feels they are unnecessary. They feel they have a
better, and more tried and true language. Java of course has two (at
least former) members of the Lisp comunity amoung its three
architects.
Mike Warren
> Part of the problem is that Emacs is everything to all people, so it
> is difficult to find the "typical" user. What we really need isn't
> fancy GUI buttons (it is a sad thing that so many people believe
> good user interfaces are a question of selecting eye-candy widgets),
> but volunteers who will write task oriented tutorials with inline
> customize controls.
Maybe it needs something like a ``meta-customise'' not unlike the
``task'' selection in Debian's install: one could choose from a number
of typical customise setups and go from there (e.g. ``programmer'',
``newbie'', ``writer'', ``scientific writer'', ...)
--
mike [at] mike [dash] warren.com
<URL:http://www.mike-warren.com>
GPG: 0x579911BD :: 87F2 4D98 BDB0 0E90 EE2A 0CF9 1087 0884 5799 11BD
Mike Warren
> I read this sort of thing and realise how *long* Emacs has been
> going for... I'm not actually sure whether it's older than I am or
> not, but it must be close to it. I only met Emacs in 1995 and only
> started to *use* it in '97... but I've been hooked and a total
> (X)Emacsophile ever since.
I can't live without Emacs any more. The last time someone thought,
``hey! Mike's a computer-guy; he can fix my Windows machine'' and
forced me to use Notepad, I ended up printing a half-dozen copies of
some config file while trying to go to the previous line (C-p) before
I realized why the cursor wasn't moving...
Steve
> Tabbed pane dialog boxes are just eyecandy. I do not say this is
> bad.
That point might come across better if you avoid using words like
"just" and "eyecandy".
> Besides, are you aware, that customize creates it's groups on the fly?
> Thus it is possible that, say, one and the same variable is part of
> different groups. And it allows such nifty things like
> `customize-apropos'. AFAICU this plays a role in the design of
> `customize'.
Yes. I still think emacs-customize has a busy appearance, confusing
explanations and is slow.
>
> [...]
> > I've observed an intern in our office who was a new emacs user. He
> > did what I did and other people in our office did. He read well
> > commented .emacs files and copied what he liked. His view ( and mine
> > ) that this was far quicker, and easier then dealing with customize.
>
> This is not so much a technical issue, it is a social issue. The
> Emacs-community tends to recommend hacking your .emacs.
Nobody told him to have a look at any .emacs files ( he didn't know
what they were ) until he got fed up with customize.
> But from lurking in emacs-devel I got the impression that improving
> the user interface is very high on the priority list in the
> Emacs-Olymp. RMS Kronides himself seems to have an eye on that.
Thats good to hear.
Like every other technology emacs labors under outdated images from
people who haven't looked at it in a long time.
Some decicisions do you make wonder though. Given what you wrote
above I think it might be an issue of emacs developers being out of
sync with what users would like.
This happens to the best of us.
> Does Java still count as a "new" technology?
Compared to other technologies availabe in unix, but that is not what
my point was about. I've done a lot of work both in ms windows and
*nix environments.
Maybe its the particular people I met. The ms windows geeks haven't
been hostile. A chunk ( not all ) of the *nix people I have worked
with have been very hostile towards java, or most new technologies. I
haven't understood why.
Every technology has its pitfalls, but for some reason with the nix
people I have come across it goes from preferences to *venom* with
java.
Steve
> Oliver Scholz <alkib...@gmx.de> writes:
> >
> > > I've noticed that a lot of people in the unix community are very
> > > hostile or snobbish ( false? ) towards Java and other new
> > > technologies. I can't figure it out.
>
> Thats because most of the time "new technology" isn't all that new,
> instead just repackaged/prettified stuff from 10-20 years ago. Or
> more charitably, its more or less evolved and enhanced. Whats
> particularly new & innovative about Java?
The text you have quoted above are my utterances, not Oliver's.
Every technology has its pitfalls. Why the *hostility* ?
BTW, I think terms like "eye candy" and "repackaged, prettified"
reflect an underlying ignorance ( no offense, really ) about the
technologies in question.
Those terms (unfairly) gloss over all the details, perspiration of
what it takes to make a GUI ( and the utility it provides ), or
"repackage" some ideas from older technologies that never made it ( or
spread beyond a certain point )into something useful.
Its a provincial attitude
"Its not what I am used to, its not what I know, its new, with some
effort I can hackney existing technologies to do a similar jobs (
though maybe not as well), therefore that technology isn't all that
good and the innovations/features that it has are just __trivial__
reworkings, with no significant value added that someone in the know
like myself could bang out in a weekend if I deemed it worth my time
to come down out of my tower of knowledge. ('new' || 'what I dont
use' || 'what I don't know") == ('inferior' || 'trivial")".
No offense, I mean that. I've developed in multiple environments and
that is what the underlying atmosphere in *nix shops smell like to me.
Ironically, these are the same people who claim that people are
unwilling to learn if they don't want to use a particular technology (
theirs ).
Oy!
I guess I have just been around too many other programmers without a
break :)
> I guess the evolution of hardware giving the average end user
> unbelievable amounts of ram and cpu grunt and disk space is a
> considerable change, but software hasn't changed all that much since
> the Atari/Commodore/AppleII days- its gotten bigger & fancier, and
> wastes a lot more cpu cycles and ram but fundamentally it doesn't do
> all that much more.
This is another blanket ignorant trivialization. Again, no
offense....really.
A wooden horse drawn plough and a modern tractor both give similar
results.
To go from there to say something like
"oh sure, gasoline motors and some other advances in manufacturing
have addedsmall things, but at the end of the day farm tools have
remained mostly the same."
David Kastrup
> Tabbed pane dialog boxes are just eyecandy. I do not say this is
> bad. I like eyecandy very much and I want a shiny good-looking
> GTK-Emacs in the future, with anti-aliased faces and a
> face-sensitive fill-function. But eyecandy and beginner-friendliness
> or ease of use are quite different things. Please, do not throw them
> together.
<URL:http://preview-latex.sourceforge.net> is "just" eyecandy. It
uses streamlined background processes involving LaTeX, special styles,
an intricate daemon operation of GhostScript, in order to replace
source text with previews matching your editing window in size and
color. But all that effort goes merely into enhancing the buffer
display. Blindfold a user, and he will not notice its presence: the
same keystrokes will achieve the same effects. The files do not
change. Emacspeak would tell no differences. Exclusively "eyecandy".
Providing a radical usability enhancement to LaTeX editing with Emacs.
It also improves ergonomy, because your eyes and concentration need
not switch between source and preview, and economy because it saves
the additional screen estate you's need to reserve for a separate
previewer.
Exclusively "eyecandy". It's not just about snazziness.
Oliver Scholz
> Oliver Scholz <alkib...@gmx.de> writes:
>
>> Tabbed pane dialog boxes are just eyecandy. I do not say this is
>> bad. I like eyecandy very much and I want a shiny good-looking
>> GTK-Emacs in the future, with anti-aliased faces and a
>> face-sensitive fill-function. But eyecandy and beginner-friendliness
>> or ease of use are quite different things. Please, do not throw them
>> together.
>
> <URL:http://preview-latex.sourceforge.net> is "just" eyecandy.
[...]
> Providing a radical usability enhancement to LaTeX editing with Emacs.
> It also improves ergonomy, because your eyes and concentration need
> not switch between source and preview, and economy because it saves
> the additional screen estate you's need to reserve for a separate
> previewer.
[...]
We are miscommunicating. That is: I have expressed myself not clear
enough.
I wouldn't call preview-latex "eyecandy" for the very reasons you
mentioned. (Especially because of the ergonomy, the screen estate is a
no-issue with my WM).
Appearance is not in general only matter of what I call
"eyecandy". Font-lock is another example: different faces guide the
eye and the concentration.
But the things I mentioned are just eyecandy, IMO. To have the _same_
menus as now but with GTK instead of Athena or Motif would just look
nicer. Antialiased faces would look more beautiful but nothing else.
O.K., one could say that even these things are at the
borderline[1]. But we were talking about the UI of customize. My claim
is, that tabbed dialog boxes don't add anything more than eyecandy
(again: not that I think this is a bad thing). Imagine the same
customize that we have now, but not in a buffer but in a pop-up dialog
box with tabs and toolkit-buttons. What exactly would be the benefit
of this, UI-wise? Except, of course, that I am suddenly _forced_ to
take my hands off the keyboard and catch the mouse ... (*grrr*)
And the other way around: imagine the most sophisticated and most
beginner-friendly customize in the world in a tabbed dialog box. Why
should it be impossible to have the same perfect thing in form of
textual widgets in a buffer?
Maybe Steve would say, that I am wrong here. And that dialog boxes
would really provide a better ergonomy. But I would like to hear the
reasons.
-- Oliver
Footnotes:
[1] Yes, I know. GTK has IIRC some other benefits besides looking
nicer. And as for anti-aliasing: free scalable fonts are most often
not hinted for smaller sizes, so they are in some cases hard to read
on a computer display. Anti-aliasing would help a lot here. OTOH
anti-aliased fonts look slightly blurred, so they put additional
stress on the eye. (That's way I think anti-aliasing should be a
property of the face.) And finally: the fact that the current
fill-functions are not face-sensitive may be distracting sometimes.
--
16 Thermidor an 210 de la Révolution
Liberté, Egalité, Fraternité!
Oliver Scholz
> Oliver Scholz <alkib...@gmx.de> wrote in message
>
>> Tabbed pane dialog boxes are just eyecandy. I do not say this is
>> bad.
>
> That point might come across better if you avoid using words like
> "just" and "eyecandy".
Maybe. In a different context I would have said "beautiful
appearance". But we were talking about UI and my claim is, that
"toolkit dialog boxes vs. the existing textual widgets" is not
relevant here.
>> Besides, are you aware, that customize creates it's groups on the fly?
>> Thus it is possible that, say, one and the same variable is part of
>> different groups. And it allows such nifty things like
>> `customize-apropos'. AFAICU this plays a role in the design of
>> `customize'.
>
> Yes. I still think emacs-customize has a busy appearance, confusing
> explanations and is slow.
You already said this. And perhaps I am tempted to say: you are
right. But other than you I am not yet convinced that there is a way
to fix this. The amount of things that customize has to cover is
huge. You seem to think that it is possible to get a clearer
interface, though. That's why I asked for a more concrete example. As
a said, I do not expect ready-made UI-guidelines. A vague description
would possibly do. But something like this is necessary to discuss the
issue seriously.
>> [...]
>> > I've observed an intern in our office who was a new emacs user. He
>> > did what I did and other people in our office did. He read well
>> > commented .emacs files and copied what he liked. His view ( and mine
>> > ) that this was far quicker, and easier then dealing with customize.
>>
>> This is not so much a technical issue, it is a social issue. The
>> Emacs-community tends to recommend hacking your .emacs.
>
> Nobody told him to have a look at any .emacs files ( he didn't know
> what they were ) until he got fed up with customize.
O.K, granted. I don't know. Currently I try to help a friend of mine
with Emacs. I decided that I should not give him the impression that
he has to be a Lisp-programmer right from the start, so I tried to
direct him to the respective sections in customize. I discovered that
this is more work for me than to give him a snipplet from my Emacs.
>> But from lurking in emacs-devel I got the impression that improving
>> the user interface is very high on the priority list in the
>> Emacs-Olymp. RMS Kronides himself seems to have an eye on that.
>
> Thats good to hear.
>
> Like every other technology emacs labors under outdated images from
> people who haven't looked at it in a long time.
>
> Some decicisions do you make wonder though. Given what you wrote
> above I think it might be an issue of emacs developers being out of
> sync with what users would like.
>
> This happens to the best of us.
Hmm. Maybe.
But it is possible that we are not expecting the same things here. In
many cases beginners have different needs than experienced users. Take
an example from a different editor: a few people whose opinions count
a lot in my book maintain that vi's UI for text editing and it's
keybindings are far more efficient than Emacs'. But of course they are
harder to learn. So the same UI that is good for experienced users is
very bad for beginners.
Such things must be balanced against each other. To make the right
decision is not always easy. To improve the UI needs a lot of careful
consideration. I would put it this way: the learning curve for new
users shouldn't be so steep as it is now, but it may not become a flat
line.
The goal can not be to make Emacs exactly similar to other
editors. (Not that you said this. But I think it is worth to call this
into memory again.) I wouldn't say that Emacs is the right editor for
everyone under the sun. If Emacs tried to satisfy everyone's needs it
might become a much weaker tool.
-- Oliver
--
16 Thermidor an 210 de la Révolution
Liberté, Egalité, Fraternité!
Greg Menke
> >
> > Thats because most of the time "new technology" isn't all that new,
> > instead just repackaged/prettified stuff from 10-20 years ago. Or
> > more charitably, its more or less evolved and enhanced. Whats
> > particularly new & innovative about Java?
>
> The text you have quoted above are my utterances, not Oliver's.
I know- I inadvertently followed up to his. Sorry.
>
> Every technology has its pitfalls. Why the *hostility* ?
Because often the new technology isn't all that new and the hype
wastes time, energy and money.
>
> BTW, I think terms like "eye candy" and "repackaged, prettified"
> reflect an underlying ignorance ( no offense, really ) about the
> technologies in question.
>
> Those terms (unfairly) gloss over all the details, perspiration of
> what it takes to make a GUI ( and the utility it provides ), or
> "repackage" some ideas from older technologies that never made it ( or
> spread beyond a certain point )into something useful.
>
> Its a provincial attitude
Perhaps I am too cynical. I don't denegrate the labor spent in these
upgrades and incremental changes- periodically reimplementing things
is required. On the other hand, trotting out a new programming
language which is more or less the same old thing with a few of the
old language's problems fixed (along with the invention of a whole set
of new problems) doesn't seem much to get excited about.
>
> "Its not what I am used to, its not what I know, its new, with some
> effort I can hackney existing technologies to do a similar jobs (
> though maybe not as well), therefore that technology isn't all that
> good and the innovations/features that it has are just __trivial__
> reworkings, with no significant value added that someone in the know
> like myself could bang out in a weekend if I deemed it worth my time
> to come down out of my tower of knowledge. ('new' || 'what I dont
> use' || 'what I don't know") == ('inferior' || 'trivial")".
I don't automatically think something new is bad, just that frequently
its just not all that interesting.
> No offense, I mean that. I've developed in multiple environments and
> that is what the underlying atmosphere in *nix shops smell like to me.
So have I. I did Windows for 10 years until dealing with the same old
clumsiness and bugs was literally making me depressed. I went
Windows-free in 1997 and ever since its felt like I rediscovered
programming.
> Ironically, these are the same people who claim that people are
> unwilling to learn if they don't want to use a particular technology (
> theirs ).
Oh I regularly cram new stuff into my head- its just I'd like to see
something about how the return will be worth the effort. Just
recently I've been learning the in-memory structure of executables as
applied to rom images in embedded systems. I gives a very interesting
perspective on a language. Over the last year or so I've been
learning OpenGL, SNMP, assembly on MIPS and PowerPC, embedded 8 bit
controller assembly & Basic, as well as fancying up my skill with
C/C++ and Lisp. Tex/Latex is probably coming soon.
Working with Lisp has been a huge help for my coding style in C/C++.
Learning Prolog (to the extent I learned it) made me think about
things quite differently as well. Python is an interesting language-
a bit young at this point, but interesting. I just don't see how
deeply learning Java or C# will benefit me much- or frankly, what
problems they solve which haven't already been solved a number of
times already.
> Oy!
>
> I guess I have just been around too many other programmers without a
> break :)
Or taking marketing driven technologies too seriously. After all
Java, C# and .NET aren't there because there's a technical problem for
them to solve which considerably exceeds the capabilities of existing
languages & tools, its to ensure a monopoly position in a market. If
Sun & Microsoft were really interested in these languages for their
technical utility, we'd have ANSI standards & committees and the
normal endless wrangling, BUT we'd also have languages that are not
beholden to the whims of the companies that sell them- and somewhat
less of the licensing foolishness that software companies seem to
delight in.
>
> > I guess the evolution of hardware giving the average end user
> > unbelievable amounts of ram and cpu grunt and disk space is a
> > considerable change, but software hasn't changed all that much since
> > the Atari/Commodore/AppleII days- its gotten bigger & fancier, and
> > wastes a lot more cpu cycles and ram but fundamentally it doesn't do
> > all that much more.
>
> This is another blanket ignorant trivialization. Again, no
> offense....really.
OK, I'll grant my comment there was somewhat extreme. I'm not one of
those who says all types of software than can be have already been
invented. I would say however its been awhile since a new type of
software has been invented. Though perhaps the VHDL stuff for IC's
and various related CAD/CAM systems is really different- it certainly
allows circuits of such complexity to be designed that it would
probably be impossible for humans to do them.
> A wooden horse drawn plough and a modern tractor both give similar
> results.
>
> To go from there to say something like
>
> "oh sure, gasoline motors and some other advances in manufacturing
> have addedsmall things, but at the end of the day farm tools have
> remained mostly the same."
But as far as software is concerned, they pretty much have. The
interfaces are prettier and now you can create arbitrarily complicated
schematics of a system and have a computer write much of the code
(which will almost certainly have bugs anyway...)- but that kind of
stuff has been around for over a decade and in some forms even longer.
Modern configuration management tools are a definite step forwards
from 10 years ago- but they aren't new in any way either.
Gregm
Kai Großjohann
> Working with Lisp has been a huge help for my coding style in C/C++.
> Learning Prolog (to the extent I learned it) made me think about
> things quite differently as well. Python is an interesting language-
> a bit young at this point, but interesting. I just don't see how
> deeply learning Java or C# will benefit me much- or frankly, what
> problems they solve which haven't already been solved a number of
> times already.
I don't know C#. I looked at Java, and I learned a couple of things:
* This strong typing stuff is a mixed bag. It's easy to make awful
mistakes with all this autoconversion going on in Perl, but I don't
like having to type all these typecasts.
* I liked the way that Java integrates exception handling into the
framework. Sure, Perl has exceptions, too, but they aren't
standardized at all. With Java, you have a standard set of
exceptions and can build on them.
Only later did I discover that (Emacs) Lisp also has this :-) Very
nifty. But it is used a lot more in Java, I think.
* I learned that the exceptions that can be thrown are also part of
the signature of a method. So if you want a stable signature, then
you got to construct your own exceptions and rebless all exceptions
thrown from lower layers into exceptions from your layer and then
rethrow them. Otherwise the layers upwards from you would have to
change when you change your implementation.
This was an interesting learning experience.
* Java manages to combine some of the disadvantages of strong typing
(at compile time) with the disadvantages of run-time type checking,
by not having something like the C++ templates for containers. Why
can't I say I want a List of Integers and then Java takes care for
me that only Integers are in this List? Instead, I am forced to
take care of it myself by having to write all the typecasts.
But in the end, that's just typing, and Java is really nice in
always slapping me on my hand when I try to aim the gun towards my
foot :-)
Thien-Thi Nguyen
> A wooden horse drawn plough and a modern tractor both give similar
> results.
people emit hostility when they are asked to be the horse.
thi
Greg Menke
> * This strong typing stuff is a mixed bag. It's easy to make awful
> mistakes with all this autoconversion going on in Perl, but I don't
> like having to type all these typecasts.
I find strong types a mixed bag too. Sometimes (often) it seems more
trouble than its worth- particularly in the case you suggest when you
end up with incessant typecasts. Then theres the other times when it
saves you from an error. I do like not being forced into it by the
language however.
> Only later did I discover that (Emacs) Lisp also has this :-) Very
> nifty. But it is used a lot more in Java, I think.
Common Lisp has a quite sophisticated exception system (called
"conditions") which lets you do fairly exotic stuff; much more than
try/catch kinds of things. I don't understand it very well yet- but
the analyses of it that I've read suggest its quite flexible.
I'm not particularly familiar with Elisp beyond the basic Lisp
structures, but I imagine whatever support is has for exceptions would
be a subset of the full Common Lisp condition system.
>
> * I learned that the exceptions that can be thrown are also part of
> the signature of a method. So if you want a stable signature, then
> you got to construct your own exceptions and rebless all exceptions
> thrown from lower layers into exceptions from your layer and then
> rethrow them. Otherwise the layers upwards from you would have to
> change when you change your implementation.
>
> This was an interesting learning experience.
I think this would be a particuarly annoying feature. Have you found
it useful at all?
I've heard the often proposed advantage of Java where the use of a
class (can?) force you to deal with all the exceptions it is able to
issue. That seems a rather dogmatic approach to system design. Just
because you catch all the exceptions a particular class can create,
doesn't relate to how reasonable the exceptions are in the first place
or how well your code deals with them.
Gregm
Kai Großjohann
> I'm not particularly familiar with Elisp beyond the basic Lisp
> structures, but I imagine whatever support is has for exceptions would
> be a subset of the full Common Lisp condition system.
Ah, yes CL has continuable errors. I wonder what those are... But
they must be nifty.
>> * I learned that the exceptions that can be thrown are also part of
>> the signature of a method. So if you want a stable signature, then
>> you got to construct your own exceptions and rebless all exceptions
>> thrown from lower layers into exceptions from your layer and then
>> rethrow them. Otherwise the layers upwards from you would have to
>> change when you change your implementation.
>>
>> This was an interesting learning experience.
>
> I think this would be a particuarly annoying feature. Have you found
> it useful at all?
I guess it's inevitable. Imagine you have a class storing addresses,
and you implement it on top of regular files. Then you might get
things like FileNotFoundException. Then later on you change your
class to working with a database. Then you might get things like
NoSuchTableException (I made this one up).
Clearly your code throwing FileNotFoundException today and
NoSuchTableException tomorrow is not going to work (for a clean
design).
So you must decide which exceptions you want to throw and then you
need to rebless all exceptions.
It's not clear to me how to avoid this.
Hm. Maybe you could attach properties (transient error, fatal error,
...) to an exception and then the catch statements would depend on
those properties rather than the actual class. But this only works
if the set of properties is complete.
Janne Rinta-Mänty
> The tool bars in Emacs seem totally useless to me, hence I disables
> it. However, that is true for the tool bars for all other
> applications I have used. Again, I suspect that like me, other
> Emacs developers haven't really got the idea behind a tool bar yet.
The idea behind a tool bar is to waste screen estate and give
something to do (a memory game) for people who can't read.
--
Janne Rinta-Mänty
Greg Menke
>
> > I'm not particularly familiar with Elisp beyond the basic Lisp
> > structures, but I imagine whatever support is has for exceptions would
> > be a subset of the full Common Lisp condition system.
>
> Ah, yes CL has continuable errors. I wonder what those are... But
> they must be nifty.
I think they are. I've not addressed really learning them yet.
try/catch stuff is pretty easy, but conditions are asserted to go way
beyond that.
> >> * I learned that the exceptions that can be thrown are also part of
> >> the signature of a method. So if you want a stable signature, then
> >> you got to construct your own exceptions and rebless all exceptions
> >> thrown from lower layers into exceptions from your layer and then
> >> rethrow them. Otherwise the layers upwards from you would have to
> >> change when you change your implementation.
> >>
> >> This was an interesting learning experience.
> >
> > I think this would be a particuarly annoying feature. Have you found
> > it useful at all?
>
> I guess it's inevitable. Imagine you have a class storing addresses,
> and you implement it on top of regular files. Then you might get
> things like FileNotFoundException. Then later on you change your
> class to working with a database. Then you might get things like
> NoSuchTableException (I made this one up).
>
> Clearly your code throwing FileNotFoundException today and
> NoSuchTableException tomorrow is not going to work (for a clean
> design).
Shouldn't this kind of thing be dealt with by a "pluggable" lower
level class that manages storage, where low level errors are issued by
the lower level routines? Or am I going beyond the extent of your
example?
> So you must decide which exceptions you want to throw and then you
> need to rebless all exceptions.
What does "blessing" mean to the compiler and what is the penalty if
the programmer lies about having done so?
>
> Hm. Maybe you could attach properties (transient error, fatal error,
> ...) to an exception and then the catch statements would depend on
> those properties rather than the actual class. But this only works
> if the set of properties is complete.
That sounds more like a reasonable approach. Then you can choose an
exception processing model that suits instead of laboriously supplying
a set of exception handlers that may or may not match the
preconceptions of the class you're dealing with.
Gregm
Greg Menke
Its also pretty handy for people who obsess over pushing their mouse
around. I'm just glad its easy to turn the things off (along with the
menus).
Gregm
Per Abrahamsen
> Besides, are you aware, that customize creates it's groups on the fly?
> Thus it is possible that, say, one and the same variable is part of
> different groups. And it allows such nifty things like
> `customize-apropos'. AFAICU this plays a role in the design of
> `customize'.
An important design criteria is that Emacs development is
extremely decentralized. For any customization facility to be kept
both complete and up-to-date, it need
1) To be coupled closely with the relevant package code.
2) To be really easy to program.
_All_ Emacs programmers need to be able to write customization
functionality for their code, and it has to be easy and obvious,
otherwise they won't bother.
The inspiration is Emacs doc string, all Emacs commands tend to be
documented, and the documentation tend to be up to date. However,
finding the relevant commands (or options) is a different issue.
The difference is that the API for customization and command
documentation are both bottom up. This makes them both powerful, easy
to use and flexible from a programmers point of view. You can easily
create new tools that utilize the information provided, which is what
you noted above.
However, for a new user top-down documentation is initially much more
useful. This, however, is much harder to create in a distributed
fashion. The Emacs Manual is excellent, but that is an exception that
only exists because Richard M. Stallman personally does an exceptional
work to keep it consistent and up to date. Good tutorial writing and
customization is not parallelizable, and thus not an easy match for
free software.
Per Abrahamsen
> I don't think customize uses its approach because of any dislike for
> pop up dialogs.
I, as well as most modern HCI researchers, really dislike dialogs.
They are extremely user-hostile, interrupt work, make use slower and
harder. Inline forms are much better, and the trend of newer
applications is to move that way (e.g. Mozilla is currently getting an
isearch like functionality).
Given the popularity of web-browsers, users are also getting used to
having forms inline, and less accepting for dialogs. Popups are
generally hated by the browser-using community, and one of the major
selling points of Mozilla is the ability to disable them in various
contexts.
However, this is simply a question of popup vs. inline, not graphical
vs. textual. The customize widgets were as graphical as the (X)Emacs
technology at the time permitted, with the ability to "downgrade"
gracefully for displays that did not support them. As Emacs get
support for more graphics, I hope someone will write the code to make
the customize widgets use it, when available.
I hope they will also make it possible to disable the graphics, I
personally prefer the textual widgets because I'm weird.
> But customization brings on 'wiredness'. Its a fixed set of changes
> which you discover by exploring a set of alternatives expressed in
> widgets and pull down menus. They are only a set of alternatives
> someone has picked in advance.
One of them tend to be "other", and you can always choose "Display
initial Lisp Expression" to edit the Lisp directly.
> When one uses ilisp-mode, the idea of editing a defun and having it
> updated in your source file is not unusual. It is not dependent on
> any special templating of your source files. A customize packages
> could let you do just that, if you wanted to edit the elisp code
> yourself. It could also replace the defun with (nicely readable)
> boilerplate generated by its menu/widget mode.
It sound like you want to create a syntactical editor for creating
Emacs Lisp code. I personally believe syntactical editors are a
creation of evil, and much prefer to use a text editor for
programming.
> steves...@yahoo.com (Steve) writes:
>
>> A lot of people view the emacs and lisp communties as narrow minded.
A lot of people have a narrow minded view of the Emacs community.
Kai Großjohann
>> Clearly your code throwing FileNotFoundException today and
>> NoSuchTableException tomorrow is not going to work (for a clean
>> design).
>
> Shouldn't this kind of thing be dealt with by a "pluggable" lower
> level class that manages storage, where low level errors are issued by
> the lower level routines? Or am I going beyond the extent of your
> example?
Anyway, there's going to be some class which handled files yesterday
and which will handle an RDBMS tomorrow. And we don't want the
exceptions thrown by this class to change.
I don't think it matters what you call this class :-)
>> So you must decide which exceptions you want to throw and then you
>> need to rebless all exceptions.
>
> What does "blessing" mean to the compiler and what is the penalty if
> the programmer lies about having done so?
Well, err. I guess that in Java it would look like:
try { ... }
catch (FileNotFoundException e) {
throw new CouldntStoreRecordException("blarfl " + e.toString());
}
I shouldn't have used a Perlish term for Java code. And even in
Perl, creating a new object is probably better. Or would be better,
if exceptions in Perl weren't strings...
>> Hm. Maybe you could attach properties (transient error, fatal error,
>> ...) to an exception and then the catch statements would depend on
>> those properties rather than the actual class. But this only works
>> if the set of properties is complete.
>
> That sounds more like a reasonable approach. Then you can choose an
> exception processing model that suits instead of laboriously supplying
> a set of exception handlers that may or may not match the
> preconceptions of the class you're dealing with.
But it's not done in Java :-)
Nix
> * This strong typing stuff is a mixed bag. It's easy to make awful
> mistakes with all this autoconversion going on in Perl, but I don't
> like having to type all these typecasts.
The right thing to do, of course, is decent type inferencing like in ML
or Haskell... but with a better implementation that gives readable
error messages ;)
> * Java manages to combine some of the disadvantages of strong typing
> (at compile time) with the disadvantages of run-time type checking,
> by not having something like the C++ templates for containers. Why
This is ackowledged as a problem: apparently templates (from the GJ
project) will go in sooner or later.
--
`There's something satisfying about killing JWZ over and over again.'
-- 1i, personal communication
Nix
> Nix <nix-ra...@esperi.demon.co.uk> writes:
>> I mean, I've now got >100K of *customization*; you shouldn't really need
>> all that to make an editor usable. (But perhaps my definition of `usable'
>> is rather extreme.)
>
> I've kept mine pruned to 6 lines, although I did write my own
> color pallette code (about 13 lines including comments) to integrate
> with customize's way of setting face attributes without having to
> create the faces first. I would probably remove those 6 lines if I
> felt like taking the time to track what they did through the Emacs
> sources and be sure of what I could do in ELisp to replace them.
Ah. I fear I've been unclear here. I meant `elisp' when I said
`customization': I don't use customize itself at all.
> I'm not unsympathetic to the difficulties new users face in learning
> Emacs. But a good part of Emacs's benefits come from what you can do
> with a little knowledge of ELisp. When an Emacs user now comes to
> this point they are faced with a .emacs file filled with a large
> amount of customize babble which they are warned not to touch. If
> they have any sense of programming style, of course they will want to
> change it! What a horrible introduction to ELisp.
100% agreed --- although XEmacs has partially solved that by shoving
customize stuff into a separate file that .emacs (or .xemacs/init.el)
overrides.
> In childhood development we find it important to ween babies from
> their point-and-grunt stage and teach them simple sentences as soon as
> possible. Literacy is something one does not postpone or put off,
> unless you are trying to create a permanent under-class.
Quite so. Why people think point-and-click is better than languages,
when languages are humans' strong point, is quite beyond me.
> I have programmer friends who I can talk to freely about all things
> except Lisp. They will argue or agree about abortion, gun rights,
> belief in god, C++, Microsoft, whatever. But if I even mention Lisp
> they just mumble something nasty under their breath and refuse to
> discuss it.
Same here: they seem to associate it with punched cards and ancient
record-keeping systems, simply because the language family is old.
They don't realise that in this case `old' does not mean `bad'.
> And they haven't even heard of 'comp.lang.lisp'!
>
>> `There's something satisfying about killing JWZ over and over again.'
>> -- 1i, personal communication
>
> Lets not dwell on it!
This from a user of mine who added a JWZ character as a barkeep in a MUD
she works on ;}}}
--- oops, Jamie reads this group, doesn't he... ;}
Nix
> I can't live without Emacs any more. The last time someone thought,
> ``hey! Mike's a computer-guy; he can fix my Windows machine'' and
> forced me to use Notepad, I ended up printing a half-dozen copies of
> some config file while trying to go to the previous line (C-p) before
> I realized why the cursor wasn't moving...
When I'm forced to use MS Word, I find myself deleting the entire
document quite frequently, because C-a selects everything, and then
typing deletes it...