Are there any LISP development systems that are VC, or other GUI IDE like?
Robert Posey
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
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
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
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
Does it work in windows, its written TCL\TK so it should in theory?
Erik Naggum
| 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
Robert Posey <mu...@raytheon.com> wrote:
> Does it work in windows, its written TCL\TK so it should in theory?
>
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
> ... 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
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
> 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
> 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
>
>
> 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
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
"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
> 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
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
| 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
"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ø
> 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
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
> 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
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
> 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
> 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
ctrl-]
M-x apropos
M-x replace-string
Robert Posey
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
> 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
>
>
> ctrl-]
> M-x apropos
you can get help more simply by just
C-h (a b c .....) ;-)
Regards
Friedrich
Robert Posey
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
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
> 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
> 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
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
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
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
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
> 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
> > 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
> 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
>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
<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
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
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
> 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
>>>>> "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