Board index » cppbuilder » Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Re: Install Kylix3 on Mandrake 10.1, Suse 9.1


2004-11-18 04:35:58 AM
cppbuilder22
Mike Margerum < XXXX@XXXXX.COM >writes:
Quote
Can emacs generate a make file? Thats another annoyance of mine. I
don't like having to modify make files.
I do not know, but in order for anything to generate a makefile, you
have to tell it all the inter-dependencies. BCB requires that you
tell it all that up front too, in the project manager. However, it's
not very flexible and so bcb's makefile generation is easy.
When you override settings on per file and per directory file groups,
it gets very hard to generate. Makefiles are kind of ugly to begin
with, so really it's just a matter of converting the specification
from one format into another.
We use "template" makefiles, and basically just fill in the blanks.
Then add exceptions, whenever they apply. Thus, I wouldn't know if
emacs can help do this or not, but I'd suspect someone has tried to
write it...
--
Chris (TeamB);
 
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Mike Margerum < XXXX@XXXXX.COM >writes:
Quote
I didn't realize emacs could do code completion. Does it just parse
C++ I guess? Does that work with python too?
It doesn't really parse C++, it just reads strings in the code. It
works in any buffer, so it'd work for python too. For example, while
composing this post, I can use completion for any word already in the
editor. For example "bo" expands to "borland" just by typing bo and
then hitting meta-slash. "p" expands to "post" and if I hit meta-slash
again (w/o typing anything else in between), it changes to "python."
Actually, I didn't even know about this feature until you asked, and I
searched the web for "emacs code completion" Someone suggested this.
It's not based on the compiler symbol tables or anything, but seems to
work quite nicely, and *very* fast.
--
Chris (TeamB);
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Andrue Cope [TeamB] wrote:
Quote
It basically feels like what it is:Free software.
I strongly disagree. I've been using OO as my office suite for years
now, and already wrote a full book and a fair number of papers in it.
It is a full fledged, *professional* piece of software.
--
Ken
planeta.terra.com.br/educacao/kencamargo/
* this is not a sig *
 

{smallsort}

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

I find code completion very useful as I have very little ram in this
brain. These API's are getting so complex, I can never remember every
method and every property.
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Well i've written some pretty complex BCB/VS apps and I have never
written a makefile. I'm well aware of what a makefile is but frankly i
haven't coded one in years. Makefiles may be easy to build but its also
easy to make a dependency mistake and not have your code compile
correctly. I know there are 3rd party apps that will parse CPP files
and generate a make file. I was just wondering if this was built into
emacs. Again, I don't understand this attitude where everything has to
be written from scratch by hand everytime. I have built dozens of small
"one off" apps this year and having to create a project and makefile
from scratch for each one would have been killer. These apps literally
took hours in BCB to build and would have take days if I wrote them from
scratch. If you are working on one monolithic non gui app, I guess this
approach works.
Thanks for the link.
Oscar Fuentes wrote:
Quote
Mike Margerum < XXXX@XXXXX.COM >writes:


>Can emacs generate a make file? Thats another annoyance of mine. I
>don't like having to modify make files.


A makefile declares how to turn one set of files into another. Surely
you realize that this can be very complex. For simple build
specifications (those BCB uses) it is trivial to write a Makefile, and
certainly is trivial to write an Emacs function that spits such a
Makefile.

On the link I provided before there is a package for project
manager. See EDE. I know nothing about it. I write my Makefiles.

 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Chris Uzdavinis (TeamB) wrote:
[...]
Quote
Just out of curiousity, what do you feel emacs lacks? I feel exactly
the opposite: I've never found an IDE to match emacs.
That's because you don't do GUI's. :-)
Cheers,
--
Nicola Musatti
Team Thai Kingdom
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
Quote
[...]

>on the fly syntax checking,

True. Do any C++ ides do that?
How is code completion supposed to work
without this?
Quote
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
Quote
[...]

