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

60 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