* Re: CEDET [not found] <mailman.28.1073407051.928.help-gnu-emacs@gnu.org> @ 2004-01-06 17:06 ` Martin Rydstr|m 2004-01-06 21:05 ` CEDET Martin Stemplinger 1 sibling, 0 replies; 5+ messages in thread From: Martin Rydstr|m @ 2004-01-06 17:06 UTC (permalink / raw) 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_ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: CEDET [not found] <mailman.28.1073407051.928.help-gnu-emacs@gnu.org> 2004-01-06 17:06 ` CEDET Martin Rydstr|m @ 2004-01-06 21:05 ` Martin Stemplinger 2004-01-07 13:41 ` CEDET Kevin Dziulko 1 sibling, 1 reply; 5+ messages in thread From: Martin Stemplinger @ 2004-01-06 21:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: CEDET 2004-01-06 21:05 ` CEDET Martin Stemplinger @ 2004-01-07 13:41 ` Kevin Dziulko 0 siblings, 0 replies; 5+ messages in thread From: Kevin Dziulko @ 2004-01-07 13:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Emacs learning curve @ 2010-07-12 19:18 grischka 2010-07-12 20:53 ` Óscar Fuentes 0 siblings, 1 reply; 5+ messages in thread From: grischka @ 2010-07-12 19:18 UTC (permalink / raw) To: drew.adams; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-12 19:18 Emacs learning curve grischka @ 2010-07-12 20:53 ` Óscar Fuentes 2010-07-12 22:03 ` Drew Adams 0 siblings, 1 reply; 5+ messages in thread From: Óscar Fuentes @ 2010-07-12 20:53 UTC (permalink / raw) To: emacs-devel 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] ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Emacs learning curve 2010-07-12 20:53 ` Óscar Fuentes @ 2010-07-12 22:03 ` Drew Adams 2010-07-12 22:29 ` Óscar Fuentes 0 siblings, 1 reply; 5+ messages in thread From: Drew Adams @ 2010-07-12 22:03 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > >> 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".) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-12 22:03 ` Drew Adams @ 2010-07-12 22:29 ` Óscar Fuentes 2010-07-12 23:22 ` Drew Adams 0 siblings, 1 reply; 5+ messages in thread From: Óscar Fuentes @ 2010-07-12 22:29 UTC (permalink / raw) To: emacs-devel "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] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-12 22:29 ` Óscar Fuentes @ 2010-07-12 23:22 ` Drew Adams 2010-07-12 23:53 ` Óscar Fuentes 0 siblings, 1 reply; 5+ messages in thread From: Drew Adams @ 2010-07-12 23:22 UTC (permalink / raw) To: 'Óscar Fuentes', emacs-devel > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-12 23:22 ` Drew Adams @ 2010-07-12 23:53 ` Óscar Fuentes 2010-07-13 1:58 ` Stephen J. Turnbull 0 siblings, 1 reply; 5+ messages in thread From: Óscar Fuentes @ 2010-07-12 23:53 UTC (permalink / raw) To: emacs-devel "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] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-12 23:53 ` Óscar Fuentes @ 2010-07-13 1:58 ` Stephen J. Turnbull 2010-07-13 3:25 ` Óscar Fuentes 0 siblings, 1 reply; 5+ messages in thread From: Stephen J. Turnbull @ 2010-07-13 1:58 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Ó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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-13 1:58 ` Stephen J. Turnbull @ 2010-07-13 3:25 ` Óscar Fuentes 2010-07-13 6:34 ` Tom 0 siblings, 1 reply; 5+ messages in thread From: Óscar Fuentes @ 2010-07-13 3:25 UTC (permalink / raw) To: emacs-devel "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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-13 3:25 ` Óscar Fuentes @ 2010-07-13 6:34 ` Tom 2010-07-13 8:02 ` Stephen J. Turnbull 0 siblings, 1 reply; 5+ messages in thread From: Tom @ 2010-07-13 6:34 UTC (permalink / raw) To: emacs-devel Ó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). ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-13 6:34 ` Tom @ 2010-07-13 8:02 ` Stephen J. Turnbull 2010-07-13 8:32 ` Tom 0 siblings, 1 reply; 5+ messages in thread From: Stephen J. Turnbull @ 2010-07-13 8:02 UTC (permalink / raw) To: Tom; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-13 8:02 ` Stephen J. Turnbull @ 2010-07-13 8:32 ` Tom 2010-07-13 11:59 ` Eric M. Ludlam 0 siblings, 1 reply; 5+ messages in thread From: Tom @ 2010-07-13 8:32 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs learning curve 2010-07-13 8:32 ` Tom @ 2010-07-13 11:59 ` Eric M. Ludlam 2010-07-13 16:43 ` CEDET (was: Emacs learning curve) Leo 0 siblings, 1 reply; 5+ messages in thread From: Eric M. Ludlam @ 2010-07-13 11:59 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* CEDET (was: Emacs learning curve) 2010-07-13 11:59 ` Eric M. Ludlam @ 2010-07-13 16:43 ` Leo 2010-07-13 17:16 ` CEDET Chong Yidong 0 siblings, 1 reply; 5+ messages in thread From: Leo @ 2010-07-13 16:43 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: CEDET 2010-07-13 16:43 ` CEDET (was: Emacs learning curve) Leo @ 2010-07-13 17:16 ` Chong Yidong 0 siblings, 0 replies; 5+ messages in thread From: Chong Yidong @ 2010-07-13 17:16 UTC (permalink / raw) To: Leo; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* CEDET @ 2004-01-06 15:32 Kevin Dziulko 0 siblings, 0 replies; 5+ messages in thread From: Kevin Dziulko @ 2004-01-06 15:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-07-13 17:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <mailman.28.1073407051.928.help-gnu-emacs@gnu.org> 2004-01-06 17:06 ` CEDET Martin Rydstr|m 2004-01-06 21:05 ` CEDET Martin Stemplinger 2004-01-07 13:41 ` CEDET Kevin Dziulko 2010-07-12 19:18 Emacs learning curve grischka 2010-07-12 20:53 ` Óscar Fuentes 2010-07-12 22:03 ` Drew Adams 2010-07-12 22:29 ` Óscar Fuentes 2010-07-12 23:22 ` Drew Adams 2010-07-12 23:53 ` Óscar Fuentes 2010-07-13 1:58 ` Stephen J. Turnbull 2010-07-13 3:25 ` Óscar Fuentes 2010-07-13 6:34 ` Tom 2010-07-13 8:02 ` Stephen J. Turnbull 2010-07-13 8:32 ` Tom 2010-07-13 11:59 ` Eric M. Ludlam 2010-07-13 16:43 ` CEDET (was: Emacs learning curve) Leo 2010-07-13 17:16 ` CEDET Chong Yidong -- strict thread matches above, loose matches on Subject: below -- 2004-01-06 15:32 CEDET Kevin Dziulko
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.