Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Are there any LISP development systems that are VC, or other GUI IDE like?

71 views
Skip to first unread message

Robert Posey

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Dear Gentle Sirs,

While the interpreted, or incremental compiled nature of LISP is growing on
me I still find all the systems I have used to be a pain. I want to have
the classic watch function where I can step through the code and watch
my variables change. I want break points that are set with a click, instead
of modifying code. Is there a LISP IDE that has these functions for a
reasonable price? Another nice to have would be automatic completion for
structures or classes instants.

Muddy

David Bakhash

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Robert Posey <mu...@raytheon.com> writes:

If you're not writing any serious apps, but are just learning the
language, then I'd just use Emacs Lisp with its cl.el package.

If you start Emacs or XEmacs, and then evaluate:

(load "cl")

then you can access the step-wise debugger and evaluator. It's really
very smooth. I use it in XEmacs all the time.

If you absolutely insist on using an ANSI CL implementation, then I
don't know the answer. I have wished for the same, and never found it
in either Allegro CL (Franz) or Harlequin LispWorks. Surprisingly,
(X)Emacs beats them both in this respect, as far as I know.

dave

Robert Posey

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to

David Bakhash wrote:
>
> Robert Posey <mu...@raytheon.com> writes:
>
> > While the interpreted, or incremental compiled nature of LISP is growing on
> > me I still find all the systems I have used to be a pain. I want to have
> > the classic watch function where I can step through the code and watch
> > my variables change. I want break points that are set with a click, instead
> > of modifying code. Is there a LISP IDE that has these functions for a
> > reasonable price? Another nice to have would be automatic completion for
> > structures or classes instants.
>
> If you're not writing any serious apps, but are just learning the
> language, then I'd just use Emacs Lisp with its cl.el package.
>
> If you start Emacs or XEmacs, and then evaluate:
>
> (load "cl")
>

The class required ANSI CL, though I would prefer not to support Elisp for the
same reasons that Visual J is disliked. I haven't really run any Elisp programs
in the debugger, though their compiler error messages are so much better than
CLISP or Harlequin that I have started writing programs to meet Elisp's
non-standard(read as evil) case sensitive requirements. I guess I will have
to try the debugger. Does ELISP have a way to display watches like a C
compiler.

BTW do you have an interface to CLISP built into your XEmacs? I downloaded
ILISP
but I have tried to install it. I will admit that Linux, XEmacs still gives
me problems. I sure hope that if Microsoft is broken up, one of the parts
supports Linux in a big way with user friendly tools that are still highly
configurable. Despite their problems Microsoft still has the ease for
casual user department locked up.

Muddy

Eugene Zaikonnikov

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
In article <cxjg0v3...@engc.bu.edu>,
David Bakhash <ca...@bu.edu> wrote:

> If you absolutely insist on using an ANSI CL implementation, then I
> don't know the answer. I have wished for the same, and never found
it
> in either Allegro CL (Franz) or Harlequin LispWorks. Surprisingly,
> (X)Emacs beats them both in this respect, as far as I know.
>

You may want to have a look on Lispdebug by Marc Mertens. Basically it
does all the things I expect from visual debugger. I can't remember its
URL, but web search returned
http://sunsite.unc.edu/pub/Linux/devel/lang/lisp/lispdebug-0.9.tgz
The author also helped a lot with debugger setup. Thanks Marc!

--
Eugene.


Sent via Deja.com http://www.deja.com/
Before you buy.

Robert Posey

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to

Does it work in windows, its written TCL\TK so it should in theory?

Erik Naggum

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
* Robert Posey <mu...@raytheon.com>

| While the interpreted, or incremental compiled nature of LISP is growing on
| me I still find all the systems I have used to be a pain.

Common Lisp systems provide more powerful hammers. if you are used to
C/C++, you are numbed to the pain of hitting your thumb with a puny
hammer (at least conceptually), but now that you hit your thumb that much
harder, it hurts again, that much more. the solution is to quit hitting
your thumb, not to pad your thumb or stifle the hammer's power.

at some point in time, you learned the C/C++ way, without reference to
much anything, right? at this point in time, you should endeavor to
learn the Common Lisp way, without reference to much anything. study how
people experience in the Common Lisp way do it. do not attempt to use
your C++ expertise in Common Lisp. what works for C/C++ has evolved over
time to be the least painful and/or most efficient. what governs
qualities such as "least painful" and "most efficient", however, are
vastly different for Common Lisp. it's that simple, really. _after_ you
have established rapport with your environment, you should compare them
in terms of what you can accomplish in each with how much work, not in
terms of how well a later experience emulates some environment that just
happened to be a prior experience.

most people, when they have learned something, tend to think in extremely
concrete terms about what they are doing. they think they click on menu
bars, drag an object, double-click on icons, etc. they _don't_ think in
terms of the operation that said physical activity causes to take place,
even though that is why they perform these physical actions. so when
they want to perform that operation in a new environment, they completely
_ignore_ the fact that they once had to associate the operation with
these actions, and now request the actions, as if the action and the
operation were the same. well, they very obviously aren't, and if they
think that way, they failed to learn what they were doing in a productive
and efficient way -- they instead learned to parrot actions. the sooner
human beings get out of this modus operandi and become _thinking_ beings,
the better, and if it hurts a little to get out of parrot mode, so be it.
most everything worth doing is associated with effort and some pain.

so, to answer your real question: no, we don't debug functions the same
way in Common Lisp as in static languages.

inserting code to get the equivalent of (conditional) breakpoints isn't a
problem, btw, since you can edit and recompile a function in seconds, and
if you have to do it with a mouse click, teach Emacs to insert "(break)"
and recompile the function upon a mouse click. I fail to see the value
of such a user interface function, but, hey, it's been years since I set
a breakpoint in any C code, too, precisely because I'm much more used to
the Common Lisp way, and even the best C debuggers _suck_, so I spend a
little more time thinking about the code I write and experimenting in --
you guessed it, Common Lisp -- before I commit the design to C, almost as
if by hand-compiling code in a real language into machine instructions
burned into an EEPROM or something equivalently hardware-like and way
cumbersome to deal with. odd as it may seem, writing bug-free C code is
really a breeze once you have come to appreciate and think in Common Lisp.

#:Erik

Eugene Zaikonnikov

unread,
Feb 10, 2000, 3:00:00 AM2/10/00
to
In article <38A1BFFF...@raytheon.com>,

Robert Posey <mu...@raytheon.com> wrote:
> Does it work in windows, its written TCL\TK so it should in theory?
>
Have no idea really. Looks like it tuned for Linuxen. Perhaps you could
make it working with use of something like gnu-win32, at least you must
be able to run configure scripts in your system.

Jeff Dalton

unread,
Feb 10, 2000, 3:00:00 AM2/10/00
to
Erik Naggum <er...@naggum.no> writes:

> ... and experimenting in --


> you guessed it, Common Lisp -- before I commit the design to C, almost as
> if by hand-compiling code in a real language into machine instructions
> burned into an EEPROM or something equivalently hardware-like and way
> cumbersome to deal with. odd as it may seem, writing bug-free C code is
> really a breeze once you have come to appreciate and think in Common Lisp.

I've done that too, for things I had to "deliver" in Java.

There are a couple of things that are provided by typical Lisp
implementations (even very simple ones) that I find to be a huge
help: they're interactive, so that I can type in expressions to
try things out; and a fair range of data types have a "printed
representation" that allows me to include instances in source
code. That means I can test things without having to write a
bunch of I/O routines first. (Even if I can't type something
in "directly", it's almost always easier to write something that
translates from a list than from a string.

Java's a fine example of a language that doesn't quite get this right.

-- jd

Marco Antoniotti

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to

Erik Naggum <er...@naggum.no> writes:

> * Robert Posey <mu...@raytheon.com>
> | While the interpreted, or incremental compiled nature of LISP is growing on
> | me I still find all the systems I have used to be a pain.
>

> inserting code to get the equivalent of (conditional) breakpoints isn't a
> problem, btw, since you can edit and recompile a function in seconds, and
> if you have to do it with a mouse click, teach Emacs to insert "(break)"

^^^^^

Erik, you are assuming that Robert is using Emacs :) A bit
unwarranted, isn't it? :)

Mayne the first step is to start using Emacs and dump the "Visual
Whatever" editor. (Which, btw, usually does a very poor job at
formatting C/C++, w.r.t. the real thing).

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa

Raymond Wiker

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Marco Antoniotti <mar...@parades.rm.cnr.it> writes:

> Mayne the first step is to start using Emacs and dump the "Visual
> Whatever" editor. (Which, btw, usually does a very poor job at
> formatting C/C++, w.r.t. the real thing).

No kidding :-) Trying to use the Microsoft offerings
(in general, including Visual Studio, Internet Explorer, Word and
Outlook) is like having your power drill replaced with a hammer and
chisel, with the added twist that the hammer handle is made from soft
rubber.

There - I feel much better now :-)

--
Raymond Wiker, Orion Systems AS
+47 370 61150

Fernando D. Mato Mira

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Raymond Wiker wrote:

> No kidding :-) Trying to use the Microsoft offerings
> (in general, including Visual Studio, Internet Explorer, Word and
> Outlook) is like having your power drill replaced with a hammer and
> chisel, with the added twist that the hammer handle is made from soft
> rubber.
>
> There - I feel much better now :-)

<rant>
And crashes notwithstanding, anyone that has worked with SGI CaseVision
knows that VisualStudio's
threads debugging is a joke.

There (me too)
</rant>

Now, I would hold writing source stepping/breakpointing support for
Emacs for a month, and start by adding watchpoint
support to your CL implementation, if it's not there. [Visual Whatever's
"Watch Window" are NO watchpoints! You need CompuWare SoftICE! Or
Rational Purify (slower and requires instrumentation, but at least you
can get it on Unix - except Linux [Is Rational a "Microsoft company"?]),
or a real ICE..]


--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720

www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html


Fernando D. Mato Mira

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
"Fernando D. Mato Mira" wrote:

>
>
> Now, I would hold writing source stepping/breakpointing support for
> Emacs for a month, and start by adding watchpoint
> support to your CL implementation, if it's not there. [Visual Whatever's
> "Watch Window" are NO watchpoints! You need CompuWare SoftICE! Or

Of course, in Lisp they are not that important, while when using C(++)..

Duane Smith

unread,
Feb 13, 2000, 3:00:00 AM2/13/00
to
Hi,

I am a new LISP programmer - coming from a background of the Visual
Studios tools - and trying to figure out how to setup a similar
environment in emacs. I use the Allegro CL package and their
"fi:common-lisp" editing mode, which does provide some nice features
(indenting, color-coding code, etc), but I still feel that it lacks a
lot of the features of the MS tools. I understand that others who have
been using emacs have discovered that it is a superior tool; however,
I am at a loss to make this discovery for myself. Are there any
on-line documents that document emac's functionality as far as making
the MS tools "like having your power drill replaced with a hammer"?

Thanks in advance,
Jonathan


On Fri, 11 Feb 2000 10:24:29 GMT, Raymond Wiker <ray...@orion.no>
wrote:

>Marco Antoniotti <mar...@parades.rm.cnr.it> writes:
>
>> Mayne the first step is to start using Emacs and dump the "Visual
>> Whatever" editor. (Which, btw, usually does a very poor job at
>> formatting C/C++, w.r.t. the real thing).
>

rposey

unread,
Feb 13, 2000, 3:00:00 AM2/13/00
to

"Pierre R. Mai" <pm...@acm.org> wrote in message
news:87900oe...@orion.dent.isdn.cs.tu-berlin.de...
> Duane Smith <n...@spam.com> writes:
>
> To find out various general (and specific) statements of the
> functionality of Emacs, just do a search on c.l.l for articles related
> to Emacs (I've written a couple myself, and most other regular posters
> here have done so, too.) on DejaNews.
>
> Some basic aspects that sum up the differences between VS and Emacs
> for me are: Emacs is not MicroSoft, Windows, Visual, Point&Click,
> it's programmable in a real programming language (Emacs Lisp), it
> has incorporated the combined experience of over 20 years of Emacs
> editing. It's not trying to compete on flashiness, it's competing
> on real-life usability. This difference in spirit permeates nearly
> all design decissions, so it's just a worlds apart experience.

Emacs documentation at best cryptic, while Visual Studio is great though
lacking in depth. Emacs maybe able to do anything, but it requires a lot of
work(I do mean a lot) and special knowledge. NONE of the many packages
I have tried seems to work exactly as described, or they leave out some
details.
I will admit that the Visual Studio Editor is not quite as nice as EMACs
with
the proper setup, but it is intergrated much nicer than any setup I have
seen. The
problem I have is that its such a pain to make any modifications, it needs a
lot more
emunerated lists of options. I am using EMACs right now with CLISP, and I
still
can't get it to work in a reasonable manner despite the fact the ILISP
package is
supposed to make it easy. I convinced that at least 80% of the dislike of
Visual
Studio is a really a protest against Microsoft. I will admit I am going to
like EMACs,
but I would NEVER, ever chose it as a tool for a software group unless I had
a
person to costumize it for job. Thats not a problem with most commerial
Software.
Actual EMACS is the worst, since it not delivered with a lot of the packages
you
are going to need.

EMACS would be improved 200% if someone would just modify the interface
packages so that they would install using a point and click installer
program.

Muddy


>
> Regs, Pierre.
>
> --
> Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest
Keyserver
> "One smaller motivation which, in part, stems from altruism is
Microsoft-
> bashing." [Microsoft memo, see
http://www.opensource.org/halloween1.html]

Pierre R. Mai

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Duane Smith <n...@spam.com> writes:

> I am a new LISP programmer - coming from a background of the Visual
> Studios tools - and trying to figure out how to setup a similar
> environment in emacs. I use the Allegro CL package and their
> "fi:common-lisp" editing mode, which does provide some nice features
> (indenting, color-coding code, etc), but I still feel that it lacks a

^^^^^^^^^^^^ Automatic indenting is IMHO not a "nice" feature, it is
essential for any serious programming to take place, especially in the
team context: Without AI(<g>), you will either have to spend some
amount of your attention to manual indenting and/or produce unevenly
indented and therefore badly-readable code (remember: you write code
for your fellow programmers, not for the computer).

> lot of the features of the MS tools. I understand that others who have
> been using emacs have discovered that it is a superior tool; however,
> I am at a loss to make this discovery for myself. Are there any
> on-line documents that document emac's functionality as far as making
> the MS tools "like having your power drill replaced with a hammer"?

Let's turn this question around: Try to list what functionality from
the Visual Studio environment you find missing, why, and what you are
trying to achieve when you use this functionality. Given this list,
the readers of c.l.l will most likely be only to happy to point out

a) ways to obtain the functionality, or
b) explain other/better ways of obtaining the indented result, or
c) explain other/better strategies alltogether of achieving the real
objective,

where appropriate. This approach will probably help you more than
some on-line documents (for this, just read the fine documentation
that comes with your Emacs)...

To find out various general (and specific) statements of the
functionality of Emacs, just do a search on c.l.l for articles related
to Emacs (I've written a couple myself, and most other regular posters
here have done so, too.) on DejaNews.

Some basic aspects that sum up the differences between VS and Emacs
for me are: Emacs is not MicroSoft, Windows, Visual, Point&Click,
it's programmable in a real programming language (Emacs Lisp), it
has incorporated the combined experience of over 20 years of Emacs
editing. It's not trying to compete on flashiness, it's competing
on real-life usability. This difference in spirit permeates nearly
all design decissions, so it's just a worlds apart experience.

Regs, Pierre.

Christopher C Stacy

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
>>>>> On Sun, 13 Feb 2000 20:23:15 -0600, rposey ("rposey") writes:
rposey> Emacs documentation at best cryptic, while Visual Studio is great
rposey> though lacking in depth.

