Re: CEDET

Re: CEDET

[Martin Rydstr|m]

Kevin Dziulko <dziulko@klaatu.canisius.edu> writes:

> I have GNU Emacs 21.2.1 for Windows NT.  I want to install the Java
> Delelopment Environment.  I am tring to install the CEDET package
> because JDE requires it.  When I type make, I get this output:

> MAKE Version 5.0  Copyright (c) 1987, 1997 Borland International
> Error makefile 66: Colon expected
> Error makefile 96: Colon expected
> Error makefile 102: Colon expected
> Error makefile 107: Colon expected
> Error makefile 112: Colon expected
> *** 5 errors during make ***

> Does anyone know what to do about this? Or an easy way to setup the
> JDE?

Try using GNU make. I believe the makefile makes use of extensions
that are (only?) in GNU make.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_

Re: CEDET

[Martin Stemplinger]

On Die Jan 06 2004 at 16:32, Kevin Dziulko <dziulko@klaatu.canisius.edu> wrote:

> Does anyone know what to do about this? Or an easy way to setup the JDE?

The JDE website has instructions on how to install JDE under
Windows. I had no problem installing JDE following these
instructions. IIRC there's no need for make. 

You may run into problems if you use the latest CEDET-distribution with
JDE.  I'd recommend using the older version of the CEDET tools,
i.e. semantic 1.4. something etc.

HTH
Martin

-- 
Remove NOSPAM to reply by mail

Re: CEDET

[Kevin Dziulko]

On Tue, 6 Jan 2004, Martin Stemplinger wrote:

> On Die Jan 06 2004 at 16:32, Kevin Dziulko <dziulko@klaatu.canisius.edu> wrote:
> 
> > Does anyone know what to do about this? Or an easy way to setup the JDE?
> 
> The JDE website has instructions on how to install JDE under
> Windows. I had no problem installing JDE following these
> instructions. IIRC there's no need for make. 
> 
> You may run into problems if you use the latest CEDET-distribution with
> JDE.  I'd recommend using the older version of the CEDET tools,
> i.e. semantic 1.4. something etc.
> 
> HTH
> Martin
> 
> 

Actually, I was trying to "make" the CEDET-distro, not JDE.

RE: Emacs learning curve

[grischka]

 > Obviously, there is no reason to choose words perversely (e.g. use
 > "red" when we mean green).

Or use "scroll-up" where it means scroll down, or use "split-horizontally"
where it splits vertically ;)

 > Analogy (not really the same thing, but it is suggestive):  Remember those
 > experiments where people put on special glasses that flip their vision
 > vertically - everything looks upside down.  In a relatively short time their
 > brains adapt completely, so they actually see everything rightside up.

Sure, but the point is to put the glasses on _before_ one decides for
naming conventions as above.

--- grischka

Re: Emacs learning curve

[Óscar Fuentes]

grischka <grishka@gmx.de> writes:

>> Obviously, there is no reason to choose words perversely (e.g. use
>> "red" when we mean green).
>
> Or use "scroll-up" where it means scroll down, or use "split-horizontally"
> where it splits vertically ;)

Good one. Sometimes Emacs makes me wonder if I suffer from some type of
spatial disability.

The Emacs community has a more serious confussion discriminating what's
good and what's bad among two opposites, though:

A few weeks ago I was required to translate an old, small Visual Basic
application to C#. I was less than thrilled with the job, but anyways
the first thing was to configure Emacs as a C# editor. There is
csharp-mode, which does code formatting. So far, so good. There are two
methods for code completion, one based on CEDET and the other on an
external tool. The CEDET method was a nonstarter, the other worked
so-so. As I'm an absolute beginner on C# and it comes with a vast API,
code completion was too much of a time-saver to be neglected. After 3
hours trying to raise Emacs to the minimum usability level, I gave up
and tried certain popular IDE, out of despair. 15 minutes later my
client's application, on its basic inception, was running on the screen,
mostly thanks to an accurate and fast code completion system that not
only shows the candidates for completion, but also displays some
documentation explaining what every method does. This saves a lot of
time browsing documentation.