There are probably hundreds of things in emacs that other ides don't
have too. It goes both ways, but the fancy gui stuff is what's
usually seen. Buffer handling,
I think even BC++ had that. I never knew
what it is good for. But maybe you can
convince me? :)
Quote
rectangular editing,
You mean like marking a rectangular block
of text (that doesn't start at column #1)?
I cannot remember having worked with an
IDE that didn't have this.
Quote
navigation,
macros,
What is this? Why do you need macros to
navigate?
Quote
customization,
BCB is weak in this. However, even the now
legendary BC++ IDE had a lot of customization
possibilities. And VS is ver configurable.
Quote
ad lib function definition,
What's this?
Quote
historical edits,
And this?
Quote
advanced kill-ring retrievals,
And this one?
Quote
multi-split-screen views (horizontal
and vertical),
I think BC++ did this, BCB does, and VS
does it, too.
Quote
point stacks,
Again: What's this?
Quote
very intelligent code indenting and
highlighting,
VS does.
Quote
and so on. These are more fundamental to editing and
not so much of the "point and click your way to success", but unless
I'm working on writing a GUI, this is the most important part of the
editor.
Except those I don't know what the buzz-word
means, I haven't found one my IDE doesn't.
But note that you said "editor", while Mike
was speaking of an IDE. The editor is just
one part of an IDE. (Even though it might be
the most important one). An IDE does a lot
more. It manages projects, dependencies,
different project configurations, integrates
editor, compiler, de{*word*81}, object browsers,
RAD builder, and exposes an API for 3rd-party
vendors to plugin and enhance it. And it
provides you with (almost) all the tools
needed in a coherent way, with similar look,
feel, and keyboard shortcuts.
I know you'll argue that you can have the
same (or even more and better) functionality
through asembling you favourite tools and
hosting them within your favaourite editor.
(And I know what you're talking about here.
I worked a lot with the Linux guy next door
to port some template stuff of mine to GCC.)
But then I'd argue that all what you do in
C++ and even more you can do in assembler.
C++ limits you, but in the end makes your
job easier in the 95% of the cases when
you don't need to go beyond those limits.
It's the same with an IDE.
Quote
>The whole component oriented aspect of delphi is powerful and makes
>developing an app so much faster. All of this applies 3 fold when
>it comes to data driven websites.

Ok, but that's including the compiler and included libraries, which
emacs isn't trying to be. [...]
Right. It's not trying to be an IDE.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Mike Margerum < XXXX@XXXXX.COM >writes:
Quote
Again, I don't understand this attitude where everything has
to be written from scratch by hand everytime.
I don't think anyone suggested that! I have a handful of
applications, all re-using makefile code as a library, based on ACE
makefile code. (It's almost a complete programming langauge...)
For example, my applications are no more complex than this:
MAKEFILE = Makefile
DEPENDENCY_FILE = .$(MAKEFILE).depend
BIN = data-reader
FILES = Data_Event_Generator
include ../makeinclude.macros
The real "code" of the makefile begins in the parent directory's
makeinclude.macros file, which has lots of common rules factored out,
etc, and which pulls in ACE makefile helper libraries. The
makeinclude.macros file looks like this:
machine:=$(shell uname -m)
ifeq ($(machine),x86_64)
CFLAGS += -march=k8
endif
need_PRISM_INC = 1
use_libATD=1
use_libShipper=1
PSRC = $(addsuffix .cpp,$(BIN))
POBJ = $(addsuffix .o,$(BIN))
SRC = $(addsuffix .cpp,$(FILES))
OBJ = $(addsuffix .o,$(FILES))
LDLIBS += -lBookReader
LDFLAGS += -L../lib
INCLDIRS += -I.. -I../include
BUILD = $(VBIN)
ifndef debug
CFLAGS += -DNDEBUG
endif
ifdef release
CFLAGS += -O3
endif
.shobj:
mkdir -p ./.shobj
all: .shobj .obj $(BIN)
$(BIN): ../lib/libBookReader.a
include $(PRISM_ROOT)/makeinclude.macros
Not too bad yet, and still pretty high-level. The
$(PRISM_ROOT)/makeinclude.macros adds more details, and is where the
complexity really begins. That, however, is a company library and is
not something that is rewritten often, and is actually hardly ever
tweaked except when necessary.
I'm just showing this to demonstrate that you can develop makefiles as
libraries and have reusable code in them as well. (I certainly do not
consider myself expert in Makefiles, and don't even understand all the
things that the ACE makefiles do. I just use them as documented, and
it all just works.)
Quote
I have built dozens of small "one off" apps this year and having to
create a project and makefile from scratch for each one would have
been killer.
But you do have to create a project. File|New|New APplication does
create a project.
Quote
These apps literally took hours in BCB to build and would have take
days if I wrote them from scratch. If you are working on one
monolithic non gui app, I guess this approach works.
Big projects don't just appear overnight. They tend to grow.
Similarily, makefiles grow with them. It's not like one day you just
have an enormous project and have to suddenly construct a full build
system for it.
--
Chris (TeamB);
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

"Hendrik Schober" < XXXX@XXXXX.COM >writes:
Quote
Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
>[...]
>
>>on the fly syntax checking,
>
>True. Do any C++ ides do that?

How is code completion supposed to work
without this?
In some cases you have to do a regular compile of your application at
least once before it works.
Borland's working on improving the background-compilation-as-you-type
approach to not have the speed problems that it had in the past, and
to work better with incomplete code.
--
Chris (TeamB);
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
Quote
"Hendrik Schober" < XXXX@XXXXX.COM >writes:

>Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
>>[...]
>>
>>>on the fly syntax checking,
>>
>>True. Do any C++ ides do that?
>
>How is code completion supposed to work
>without this?

In some cases you have to do a regular compile of your application at
least once before it works.
In all other cases your IDE needs to compile
in the background while you type. I'd call
this on the fly syntax checking.
Quote
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

"Hendrik Schober" < XXXX@XXXXX.COM >writes:
Quote
Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
>[...]
>
>There are probably hundreds of things in emacs that other ides don't
>have too. It goes both ways, but the fancy gui stuff is what's
>usually seen. Buffer handling,

I think even BC++ had that. I never knew
what it is good for. But maybe you can
convince me? :)
It's not just having multiple buffers, but navigating intelligently
between them. Emacs has some sort of MRU algorithm so that you cycle
through the most recent buffers first, not just in order of opening
the files. This way something opened early that isn't viewed for a
while "bubbles down" to the end of the queue.
Also, you can jump to buffers by name, and it has tab-completion for
the name so you can just type the first few characters of the file,
hit tab, then jump to that buffer. No mouse clicking and lots of
dialog boxes. No tabs that get unwieldly after you open too many
files, etc.
Quote
>rectangular editing,

You mean like marking a rectangular block
of text (that doesn't start at column #1)?
I cannot remember having worked with an
IDE that didn't have this.
It's a lot more than just marking a rectangular block. You can save
multiple rectangles in memory, paste them later, or insert new
rectangles inside the buffer. You can select a rectangluar region and
have it insert text at the beginning of each line of that rectangle.
This is surprisingly useful (typing something once and having it
appear on each line, all in the same column of the rectangle.)
You can easily delete the rectangular region of text as well, making
it easy to mass-change a column of data by deleting the region then
typing something new to insert in its place.
Quote
>navigation,
>macros,

What is this? Why do you need macros to
navigate?
There's a comma between those words. Navigation had to do with
navigating between buffers.
Quote
>customization,

BCB is weak in this. However, even the now
legendary BC++ IDE had a lot of customization
possibilities. And VS is ver configurable.
Yes, but it's still a far cry from emacs. One of the main reasons
that Emacs is so flexible is that the very core is written in C enough
to host the emacs lisp language. Then the rest of the editor is
written in lisp... the same language you use to customize it. That
is, the "scripting language" is not an add-on that exposes *some*
interfaces, but it is THE language that exposes ALL of the interfaces.
That's why, for example, people are able to do amazing things like
write web browsers, email clients, tetris games, and IRC modes all to
work in the same editor. It's so thorougly programmable that it's
almost a general purpose environment with an emphasis on a textural
user interface.
Quote
>ad lib function definition,

What's this?
This is in regards to functions customizing the editor, not to
functions in the C++ code you may be writing. Binding a recorded
macro to a key by saving it in a function.
Quote
>historical edits,

And this?
I think I meant recursive edits. You can be doing an operation, like
spell checking, and interrupt that to start editing some more, and
say, start recording a macro. Then you can pause recording the macro,
edit some more, then return to recording the macro, finish that, then
return to finish spell checking.
For historical edits, though, it can have numbered backup files, CVS
integration, and pretty nice undo/redo features.
Quote
>advanced kill-ring retrievals,

And this one?
Each time you delete some text, it doesn't just vanish, and it doesn't
just go to an equivalent of the "clipboard". It's pushed onto a stack
of deleted things, called a kill-ring. You can later past things from
this, with the most recent deletion (kill) first, and cycle through
the previous kills as well. Thus you don't lose something you cut
just because you deleted more stuff which overwrote it. Once I
learned about this feature I really came to appreciate it.
Quote

>multi-split-screen views (horizontal
>and vertical),

I think BC++ did this, BCB does, and VS
does it, too.
Not like this. You can split the screen horizontally, then do a
vertical split in the top half of that, and then do another vertical
split in the top-left quadrant, then do a horizantal split in the
middle of one of those new mini panes. That is, you can be viewion
many *different* buffers at the same time, in different sized windows,
and split and unsplit them as necessary.
Quote
>point stacks,

Again: What's this?
Throughout the buffer you can mark the current position of the point
(cursor), which is like starting a new region to be marked off.
However, it's more than just starting to mark a region, it's saving
the location on a stack. You can do some nice in-buffer navigation
with this, using the marks as bookmarks. You can mark a section, then
"pop the stack and jump to that place") With multiple marks, you can
pop back to each place they were made. It's really nice if you're
working in a big file and need to jump around, and then come back.
Just mark the current section, go elsewhere, then pop back to the last
place. Then pop back to the last place before that, etc.
Another nice, useful feature, while simple, is the ability to swap the
current position of the curser with the top of the stack. Doing this
allows you to jump back and forth very quickly between two places in
the file, without touching the rest of your point stack.
Quote

>very intelligent code indenting and
>highlighting,

VS does.
Not like this.
Quote
Except those I don't know what the buzz-word
means, I haven't found one my IDE doesn't.
But note that you said "editor", while Mike
was speaking of an IDE. The editor is just
one part of an IDE. (Even though it might be
That's true, but the editor is still a major part and if it's weak,
all the other bells and whistles don't really help that much.
Quote
the most important one). An IDE does a lot
more. It manages projects, dependencies,
different project configurations, integrates
editor, compiler, de{*word*81}, object browsers,
Emacs can integrate editor, compiler, de{*word*81}, and object browsers.
Quote
RAD builder, and exposes an API for 3rd-party
vendors to plugin and enhance it.
Emacs doesn't have just an API, it's got a full programming language
with networking, threads, and so on.
Quote
And it provides you with (almost) all the tools needed in a
coherent way, with similar look, feel, and keyboard shortcuts.
Same here.
Quote
I know you'll argue that you can have the
same (or even more and better) functionality
through asembling you favourite tools and
hosting them within your favaourite editor.
Having them brought together has some obvious benefits, especially if
it adds value by doing more than just interfacing them. (If it can
make use of the features of the different tools such that they combine
to do more than they would do alone, then it's a big winn.) However,
you also are limited to the IDEs lowest common denominator, especially
if the tools it wraps only can access a subset of their features
because the IDE doesn't expose everything, or because the options are
so thoroughly hidden that you can't seem to find them.
Quote
(And I know what you're talking about here.
I worked a lot with the Linux guy next door
to port some template stuff of mine to GCC.)
But then I'd argue that all what you do in
C++ and even more you can do in assembler.
And you could program that assembler in emacs, with all the same
benefits you already know and love. :)
Quote
C++ limits you, but in the end makes your
job easier in the 95% of the cases when
you don't need to go beyond those limits.
It's the same with an IDE.
It all depends on what you want. I wouldn't mind if emacs had more
features that the IDEs have, but I require a good editor more than the
other stuff. Without a good editor, the IDE is more annoying than
useful to me.
--
Chris (TeamB);
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
Quote
[...]
It's not just having multiple buffers, but navigating intelligently
between them. Emacs has some sort of MRU algorithm so that you cycle
through the most recent buffers first, not just in order of opening
the files. This way something opened early that isn't viewed for a
while "bubbles down" to the end of the queue.
Same in VS. First, I hated it. Now I
like it.
Quote
Also, you can jump to buffers by name, and it has tab-completion for
the name so you can just type the first few characters of the file,
hit tab, then jump to that buffer. No mouse clicking and lots of
dialog boxes. No tabs that get unwieldly after you open too many
files, etc.
And I always thought I am a keyboard
afficinado! :) Seriously, I have no problems
opening older files by entering a menu as
long as I don't have to use the mouse for
that.
Quote
>>rectangular editing,
>
>You mean like marking a rectangular block
>of text (that doesn't start at column #1)?
>I cannot remember having worked with an
>IDE that didn't have this.

It's a lot more than just marking a rectangular block. You can save
multiple rectangles in memory, paste them later, or insert new
rectangles inside the buffer. You can select a rectangluar region and
have it insert text at the beginning of each line of that rectangle.
This is surprisingly useful (typing something once and having it
appear on each line, all in the same column of the rectangle.)

You can easily delete the rectangular region of text as well, making
it easy to mass-change a column of data by deleting the region then
typing something new to insert in its place.
I think VS does most, if not all of that.
(And I think even BCB does most of it.)
Quote
>>navigation,
>>macros,
>
>What is this? Why do you need macros to
>navigate?

There's a comma between those words. Navigation had to do with
navigating between buffers.
Sorry. However, navigation is something all
editors/IDEs need. VC has macros. Do did
BCC++ ten years ago, BTW.
Quote
>>customization,
>
>BCB is weak in this. However, even the now
>legendary BC++ IDE had a lot of customization
>possibilities. And VS is ver configurable.

Yes, but it's still a far cry from emacs. One of the main reasons
that Emacs is so flexible is that the very core is written in C enough
to host the emacs lisp language. Then the rest of the editor is
written in lisp... the same language you use to customize it. That
is, the "scripting language" is not an add-on that exposes *some*
interfaces, but it is THE language that exposes ALL of the interfaces.
I think that's pretty much the same with
VS.NET. Much of it written in .NET and it
exposes its innards as .NET objects.
However, I am not all that interested in
programming my IDE. It is there to help
me programming, not to make me programming
it.
Quote
[...]

>>ad lib function definition,
>
>What's this?

This is in regards to functions customizing the editor, not to
functions in the C++ code you may be writing. Binding a recorded
macro to a key by saving it in a function.
VS does this for years.
Quote
>>historical edits,
>
>And this?

I think I meant recursive edits. You can be doing an operation, like
spell checking, and interrupt that to start editing some more, and
say, start recording a macro. Then you can pause recording the macro,
edit some more, then return to recording the macro, finish that, then
return to finish spell checking.
Ah. Does one need that? :)
Quote
For historical edits, though, it can have numbered backup files,
I always hated these numbered backup files.
Quote
CVS
integration,
And I never used those. (But VCS is integrated
and there's 3rd-party plugins to integrate it
even better.)
Quote
and pretty nice undo/redo features.
Like?
Quote
>>advanced kill-ring retrievals,
>
>And this one?