I would suggest that you start by reading the help information that
comes up immediately when you start emacs. On the fourth line you
will find two items: an on-line interactive tutorial, and a manual.
If you can't figure out how to proceed from there, then you should
probably just stick with Microsoft Visual Studio, and also forget about Lisp.


Erik Naggum

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
* Robert Posey

| Actual EMACS is the worst, since it not delivered with a lot of the
| packages you are going to need.

nonono, _you_ are the worst, since you have been delivered with a lot of
opinions instead of appreciation for the facts you would have needed to
form them.

| EMACS would be improved 200% if someone would just modify the interface
| packages so that they would install using a point and click installer
| program.

most users would be improved 200% if someone just replaced their concepts
of what "simplicity" is all about with something approaching intelligence
in design.

also, I think children should come with little infrared receptors that
obeyed the "mute" button on my remote control, so now I'm going to
complain vociferously to everybody who make children that they should
improve their children 200% by changing them so the remote control I use
to shut up TV commercials will work on annoying children, too.

try M-x customize RET the next time you feel like pointing and clicking.
if that doesn't help, do something entirely new and different, and RTFM.

incidentally, there _are_ good IDEs for Common Lisp, too, but I surmise
that your penchant for complaining out of ignorance will apply yet again,
so I won't harm the vendors of such IDEs by naming them so you can post
yet more negative drivel about stuff you don't understand. figure it out
for yourself -- you need to get used to figuring things out for yourself.

and while I'm speaking my mind, the reason intelligent, competent people
hate Microsoft is that that company alone has produced millions of people
just like you who have zero clue and an overpowering desire to prove it
to the entire world. "make a tool a fool can use, and only a fool will
use it" has never been truer than of the anti-educational, anti-skill-
building cruftware that Microsoft has made billions peddling to unwitting
losers who now think they have a clue about using computers productively
(which is very different from fooling around with them all day). they
don't, and thanks to Microsoft, they never will, unless they let go of
the myth that Microsoft has made using computers easy to use. in fact,
the only thing that Microsoft has made _real_ easy for their users is
handing over lots and lots of money to Microsoft in exchange for more
hype to believe in, more vaporware to wait for, and most of all, more
vehicles for viruses to get scared into bying more software to avoid.

don't follow up to this article until you have found and tried at least
three different IDE-based Common Lisp environments and have decided to
fail to complain about them. thank you for your cooperation.

#:Erik

Marco Antoniotti

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

"rposey" <robert...@worldnet.att.net> writes:

> "Pierre R. Mai" <pm...@acm.org> wrote in message
> news:87900oe...@orion.dent.isdn.cs.tu-berlin.de... > Duane
> Smith <n...@spam.com> writes:

> > > To find out various general (and specific) statements of the >
> functionality of Emacs, just do a search on c.l.l for articles
> related > to Emacs (I've written a couple myself, and most other
> regular posters > here have done so, too.) on DejaNews.
> > > Some basic aspects that sum up the differences between VS and
> Emacs > for me are: Emacs is not MicroSoft, Windows, Visual,
> Point&Click, > it's programmable in a real programming language
> (Emacs Lisp), it > has incorporated the combined experience of over
> 20 years of Emacs > editing. It's not trying to compete on
> flashiness, it's competing > on real-life usability. This
> difference in spirit permeates nearly > all design decissions, so
> it's just a worlds apart experience.
>

> Emacs documentation at best cryptic, while Visual Studio is great

> though lacking in depth.

You just pointed out one of the absolutely most unnerving things about
MS help stuff (BTW. StarOffice suffers from similar deficiencies).

> Emacs maybe able to do anything, but it requires a lot of work(I do
> mean a lot) and special knowledge.

Yes. It requires work (which I usually found to be "real" work, which
made me learn something), but it requires no "special" knowledge
(being knowledge of Lisp languages the cornerstone of computing :) ).

> NONE of the many packages I have tried seems to work exactly as
> described, or they leave out some details.

Have you tried ILISP (shameless plug: http://ilisp.cons.org)? I am
happy to improve the beast.

> I will admit that the Visual Studio Editor is not quite as nice as
> EMACs with the proper setup,

AFAIK C/C++ mode comes up automatically in the out-of-the-box Emacs.

> but it is intergrated much nicer than
> any setup I have seen.

Integrated with *what*. On a second (painful) note, is it better
integrated that the 80's Lisp Machine environments? :)

> The problem I have is that its such a pain
> to make any modifications, it needs a lot more emunerated lists of
> options. I am using EMACs right now with CLISP, and I still can't
> get it to work in a reasonable manner despite the fact the ILISP
> package is supposed to make it easy.

I am listening... what exactly does not work?

> I convinced that at least 80%
> of the dislike of Visual Studio is a really a protest against
> Microsoft.

It does come in to play.... I'd like the MS guys tell me why do you
need a web browser to install (read: install) a C/C++ development tool :)

> I will admit I am going to like EMACs, but I would
> NEVER, ever chose it as a tool for a software group unless I had a
> person to costumize it for job.

The most important support too for a group to work together is a
revision control system (CVS, PRCS, etc etc). These tools are not present
in the Visual stuff. There are hooks, but you need to buy and
configure one of these tools to work properly with Visual/*. Hence
you still need to do configuration work.

> Thats not a problem with most

> commerial Software. Actual EMACS is the worst, since it not


> delivered with a lot of the packages you are going to need.

Like.... I am writing this message with Emacs. :)

> EMACS would be improved 200% if someone would just modify the
> interface packages so that they would install using a point and
> click installer program.

What's wrong with

$ configure
$ make
$ make install

?

Stig E. Sandø

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
"rposey" <robert...@worldnet.att.net> writes:

> EMACS would be improved 200% if someone would just modify the interface
> packages so that they would install using a point and click installer
> program.

I had to to use Windows a couple of days and if I am not completely
wrong, Emacs had a clicky-click installer thing. The more Un*x-like
install:

$ ./configure --prefix=/where/you/want/emacs


$ make
$ make install

can hardly be called complex either. And if you use any decent
GNU/Linux-distribution it is also a clicky-click install (Redhat,
Debian, etc).

--
------------------------------------------------------------------
Stig Erik Sandoe st...@ii.uib.no http://www.ii.uib.no/~stig/

Raymond Wiker

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
[ Warning: low on LISP content, high on VS gripes. ]

Marco Antoniotti <mar...@parades.rm.cnr.it> writes:

> "rposey" <robert...@worldnet.att.net> writes:
>
> > Emacs documentation at best cryptic, while Visual Studio is great
> > though lacking in depth.
>
> You just pointed out one of the absolutely most unnerving things about
> MS help stuff (BTW. StarOffice suffers from similar deficiencies).

There's a difference in emphasis here. The MS documentation is
"optimised" for giving superficial information for casual users, while
Emacs gives (mainly) reference-class information for people who
actually *use* Emacs.

> > Emacs maybe able to do anything, but it requires a lot of work(I do
> > mean a lot) and special knowledge.
>
> Yes. It requires work (which I usually found to be "real" work, which
> made me learn something), but it requires no "special" knowledge
> (being knowledge of Lisp languages the cornerstone of computing :)).

Also, it's impossible (in my case, at least) to outgrow Emacs
- if you have a problem that is not already solved for you in Emacs,
you can write your own solution (or get somebody else to do it), and
if it's done right, it will feel as a natural part of Emacs. Contrast
this with Visual Studio: you can't even extend VS' knowledge about how
it should "compile" new file types (e.g, invoke an IDL compiler on
files with a .idl suffix.) When I started using Visual Studio almost
two years back, it was about as painful as if I were to try on clothes
that fit 20 years back.



> > NONE of the many packages I have tried seems to work exactly as
> > described, or they leave out some details.
>
> Have you tried ILISP (shameless plug: http://ilisp.cons.org)? I am
> happy to improve the beast.

On a slightly different note: if you use XEmacs, there is a
system for adding/deleting extension packages.

> > I will admit that the Visual Studio Editor is not quite as nice as
> > EMACs with the proper setup,
>
> AFAIK C/C++ mode comes up automatically in the out-of-the-box Emacs.

... and C/C++-mode in Emacs even understands C/C++ syntax. The
VS editor does not, e.g, try

void fun()
{
for (int i = 0; i < 5;
i++) /* this line will not be indented correctly */
; /* ditto */
}

In this case, the VS editor thinks that the semicolon on the
first line terminates a statement, and indents i++) as the beginning
of a statement.


> > but it is intergrated much nicer than
> > any setup I have seen.
>
> Integrated with *what*. On a second (painful) note, is it better
> integrated that the 80's Lisp Machine environments? :)

VS integrated? Hah. The Visual Studio editor gets completely
confused if you try to get it to indent code inserted by the GUI
designer. This is partly because the people who "designed" the GUI
macros (e.g, for message passing etc) decided to break common-sense
guidelines for how to write macros.

> > I convinced that at least 80%
> > of the dislike of Visual Studio is a really a protest against
> > Microsoft.
>
> It does come in to play.... I'd like the MS guys tell me why do you
> need a web browser to install (read: install) a C/C++ development tool :)

*I'm* convinced that the only people who actually like Visual
Studio have never used more powerful tools.