The mentioned code completion system on that IDE is a marvel for
beginners but, as it constantly pops on the screen hiding the code
below, maybe it is a pain for experienced hackers who know the API
well. Of course there is a knob for disabling it.

The crux of the matter is that the IDE comes ready to be as helpful as
possible for beginners, and adds options for turning features on and off
as you adquire experience. This is equivalent to saying that the IDE
comes preconfigured for making converts and then it assumes that as
those newcomers adquire experience they will learn how to adapt things
to their taste.

Emacs does just the opposite. See how people on this discussion says "of
course the new Emacs user will read the Tutorial etc." I was able to
write and run a basic application on a language that I barely know,
using a IDE for the first time, in less time that it takes to read the
Emacs tutorial. Translating the 5000 LOC Visual Basic application to C#
required less time than I needed for learning and configuring Emacs for
matching the usability level of my previous editor, ten years ago (and
now it wouldn't require much less work.)

The GNU project, and Emacs specifically, is about producing Free
software for the people. "People" here means all potential audience. In
practice, Emacs today is mostly focused on bringing incremental
improvements for current users, caring little about the demands and
expectations of the rest of world. It is disheartening to see how every
time that someone proposes a tiny change on the default configuration
for lowering the entry barrier, a vociferous group of reactionaries try
to block the initiative, usually winning the fight, just because they
don't want to add a line or two to their .emacs file.

IMAO the Emacs maintainers should ignore the winning and threatening of
those users and focus on making Emacs as attractive as possible to the
new generations of hackers. Having gratuitous oddities, expecting a
sustained effort from the prospective user until he perceives the
virtues of Emacs, being dismissive towards competing tools instead of
learning why they are attracting more users than Emacs... is simply
wrong.

The user who must be happy with Emacs is the user who doesn't know it
yet.

[snip]

RE: Emacs learning curve

[Drew Adams]

> >> Obviously, there is no reason to choose words perversely
> >> (e.g. use "red" when we mean green).
> >
> > Or use "scroll-up" where it means scroll down, or use 
> > "split-horizontally" where it splits vertically ;)
> 
> Good one.

Actually no, bad one.

I specifically chose red/green and _not_ up/down, because up from one vantage
point is down from another.  _Not_ so for red/green.  It is not perverse to call
something "up" which someone else might naturally think of as down - it depends
on the context.

The question of whether to consider scrolling from the point of view of the view
port / window or the point of view of the paper / data surface / buffer (which
is moving?) is as old as the hills.  And the answer sometimes depends on the
particular application in a logical way (think cockpit); otherwise it is
arbitrary.

Similar considerations apply to splitting horizontally/vertically.  We can all
agree on which is horizontal and which is vertical between _ and |, but what
happens when something is _split_ horizontally?

As soon as you say "split", the ambiguity/choice goes away.  A different verb
choice could have been made.  If the choice were to call it "duplicating" the
window, then it might make sense to call what we call horizontal splitting
"vertical duplicating": you duplicate a window above or below itself.

But with the point of view of splitting (the verb), the answer unambiguosly
agrees with Emacs terminology - you do in fact split the window horizontally.
Take an axe, hold it horizontally, and split the window.  Go ahead.  You get two
windows disposed vertically, one above the other.  It is simply incorrect to say
that "`split-horizontally' splits vertically".  Bad one, I'm afraid.