Each time you delete some text, it doesn't just vanish, and it doesn't
just go to an equivalent of the "clipboard". It's pushed onto a stack
of deleted things, called a kill-ring. You can later past things from
this, with the most recent deletion (kill) first, and cycle through
the previous kills as well. Thus you don't lose something you cut
just because you deleted more stuff which overwrote it. Once I
learned about this feature I really came to appreciate it.
Mhmm. Sounds nice, although I daily do
this with a combo of undo/redo/cut/paste.
Also, I have a plugin that keeps the last
ten paste buffers and let's me pick. That
does it for me in 99,99% of all cases.
Quote
>>multi-split-screen views (horizontal
>>and vertical),
>
>I think BC++ did this, BCB does, and VS
>does it, too.

Not like this. You can split the screen horizontally, then do a
vertical split in the top half of that, and then do another vertical
split in the top-left quadrant, then do a horizantal split in the
middle of one of those new mini panes. That is, you can be viewion
many *different* buffers at the same time, in different sized windows,
and split and unsplit them as necessary.
In VS you can switch (from the tabbed view)
to the classic MDI view. Then you can open
as many views of the same file as you want
and arrange them any way you want. Of course,
that's not as nifty as having unlimited
nested splitted views. But I never used more
than one horizontal and one vertical split
at the same time -- and that I used probably
only thrice in the last ten years. (However,
I seem to remember that I once got lost in
splited windows with BC++4 which I think had
this feature ten years ago. I haven't missed
it since.)
Quote
>>point stacks,
>
>Again: What's this?