> > I will admit I am going to like EMACs, but I would
> > NEVER, ever chose it as a tool for a software group unless I had a
> > person to costumize it for job.
>
> The most important support too for a group to work together is a
> revision control system (CVS, PRCS, etc etc). These tools are not present
> in the Visual stuff. There are hooks, but you need to buy and
> configure one of these tools to work properly with Visual/*. Hence
> you still need to do configuration work.

Microsoft *has* a revision control system that comes with
Visual Studio. It's called SourceSafe, but is commonly known as
SourceUnsafe, because it has... weaknesses ;-)

Anyway, you still need to do configuration work on Visual
Studio. For instance, it is set up, *as default*, with tab size = 4,
and to compress whitespace as a number of tabs. This is *evil* and
needs to be changed before you start using Visual Studio.

> > Thats not a problem with most
> > commerial Software. Actual EMACS is the worst, since it not
> > delivered with a lot of the packages you are going to need.
>
> Like.... I am writing this message with Emacs. :)
>

> > EMACS would be improved 200% if someone would just modify the
> > interface packages so that they would install using a point and
> > click installer program.
>

> What's wrong with
>
> $ configure

> $ make
> $ make install

See my earlier comment about installing extension packages in
XEmacs. BTW: the ilisp "package" for XEmacs is somewhat old - I guess
the XEmacs package admins need to be told about the new version...

Fernando D. Mato Mira

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
rposey wrote:

> Emacs documentation at best cryptic, while Visual Studio is great though

ctrl-x ctl-s
ctrl-x ctl-v
ctrl-x 5 f
ctrl-k
ctrl-y
ctrl-w
ctlr-s
tab
meta-<
meta->
ctrl-g
M-x query-replace
ctrl-x ctrl-c

For Lisp:
meta-ctrl-q
meta-.
[plus basic things like eval expr, eval reqion, insert breakpoint (Talk,
HA!),..]

If your're brave:

M-x query-replace-regexp

[I'm a (X)Emacs dummy! And I don't want any other editor!]

Marco Antoniotti

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

Raymond Wiker <ray...@orion.no> writes:

> [ Warning: low on LISP content, high on VS gripes. ]
>
> Marco Antoniotti <mar...@parades.rm.cnr.it> writes:
>
> > "rposey" <robert...@worldnet.att.net> writes:
> >

> > > Emacs documentation at best cryptic, while Visual Studio is great

> > > though lacking in depth.
> >
> > You just pointed out one of the absolutely most unnerving things about
> > MS help stuff (BTW. StarOffice suffers from similar deficiencies).
>
> There's a difference in emphasis here. The MS documentation is
> "optimised" for giving superficial information for casual users, while
> Emacs gives (mainly) reference-class information for people who
> actually *use* Emacs.

I want both. I agree that Emacs could use more of the first form, but
having only that is IMHO worse.

...

> *I'm* convinced that the only people who actually like Visual
> Studio have never used more powerful tools.

Like Emacs :)

> > The most important support too for a group to work together is a
> > revision control system (CVS, PRCS, etc etc). These tools are not present
> > in the Visual stuff. There are hooks, but you need to buy and
> > configure one of these tools to work properly with Visual/*. Hence
> > you still need to do configuration work.
>
> Microsoft *has* a revision control system that comes with
> Visual Studio. It's called SourceSafe, but is commonly known as
> SourceUnsafe, because it has... weaknesses ;-)

I suppose you hve to get the top-of-the line VC/C++ package to see
it. One *huge* project I know of, uses ClearCase.

> Anyway, you still need to do configuration work on Visual
> Studio. For instance, it is set up, *as default*, with tab size = 4,
> and to compress whitespace as a number of tabs. This is *evil* and
> needs to be changed before you start using Visual Studio.
>

...


>
> See my earlier comment about installing extension packages in
> XEmacs. BTW: the ilisp "package" for XEmacs is somewhat old - I guess
> the XEmacs package admins need to be told about the new version...

The latest released version is 5.9.4 (soon to be 5.9.5), which can be
found at http://ilisp.cons.org. I guess I will have to find out who
the XEmacs people are.

(PS. Apologies. mail list subscriptions for ILISP are still broken).

Tim Bradshaw

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
* rposey wrote:
> EMACS would be improved 200% if someone would just modify the interface
> packages so that they would install using a point and click installer
> program.

XEmacs has this (Options / Manage Packages), FSF Emacs may well have.

I think that most of the Emacs problem you are describing is the usual
`I will not go up the learning curve' issue that people have with
basically everything.

--tim

Johan Kullstam

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
"rposey" <robert...@worldnet.att.net> writes:

> Emacs documentation at best cryptic, while Visual Studio is great

> though lacking in depth. Emacs maybe able to do anything, but it
> requires a lot of work(I do mean a lot) and special knowledge. NONE


> of the many packages I have tried seems to work exactly as
> described, or they leave out some details.

for basic emacs usage, i found the o'reilly emacs book helpful.
sometimes there's no beating dead trees. (you can also print out the
texinfo pages.)

also, people complain about emacs using lisp as an extension language.
if you don't know lisp at all, this could be a problem. this
shouldn't, however, be trouble for you since you know (or are
learning) lisp. my only complaint is that emacs lisp isn't common
lisp, but i guess you can't always have everything.

--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!

Fernando D. Mato Mira

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
I forgot:

ctrl-]
M-x apropos
M-x replace-string

Robert Posey

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

Christopher C Stacy wrote:
>
> >>>>> On Sun, 13 Feb 2000 20:23:15 -0600, rposey ("rposey") writes:

> rposey> Emacs documentation at best cryptic, while Visual Studio is great


> rposey> though lacking in depth.
>
> I would suggest that you start by reading the help information that
> comes up immediately when you start emacs. On the fourth line you
> will find two items: an on-line interactive tutorial, and a manual.
> If you can't figure out how to proceed from there, then you should
> probably just stick with Microsoft Visual Studio, and also forget about Lisp.

I have Read it, if you have used Microsoft Visual Studio help functions
at all you would find they are much better. However, a piece of software that
makes a user with good basic knowledge in computers and the task at hand read
a lot of documentation is using a very dated delivery concept. I think its sort
of
of sad when otherwise rational people let emotions cloud their comments and
opinion about technical subjects. As I said, I use EMACS for LISP, but
wouldn't use it for Windows C/C++ programing. Since VC++ is the dominate
platform in the windows environment I doubt that this opinion is fatally
flawed. I always find it strange when people become convinced that only
they know the true way to do something. Most if not all professional
programmers have had at least exposure to EMACS, and many don't use it.
I will admit, if you change languages a lot EMACS has a tremendous advantage
in that it has support for almost any language. However, the standard setup
for windows even with XEMACS lacks in initial polish. Its the same with
every freeware program I have ever seen, their basic underlying
function maybe better than the commercial systems, but ease of use suffers.

I will say again that EMACS could be made much, much better by developing
a standard install method that was point and click like windows.

Muddy

Paolo Amoroso

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
On Sun, 13 Feb 2000 20:23:15 -0600, "rposey"
<robert...@worldnet.att.net> wrote:

> Emacs documentation at best cryptic, while Visual Studio is great though


> lacking in depth. Emacs maybe able to do anything, but it requires a lot of
> work(I do mean a lot) and special knowledge. NONE of the many packages

Did you bother to check the--free--Emacs Lisp tutorial or the programming
book published by O'Reilly?


> I have tried seems to work exactly as described, or they leave out some
> details.

The fact that a package leaves out some details may depend on your frame of
reference.


> emunerated lists of options. I am using EMACs right now with CLISP, and I
> still
> can't get it to work in a reasonable manner despite the fact the ILISP
> package is
> supposed to make it easy.

ILISP is actively maintained (i.e. Marco Antoniotti is putting together new
releases like a rabbit :) and several users, including the CLISP authors,
provide valuable feedback for improving the way it works with ILISP. If you
have suggestions or you have found unknown bugs, let the maintainers know
about them.


> I convinced that at least 80% of the dislike of
> Visual

> Studio is a really a protest against Microsoft. I will admit I am going to

I suspect the other 20% of the dislike is a protest against C++.


> Actual EMACS is the worst, since it not delivered with a lot of the packages
> you
> are going to need.

Since a typical Emacs distribution is so small, and it does so few things
out of the box, it may be a good idea to deliver it with a lot of new
packages :) I simply can't understand why that funny Emacs icon looks like
a kitchen sink...


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Friedrich Dominicus

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Fernando D. Mato Mira wrote:
>
> I forgot:
>
> ctrl-]
> M-x apropos

you can get help more simply by just
C-h (a b c .....) ;-)

Regards
Friedrich

Robert Posey

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

Erik Naggum wrote:
>
> * Robert Posey


> | Actual EMACS is the worst, since it not delivered with a lot of the
> | packages you are going to need.
>

> nonono, _you_ are the worst, since you have been delivered with a lot of
> opinions instead of appreciation for the facts you would have needed to
> form them.
>

> | EMACS would be improved 200% if someone would just modify the interface
> | packages so that they would install using a point and click installer
> | program.
>
>

<Deleted a bunch of meaningless ramble>

> incidentally, there _are_ good IDEs for Common Lisp, too, but I surmise
> that your penchant for complaining out of ignorance will apply yet again,
> so I won't harm the vendors of such IDEs by naming them so you can post
> yet more negative drivel about stuff you don't understand. figure it out
> for yourself -- you need to get used to figuring things out for yourself.

I have facts that prove you are wrong, but I not telling( Because I don't
believe them myself, or I am really unwilling to chance a real debate).
Not that there is any reason for his attitude at all.

>
> and while I'm speaking my mind, the reason intelligent, competent people
> hate Microsoft is that that company alone has produced millions of people
> just like you who have zero clue and an overpowering desire to prove it
> to the entire world. "make a tool a fool can use, and only a fool will
> use it" has never been truer than of the anti-educational, anti-skill-
> building cruftware that Microsoft has made billions peddling to unwitting
> losers who now think they have a clue about using computers productively
> (which is very different from fooling around with them all day). they
> don't, and thanks to Microsoft, they never will, unless they let go of
> the myth that Microsoft has made using computers easy to use. in fact,
> the only thing that Microsoft has made _real_ easy for their users is
> handing over lots and lots of money to Microsoft in exchange for more
> hype to believe in, more vaporware to wait for, and most of all, more
> vehicles for viruses to get scared into bying more software to avoid.


You are now my new Newsgroups Closed Mind of Year. I guess you must feel
really threaten that more people can use computers without the high
initial price. Technology is not a social club, it should always be
made as easy to use as possible. If you really think anyone would doesn't
want to waste time learning painfully complex tools for every new task
is a loser, you need to reconsider the task. If this crazed rant is a
result of some deep emotion attachment to EMACS, GET A LIFE. Why you
think ease of use is anti educational, I will never know. All tools,
software or not should be designed to aid the user as much as possible
to do their job. Any learning curve time that involves the tool is
wasted time, and should be minimized. The tool expose information about
it functions and the basic task in layered way. That way if you are
trying to do a standard task, you don't have to have all the domain
knowledge to do it. Of course this has risks, but it of great benefit
when doing infrequent tasks.

>
> don't follow up to this article until you have found and tried at least
> three different IDE-based Common Lisp environments and have decided to
> fail to complain about them. thank you for your cooperation.

After this incredible childish response, you would dare to tell me what to
do. I have tried Corman, and Harlequin PE and they were okay I guess.
The very idea I can't comment about the faults that must exist in any
software is a joke. First of all I never said there weren't any
LISP IDE's that were as good as the VS family, I simply asked if there
were any like it. Your response is paranoid in the extreme, LISP and
EMACS aren't a religion so chill out. All editors, languages and
people have flaws and to pretend different makes you look foolish.
This is another example of one of the problems in EMACS, LINUX and
I guess LISP community, the desire to demonize the other side. Either
you like doing it MY WAY or you are stupid and part of the Grand
Microsoft plot to take over the world. I would also challenge you
to write a few programs with VC or Visual Basic and see if you don't
find some advantages. I will admit if you spend a lot of time customizing
EMACS it maybe better than VS or any other product. However, any time
you write your own software you should like the results better. I will
admit you pissed me off, for which I beg forgiveness for lack of emotional
control. However, either you are having a bad day, or you have some
deep hurts you need to deal with.


In Love and Trust,

Muddy


> #:Erik

Christopher C Stacy

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
>>>>> On Mon, 14 Feb 2000 11:30:08 -0600, Robert Posey ("Robert") writes:
Robert> I have Read it, if you have used Microsoft Visual Studio help functions
Robert> at all you would find they are much better.

I have used Visual Studio a lot, and I am familiar with its help
system, and I continue to disagree with you. However, I am not
interested in your opinion about either MS or Emacs.
I told you how to access the Emacs help functionality,
and as far as I am concerned, that's the end of it.
If you don't like Emacs, please move on to something else.
I am not interested in your opinion of Emacs (or anything else, actually).

Tim Bradshaw

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
* Robert Posey wrote:
> However, a piece of software that
> makes a user with good basic knowledge in computers and the task at hand read
> a lot of documentation is using a very dated delivery concept.

Damn, I had forgotten that this is the post-literate age.

--tim

Pierre R. Mai

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Friedrich Dominicus <Friedrich...@inka.de> writes:

> Fernando D. Mato Mira wrote:
> >
> > I forgot:
> >
> > ctrl-]
> > M-x apropos
>
> you can get help more simply by just
> C-h (a b c .....) ;-)

[Warning: spoof of an "argument" by a recent poster in this thread
ahead]

And, as Emacs is likely to tell you, using C-h ? to get help on all
the ways you can get help using C-h ;) And this is even explained on
the splash screen. Compare that to Visual Studio, where you'll have
to learn how to operate Menus, find F1 (which is arguably less
mnemonic than C-h for help ;), etc. all by yourself. What do you mean
everyone knows how to operate menus? So Windows is a club for the
initiated only? So Emacs is much more usable than Visual Studio...

Robert Monfera

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

The IDEs of ACL for Windows and LWW would give you a reasonable balance
of GUI-ness and Emacs-ness, the LWW IDE being closer to Emacs. Just a
simple example: both implementations give you incremental search, which
is not available on MS tools in general. Although ACL does not use
tooltips the way VB does, you still get to see the formal parameters of
a function on the top of the screen.

Some off-topic nit-picking:

Robert Posey wrote:

> I have facts that prove [Erik is] wrong, but I not telling( Because I


> don't believe them myself, or I am really unwilling to chance a real
> debate).

It must be a weird feeling to have facts proving someone wrong that you
either don't believe yourself or are unwilling to risk a real debate on
:-) These types of facts are called guesses, beliefs or suspicions.

> Any learning curve time that involves the tool is
> wasted time

Let's separate difficulty due to the inherent complex nature of
something versus difficulty due to incoherent, limitation-ridden and
careless implementation - calling them complexity and complication,
respectively. You can't do away with _complexity_ without reducing
functionality. Time spent on _complications_ may seem wasted (depending
on how determined we are to get somewhere), but time spent on
understanding and harnessing _complexity_ is time spent on our long-term
education.

> All editors, languages and people have flaws and to pretend different
> makes you look foolish.

Could you quote anyone claiming that someone or something is flawless?

> This is another example of one of the problems in EMACS, LINUX and
> I guess LISP community, the desire to demonize the other side.

As opposed to the more pragmatical attitude from Microsoft, like "let's
choke off Netscape's air supply".

> you like doing it MY WAY or you are stupid and part of the Grand
> Microsoft plot to take over the world.

I think _even_if_ Microsoft tools were better, some people would have
ethical problems using them.

> I would also challenge you
> to write a few programs with VC or Visual Basic and see if you don't
> find some advantages.

Anyone to volunteer hosting the event so that all of us can follow it
through MS NetMeeting?

Robert

Michael Hudson

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Warning: Rant ahead!

Robert Monfera <mon...@fisec.com> writes:

> The IDEs of ACL for Windows and LWW would give you a reasonable balance
> of GUI-ness and Emacs-ness, the LWW IDE being closer to Emacs. Just a
> simple example: both implementations give you incremental search, which
> is not available on MS tools in general.

It's there actually. Hidden, but present. What drives me up the wall
is having to reach for the bloody rodent every other second. Oh, and
that fact that I'm in Visual Studio generally means I'm programming to
the Win32 API (ick!), MFC (arguably worse) or ATL (a little less
grating, but amazingly badly flawed) using C++ (you didn't really want
to deference that pointer did you? Oh well, the defaults don't stop on
all memory violations (!!!!!!!!!!!), so you won't find out ... very
often), and coping with comedy bugs in the compiler (and other things
...) you have no chance of ever seeing fixed.

Just another Windows drop-out (and I haven't even graduated yet!),
Michael

PS: Sorry.

Harley Davis

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
rposey <robert...@worldnet.att.net> wrote in message
news:887p6k$b7ok$1...@flash.seas.smu.edu...

> Emacs documentation at best cryptic, while Visual Studio is great though
> lacking in depth. Emacs maybe able to do anything, but it requires a lot
of
> work(I do mean a lot) and special knowledge. NONE of the many packages
> I have tried seems to work exactly as described, or they leave out some
details.

Among the rhetoric from die-hard Emacs fans and the half-literate whining
from the VS fans, there are some valid points to be made.

In particular, despite being a Emacs man myself, I do have to admit that
going up the learning curve with Emacs is harder than climbing the VS
learning curve. Naturally, the view from the top with Emacs is much
better.

But I believe there is a social dimension to all this: Most (maybe all)
Emacs users that I know come from academic or industrial research
environments, working on either Lisp Machines or Unix or both, where there
was an extensive support community who maintained the tool and its
environment and mentored new users into the spirit of the community. I
would imagine it is very rare for a new user to come upon Emacs and develop
expertise and fondness for it sui generis - there is a lack of introductory
material and, more importantly, motivational examples of wizardly people
maximizing their productivity using this tool that at first glance seems
formidable indeed.

And I would think that this feeling is even more pronounced when the new
Emacs user comes from the Windows world, where the development tools have
traditionally been shoddy, and where, compared to its predecessors, Visual
Studio seems like a Great Leap Forward and a marvel of beauty, flexibility
and extensibility, while Emacs seems like a taciturn, barren cliff, loathe
to reveal its secrets to the newcomer.

-- Harley

Daniel Barlow

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Robert Posey <mu...@raytheon.com> writes:

> I will say again that EMACS could be made much, much better by developing
> a standard install method that was point and click like windows.

I install emacs about once a year, on average.

I use it every day.

There is a point to be made here about the relative utility of honing
the installation procedure versus, say, a blood pressure interface to
the Gnus adaptive scoring system.

-dan

Pierre R. Mai

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Michael Hudson <mw...@cam.ac.uk> writes:

> > simple example: both implementations give you incremental search, which
> > is not available on MS tools in general.
>
> It's there actually. Hidden, but present. What drives me up the wall

It is? Real _incremental_ search (i.e. the equivalent of C-s in Emacs)?
I'm suitably impressed if they have (after 7 years of MS Visual what
not) finally implemented something so "advanced". I guess incremental
regexp search (C-M-s) is still not included, though?

Raymond A. Wiker

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Robert Posey <mu...@raytheon.com> writes:

> made as easy to use as possible. If you really think anyone would doesn't
> want to waste time learning painfully complex tools for every new task
> is a loser, you need to reconsider the task. If this crazed rant is a
> result of some deep emotion attachment to EMACS, GET A LIFE. Why you
> think ease of use is anti educational, I will never know. All tools,
> software or not should be designed to aid the user as much as possible
> to do their job.

Please consider the difference between a tool that is easy to
use for somebody who only uses it occasionally, and a tool that gets
more powerful the more you use it. I've *never* been able to see the
point in optimising the user interface for non-users, which is exactly
what *every* Microsoft tool I've seen does.

What's more, it's actually easy to see, in a number of
document formats, whether a particular document has been prepared in a
Microsoft-style application or an application where the emphasis has
been put on correctness and *useful* functionality.

> Any learning curve time that involves the tool is wasted time, and
> should be minimized. The tool expose information about it
> functions and the basic task in layered way. That way if you are
> trying to do a standard task, you don't have to have all the
> domain knowledge to do it. Of course this has risks, but it of
> great benefit when doing infrequent tasks.

Is this the Windows "consistency" argument? Are you next going
to claim that all tools always use Ctrl-F for doing a
search-operation, and that it's always found in the "Edit" menu? And
that Cut, Copy and Paste are always Ctrl-X, Ctrl-C and Ctrl-V? I can't
wait...

> > don't follow up to this article until you have found and tried at least
> > three different IDE-based Common Lisp environments and have decided to
> > fail to complain about them. thank you for your cooperation.
>
> After this incredible childish response, you would dare to tell
> me what to do. I have tried Corman, and Harlequin PE and they
> were okay I guess. The very idea I can't comment about the
> faults that must exist in any software is a joke.

I think the argument is that these tools are not tools for
casual users, and your experience with them, so far, *is* that of a
casual user.

> First of all I never said there weren't any LISP IDE's that were
> as good as the VS family, I simply asked if there were any like
> it. Your response is paranoid in the extreme, LISP and EMACS
> aren't a religion so chill out. All editors, languages and
> people have flaws and to pretend different makes you look
> foolish.

A *big* difference here is that you are claiming to have found
weaknesses with Emacs/Xemacs after a few hours dabbling. Have you
noticed that none of the experienced users make similar complaints?
Further, that people who have used *better* tools *still* complain
about Visual Studio, even after they have used it for a while? Does
this suggest a basic difference?

> This is another example of one of the problems in EMACS, LINUX
> and I guess LISP community, the desire to demonize the other
> side. Either you like doing it MY WAY or you are stupid and
> part of the Grand Microsoft plot to take over the world. I
> would also challenge you to write a few programs with VC or
> Visual Basic and see if you don't find some advantages.

What makes you think that there *are* any advantages with
Visual Studio and Visual Basic? Visual Studio is (possibly) OK for
small, single-person projects by people who haven't been spoilt by
tools that do what they are supposed to do. Visual Basic is a
programming language for people without the skill set normally
required for serious programming, and neither the time nor the
inclination to learn. One possible advantage with the Visual Basic
environment is that you get reasonably short development cycles, but
guess what - the Lisp environments give you *more* of the same.

> I will admit if you spend a lot of time customizing EMACS it
> maybe better than VS or any other product. However, any time
> you write your own software you should like the results better.

Without modifying Emacs at all, it's a better editor for C/C++
files.


--
Raymond Wiker, Høyveien 55, 4800 Arendal
+47 370 22965

Fernando

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
On 14 Feb 2000 00:34:42 +0100, pm...@acm.org (Pierre R. Mai) wrote:


>Let's turn this question around: Try to list what functionality from
>the Visual Studio environment you find missing, why, and what you are
>trying to achieve when you use this functionality. Given this list,
>the readers of c.l.l will most likely be only to happy to point out

The autocompletion hints stuff (intellisense or however its
called). It's convenient. :-)


//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------

Fernando

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
On Sun, 13 Feb 2000 20:23:15 -0600, "rposey"
<robert...@worldnet.att.net> wrote:


>Emacs documentation at best cryptic, while Visual Studio is great though
>lacking in depth. Emacs maybe able to do anything, but it requires a lot of
>work(I do mean a lot) and special knowledge.

Maybe you should give Infodocks a try (at beopen.com). It's a
preconfigured emacs ide. I never used it myself, but it seems more
"user friendly".

Robert Posey

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

Harley Davis wrote:
>
> rposey <robert...@worldnet.att.net> wrote in message
> news:887p6k$b7ok$1...@flash.seas.smu.edu...

> > Emacs documentation at best cryptic, while Visual Studio is great though
> > lacking in depth. Emacs maybe able to do anything, but it requires a lot
> of

> > work(I do mean a lot) and special knowledge. NONE of the many packages
> > I have tried seems to work exactly as described, or they leave out some
> details.
>
> Among the rhetoric from die-hard Emacs fans and the half-literate whining
> from the VS fans, there are some valid points to be made.

I wouldn't consider my argument half-literate, whining perhaps but
literate whining. My major problem is that I have to use EMACS for weeks
at a time. This means I am always in the steep part of the curve. In the
Embedded World you often don't have much of a choice on tools, so using
it all the time isn't a good option.

>
> In particular, despite being a Emacs man myself, I do have to admit that
> going up the learning curve with Emacs is harder than climbing the VS
> learning curve. Naturally, the view from the top with Emacs is much
> better.
>

See above.



> But I believe there is a social dimension to all this: Most (maybe all)
> Emacs users that I know come from academic or industrial research
> environments, working on either Lisp Machines or Unix or both, where there
> was an extensive support community who maintained the tool and its
> environment and mentored new users into the spirit of the community. I
> would imagine it is very rare for a new user to come upon Emacs and develop
> expertise and fondness for it sui generis - there is a lack of introductory
> material and, more importantly, motivational examples of wizardly people
> maximizing their productivity using this tool that at first glance seems
> formidable indeed.

That is my case indeed, which is why I stated I would never choose it for
a development team tool UNLESS I had the mentors to setup and explain the
common interface. This problem could be relatively easily fixed by use
of installation routines, if the community wanted to. In the business world
tools that require a long period to learn add a lot to cost. Out of the Box
usability is very important.

>
> And I would think that this feeling is even more pronounced when the new
> Emacs user comes from the Windows world, where the development tools have
> traditionally been shoddy, and where, compared to its predecessors, Visual
> Studio seems like a Great Leap Forward and a marvel of beauty, flexibility
> and extensibility, while Emacs seems like a taciturn, barren cliff, loathe
> to reveal its secrets to the newcomer.
>

Exactly, one of the key problem is again the lack of refined setups. Without
mentors, a lot of people see EMACS as a painful tool that is hard to use.
Sure you hear claims that it is capable of great things, but often very hard
to believe when you can't even exit the program. Even I will admit the
ELISP system gives the best error messages I have seen in a LISP system. Its
a good example of what should be the norm for EMACS. Another problem is the
documentation is written from an Unix prospective, this means you are constantly
translating to windows terms. Its by no means a show stopper, but its a
constant
problem. I think the real reason some people come to hate EMACS is that they
encounter it most often when they are learning a new language, and thus the
two learning curves are multiplied. I have decided to learn EMACS in detail,
but I do plan to add Installation programs as soon as I know how.

Muddy


> -- Harley

Robert Posey

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

Robert Monfera wrote:
>
>
>
> > I have facts that prove [Erik is] wrong, but I not telling( Because I


> > don't believe them myself, or I am really unwilling to chance a real
> > debate).
>

> It must be a weird feeling to have facts proving someone wrong that you
> either don't believe yourself or are unwilling to risk a real debate on
> :-) These types of facts are called guesses, beliefs or suspicions.
>

Actually that statement was poking fun at the comment the previous poster had
made. I was implying the only reason people refuse to state their facts is
because they either don't exist, or they don't really believe them. I not
sure how you would get usable data to prove an Editor is better than all others.

Assuming neither choice lacked a vital feature, I not sure a proof is possible.

Muddy

Gareth McCaughan

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
Robert Posey wrote:

> I have Read it, if you have used Microsoft Visual Studio help functions

> at all you would find they are much better.

I use both every day. What help functions in Visual Studio
are you actually referring to? The ones that describe the
IDE, or the ones that describe the language you're using it
to write programs in?

The documentation that comes with Emacs doesn't include
documentation for C, or Lisp, or FORTRAN, or Smalltalk,
or Python, or [etc]. (Actually, there's some documentation
for *Emacs Lisp*.) Is that what you prefer about Visual
Studio?

> Since VC++ is the dominate
> platform in the windows environment I doubt that this opinion is fatally
> flawed.

This strikes me as a curious argument.

> I will say again that EMACS could be made much, much better by developing
> a standard install method that was point and click like windows.

Do you mean for installing Emacs itself, or for installing
add-on bits of Emacs -- new modes, and the like?

--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction

Bulent Murtezaoglu

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to

>>>>> "RP" == Robert Posey <mu...@raytheon.com> writes:
RP> [...] This means I am always in the
RP> steep part of the curve. In the Embedded World you often
RP> don't have much of a choice on tools, so using it all the time
RP> isn't a good option.

Unless you have the kind of embedded project you can use Linux or at
least a Unix based environment for. Those do exist and I suspect
will become more common above the PIC level.

[...]
RP> That is my case indeed, which is why I stated I would never
RP> choose it for a development team tool UNLESS I had the mentors
RP> to setup and explain the common interface. This problem could
RP> be relatively easily fixed by use of installation routines, if
RP> the community wanted to.

I don't think this is true. The problems you are outlining are not
really installation problems. Even if the set-up was properly
installed people whose development experience have been limited to
visual-mumble will need to overcome the culture shock. So yes, even
though you could make the initial install point and click (and it is
if you are using a Linux distribution and maybe emacs under
windows[??]), I don't think it will help you as much as you seem to
think.

RP> In the business world tools that
RP> require a long period to learn add a lot to cost. Out of the
RP> Box usability is very important.

Yes, I do wonder though if the cost of crippling people is higher in
the long term. The difference seems to be between getting something
working in a day and getting something working _and_ learning a tool
-- one that works well and will _not_ change gratuitously -- in maybe
a few days more. I think the latter is cheaper if you have the right
kind of people.

As MA pointed out it is ridiculous for VS to require you to install IE
(I am not kidding, the installation program tells you that if don't
install IE you won't get documentation or possibly a usable install).
There has to be a cost associated with accomodating the dual agenda
that this particular vendor has. I am being generous by saying dual
here. What will they do to you tomorrow? Is all this extra change
free to businesses?

I certainly feel like putting my fist thru the screen a few times
when the client requires development with MS -- do you think I don't
charge for this extra aggravation? So I know at least some businesses
are paying for it.

RP> [...] Another problem is the documentation is written
RP> from an Unix prospective, this means you are constantly
RP> translating to windows terms. Its by no means a show stopper,
RP> but its a constant problem. [...]

What I don't understand is _how_ all these people ended up building
extensive experience with Windows. It has only been half-way stable
since NT and that has only been around in the 4.0 incarnation since 96
or so. Did CS departments immediately jump to using Windows in 96 for
course work? Where did these people initially learn their profession?
Or are we talking about self-taught people and people who completed IT
programs where they did not get exposed much to Unix but used stuff
like 4GLs and such. It is amazing to me that there can be so many
programmers/engineers etc. w/o any non-Windows experience. Windows
has not been around for _that_ long!

[another post that prolly does not belong in cll by]

BM


Erik Naggum

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
* Robert Posey <mu...@raytheon.com>

| You are now my new Newsgroups Closed Mind of Year.

I just knew you were the authority on Closed Minds.

| I guess you must feel really threaten that more people can use computers
| without the high initial price.

at least your guesses are improving in quality -- now you make them about
issues on which you at least have relevant personal experience.

| Technology is not a social club, it should always be made as easy to use
| as possible.

sure. but not easier, as the genius once said.

| If you really think anyone would doesn't want to waste time learning
| painfully complex tools for every new task is a loser, you need to
| reconsider the task.

only someone who confuses a particular implementation of an idea with the
idea itself could say something so utterly devoid of intelligence.

| If this crazed rant is a result of some deep emotion attachment to EMACS,
| GET A LIFE.

and just what made you think in terms of deep emotional attachment, Robert?

| Any learning curve time that involves the tool is wasted time, and should
| be minimized.

_very_ good advice. and it has evidently worked wonders for you.

| After this incredible childish response, you would dare to tell me what
| to do.

children are supposed to be told what to do, but the stubbornness that
causes children to do the opposite of what they are told, no matter how
foolish or stupid, is the very definition of a childish reaction to being
told what to do. so why don't you do something to convince me that _I_
would benefit from talking to like you were an adult? so far, you have
respond _solely_ on what _you_ see as childish, and nothing else. if you
don't want to be treated as a stupid child, well, do something else. how
hard can it be? (and if it _is_ too hard for you, perhaps that's a clue?)

| The very idea I can't comment about the faults that must exist in any
| software is a joke.

sure is, but you're the first to make that joke. I must assume it made
you laugh to yourself because it's tragically unfunny to anyone else.

| Your response is paranoid in the extreme, LISP and EMACS aren't a
| religion so chill out.

so just what _are_ you so mortally afraid of, Robert, that this is what
you consider most helpful to your cause?

| All editors, languages and people have flaws and to pretend different
| makes you look foolish.

definitiely, but what about you, who actually _think_ people pretend
something so foolish?



| This is another example of one of the problems in EMACS, LINUX and I
| guess LISP community, the desire to demonize the other side.

and here I was under the impression that we learned this from you, but I
guess you know the Emacs, Linux and Common Lisp communities better than
anyone who is actually a member of any of them, and you certainly know
them far better than you know the community you came from, such that you
don't for a minute hesitate to extrapolate your expectations from your
home community to _all_ others without checking or waiting to see that
what you believe holds for the new and different communities you meet.

| Either you like doing it MY WAY or you are stupid and part of the Grand
| Microsoft plot to take over the world.

see? I _knew_ you had "demonize" written all over you. nobody thinks
like this, Robert, except morons who actually believe that accusations
such as that one reflects on anyone but themselves. but yes, I do think
you're terribly stupid. it has nothing to do with doing anything my way
or not, but rather the insistence that _you_ want things your way or not
at all. objects reflected in your PC screen are closer than they appear.

| I would also challenge you to write a few programs with VC or Visual
| Basic and see if you don't find some advantages.

trust me, I'm so smart I can find _some_ advantages with absolutely
anything, including killing people, using Perl, starting wars, installing
Windows on a would-be computer, or even help funding George W. Bush's
presidential campaign (he's _almost_ as clueless and negative about stuff
he doesn't grasp as you are), but that also means I'm so smart I can find
fundamental disadvantages that I don't want to pay for by the few, and by
now comparatively _irrelevant_ advantages I find. you see, unlike you,
smart people weigh costs and benefits, they don't just go for whatever
has _some_ advantages.

| I will admit if you spend a lot of time customizing EMACS it maybe better
| than VS or any other product.

now, why would you "admit" that? how would you know? what else that you
know nothing about do you "admit"? don't flatter yourself by pretending
to flatter me with superficial agreement to statements the ramifications
of the contents of which you cannot realize at your level of competence.
and I'm your Newsgroups Closed Mind of the Year, remember? as such, I'm
certainly not open to your admissions of ignorance disguised as groveling.

| I will admit you pissed me off, for which I beg forgiveness for lack of
| emotional control.

nah, I don't forgive people. I wait until they stop doing what they beg
forgiveness for, and shoot them down again if they repeat it, especially
after they have begged forgiveness for it, because that means they have
not learned, and not learning when you have the opportunity is the only
unforgivable sin. and, _actually_, begging forgiveness is the hallmark
of someone who is going to repeat the same sin over and over again.

| However, either you are having a bad day, or you have some deep hurts you
| need to deal with.

sure. I'll happily yield to your profound expertise in this area, too.

next time, try to speak _explicitly_ for yourself on psychological
matters, Robert, since that is what you are _implicitly_ doing, anyway.

good luck, "Muddy".

#:Erik

Marco Antoniotti

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

Paolo Amoroso <amo...@mclink.it> writes:

> ILISP is actively maintained (i.e. Marco Antoniotti is putting together new
> releases like a rabbit :)

It takes at least two rabbits. There are many :)

Marco Antoniotti

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

pm...@acm.org (Pierre R. Mai) writes:

> Michael Hudson <mw...@cam.ac.uk> writes:
>
> > > simple example: both implementations give you incremental search, which
> > > is not available on MS tools in general.
> >
> > It's there actually. Hidden, but present. What drives me up the wall
>
> It is? Real _incremental_ search (i.e. the equivalent of C-s in Emacs)?
> I'm suitably impressed if they have (after 7 years of MS Visual what
> not) finally implemented something so "advanced". I guess incremental
> regexp search (C-M-s) is still not included, though?

Well. It has been a design choice in all (IMHO) MS (and
competitor/emulators) software, to "dumb down" the user interface in
order to achieve visually "right" effects in a "fast" way, only to
have the solution bite you back when you need somethign just one iota
more sophisticated. I.e. "for all problems there is a solution that
is simple, fast and wrong".

My favourite is the "bullet" idea. Back in the MS Word 3 on the Mac
days, you would define your "itemize" styles yourself and you would
actually customize them correctly.

Now, the casual user hits the bullet button, the promote/demote arrows
and, lo and behold, the item numbering gets messed up. S/he then
passes the document to you, and you spend a *lot* of time doing and
undoing this numbering and itemizing etc. And I haven't even started
talking about Figures and (Numbered) Captions (alas, I haven't looked
ad Office 2000, maybe they saw the light).

Gimme LaTeX.

Marco Antoniotti

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

Gareth McCaughan <Gareth.M...@pobox.com> writes:

> In the same vein, if you type the start of a function
> invocation
>
> y = f(
>
> then it pops up a "tool-tip" box showing you the function's
> signature, and as you enter arguments it keeps the type of
> the one you're entering highlighted. Again, there are some
> gratuitous nastinesses; but, again, it's still good to have.

ILISP 5.9.4 does the same for Common Lisp under Emacs :) Yes. There
are some gratuitus nastinesses in ILISP as well :)

Raymond Wiker

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Gareth McCaughan <Gareth.M...@pobox.com> writes:

> Raymond A. Wiker wrote:
>
> > Please consider the difference between a tool that is easy to
> > use for somebody who only uses it occasionally, and a tool that gets
> > more powerful the more you use it. I've *never* been able to see the
> > point in optimising the user interface for non-users, which is exactly
> > what *every* Microsoft tool I've seen does.
>

> There's a very obvious point in it. It's non-users who buy
> the software. Users already have it. :-)

On what sort of criteria do non-users buy software? I cannot
think of any other (valid) reason than that somebody they
trust/respect has recommended it. If they buy a package merely because
they like the illustrations on the box, or because they've played with
it for 5 minutes in a shop, they deserve what they get...

> (This is perhaps unfair. I suspect that most copies of MS's
> development tools are bought by companies for their employees,
> and that the decision to use those tools is taken by people
> who do use them.)

I agree with the first part, but not the second. There are
*large* corporations where the developers have been switched from Unix
system (or whatever they are comfortable with, and works) to PCs, just
because PC's are good enough for the bean-counters, and they cost
slightly less. No thought is given to the fact that the developers'
productivity and motivation is lowered, and that the PC's require
about an order of a magnitude more in support personnel...

In this case, the employers deserve what they get.

--
Raymond Wiker, Orion Systems AS
+47 370 61150

Jason Trenouth

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
On Mon, 14 Feb 2000 18:17:28 +0100, Paolo Amoroso <amo...@mclink.it> wrote:

> I simply can't understand why that funny Emacs icon looks like
> a kitchen sink...

A new icon (on NT Emacs 20.x at least) has replaced the kitchen sink. We stared
cross-eyed at it for a long time, imagining it to be anything from a
thunderstorm to a mushroom, before someone told us it was a Gnu's face.

__Jason

Philip Lijnzaad

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
On 14 Feb 2000 23:45:33 +0000,
"Gareth" == Gareth McCaughan <Gareth.M...@pobox.com> writes:
Gareth> In the same vein, if you type the start of a function
Gareth> invocation

Gareth> y = f(

Gareth> then it pops up a "tool-tip" box showing you the function's

Does this involve a paperclip ?-)

Gareth> signature, and as you enter arguments it keeps the type of

For emacs lisp, there is eldoc:

;;; eldoc.el --- show function arglist or variable docstring in echo area

which works wonders; I suspect there are more language-specific versions of
such functionality out there (starting with etags and find-tag).

Philip
--
Not getting what you want is sometimes a wonderful stroke of luck.
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53

William Deakin

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Robert wrote:

> I wouldn't consider my argument half-literate, whining perhaps but literate
> whining.

This statment puzzles me as elsewhere you have state that you don't like reading. I
believe your words were 'However, a piece of software that makes a user ... read a
lot of documentation is using a very dated delivery concept.' I was under the
illusion that reading was a fundamental of literacy. But hey, maybe this is no
longer cool with you hep-cat daddios out there ;)

TTFN,

:) will

ps: It makes me curious as to what the most popular beat-combo is these days?


Jan Vroonhof

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Philip Lijnzaad <lijn...@ebi.ac.uk> writes:

> ;;; eldoc.el --- show function arglist or variable docstring in echo area
>
> which works wonders; I suspect there are more language-specific versions of
> such functionality out there (starting with etags and find-tag).

Ilisp (Common lisp) and JDE (Java). That is because these languages
actually provide the information needed in some reasonable form.

Eric Ludlam is working on this (and has a mostly working general
parser in Elisp!, incluse yacc equivalent). He has requested help from
people with parser experience to make it faster.

Jan

Marco Antoniotti

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

Jan Vroonhof <vroo...@frege.math.ethz.ch> writes:

He can do (require 'cl) and use all the CL facilities in Emacs Lisp.
Then he can port the beast to CL and compile it to native code. :)

Pierre R. Mai

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Robert Posey <mu...@raytheon.com> writes:

> That is my case indeed, which is why I stated I would never choose it for
> a development team tool UNLESS I had the mentors to setup and explain the
> common interface. This problem could be relatively easily fixed by use
> of installation routines, if the community wanted to. In the business world
> tools that require a long period to learn add a lot to cost. Out of the Box
> usability is very important.

Look, you keep repeating this mantra time and time again, but it is
wrong!

Out of the Box usability is very important in cases were the indented
audience are fleeting users only, i.e. ATMs, much end-user software
for non-professionals, etc. If you only use the tools some small
amount of time x in every week/month, and the time to learn the tool
enough to be able to accomplish simple tasks is y >> x, then yes, this
costs you dearly, and is clearly a very sub-optimal situation.

But extrapolating from this to all software, all tools and the whole
business world is just totally brain-damaged.

I'm currently part of the business world that supplies tools (in this
case simulation software) to other parts of the business world. The
tools we provide usually take a non-trivial time to learn, to even do
trivial things with them. Part of this time is needed because the
issue at hand (modelling) is non-trivial, and other parts of the
process are caused by the fact that the software is not optimized
towards out of the box useability, but rather for operational use in
every day business decissions by people who know (and need and want to
know) what they are doing.

We also offer out-of-the-box solutions, but those are much less
flexible, convenient and powerful in the long run, and therefore
provide much less leverage. There is also only one reason why they
are useable out-of-the-box: Because we make decissions for our
customers. This has advantages (out-of-the-box useability, no
only very limited understanding necessary), but also quite a number of
disadvantages (higher cost, less flexibility, no knowledge build-up in
the customer's organization, less leverage).

So does the long time to learn to use our tools proficiently add
significantly to the customer's cost? Yes. Does the power that is
gained by the user add significant value to the bottom-line? You
bet. When you are talking about savings on the order of several
million simulation project, you can let one person learn a very long
time (years) before the cost becomes significant. And this doesn't
take into account raised earning potential and customer satisfaction
because of increased flexiblity, and higher reliability in your
commitments.

Oh and BTW: None of the learning cost could be significantly lowered
by better _installation_ tools either for Emacs or for our products.
Have you really tried either XEmacs or BeOpen's InfoDock? Or maybe
you are confused as to what constitutes installation of a product?

> Sure you hear claims that it is capable of great things, but often very hard
> to believe when you can't even exit the program. Even I will admit the

How dumb would a user (we are talking about a professional programmer
in this case) have to be, to fail to (the following is based on
XEmacs, but similar things will apply to FSF Emacs and BeOpen's
Infodock):

a) Read the splash (startup) screen, which tells him exactly how to
leave Emacs:

<quote>
XEmacs comes with ABSOLUTELY NO WARRANTY; type C-h C-w for full details.
You may give out copies of XEmacs; type M-x describe-copying to see the conditions.
Type C-h C-d for information on getting the latest version.

Type f1 or use the Help menu to get help.
Type C-x u to undo changes (`C-' means use the Control key).
To get out of XEmacs, type C-x C-c.
Type C-h t for a tutorial on using XEmacs.
Type C-h i to enter Info, which you can use to read online documentation.
For tips and answers to frequently asked questions, see the XEmacs FAQ.
(It's on the Help menu, or type C-h F [a capital F!].)
</quote>

b) Use the menus (a skill that your average Windows user should be up
to), and find the Exit XEmacs menu item in the File (i.e. first)
menu, just where you would expect it under all other Windows
applications,

or

c) Find the Help menu (again just where it is in Windows apps), and
find all the useful help items (such things as "Basics"), which
will not only explain to him how to leave XEmacs, but how to use it
as well.

I'm sorry, but if leaving Emacs presents a problem to you (nowadays,
not in the 1980s), then you should most definitely not be programming,
or doing anything else that requires some amount of mental acuity.

> ELISP system gives the best error messages I have seen in a LISP
> system. Its a good example of what should be the norm for EMACS.

???? ELisp is the norm for FSF and X Emacs.

> Another problem is the documentation is written from an Unix
> prospective, this means you are constantly translating to windows
> terms. Its by no means a show stopper, but its a constant problem.

a) Emacs documentation isn't really written from a purely Unix
perspective. It's written more from an Emacs perspective
(e.g. compare frame vs. window in Emacs vs. X11). All Emacs terms
are defined within the documentation.

b) Well, the Visual Studio documentation is written from a purely
Windows perspective. Why is this no problem?

> I think the real reason some people come to hate EMACS is that they
> encounter it most often when they are learning a new language, and
> thus the two learning curves are multiplied. I have decided to
> learn EMACS in detail, but I do plan to add Installation programs as
> soon as I know how.

I'm still not sure what you mean by installation programs:

a) A InstallShield-like program that installs Emacs itself?

I don't see how this is going to buy you much in terms of
useability, when compared to the point&click installation of the
ZIP archive that my XEmacs for Windows came in.

b) Installation tools for add-on packages?

XEmacs 21.* already comes with those. They work point&click, even
automagically (e.g. automatic download of AucTex mode when you
first visit a *.tex file) and network-transparently. What more do
you need?

c) Something else entirely?

If you want "better" pre-configured settings, try BeOpen's Infodock
(in essence a well-packaged XEmacs with many flashy default
settings).

Pierre R. Mai

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Gareth McCaughan <Gareth.M...@pobox.com> writes:

> Robert Posey wrote:
>
> > I wouldn't consider my argument half-literate, whining perhaps but

> > literate whining. My major problem is that I have to use EMACS for weeks

> > at a time. This means I am always in the steep part of the curve. In the
> > Embedded World you often don't have much of a choice on tools, so using
> > it all the time isn't a good option.
>
> The only embedded-systems person whose toolset I know much
> about uses Emacs all the time. What about embedded systems
> makes you any less likely to be able to choose what editor
> you use?

Note also that since many years many people are choosing the GNU
tool-chain in the version distributed and supported by Cygnus.
This practically includes Emacs by default. And since Cygnus has
built it's riches (with exponential growth for most parts of the
last decade) on this product/business model, I'd wager that at
least a significant part of the embedded-systems "Business World"
sees things differently from their self-appointed speaker, Robert
Posey.

I'm not sure on this one, but someone pointed out to me that Cygnus is
the biggest _independent_ tool vendor for the embedded market (Cygnus
is now part of Red Hat, IIRC).

Joe Marshall

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

Gareth McCaughan <Gareth.M...@pobox.com> wrote in message
news:86putze...@g.local...

> In the same vein, if you type the start of a function
> invocation
>
> y = f(

>
> then it pops up a "tool-tip" box showing you the function's
> signature, and as you enter arguments it keeps the type of
> the one you're entering highlighted.

I thought this was sort of neat until the damn `tool-tip' box
obscured the thing I was looking at to figure out what
actual value I wanted to pass. The tool tip told me I should
pass an int, but it obscured the value of the int I wanted.

Eventually, MS will re-invent the mode line.

Robert Posey

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

Gareth McCaughan wrote:
>
> Robert Posey wrote:
>
> Only to people who are short-sighted and fixated on immediate
> profit rather than long-term success.
>
> Many things that are worthwhile take time to learn. Emacs
> is one. So is every programming language that's worthwhile.
> So is every operating system (and if you think Windows is
> an exception, think again. You've just forgotten learning).
>
> Emacs could be made to have an easier learning curve. I hope
> it will be. I'm not saying that ease of use doesn't matter.
> But I *am* saying that if you really think that everything
> you use has to be easy to use out of the box, then you deserve
> to fail and probably will. I don't actually believe that you
> think that, because clearly you know at least one programming
> language and are learning at least one other. So I don't
> understand why you say it.
>
I am a systems/embedded Test Engineer so while I haven't spent
more than 5% of my totally time programing I "Know" several
ASM's, C, C++, Visual Basic, and I am learning LISP and JAVA. I
have also used Fortran, Ada and Pascal so I am used to learning
curves. My problem is that if a tool has a very high learning curve
to do anything it is a much more painful experience to learn it
well. If you switch between systems all the time, that becomes
a major drag. I would whole heartily agree with your statements
that it is certainly better use the best system except that with
high turn-over and short cycle times it becomes a major pain. For
people who don't write software most of the time, the MS VS type
tools give them an easier startup time. Since they aren't writing
major applications(hopefully), the issues of it being good software
involve algorithm issues and not sw arch. I will admit that if
you program everyday in a semi stable environment that a highly
customizable editor like EMACS is the best choice. I will even
admit that EMACS is one of the best free ones, and the widespread
extension availability make it the best choice.

In a windows environment Visual C does have some advantages with
the ease of using MS various libraries, but I could easily see
using EMACS to write the code and then transferring to VC.

Actually of all Microsoft Development products the only one I really
like is Visual Basic. Not that I like basic, but because it fairly
well integrated into the MS Office products. This makes it a much
easier to use extendable macro language. Despite the security problems
VB. is one of the nicest things about MS Office Products.


BTW I am planning to learn EMACS for the reasons stated, I think there
maybe some vary nice commercial products, but while I am in school
EMACS is the best choice.

> I spend several hours each working day writing code at the moment.
> Suppose the figure is 4 hours a day, 4 days a week, 30 weeks a
> year; that should be a lower bound for anyone whose job involves
> a lot of programming. That means a minimum of 480 hours a year.
> If the Emacs environment takes 20 hours of solid work to get
> used to and makes you 10% more productive, the effort will pay
> for itself in less than 6 months.
>
> What was that about out-of-the-box usability, again?

See above, my situation is different. I have to repeat the learning
curve too often.

Robert Posey

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

William Deakin wrote:


>
> Robert wrote:
>
> > I wouldn't consider my argument half-literate, whining perhaps but literate
> > whining.
>

> This statment puzzles me as elsewhere you have state that you don't like reading. I
> believe your words were 'However, a piece of software that makes a user ... read a
> lot of documentation is using a very dated delivery concept.' I was under the
> illusion that reading was a fundamental of literacy. But hey, maybe this is no
> longer cool with you hep-cat daddios out there ;)


If I stated I didn't like reading I lied. I love to read, and I will admit I am
just now finishing the EMACS Manuals. I probably read 100+ books a year, with
20 of them technical books of some kind. However, I though you were using
half-literate to refer to my presentation of my arguments, not my lack of
reading ability.


Muddy

Jonathan Guthrie

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Gareth McCaughan <Gareth.M...@pobox.com> wrote:
> Robert Posey wrote:

>> I wouldn't consider my argument half-literate, whining perhaps but

>> literate whining. My major problem is that I have to use EMACS for weeks
>> at a time. This means I am always in the steep part of the curve. In the
>> Embedded World you often don't have much of a choice on tools, so using
>> it all the time isn't a good option.

> The only embedded-systems person whose toolset I know much
> about uses Emacs all the time. What about embedded systems
> makes you any less likely to be able to choose what editor
> you use?

Well, THIS embedded-systems programmer routinely uses Epsilon (which is
close enough to canonical Emacs so that the differences are somewhat
maddening) and XEmacs and vi. I don't use Visual Studio for anything as
the I use BATch files for the MS-DOS hosted stuff (and the languages
are typically BASIC and assembly language) and make files on any platform
where I can count on the presence of a decent make.

Back before I got this job and was programming gas flow computers, my
tools were GNU Emacs and make and a C cross-compiler. The choice of
compiler WAS dictated by the management (with my guidance--the Introl
compiler choked on binaries of the size we were trying to generate)
but I installed GNU Emacs and GNU Make from source.

Come to think of it, I used a recursive subroutine in that job for an
arithmetic expression evaluator, but I had to replace with a state-driven
because the cross-development system didn't have the setjmp/longjmp I
needed to handle errors. (I wouldn't do error handling the same way
now, but I didn't know what I was doing back then.)


Marc Battyani

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Robert Posey <mu...@raytheon.com> wrote in message
news:38A978F2...@raytheon.com...
.../...

> In a windows environment Visual C does have some advantages with
> the ease of using MS various libraries, but I could easily see
> using EMACS to write the code and then transferring to VC.

That's what I do.

I use XEmacs and when I have to do some VC++ I use the VisEmacs extension
that fits in Visual Studio and open the files(on the correct line) when you
click on the errors/warning messages.

One of the great advantage of using an editor not embedded into a
development tool is that you have only one editor to learn and use to edit
C/C++, VHDL, LISP, Python, Haskell, Java, JavaScript, HTML, IDL, SQL, etc.
And these days you might have to write the user interface in DHTML
JavaScript and Java, device drivers and low level stuff in C/C++, clever
useful and bug free core application stuff in Common Lisp and critical hard
real time stuff in VHDL...

;;; I hope I will have an honorable mention for the buzzword contest of the
day!

>
> BTW I am planning to learn EMACS for the reasons stated, I think there
> maybe some vary nice commercial products, but while I am in school
> EMACS is the best choice.
>

You won't regret it.

Marc Battyani

Harley Davis

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Marco Antoniotti <mar...@parades.rm.cnr.it> wrote in message
news:lwbt5i9...@parades.rm.cnr.it...

> Now, the casual user hits the bullet button, the promote/demote arrows
> and, lo and behold, the item numbering gets messed up. S/he then
> passes the document to you, and you spend a *lot* of time doing and
> undoing this numbering and itemizing etc. And I haven't even started
> talking about Figures and (Numbered) Captions (alas, I haven't looked
> ad Office 2000, maybe they saw the light).

It got worse.

-- Harley

Marco Antoniotti

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

"Harley Davis" <nospam...@nospam.museprime.com> writes:

I feared so. :{

Hartmann Schaffer

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
In article <87itzq2...@foobar.orion.no>,
Raymond Wiker <ray...@orion.no> writes:
> ...

> On what sort of criteria do non-users buy software? I cannot
> think of any other (valid) reason than that somebody they
> trust/respect has recommended it. If they buy a package merely because
> they like the illustrations on the box, or because they've played with
> it for 5 minutes in a shop, they deserve what they get...

do you want a cynical or a realistic explanation?

--

Hartmann Schaffer

It is better to fill your days with life than your life with days

Erik Naggum

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
* Robert Posey <mu...@raytheon.com>

| Sure you hear claims that it is capable of great things, but often very hard
| to believe when you can't even exit the program.

you know, it is getting harder and harder to believe anything you say
when you make such silly complaints. if you took the time to read the
stuff that is thrown in your face when you start up a default Emacs, if
not the first time you start it, at least the second time, when you have
sworn and gritted your teeth over not being able to exit the program the
first time, most of your silly complaints would simply vanish.

if I were you, I would be extremely hesitant to expose so much of my way
of dealing with things in general as you do on this Emacs topic, or,
worse, so much of your ability to learn from your experience. it seems
that if you already know how to do something in some context, any other
way is so broken that you don't even want to figure out what it would be.
now, who would want a _programmer_ who thinks like that?

| Another problem is the documentation is written from an Unix prospective,
| this means you are constantly translating to windows terms.

this could be why I don't understand your basic problems -- they are
expressed in Windows terms that lose so much precision in their
translation into tech-speak that they come out as baseless whining.

#:Erik

Gareth McCaughan

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
Philip Lijnzaad wrote:

[I said:]


> Gareth> then it pops up a "tool-tip" box showing you the function's
>
> Does this involve a paperclip ?-)

No. No paperclips *anywhere*. Not on my machine at work,
anyway. Every now and then I hear a howl of anguish from
across the office when someone else accidentally turns the
paperclip on. :-)

> For emacs lisp, there is eldoc:
>

> ;;; eldoc.el --- show function arglist or variable docstring in echo area

Oooo. I didn't know about that. Thank you. And thanks
likewise to Marco for telling me that ILISP has a similar
feature.

> which works wonders; I suspect there are more language-specific versions of
> such functionality out there (starting with etags and find-tag).

The tag-based stuff is nice, but it's more intrusive than
the Visual Studio thing. At least, it's more intrusive for
me. For someone with a better memory, who finds the
information useful less frequently, it's probably the
other way around.

Robert Posey

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

Gareth McCaughan wrote:
>
> Philip Lijnzaad wrote:
>

>
> > which works wonders; I suspect there are more language-specific versions of
> > such functionality out there (starting with etags and find-tag).
>
> The tag-based stuff is nice, but it's more intrusive than
> the Visual Studio thing. At least, it's more intrusive for
> me. For someone with a better memory, who finds the
> information useful less frequently, it's probably the
> other way around.

Visual Studio does have tags in a primitive way of bookmarks. It works pretty
well for the simple jumping around I do.

Muddy

Robert Monfera

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to

"Pierre R. Mai" wrote:

> a) A InstallShield-like program that installs Emacs itself?

Incidentally, I once have found a XEmacs distribution that used
InstallShield or its kin.

> b) Installation tools for add-on packages?
>
> XEmacs 21.* already comes with those. They work point&click, even
> automagically (e.g. automatic download of AucTex mode when you
> first visit a *.tex file) and network-transparently. What more do
> you need?

People completely new to Emacs may not know much about TeX, either - let
alone about the way of installation via just going through the *.tex
file. Also, although network-transparency does work on Windows, usually
Emacs and XEmacs freezes or won't exit properly when used. On Linux,
the Windows softmodems won't work (on Windows, they do, making the
machine 10-20% slower). There are indeed some annoyances because of
these silly reasons mostly occurring when someone is transitioning from
Windows.

> c) Something else entirely?
>
> If you want "better" pre-configured settings, try BeOpen's Infodock

AFAIK it doesn't work with Windows :-) Maybe the OP should just change
to Linux? (It was news to me anyway that Windows is being used for
embedded development.)

Robert

Steve Long

unread,
Feb 15, 2000, 3:00:00 AM2/15/00
to
My development environment:

Sun Ultra I (since it's gotta be Unix)
Allegro Common Lisp and Emacs
"Common Lisp - The Language", Guy Steele
"Common Lisp - The Reference", Franz Inc.
"Object-Oriented Common Lisp", Stephen Slade
"Teach Yourself SQL in 24 Hours", Sams
"C++: The Core Language", O'Reilly
"Unix Desk Reference", Peter Dyson

CD Player, ten CDs ranging from Wagner to Pink Floyd to Juno Reactor,
and a good set of head phones.

Tall americano, preferrably from Seattle's Best
Two Diet Cokes (neither shaken nor stirred)

Also, used to keep a collection of helpful AND useless (so I know the
difference)
hints from comp.lang.lisp from past
years (learned a great deal from everyone.)

I have MetroWerks Codewarrior on a Mac for C++ and Java work, but I've
never been as comfortable with the IDE as with the simple command-line
compiler.

sl


Marco Antoniotti

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Gareth McCaughan <Gareth.M...@pobox.com> writes:

...

> > which works wonders; I suspect there are more language-specific versions of
> > such functionality out there (starting with etags and find-tag).
>
> The tag-based stuff is nice, but it's more intrusive than
> the Visual Studio thing. At least, it's more intrusive for
> me. For someone with a better memory, who finds the
> information useful less frequently, it's probably the
> other way around.

Speaking of which...
ILISP support for tags is somewhat unsatisfactory. If anybody is
willing to look into it, it will be appreciated.

Another problem is 'etags'. Last time I checked (I should give it
another try, is my fellow countryman Potorti` listening :) ),
DEFMETHOD and friends did not get the right treatment.

Marco Antoniotti

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Steve Long <stev...@isomedia.com> writes:

> My development environment:
>
> Sun Ultra I (since it's gotta be Unix)
> Allegro Common Lisp and Emacs
> "Common Lisp - The Language", Guy Steele
> "Common Lisp - The Reference", Franz Inc.
> "Object-Oriented Common Lisp", Stephen Slade

"OO programming in CL", Sonya Keene <-- you are missing this one.

> "Teach Yourself SQL in 24 Hours", Sams
> "C++: The Core Language", O'Reilly
> "Unix Desk Reference", Peter Dyson
>
> CD Player, ten CDs ranging from Wagner to Pink Floyd to Juno Reactor,
> and a good set of head phones.

"Elio e le Storie Tese", The Complete Collection.

> Tall americano, preferrably from Seattle's Best
> Two Diet Cokes (neither shaken nor stirred)

A bottle of Montecorboli made by my friend Vieri somewhere between
Florence and Siena.

> Also, used to keep a collection of helpful AND useless (so I know the
> difference)
> hints from comp.lang.lisp from past
> years (learned a great deal from everyone.)

marcoxa@copernico:~ 51> du -s ~/lang/cl
295728 /users/marcoxa/lang/cl

Raymond Wiker

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
h...@inferno.nirvananet (Hartmann Schaffer) writes:

> In article <87itzq2...@foobar.orion.no>,
> Raymond Wiker <ray...@orion.no> writes:
> > ...
> > On what sort of criteria do non-users buy software? I cannot
> > think of any other (valid) reason than that somebody they
> > trust/respect has recommended it. If they buy a package merely because
> > they like the illustrations on the box, or because they've played with
> > it for 5 minutes in a shop, they deserve what they get...
>
> do you want a cynical or a realistic explanation?

Wouldn't they be the same :-?

Another factor that I forgot this time round is that of
"document compatibility": people and organisations keep buying (new
versions of) MS Word and Excel simply because they have become almost
universal, and because the "input filters" of competing programs are
not good enough to make sense of Microsoft's underdocumented formats.

William Deakin

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Marco wrote:

> Steve writes:
> > CD Player, ten CDs ranging from Wagner to Pink Floyd to Juno Reactor,
>

> "Elio e le Storie Tese", The Complete Collection.

Oh, what you young people listen to these days. In my day it was all
`Extreme Noise Terror', `Napalm Death' or `Dr. and the Crippins'. Something
with a beat that you can scream to ;)

:) will


Pierre R. Mai

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Raymond Wiker <ray...@orion.no> writes:

> Another factor that I forgot this time round is that of
> "document compatibility": people and organisations keep buying (new
> versions of) MS Word and Excel simply because they have become almost
> universal, and because the "input filters" of competing programs are
> not good enough to make sense of Microsoft's underdocumented formats.

Underdocumented and everchanging: Even Microsoft's input filters
can't cope with their own formats, much to often, both cross-platform
(i.e. Mac Word <-> WinWord), and cross-version (IIRC Word 97 had
serious trouble with Word 95 imports of non-trivial documents).

Pierre R. Mai

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Marco Antoniotti <mar...@parades.rm.cnr.it> writes:

> Steve Long <stev...@isomedia.com> writes:
>
> > My development environment:
> >
> > Sun Ultra I (since it's gotta be Unix)
> > Allegro Common Lisp and Emacs
> > "Common Lisp - The Language", Guy Steele
> > "Common Lisp - The Reference", Franz Inc.

Wot, no HyperSpec? I can't live Without the HyperSpec and Erik
Naggum's Emacs interface to it (browsed in Emacs via W3)... :)

> > "Object-Oriented Common Lisp", Stephen Slade
>
> "OO programming in CL", Sonya Keene <-- you are missing this one.

And "The Art of the Metaobject Protocol", by Gregor Kiczales et al.

Whenever I'm pondering how to design some extensible interface,
looking into the AMOP often suffices to come up with a good design.

Tim Bradshaw

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
* Raymond Wiker wrote:

> Another factor that I forgot this time round is that of
> "document compatibility": people and organisations keep buying (new
> versions of) MS Word and Excel simply because they have become almost
> universal, and because the "input filters" of competing programs are
> not good enough to make sense of Microsoft's underdocumented formats.

This is to understate the problem slightly. People keep buying *new*
versions of these programs because they are essentially virii. Each
new version of Word produces documents that old versions will not deal
with correctly. The format is also closed so it is not possible to
usefully reverse-engineer it. And people send you stuff in Word which
is important to your business. Therefore you *must* keep upgrading,
*even if Word is more expensive to own than other products*. Open
document formats can not compete against closed ones without
essentially regulatory help.

Note that the sense in which Word, say, is a virus, is much stronger
and more toxic than the sense that Gabriel claimed Unix was a virus in
the worse-is-better paper.

--tim

Espen Vestre

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
pm...@acm.org (Pierre R. Mai) writes:

> Even Microsoft's input filters can't cope with their own formats

...but's that part of their business model!

--
(espen)

Pierre R. Mai

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Robert Monfera <mon...@fisec.com> writes:

> > b) Installation tools for add-on packages?
> >
> > XEmacs 21.* already comes with those. They work point&click, even
> > automagically (e.g. automatic download of AucTex mode when you
> > first visit a *.tex file) and network-transparently. What more do
> > you need?
>

> People completely new to Emacs may not know much about TeX, either - let
> alone about the way of installation via just going through the *.tex
> file. Also, although network-transparency does work on Windows, usually

Well, AFAIK the automagic installation is not particular to AucTeX and
*.tex files, but rather a part of the package management system: At
least on my old 21.* beta for Windows, when I visit a file for which
the system knows that a major mode exists that is not installed, then
it offers to download it (IIRC). I just picked tex as an example
since that's where I found out about this feature.

I generally don't like this kind of automagic, but others do...

One way or another you can just as well go to Options/Manage Packages/
List&Install and do the selection and installing "manually", point and
click style, also from your local hard-drive. This is all described
in Options/Manage Packages/Help...

> Emacs and XEmacs freezes or won't exit properly when used. On Linux,
> the Windows softmodems won't work (on Windows, they do, making the
> machine 10-20% slower). There are indeed some annoyances because of
> these silly reasons mostly occurring when someone is transitioning from
> Windows.

Yes, all things Windows should be avoided where possible, or strange
things will happen (not only w.r.t. Emacs). Sadly it is the casual
users that get hit by this, and they can't do anything about it.

> > If you want "better" pre-configured settings, try BeOpen's Infodock
>

> AFAIK it doesn't work with Windows :-) Maybe the OP should just change
> to Linux? (It was news to me anyway that Windows is being used for
> embedded development.)

Yes, you are right, I remembered incorrectly: Only the OO-Browser is
available in precompiled format for Win32. Sorry for that. OTOH it
should probably pose no problem to contract with BeOpen for support on
Windows...

Robert Posey

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Erik Naggum wrote:
>
> * Robert Posey <mu...@raytheon.com>
> | You have to use the materials and people available to get the job done.
>
> this is the core of your attitude, I presume, so I'll let it stand out as
> something with which I _profoundly_ disagree, in one particular aspect:
> that such materials and people should not be vastly improved in order to
> get the job done. I have always believed that whatever was available to
> me were no more than _raw_ materials, and that failure to shape the raw
> materials into something better fit for the tasks at hand was the best
> way possible _not_ to complete those tasks.

I agree with you about what should be done, unfortunately I work for very
large company where I am totally unable to affect hiring policies. The concept
of spending time improving the tools, even something as minor as EMACS
customization
is strongly discouraged. In fact, given the near zero overhead budgets, it
could even be illegal to use customer money to improve tools. It certainly
would have to be approved.

>
> in particular, a computer does not serve very simple, well-defined needs,
> and it consequently always needs work to make it do exactly what I want.
>
> machines that serve simple, well-defined needs are called "appliances",
> which is why I call otherwise interesting computer hardware that runs
> anything Microsoftish "Windows appliances".
>
> | I guess I made a mistake when I mentioned a Microsoft Product, I always
> | expect technical issues to be debated without strong emotions.
>
> good engineers and scientists are the most passionate people I know.
> moreover, I'm confident that this is a univeral truth: competent people
> _feel_ strongly about quality. that's what makes it possible for them to
> keep quality on top of their list at all times -- if they had to _think_
> about quality consciously, it would be like using the conscious mind to
> walk or to drive a car or to make love.

Being passionate is not excuse for lack of ability to make rational arguments,
when people let their emotions control them, they fail to make arguments that
convince people. I certainly agree that good engineer approach their work
more as an obsession, that a job. I have never met a good engineer, much
less a great one who wasn't constantly striving to do better.

Actually I am considered somewhat of a fanatic myself, however in the
specification
driven world it is hard to get features included that would actually reduce
cost. This is mostly a result of the contract and cost center driven concept
my company works under. Since each project is largely financially separate,
the project manager never wants to pay for any additional training, or
tool development. Thus you get a lot of tools that maybe adequate for
the task, but lack the features that would be needed for they to be applicable
to
other projects. This of course a stupid way to manage a company, but I have
been unable to convert anyone who matters. The management loves to talk process
but won't spend any money on it. Of course the management is constantly
wondering why we don't get more reuse, while refusing to give time and budget
to produce reusable products. Since every program is measured in isolation,
the fact that it produces code that is hard to maintain, and not reusable is
not properly accounted for. The software people do make a lot of effort to
do the best they can, but they are too tied to the idea that each software
module should do no more than the actual written requirements. Their has
been some improvements, but it is still not where it should be.

>
> however, it has become clear to me in the past few years that lots of
> people have no emotions connected to their rational faculties whatsoever
> -- they simply feel _nothing_ when it comes to anything factual -- which
> is why you hear them claim that emotions are irrational. yeah, _their_
> emotions are irrational. technical people, however, seem to be able to
> deal with science and engineering as well as people emotionally, while
> the "people people" are restricted to deal with people emotionally and
> cannot fathom that anyone can possibly feel anything about a program.
>
> so _I_ guess you have never met a single competent engineer in your life,
> and now that you do, in this newsgroup, you stick to your belief that
> those who _feel_ anything about engineering and science must be madmen.

I never mean to say that they shouldn't feel strongly, but that shouldn't blind
them to both sides of an issue. To become so emotionally attached to a
EDITOR is a problem. If any complain about EMACS drives them to attack the
the commentator, they have lost touch with reality. EMACS is a fine program,
BUT many people hate EMACS with equal passion. When you allow your emotion
to so blind to other points of view, your engineering ability has been
severely compromised.


>
> this also explains why you react so emotionally to Emacs. it was never
> made for people like you. its very existence is probably an affront to
> your very belief system.
>
> | EMACS is just a editor, perhaps its the best one, but it is still just an
> | editor.
>
> exactly. you feel _nothing_ about software. probably sort of like I do
> towards sports as entertainment.
>
> | One of the things that does piss people off is extreme over reaction to
> | ANY complain about EMACS.
>
> don't flatter yourself. competent people get pissed off at idiotic
> complaints about anything, but there are literally millions of complaints
> about Emacs that have been taken very seriously by its developers and
> have caused competent people to make changes to Emacs to improve it.
>
> you, however, couldn't produce a constructive complaint about Emacs if
> your life depended on it, so don't pretend to speak for any experience
> other than serving up some idiotic complaints that truly annoy people.

Yet again a silly comment, since at least one person involved with the creation
of EMACS has agreed with one of my complains. If you think the widely
recognized relatively steep initial learning curve of EMACS doesn't exist you
have lost all touch with reality. I have heard 100's of people complain
about it, and since we are talking about a human factors issue this is
absolute proof. So unless you have knowledge of well conducted surveys
that disprove this basic point, you are the one making invalid unsupported
statements. I find it impossible to believe that anyone who has contact with
many people using a version of EMACS that has not been customer configured
has not heard a lot of complains. Engineers need to realize, that when you
are talking about human interfaces that how easy there are to use is an
undeniable quality factor. Is it the only one, of course not. However,
to assert that none of my arguments are valid, you have to prove that
many people don't have problems with EMACS. None of my complains ever stated
anything about EMACS being bad, or that people using it were wrong. I also
never stated that I liked how things were run at my company. However,
the paranoid of the EMACS Zealots has made them see things that aren't
there. Like I have said many times, I like XEMACS and plan to learn it
better. However, if I have time to contribute anything to the package it
will be to make it easier to use.

>
> I wonder, sometimes, why people who have demonstrated to have zero clue
> need to prove it so many times over. they don't grow clues by denying
> that clues exist, so why this need to pretend that what they have done
> was clueful? "ANY complain[t] about Emacs", for instance, is such an
> obviously bogus and self-serving exaggeration that it's _ridiculous_.

Read my posting again, and see if I ever said anything to justify the reactions
people made.
>
> | I for one find that people that can't handle criticism about their badly
> | often have the most doubts about their own point of view.
>
> is that why you can't handle criticism of your reactions here?
>
> by the way, wishful thinking like "there's something wrong with those who
> hate me" is a very useful psychological defense mechanism for those who
> are mentally unprepared to accept that other people aren't hateful to
> begin with and don't react without reason or observable cause. it is
> fairly interesting to watch people respond to criticism as if criticism
> of _them_ has to come from psychopaths, while they are eminently able to
> criticize just about anything, usually without justifiable reasons.

If any of you hate me for my comments you need serious help. I certainly
don't even dislike anyone in this conversation. I personally believe that
hating anyone is a serious flaw, but this conversation is so far from
justification for hate that baffles me that you would even mention the
word.


Deleted more unfounded comments from someone who has serious issues.


In Love and Trust,
Muddy

Ian Wild

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Robert Posey wrote:
>
> I work for very
> large company where I am totally unable to affect hiring policies. The concept
> of spending time improving the tools, even something as minor as EMACS
> customization
> is strongly discouraged. In fact, given the near zero overhead budgets, it
> could even be illegal to use customer money to improve tools. It certainly
> would have to be approved.

Are you never allowed to go home?

All the elisp I've ever written was done at home. Things
I thought would be useful at work then found their way here.
I can't imagine anyone busting you for spending a few seconds
^Xi-ing a defun or two to your own ~/.emacs. You could even
wait until lunchtime....


(And, yes, I've tried VS. I find it utterly baffling.)

Michael Kappert

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Robert Posey wrote:
> If you think the widely recognized relatively steep initial learning curve
> of EMACS doesn't exist you have lost all touch with reality.

I always thought 'having a steep learning curve' meant 'learning quickly'.
Also, i thought that a 'learning curve' was attributed to the person that
learns,
not to the thing being learned.

As a non-native english speaker, could someone explain this to me?

Michael


--
Michael Kappert
Fraunhofer IITB
Fraunhoferstr. 1 Phone: +49(0)721/6091-477
D-76131 Karlsruhe, Germany EMail: k...@iitb.fhg.de

Robert Posey

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Ian Wild wrote:


>
> Robert Posey wrote:
> >
> > I work for very
> > large company where I am totally unable to affect hiring policies. The concept
> > of spending time improving the tools, even something as minor as EMACS
> > customization
> > is strongly discouraged. In fact, given the near zero overhead budgets, it
> > could even be illegal to use customer money to improve tools. It certainly
> > would have to be approved.
>

> Are you never allowed to go home?
>
> All the elisp I've ever written was done at home. Things
> I thought would be useful at work then found their way here.
> I can't imagine anyone busting you for spending a few seconds
> ^Xi-ing a defun or two to your own ~/.emacs. You could even
> wait until lunchtime....

There are problems with this in the overregulated environment of
a Defense contractor, but I am doing this to learn and customize
EMACS. We also have the IT people to content with, you must understand that
we are not allowed install anything on our computers without permission.
Actually I do this often, but I am unwilling to do it for a huge group. Of
course for the company to get much lift off of the improved tools they have
to be standardized at least a functions supported level. I had an amazingly
hard time convincing TI(former owner) to get a support person to write a
macro for Mentor to automate a 15 minute process, with dozens of entries that
didn't change, but in which any mistakes caused the process to abort. They
did give me an award for it I will admit. However, if the support person
hadn't been a friend, it would have never happened. In this environment, the
tractability requirements make it very valuable to have all products produced
under costly controls. While most customizations of an editor would be okay,
the reluctance to spend much time on this is widespread. Of course no outside
vendor tool set is ever going to meet all our requirements without some
customization,
but there is great reluctance. BTW if anyone has any cost savings numbers to
support using customizable tools like EMACS, please post them or send them to
me at mu...@raytheon.com. I by no means like the environment I am in, but
I graduate in a year or so. Its not worth it to change at the moment.

Muddy


>
> (And, yes, I've tried VS. I find it utterly baffling.)

I will admit that VC and VJ are more than a little baffling, but Visual
Basic, when combined with Visual Basic for application is by far the easiest

Robert Posey

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Michael Kappert wrote:


>
> Robert Posey wrote:
> > If you think the widely recognized relatively steep initial learning curve
> > of EMACS doesn't exist you have lost all touch with reality.
>

> I always thought 'having a steep learning curve' meant 'learning quickly'.
> Also, i thought that a 'learning curve' was attributed to the person that
> learns,
> not to the thing being learned.
>
> As a non-native english speaker, could someone explain this to me?

I am not sure which is correct, but I have usually heard it used to describe the
process of learning a task. Each new concept or task has a learning curve that
is relatively fixed. However, a person learning the new task may start at
different
places on the curve. Thus the proper usage is to say a person is ON a Learning
Curve
and a Process has a Learning Curve. They can also progress at different rates
up
or down the curve. In the formal model, I not sure how exactly the rate of
progress
is modeled. I am only familiar with concept of people starting at different
places on
the curve. I think the concept of going down a learning curve refers a person
forgetting
a process they are not using. I maybe completely off on the formal concept, but
that
is the usage in this company.

Muddy

Jonathan Guthrie

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Robert Posey <mu...@raytheon.com> wrote:
> I went so far as to explain why the
> initial learning curve was a problem. Do I think its wise that companies
> don't make the effort to hire good people and train them on powerful tools
> like a customized version of EMACS can be.

I'm sure Mr. Naggum's rant is better, but here's mine:

How long does it take to learn that the up-arrow moves you up in the
file, the down arrow moves you down, the left- and right-arrows do the
obvious things, control-x control-s saves and control-c control-s exits?
To learn to make minimal use of an editor is the work of seconds.

Marking text and deleting or copying takes a few more seconds to learn.
Yes, to learn too nontrivial things takes a while, but most of what
beginners do with editors is trivial. (I would say that most of what
advanced users do with editors is trivial, but there are people who do
EMACS Lisp as automatically as they breathe.) Most of the rest is
specialized to the application and, therefore, is limited.

I used vi for years before learning how to cut-and-paste between files.

> Of course not, but having no desire to
> rise above a lead technical position there is nothing I can do about that.

That's another thing about what you say. Technical lead is going to be
responsible for specifying positions and qualifying candidates. You have
to be if you expect to get the people you need to do the job. That is,
if you take the job you say you don't want to rise above, you WILL BE
responsible for setting some of these policies. In that case, you should
take my advice: Don't hire people who expect that their employer will
train them in what they need to know. Usually, new people are dropped in
to firestorms and will need to get up to speed on their own because
everyone else is busy doing the work they're paid to do. Instead, look
for people who are willing to take a pile of specifications and such and
figure out what to do on their own, or with a minimum of involvement
from the others on the team. I'll pay for your copy of O'Reilly's
_Learning GNU Emacs_ and _Using Vi_, but don't expect me to read them to
you, or force you to read them yourself if the information contained
therein is what you need to do your job properly.

I don't like hiring people who are Microsoft-oriented because they tend
to be married to Microsoft Technical Support. If I hire you (and I DO
hire people) I'm paying YOU for YOUR knowledge and I'm not getting my
money's worth if the sum total of that knowledge is Microsoft's 800-number
for technical support. Yes, if you have a well-defined question with a
known answer (that somehow didn't make it into the documentation, where
the answers to all well-defined questions should be) it may be cheaper in
this one instance to have you ask someone at Microsoft for that answer.

However, in the long run, I, as an employer, benefit more if you develop
a deep understanding of the systems you work on and the environment that
you work in and that requires mucking about with the innards (I like to
call it "spelunking" because it is) in a way that may not be immediately
productive. I should also point out that many of the questions asked of
anybody's technical support are not well-formed and, as a result, the
answers those people get are ambiguous, misleading, or just plain wrong.

Now, I personally don't know any systems for which using Microsoft Visual
Studio is a requirement and I sure don't work on any for which it is an
available tool, so the learning curve difference (and it's not as large
as you think--it's just that you've already climbed the one already so
it looks smaller than it was at the time) is not significant in my case.
YMMV, but to make sense, you've got to pick whether you approach things
as an embedded systems programmer or a Windows application developer.
The two approaches are different. Right now, and as a senior embedded
systems programmer, you look an awful lot like a Windows application
developer to me.


Tim Bradshaw

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
* Michael Kappert wrote:
> I always thought 'having a steep learning curve' meant 'learning quickly'.
> Also, i thought that a 'learning curve' was attributed to the person that
> learns,
> not to the thing being learned.

The general use, I think, is that there's a certain amount you have
to learn before you can begin to use something in a reasonable way (be
it a program or a violin). If the amount you have to learn is a lot
(say for a violin), then the curve is described as `steep'. It only
really makes sense to talk about it that way if you consider the time
it takes too -- the learning curve for a violin is not steep in any
reasonable sense if you're willing to spend 50 years on learning it.

I think that it's pretty clear that the ability to deal with a really
aggressive learning curve in this sense is one of the characteristics
which used to distinguish real computer people from the general
population. We all have our stories of how the first job we did after
college involved being an office and a cheque book and told to make a
supercomputer by next week. And part of the trick is to know that you
*can* do this frightening thing, certainly in my case after a couple
of instances of being given some thing to do which I had no idea even
how to start, and discovering that I could just read the manual and
fight my way through it, I don't get frightened by learning hard things
any more.

But I think now that everyone uses computers, many more people are
just not willing to put this effort in, and they want something that
they can use competently immediately with no effort. Many people
perhaps can't do the fast-learning thing, and sadly others, who could,
are being spoiled by the received wisdom that it should not be
necessary. Sometimes I wonder why this has not happened for things
like musical instruments -- you don't hear people saying `the violin
should just not be so difficult to play!'.

Whether it is *possible* to have an immediately-usable program which
is not just crippling later on, when all the easy stuff starts getting
in the way, I don't know. I suspect it may be, but I haven't seen
one. Certainly things like the Windows GUI fail dismally here for me
(I haven't used the visual-foobar environments though).

--tim

Harley Davis

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Michael Kappert <k...@iitb.fhg.de> wrote in message
news:38AACBB2...@iitb.fhg.de...

>
>
> Robert Posey wrote:
> > If you think the widely recognized relatively steep initial learning
curve
> > of EMACS doesn't exist you have lost all touch with reality.
>
> I always thought 'having a steep learning curve' meant 'learning quickly'.
> Also, i thought that a 'learning curve' was attributed to the person that
> learns, not to the thing being learned.

An interesting question actually.

If a learning curve is plotted as skill level on the dependent axis vs. time
on the independent axis, then of course people have learning curves, not the
thing being learned - unless for a particular task there is strong enough
similarity between people that each learner's curve is essentially
identical.

I believe most people elide the distinction between an individual's learning
curve for a task and the task's average learning curve, especially when
comparing tasks: It is easier for almost everyone to get started using VS
than to get started using Emacs, so we can simply compare average learning
curves.

As far as the steepness of learning curves, this surprised me at first but
logically you are of course correct - a steep learning curve would imply a
task which is easily or at least quickly learned to a high degree of skill.
However, despite all logic, people often speak of steep learning curves for
tasks that are difficult and lengthy to acquire. My best guess here is that
they confuse the actual interpretation of the graph (which would lead to
your conclusion) with the natural implications of being confronted with a
steep hill in physical reality - such a hill is difficult and lengthy to
climb.

-- Harley

Robert Posey

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Jonathan Guthrie wrote:
>
> Robert Posey <mu...@raytheon.com> wrote:
> > I went so far as to explain why the
> > initial learning curve was a problem. Do I think its wise that companies
> > don't make the effort to hire good people and train them on powerful tools
> > like a customized version of EMACS can be.
>
> I'm sure Mr. Naggum's rant is better, but here's mine:
>
> How long does it take to learn that the up-arrow moves you up in the
> file, the down arrow moves you down, the left- and right-arrows do the
> obvious things, control-x control-s saves and control-c control-s exits?
> To learn to make minimal use of an editor is the work of seconds.
>
> Marking text and deleting or copying takes a few more seconds to learn.
> Yes, to learn too nontrivial things takes a while, but most of what
> beginners do with editors is trivial. (I would say that most of what
> advanced users do with editors is trivial, but there are people who do
> EMACS Lisp as automatically as they breathe.) Most of the rest is
> specialized to the application and, therefore, is limited.

People still have problems, why is another question. Part of the problem
is many people are used to Windows type method and out of the box Emacs is
much different.


>
> I used vi for years before learning how to cut-and-paste between files.
>
> > Of course not, but having no desire to
> > rise above a lead technical position there is nothing I can do about that.
>
> That's another thing about what you say. Technical lead is going to be
> responsible for specifying positions and qualifying candidates. You have
> to be if you expect to get the people you need to do the job.

Not here, I have never had the chance to hire my own people. It happens, but
the much more common event is that they are assigned. Even when you have a
choice, it tends to be very limited.

> I don't like hiring people who are Microsoft-oriented because they tend
> to be married to Microsoft Technical Support. If I hire you (and I DO
> hire people) I'm paying YOU for YOUR knowledge and I'm not getting my
> money's worth if the sum total of that knowledge is Microsoft's 800-number
> for technical support.

I actually don't use anything but Word or Excel for my main job. I haven't
found MS to ever be much help at all unless it was a business oriented
question.

> However, in the long run, I, as an employer, benefit more if you develop
> a deep understanding of the systems you work on and the environment that
> you work in and that requires mucking about with the innards (I like to
> call it "spelunking" because it is) in a way that may not be immediately
> productive. I should also point out that many of the questions asked of
> anybody's technical support are not well-formed and, as a result, the
> answers those people get are ambiguous, misleading, or just plain wrong.

I agree, except that our systems are Embedded and most of the windows and
Linux environmental knowledge is only helpful in comparison. Most of the
code I write, or design runs on system without operating systems. If they
do have an operating system its VxWorks. So while all knowledge is helpful,
when I have a choice I am much more impressed by a software person's hardware
or signal processing knowledge than anything to do with general purpose
computers. In fact too much experience with large system software design
is a big minus, it seems to create a mindset that doesn't understand real
time. This maybe why I value the ability to customize Emacs less than some,
even though it is potentially more valuable in a real time world due to
the large number of custom construct needed. If I can find someone who
knows both worlds, that wonderful. However, at my company you can be
sure that they will be gone soon.

Muddy

>
> Now, I personally don't know any systems for which using Microsoft Visual
> Studio is a requirement and I sure don't work on any for which it is an
> available tool, so the learning curve difference (and it's not as large
> as you think--it's just that you've already climbed the one already so
> it looks smaller than it was at the time) is not significant in my case.
> YMMV, but to make sense, you've got to pick whether you approach things
> as an embedded systems programmer or a Windows application developer.
> The two approaches are different. Right now, and as a senior embedded
> systems programmer, you look an awful lot like a Windows application
> developer to me.

That maybe because I don't directly write much of the Embedded code, and
write more windows stuff on the side. I design Embedded Test Algorithms,
which are even lower level than the rest of the Embedded code. When I
become involved with the code, its in the integration stage. I have
debugged many, many times more code than I have written. I guess my actual
coding experience in 15 years as a hardware designer, then systems engineer
is split about 50/50. I not saying that no one uses EMACS here, I just saying
that it has failed to be standardized as a choice. My whole point has been
apparently wasted on the flamers. I have tried to say over and over again
that their debate methodology was flawed. Remember I use EMACS even though
I don't use often enough to over come the curve. I never said it wasn't worth
the effort, I said the curve was higher than it needed to be. Looking at
the latest versions, it is clear the developers agree with me since they
have made major efforts to make it easier to use. If software companies that
produce good software continue to ignore the out of the box issues that MS
has done at least fairly well on, MS will continue to dominate. Calling the
people who complain about these issues stupid, lazy or any other insult is
not fighting Bill Legions, its surrender.

Muddy

Robert Posey

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Harley Davis wrote:
>
>
>
> As far as the steepness of learning curves, this surprised me at first but
> logically you are of course correct - a steep learning curve would imply a
> task which is easily or at least quickly learned to a high degree of skill.
> However, despite all logic, people often speak of steep learning curves for
> tasks that are difficult and lengthy to acquire. My best guess here is that
> they confuse the actual interpretation of the graph (which would lead to
> your conclusion) with the natural implications of being confronted with a
> steep hill in physical reality - such a hill is difficult and lengthy to
> climb.

I stand corrected, I believe Harley maybe correct.

Muddy

>
> -- Harley

Gareth McCaughan

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Robert Posey wrote:

> Visual Studio does have tags in a primitive way of bookmarks. It
> works pretty well for the simple jumping around I do.

That doesn't have much to do with Emacs's tags. The point
of tags is that a tags table is generated automatically,
and then you tell it "go to the definition of such-and-such
a function" and it uses the information in the tags table
to do it. Visual Studio has a similar feature, but it
doesn't use the word "tags", and the information is stored
in some opaque and undocumented format. :-)

Robert Posey

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Gareth McCaughan wrote:
>
> Robert Posey wrote:
>
> > Visual Studio does have tags in a primitive way of bookmarks. It
> > works pretty well for the simple jumping around I do.
>
> That doesn't have much to do with Emacs's tags. The point
> of tags is that a tags table is generated automatically,
> and then you tell it "go to the definition of such-and-such
> a function" and it uses the information in the tags table
> to do it. Visual Studio has a similar feature, but it
> doesn't use the word "tags", and the information is stored
> in some opaque and undocumented format. :-)

I was only equating them with the set and goto operations some one
mentioned, Visual Studio's go to definition, and got use of definition
works pretty well. I will agree however that Microsoft is that worst at
using strange formats to store files. My most favorable guess as to
why they do this is that they are trying to Stifle competition, if not
they are utter idiots. Are you sure its undocumented, have you looked at
their website?

Muddy

Hartmann Schaffer

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
In article <38AAF94F...@raytheon.com>,
Robert Posey <mu...@raytheon.com> writes:
> ...

> I don't use often enough to over come the curve. I never said it wasn't worth
> the effort, I said the curve was higher than it needed to be. Looking at
> the latest versions, it is clear the developers agree with me since they
> have made major efforts to make it easier to use. If software companies that
> produce good software continue to ignore the out of the box issues that MS
> has done at least fairly well on, MS will continue to dominate. Calling the
> people who complain about these issues stupid, lazy or any other insult is
> not fighting Bill Legions, its surrender.

most people who are seriously into software development don't mind the
initial effort to learn a tool that gives them muchg more in the long run

--

Hartmann Schaffer

It is better to fill your days with life than your life with days

Paul Wallich

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
In article <38AAF9D4...@raytheon.com>, Robert Posey
<mu...@raytheon.com> wrote:

The learning curve might be in the form of functionality achieved or percentage
of task finished vs effort expended (with effort on the y axis) to get you the
colloquial result. Time isn't really a factor except insofar as there's
only so much
energy you can devote per unit time.

One of the big questional about learning curves is plateaus and inflection
points:
Some tools require you to work very hard to get anything done at all, but once
you have learned them, you can do all the rest without further expenditure of
energy; others are more linear, and some of the most annoying have a sharp
upward slope right before the end rather than at the beginning...

paul

Erik Naggum

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
* Robert Posey <mu...@raytheon.com>

| I agree with you about what should be done, unfortunately I work for very
| large company where I am totally unable to affect hiring policies.

what part do you agree with? I'm talking about _educating_ people that
have already been hired, because whatever was hired was raw material, and
education is what shapes them into something the company can use.

| Being passionate is not excuse for lack of ability to make rational
| arguments,

you extrapolate from unwillingness to treat a bozo like you as an adult
with _ability_ to make rational arguments. this is a _fantastically_
unintelligent extrapolation.

| when people let their emotions control them,

emotions always control people. that's their fundamental function. the
question is _which_ emotions. some day you will understand this.

| I never mean to say that they shouldn't feel strongly, but that shouldn't
| blind them to both sides of an issue.

what does it _take_ to make you understand that you're the one dreaming
up this utter crap about other people? I have told you that I can see
_some_ advantages with _everything_. _why_ is this something you have to
keep denying all the time? nobody here is blinded, except you, perhaps.

| To become so emotionally attached to a EDITOR is a problem.

you don't understand how emotions work in technically apt people, so now
it's a "problem". grrrrreat! tell you wat, bozo, _nobody_ is _attached_
to an editor, emotionally or otherwise. you don't have to be _attached_
to feel something, you see. well, perhaps you do, but you're not the
prototype of all people on earth, now, are you?

| If any complain about EMACS drives them to attack the the commentator,
| they have lost touch with reality. EMACS is a fine program, BUT many
| people hate EMACS with equal passion. When you allow your emotion to so
| blind to other points of view, your engineering ability has been
| severely compromised.

*sigh*. if only you could listen to yourself instead of expecting that
others will listen to you. _nobody_ suffers from what you would dearly
hope they suffer from so _you_ could ignore them. and I mean _nobody_.
you don't understand jack shit about software and how it affects people
with a working intelligence _and_ working emotions. as soon as you
realize this, you could be worth talking to. so far, there is no sign
that your brain is able to accept anything you don't already agree to.

| If you think the widely
| recognized relatively steep initial learning curve of EMACS doesn't exist you
| have lost all touch with reality.

are you in really touch with Reality, "Muddy"? whoever _actually_ thinks
these things you dream up? I keep telling you: nobody. your enemies are
figments of your not very well developed imagination.

| However, to assert that none of my arguments are valid...

nobody has asserted any such thing.

| However, the paranoid of the EMACS Zealots has made them see things that
| aren't there.

_really_? how about the many demonstrations that you are arguing against
some really stupid stuff that _nobody_ has actually ever said?

| Read my posting again, and see if I ever said anything to justify the
| reactions people made.

just _how_ stupid are you, "Muddy"? do you really think nobody did that
_before_ they reacted to your incredibly retarded and unfounded opinions?

| > by the way, wishful thinking like "there's something wrong with those who
| > hate me" is a very useful psychological defense mechanism for those who
| > are mentally unprepared to accept that other people aren't hateful to
| > begin with and don't react without reason or observable cause. it is
| > fairly interesting to watch people respond to criticism as if criticism
| > of _them_ has to come from psychopaths, while they are eminently able to
| > criticize just about anything, usually without justifiable reasons.
|
| If any of you hate me for my comments you need serious help.

I'm _amazed_ by your reading comprehension, "Muddy". I said "[you] are


mentally unprepared to accept that other people aren't hateful to begin

with", and now your response proves just that.

you're an idiot, Robert Posey. shut your trap and leave us alone.

#:Erik

Erik Naggum

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
* Robert Posey <mu...@raytheon.com>

| However, at my company you can be sure that they will be gone soon.

so this really boils down to your still working at a place that is deeply
dissatisfying to you, but it serves your personal needs better to blame
Emacs (and/or Common Lisp) than to get out of your miserable situation.

over the years, we have had a lot of people like you in comp.lang.lisp
and the Emacs newsgroups. I guess this is so because people think it's
OK to blame these tools, but not OK to blame some other tools (such as
Microsoft's cruftware), for the simple reason that being miserable in the
majority makes people feel a lot _safer_ than being in a small minority
(whether one would be miserable there or not). I do my very best to make
people feel unsafe and a lot more miserable in the majority, so it shall
appear, if not be, safer and better to be in the minority, instead.

your apologia for remaining at a miserable place are unconvincing at best.

go fix your _real_ problem, OK?

#:Erik

Coby Beck

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Erik Naggum <er...@naggum.no> wrote in message
news:31597280...@naggum.no...
> * Robert Posey <mu...@raytheon.com>

> you're an idiot, Robert Posey. shut your trap and leave us alone.
>
> #:Erik


I, for one, believe Robert Posey has every right to post, and I don't share
at all the above sentiments.

Coby


Robert Monfera

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to

Unrelated to this thread, I just visited comp.object (which I do every
once in a while). Among others, there is an easily identifiable loser
who can't stop posting pointless articles and opening debates he
predictably fills with his useless mantra. Top contributors always
prove him wrong, but he does not change or quit despite the constant
humiliation. It seems that too much tolerance and laissez-faire freedom
of speach does not work out well on that newsgroup
(->comp.object.moderated), and I prefer self-defence of a newsgroup over
moderation. c.l.l. is the forum of a community, whose members should
have the right to try to reject noise and open newcomers' eyes to
(possibly shared) values.

It is reasonable to expect Robert to make his comments more carefully
and constructively so that he cannot be accused of repeated, aimless
hostility towards values many people foreseeably believe in. This is
not to say he brought up points unworthy of discussion.

Robert

Paolo Amoroso

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
On 16 Feb 2000 09:49:07 +0100, Marco Antoniotti <mar...@parades.rm.cnr.it>
wrote:

> Another problem is 'etags'. Last time I checked (I should give it
> another try, is my fellow countryman Potorti` listening :) ),
> DEFMETHOD and friends did not get the right treatment.

Without ILISP, the standard tag commands seem to work fine. etags is
supposed to correctly handle any kind of DEFSOMETHING form. Here is what
the Emacs manual says: "In Lisp code, any function defined with DEFUN, any
variable defined with DEFVAR or DEFCONST, and in general the first argument
of any expression that starts with `(DEF' in column zero, is a tag.". Which
specific problems are you referring to?


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Jonathan

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
Thank you to everyone who responded to my question regarding coming to
EMACS from a background of the MS Visual tools. I am trying to locate
the documentation necessary for me to start using EMACS in a more
optimal fashion. I appreciate the tip for Meta-tab and Meta-/ symbol
completion - this has already been very helpful. The eldoc module
described below also sounds useful, but I have been unable to locate
it. Can anyone point me to this module and any standard LISP resources
(ie somewhere that I could have searched for this module myself -
yahoo was unhelpful).

Thanks again,
Jonathan

On 15 Feb 2000 10:45:27 +0000, Philip Lijnzaad <lijn...@ebi.ac.uk>
wrote:

>On 14 Feb 2000 23:45:33 +0000,
>"Gareth" == Gareth McCaughan <Gareth.M...@pobox.com> writes:
>Gareth> In the same vein, if you type the start of a function
>Gareth> invocation
>
>Gareth> y = f(
>
>Gareth> then it pops up a "tool-tip" box showing you the function's
>
>Does this involve a paperclip ?-)
>
>Gareth> signature, and as you enter arguments it keeps the type of
>
>For emacs lisp, there is eldoc:
>
>;;; eldoc.el --- show function arglist or variable docstring in echo area
>
>which works wonders; I suspect there are more language-specific versions of
>such functionality out there (starting with etags and find-tag).
>
> Philip


thi

unread,
Feb 16, 2000, 3:00:00 AM2/16/00
to
"Coby Beck" <cb...@mercury.bc.ca> writes:

> I, for one, believe Robert Posey has every right to post, and I don't share
> at all the above sentiments.

i only use shared sentiments.

thi

Jon K Hellan

unread,
Feb 17, 2000, 3:00:00 AM2/17/00
to
Jonathan <n...@spam.com> writes:

> The eldoc module
> described below also sounds useful, but I have been unable to locate
> it. Can anyone point me to this module and any standard LISP resources
> (ie somewhere that I could have searched for this module myself -
> yahoo was unhelpful).

It's in the standard distribution. To activate it, put this in your
.emacs:

(autoload 'turn-on-eldoc-mode "eldoc" nil t)
(add-hook 'emacs-lisp-mode-hook 'turn-on-eldoc-mode)
(add-hook 'lisp-interaction-mode-hook 'turn-on-eldoc-mode)

If you want to look at it the code, M-x locate-library eldoc will tell
you where it is.

Jon

It is loading more messages.
0 new messages