Looking at the _result_ rather than the action of splitting, you can indeed make
the point that the result is a vertical configuration.  That's what you see,
vertical placement, and that's what you care about, so you could well argue that
`vertical' should be part of the name somehow.

But you could also argue that the window dividing line, which is also a result,
is horizontal.  It's arguably a toss-up, but I would agree that the windows and
their placement are more important than the orientation of the divider.

But wrt the action, if it is viewed as a splitting action (and not, say,
duplicating), there is only one correct answer: the terminology that Emacs uses.
Should Emacs have chosen to think about the action as splitting?  Should Emacs
have emphasized the verb/action and not the resulting positions?  This is
arguable, but it's not terribly interesting either way.

What's the point? (1) The Emacs terminology for up/down vertical/horizontal
(split) is not silly.  (2) Some such things are arbitrary, or you can at least
come up with reasonable arguments for either choice.  (3) The same is not true
for other things, such as red/green.  And that's why I purposefully chose
red/green for my example.

So no, the petty put-down, trying to use `split-horizontally' to point out how
Emacs chooses words perversely, is simply not well thought through.  I'm sure
there are some examples of poor word choice in Emacs terminology, but your
argument based on the example of up/down is specious.

And what might seem "natural" to you wrt what scrolling "up" means is not
necessarily natural to everyone or, especially, to all contexts.

Some graphical design systems have both notions of scrolling (and other
view-port vs paper movements): they let you work either way, thinking either
that you are moving the window over the paper or moving the paper under the
window.

Different contexts can make one or the other point of view (and terminology)
seem more appropriate/natural.  And apps that provide alternative contexts also
employ both terminologies - they speak about both panning the view port left and
panning the paper left, meaning opposite directions.  Users can handle this
degree of complexity. ;-)

None of this is trivial or unimportant - words do matter.  And none of it has
been designed in Emacs without thought, I am sure.  That's not to say that there
is never room for improvement.  It is to say, "a little humility, please"; you
might not be the first person to think about this.  And things might not be as
silly or unnatural as you think.

(Disclaimer: I was not involved in the Emacs choices for scroll "up" or split
"horizontally".)

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> >> Obviously, there is no reason to choose words perversely
>> >> (e.g. use "red" when we mean green).
>> >
>> > Or use "scroll-up" where it means scroll down, or use 
>> > "split-horizontally" where it splits vertically ;)
>> 
>> Good one.
>
> Actually no, bad one.

[snip]

> What's the point? (1) The Emacs terminology for up/down
> vertical/horizontal (split) is not silly.  (2) Some such things are
> arbitrary, or you can at least come up with reasonable arguments for
> either choice.  (3) The same is not true for other things, such as
> red/green.  And that's why I purposefully chose red/green for my
> example.

The fact is that the terminology we are discussing will cause confussion
on a relevant group of users. For them, the red/green example applies
fully. This is bad, and the designers shall avoid those cases.

BTW, the red/green issue is more real than you seem to think. Have you
developed a GUI (or any sort of visual interface) that uses colors for
communicating critical info? A color-blind subject could argue that you
are being perverse when using red and green for displaying info, no
matter you refer to them by the "right" names on the manual.

[snip]

Re: Emacs learning curve

[Drew Adams]

> BTW, the red/green issue is more real than you seem to think. Have you
> developed a GUI (or any sort of visual interface) that uses colors for
> communicating critical info? A color-blind subject could argue that
> you are being perverse when using red and green for displaying info,
> no matter you refer to them by the "right" names on the manual.

Sigh.  I was afraid of this.  You are probably not truly missing the point (I
hope), but you are certainly acting as if you were.  Mauvaise foi, it must be.

If I had picked black/white you would be saying that I am not sensitive to race
issues - or that I am too sensitive.  Spare me the lecture that you hope
presents you with an easy out and skirts the issue - too facile.

FWIW, I work with UI accessibility everyday.  I am well aware of the need to
avoid use of color to convey info that is not conveyed any other way.
Everything I produce at work must pass WCAG, FRA508 (US), and other
accessibility guidelines (Oracle's guidelines are a superset).

You have raised a red herring (yes red, not green ;-)).  This is not about
red/green color sensitivity or UI accessibility.  NOT AT ALL.

Think red end of the E-M spectrum vs blue end, if it helps.  The point is that
there are some distinctions that do not have the same degree of relativity as
up/down.  One person's red end of the spectrum is the same end of the spectrum
as another person's red end of the spectrum.  Whether they both see the same
thing (or anything at all) when they look at a given color is another story.