Throughout the buffer you can mark the current position of the point
(cursor) [...]
It seems bookmarks (as found in all editors I
worked with) are a lot easier to deal with.
Quote
>
>>very intelligent code indenting and
>>highlighting,
>
>VS does.

Not like this.
It does. :)
(We could argue about this endless this way.
Define "like this" and then I can decide
whether I agree or not.)
Quote
>Except those I don't know what the buzz-word
>means, I haven't found one my IDE doesn't.
>But note that you said "editor", while Mike
>was speaking of an IDE. The editor is just
>one part of an IDE. (Even though it might be

That's true, but the editor is still a major part and if it's weak,
all the other bells and whistles don't really help that much.
Right. (And I always considered BCB's editor
as weak. However, nowadays I work with VS
and that's pretty good.)
Quote
[...]

Emacs can integrate editor, compiler, de{*word*81}, and object browsers.
No, emacs can't. /You/ can, though.
Quote
[...]
Emacs doesn't have just an API, it's got a full programming language
with networking, threads, and so on.
So does VS. And you can even program it in
many languages.
Quote
>And it provides you with (almost) all the tools needed in a
>coherent way, with similar look, feel, and keyboard shortcuts.

Same here.

>I know you'll argue that you can have the
>same (or even more and better) functionality
>through asembling you favourite tools and
>hosting them within your favaourite editor.
See? I knew you would do that. :)
Quote
Having them brought together has some obvious benefits, especially if
it adds value by doing more than just interfacing them. (If it can
make use of the features of the different tools such that they combine
to do more than they would do alone, then it's a big winn.)
Yes, that's good. Like if I can script the
editor as well as all the other tools (which
just are external commands to emacs). And VS
allows just this.
Quote
However,
you also are limited to the IDEs lowest common denominator, especially
if the tools it wraps only can access a subset of their features
because the IDE doesn't expose everything, or because the options are
so thoroughly hidden that you can't seem to find them.
Of course, if your IDE sucks, then working
with it sucks, too. But there's no difference
to standalone editors. FYI: My IDE shows
the commandline of the compiler and linker
and lets me edit that either through a nice
dialog with checkboxes etc. or through
typing compiler flags directly into the
command line. (Oh, and it picks them up and
sets the checkboxes accordingly.)
Quote
[...]

And you could program that assembler in emacs, with all the same
benefits you already know and love. :)
As in any IDE.
Quote
>C++ limits you, but in the end makes your
>job easier in the 95% of the cases when
>you don't need to go beyond those limits.
>It's the same with an IDE.

It all depends on what you want. I wouldn't mind if emacs had more
features that the IDEs have, but I require a good editor more than the
other stuff. Without a good editor, the IDE is more annoying than
useful to me.
Of course, we're talking about good editors
here and IDEs that have good editors. Even
though from a certain level it's all just a
matter of personal taste. -- But that's just
what I am trying to say: Emacs isn't really
better than any good IDE. It's different and
it's got different pros and cons. IIUC, the
pros are mainly in supporting keyboard geeks.
(I'd rather pick my files from a list than
type their name -- if I can do this without
the mouse!) Most of the rest you showed is
not missing from good IDEs. (You could argue
that there aren't that many good IDEs. But
then there's aren't that many editors, too.)
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

"Hendrik Schober" < XXXX@XXXXX.COM >writes:
{snip}
Well, I've used VC++, BC++, BCB, and Emacs, and while many features
can be checked off on all the products, those features that I listed
were not nearly as well done in the proprietary IDEs.
When you don't have a feature, it's easy to get used to alternatives
(by necessity), to the point that when someone likes the missing
feature, it is deemed "unnecessary because I just do...." However, in
most cases once you try the feature, it's hard to go back.
For example, I wrote a nice little emacs extension that allows me to
jump between source files and headers, and other related files, even
if they're in different directories. For example:
$(PROJECT_ROOT)/include/foo.hpp
$(PROJECT_ROOT)/include/foo.ipp
$(PROJECT_ROOT)/src/foo.cpp
With a single keypress I can jump back and forth between the header,
the inline code, and .pp source file of foo.
(I can change extensions for other languages and have it jump between
them, too, like .ml and .mli (ocaml source and interface files))
I've done for years without this, but finally wrote it and now can
hardly live without it. :) BCB has something similar for jumping
into the header, but only if it's in the same directory, and it
doesn't work for .ipp files, or other associated files.
--
Chris (TeamB);
 

Re:Re: Install Kylix3 on Mandrake 10.1, Suse 9.1

Chris Uzdavinis (TeamB) wrote:
Quote
For example, I wrote a nice little emacs extension
I mostly agree with what you're saying, but this phrase is what, IMHO,
makes this a poor example of what you're talking about. This feature
didn't come built into emacs. You wrote it yourself.
Are you saying it's a reasonable, worthwhile investment of your time to
learn elisp and the emacs API's and write your own extension to emacs,
but it's not a reasonable, worthwhile investment of your time to learn
C++ and the BCB API's or Java and the CBX API's and to write your own
extension to BCB or CBX (or VB.NET / VS API's)?
I can accept that there's a certain amount of inertia once you get used
to the features and quirks of one editor, but if you were willing to
coerce emacs into doing what you want, then it seems like you ought to
be equally willing to coerce a different editor.
--
Gillmer J. Derge [TeamB]