Forget the sophistry and think through the arguments.  Yes, everything is
relative, including relativity of all sorts; quantity does turn into quality;
black can be white; and positive can be negative.  The universe (and
anti-universe) are dialectical at all levels, and all levels emerge and
interpenetrate.  Now back to your regularly scheduled program.

 "There is a fifth dimension, beyond that which is known to man.
  It is a dimension as vast as space and as timeless as infinity.
  It is the middle ground between light and shadow, between science
  and superstition, and it lies between the pit of man's fears and
  the summit of his knowledge. This is the dimension of imagination.
  It is an area which we call The Twilight Zone."   - Rod Serling

Re: Emacs learning curve

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> BTW, the red/green issue is more real than you seem to think. Have you
>> developed a GUI (or any sort of visual interface) that uses colors for
>> communicating critical info? A color-blind subject could argue that
>> you are being perverse when using red and green for displaying info,
>> no matter you refer to them by the "right" names on the manual.
>
> Sigh.  I was afraid of this.  You are probably not truly missing the
> point (I hope), but you are certainly acting as if you were.  Mauvaise
> foi, it must be.

No, I'm not missing the point at all. Whoever chose the terms
split-window-horizontally and split-window-vertically did a suboptimal
job, because they mean different things to different people, and using
ambiguous terms or expressions must be avoided. The fact that this
sub-topic arised is proof of the problematic nature of those terms.

And usage of down/up on Emacs (as for scrolling) contradicts current
stablished practice. Yes, there is a reasoning for doing what Emacs
does, but the issue is that it is contrary to the expectations of almost
anybody who learned to use computers on the last 20 years.

Terms must convey meaning to users, not confuse them.

[snip]

Re: Emacs learning curve

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > No, I'm not missing the point at all. Whoever chose the terms
 > split-window-horizontally and split-window-vertically did a suboptimal
 > job, because they mean different things to different people, and using
 > ambiguous terms or expressions must be avoided. The fact that this
 > sub-topic arised is proof of the problematic nature of those terms.

I have to side with Drew here.  The names are not ambiguous in
English, at least not to native speakers of my dialect interpreting
the hyphenated symbols as English phrases.  The problem is that even
those who speak my dialect may choose to interpret them in other ways,
because of the various odd things that happen in naming.  Probably the
most frequent source of confusion is glossing the symbol name as
"windows arrayed horizontally" (ie, what Drew referred to as the
result of the command).  I feel the pull of that interpretation
myself, even though I can't do an up-down inversion and get myself to
interpret the results of "split window horizontally" as a horizontal
array of windows.  (Sorry about that contuse mass of words, but
precision is necessary here.)

 > And usage of down/up on Emacs (as for scrolling) contradicts current
 > stablished practice. Yes, there is a reasoning for doing what Emacs
 > does, but the issue is that it is contrary to the expectations of almost
 > anybody who learned to use computers on the last 20 years.
 > 
 > Terms must convey meaning to users, not confuse them.

Ah, but *which* users?  Note that a natural vocabulary for new and/or
non-programmer users is a picture of the result.  A sensible way to
handle this problem would be to have an icon like "[][]" next to the
English-ized function name "Split selected window vertically" in the
menus, and a large version of the icon for use in toolbars.  (It
probably would almost never be used in the top-level toolbar, but I
can imagine a window-configuration-mode with a toolbar containing such
icons.)

OTOH, changing the terms used by long-time users would cause great
confusion and annoyance.  I don't think you can win this argument if
you target the names of commands.  It would be much easier to get
support if you create such a pictorial vocabulary for use by new users
and non-programmers.  Bonus points for making it possible to create a
"keyboard macro" using only the mouse, translate it to Lisp, and
associate the pictures with the appropriate Lisp commands.  And of
course much of the relevant vocabulary will already be present in
collections of icons provided by GNOME et al.

Re: Emacs learning curve

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snipped text where I mostly agree]

> OTOH, changing the terms used by long-time users would cause great
> confusion and annoyance.  I don't think you can win this argument if
> you target the names of commands.

I think it is more reasonable to add alias, perhaps make some commands
non-interactive and add new ones with the "new" terms, and replace all
references on the Emacs manual (not the Elisp manual) to use the new
terms.

I don't see why old timers would have a problem with this. After all, if
we expect from every newcomer to learn Emacs-ish, we can expect from the
veterans to learn that Paste means the same as Yank (in case they still
don't know.) Sure, there are technical details, none hard, although
maybe a bit controversial... Oh, wait!

> It would be much easier to get support if you create such a pictorial
> vocabulary for use by new users and non-programmers.  Bonus points for
> making it possible to create a "keyboard macro" using only the mouse,
> translate it to Lisp, and associate the pictures with the appropriate
> Lisp commands.  And of course much of the relevant vocabulary will
> already be present in collections of icons provided by GNOME et al.

Not really, the long term investment should be to teach modern terms to
Emacs, instead of insisting on forcing every newcomer to learn the Emacs
terms.

Re: Emacs learning curve

[Tom]

Óscar Fuentes <ofv <at> wanadoo.es> writes:
> 
> Not really, the long term investment should be to teach modern terms to
> Emacs, instead of insisting on forcing every newcomer to learn the Emacs
> terms.
> 

Exactly.

Most of the time when I tell people about Emacs they try it and they say
it's too alien and completion for popular languages (Java, C#) is much
better in other tools (Eclipse, Visual Studio, etc).

So in order to attract more new blood to Emacs there are two possible
ways:

1. Do something which people care about much better than other tools.
Completion comes to mind first, it should be very very good and it should
work out of the box without any addition configuration.

Due to the limited development resources for Emacs (I don't know how
many paid developers work on it, but I guess not many) it's not a 
realistic expectation.


2. The other way is to make Emacs more accessible to newbies. Basic things
should work out of the box as they work in other applications (e.g.
why should one use a different paste key just in emacs when C-v works fine
everywhere else?).

Ease of entry should be the main target, because more users means more
hackers too (some of them will come up with new ideas and contribute 
code), and more hackers means more resources for development which helps
catching up with other editors in features which people consider basic
in these days (e.g excellent completion out of the box).

Re: Emacs learning curve

[Stephen J. Turnbull]

Tom writes:

 > Ease of entry should be the main target, because more users means more
 > hackers too

You're ignoring the fact that some kinds of new users are far more
likely to convert to Emacs hackers.  Specifically, the kind of people
who don't pay too much attention to "ease of use" anyway, but rather
head straight for the workbench and grab a power grinder to smooth out
the nicks and burrs in their own user experience.

I'm not saying that we shouldn't target ease of use or conformance to
convention (more than we currently do).  Just that I don't think "more
users -> more hackers" is a good reason for it.

Re: Emacs learning curve

[Tom]

Stephen J. Turnbull <stephen <at> xemacs.org> writes:
> 
> You're ignoring the fact that some kinds of new users are far more
> likely to convert to Emacs hackers.  Specifically, the kind of people
> who don't pay too much attention to "ease of use" anyway, but rather
> head straight for the workbench and grab a power grinder to smooth out
> the nicks and burrs in their own user experience.
> 

Yes, and there are other kind of hackers how take a look at
Emacs and say why should I bother with it if it's so alien? I'll
create some Eclipse extension instead, since the Eclipse UI is
much friendlier.

I've read more than once in various places that Eclipse plugin
development is quite complicated. On the other hand I have
experience with extending Emacs and I know rapid prototyping in
Emacs Lisp is quite a pleasant experience (once you've learned
Emacs Lisp, that is).

Creating an entrance barrier by keeping the default Emacs
UI (keys, etc.) different than than ones people are used to in
popular systems turns away lots of potential developers who could
be very useful for Emacs once they get to know it better and get
the hang of it.


So yes, you are right. The current UI won't keep the very
determined hackers away, but in my experience the question most 
new users (and
most new hackers) ask when encountering Emacs is: "Why should I
bother with it if it's so alien?"

Since we don't have a killer feature which would attract new
users like perfect code assist (context aware completion, instant
display of documentation of elements, live indication of syntax
errors, etc.) out of the box with near-zero configuration, we
have to at least lower the barrier of entry, so users don't
encounter unfamiliar things right at the first steps (copy/paste
on different keys, etc.) which in my experience drives most of
them away.

Re: Emacs learning curve

[Eric M. Ludlam]

On 07/13/2010 04:32 AM, Tom wrote:
> Since we don't have a killer feature which would attract new
> users like perfect code assist (context aware completion, instant
> display of documentation of elements, live indication of syntax
> errors, etc.) out of the box with near-zero configuration, we

Enabling the CEDET code completion stuff "by default" would come pretty 
close.  I know lots of folks complain about CEDET being hard to figure 
out or configure.  On GNU systems with projects written in Automake, 
however, it self configures most of the complicated stuff, and will do a 
good job with completion in C and C++ and a few other languages.

CEDET is also now a part of Emacs.  Why not configure CEDET to be on, 
use it for a while, and instead of turning it off because of some glitch 
you don't like, fix the little things that confused you or were hard. 
That would take less time than reading this thread.

One of the things I was most surprised by was that when CEDET was 
integrated into Emacs, only 2 people tried it and reported anything from 
this list.  I fixed those things too.  Now this list is posting things 
that effectively pretend CEDET doesn't exist.  What's up with that?

Eric

CEDET (was: Emacs learning curve)

[Leo]

On 2010-07-13 12:59 +0100, Eric M. Ludlam wrote:
> Enabling the CEDET code completion stuff "by default" would come
> pretty close. I know lots of folks complain about CEDET being hard to
> figure out or configure. On GNU systems with projects written in
> Automake, however, it self configures most of the complicated stuff,
> and will do a good job with completion in C and C++ and a few other
> languages.
>
> CEDET is also now a part of Emacs. Why not configure CEDET to be on,
> use it for a while, and instead of turning it off because of some
> glitch you don't like, fix the little things that confused you or were
> hard. That would take less time than reading this thread.
>
> One of the things I was most surprised by was that when CEDET was
> integrated into Emacs, only 2 people tried it and reported anything
> from this list. I fixed those things too. Now this list is posting
> things that effectively pretend CEDET doesn't exist. What's up with
> that?
>
> Eric

I think any new feature should be enabled for a period of time for
testing purpose. If they are not tested in the development process, they
get tested in the release where users expect things to work reliably and
any problems for them can only be fixed in the next release which at
least is 1-year. Given that Emacs really doesn't have enough man-power
to handle bugs and new features, it seems even more important to find as
many bugs and feature requests to any new addition while its main author
is active.

I really hope CEDET (actually some of its components) can eventually
become a new layer for writing intelligent modes for programming
languages. Syntax highlighting through regexp is pretty dumb. In this
respect Eclipse (the latest release) has become superior to Emacs.

Leo

Re: CEDET

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> I really hope CEDET (actually some of its components) can eventually
> become a new layer for writing intelligent modes for programming
> languages. Syntax highlighting through regexp is pretty dumb. In this
> respect Eclipse (the latest release) has become superior to Emacs.

This is the reason Stefan and I wanted to include CEDET in the first
place.  For various reasons, the integration has been a difficult one,
but I consider it a long-term project.

CEDET

[Kevin Dziulko]

I have GNU Emacs 21.2.1 for Windows NT.  I want to install the Java 
Delelopment Environment.  I am tring to install the CEDET package because 
JDE requires it.  When I type make, I get this output:

MAKE Version 5.0  Copyright (c) 1987, 1997 Borland International
Error makefile 66: Colon expected
Error makefile 96: Colon expected
Error makefile 102: Colon expected
Error makefile 107: Colon expected
Error makefile 112: Colon expected
*** 5 errors during make ***

Does anyone know what to do about this? Or an easy way to setup the JDE?

Thanks!
Kevin