RE: powerful editors versus IDEs (was: License to Steal)

RE: powerful editors versus IDEs (was: License to Steal)

[Beard, Frank]

Kent, I certainly agree with most of your comments.

However, the ObjectAda (for Windows) IDE does allow you
to use a different editor, but its editor is adequate.
I tried numerous editors without finding one I liked
better, so I gave up trying to find a better one.

It has most of what I consider to be necessary features:

  - the standard search/replace
  - auto formatting
  - color coded identifiers (reserved words, comments, etc.)
  - multi-line indent/unindent and auto-indent
  - multi-line comment/uncomment
  - find in files the allows you to click on the
    entry to jump to the location in the file
  - bookmarks
  - go to definition/completion (browse), unfortunately
    it has a limitation.  You can browse forward all you
    want, but it will only pop back one level.  I'm
    hoping they will have a fix for that soon.

I miss the repeat function in emacs, where you could repeat
an action anywhere in a file.  That would definitely come in
handy when we have to add an update comment to the end of 
every line that we modify.

But I hate the way you open a file in emacs.  I like the
GUI approach of popping up an Open Dialog box to allow you
to browse to a file.  ObjectAda has a Project window that
lists all the files included in the project.  Simply
double click the entry and it opens it.  If the file is
not part of the project, then the Open Dialog is an easy
way to find and open it.

> I find it much easier to keep an editor window
> open, and build my software with _my_ choice of
> editors, importing the code fresh into the IDE
> with each edit and paying the penalty of no
> incremental compilation or whatever

This usually isn't a problem with ObjectAda until the 
project starts getting large.  And even then, you can
open another copy of ObjectAda as an editor only.
That way the copy that's opened as the project for 
compilation doesn't do the internal validation, but you
do lose the "go to completion" capability, because it
will only browse on files that are part of the project.

I don't think I tried vim.  Where can I find it?  Does
it work on Windows NT?

Thanks
Frank

-----Original Message-----
From: xanthian@well.com [mailto:xanthian@well.com]
Sent: Saturday, May 05, 2001 4:26 AM
To: comp.lang.ada@ada.eu.org
Subject: <no subject>


Subject powerful editors versus IDEs in software development Re: License to
Steal
References: <mailman.988913824.5508.comp.lang.ada@ada.eu.org>

> I prefer a GUI oriented IDE with some power.  I
> miss some of the features of both editors, but
> not nearly enough to ever go back.

> Frank

I'm a bit confused; how could you describe an IDE
as "with some power" if it doesn't even provide
for dropping through to your power editor of
choice?

  [I'm a vim() fan myself, having outgrown both
  vi() and emacs(), but that's not really
  relevant to the larger issue of being captive
  to wimpy editing tools when writing software.]

The StarLogo language in which I'm presently
writing code (don't ask) also has an IDE, also
has a "wimpy to the point of provoking suicidal
impulses" editor.

I find it much easier to keep an editor window
open, and build my software with _my_ choice of
editors, importing the code fresh into the IDE
with each edit and paying the penalty of no
incremental compilation or whatever, than I do
trying to work with an editor roughly as feature
free as MS-Notepad.

After all, typical compilers are lightning fast
today, so almost all of the _time_ I spend in
software development is spent editing, whether of
code or docs, so editing is where I want the most
powerful assistance from my choice of tools.  In
my experience with several integrated development
environments, IDE developers have too many things
on their plates to also develop the world's best
editor, whatever that might be, as part of their
tool, and the embedded editor more often smacks
of being an afterthought.

I suppose this is back to the Unix concept of a
suite of tools each of which does one thing well
and has a simple integration technique, being
more usable than a monolithic tool that does lots
of things tolerably.

Which is of course a religious issue.

All of which are only opinions, but ones based on
grunches of carpal tunnel syndrome risk taking over
almost 41 years.

Cheers!

xanthian.
--
Kent Paul Dolan <xanthian@well.com>


-- 
Posted from smtp.well.com [208.178.101.27] 
via Mailgate.ORG Server - http://www.Mailgate.ORG
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: powerful editors versus IDEs (was: License to Steal)

[Matthias Kretschmer]

> I don't think I tried vim.  Where can I find it?  Does
> it work on Windows NT?

You can find vim at www.vim.org. It works on many platforms including Windows
NT. I personally use only vi/vim as a editor, but this might not be a choice
everybody would do. vim is very powerfull if you know it, if you don't know it
at all, you could be get into trouble exiting the editor :-)

of course it supports syntax highlighting for ada (just tried it with some
files for gnat - vim knows the file-extensions, so no problem).

mfg Matthias Kretschmer

Re: powerful editors versus IDEs (was: License to Steal)

[Ted Dennison]

In article <3AF9903A.B47431C8@gmx.net>, Matthias Kretschmer says...
>
>> I don't think I tried vim.  Where can I find it?  Does
>> it work on Windows NT?
>
>NT. I personally use only vi/vim as a editor, but this might not be a choice
..
>of course it supports syntax highlighting for ada (just tried it with some
>files for gnat - vim knows the file-extensions, so no problem).

But if you use nvi instead, you can get Vigor (
http://www.red-bean.com/~joelh/vigor/ ), a MS Office Clippy clone for vi! :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com
(promoting emacs through the back-door)

Re: powerful editors versus IDEs (was: License to Steal)

[Gary Scott]

If you're using windows, Kedit for Windows has the best of both worlds,
either GUI or command line or both in whatever mixture you might need.
Emulate virtually any other editor, extremely powerful macros and native
command set.  Not sure if there's a syntax highlighting recognition file
for Ada, but fairly easy to create one that's reasonably comprehensive. 
http://www.kedit.com  I mix usage with Visual Studio by adding Kedit to
the "tools" menu.

"Beard, Frank" wrote:
> 
> -----Original Message-----
> From: Ted Dennison [mailto:dennison@telepath.com]
> 
> > I consider a macro facility to be necessary (ever needed to space over 4
> spaces
> > in 300 declarations, or create a declaration for each number in another
> file?),
> > and I notice its not in your list.
> 
> I was listing what it has, not what it is missing.  As far as the 4 spaces
> example,
> if you are talking about indenting the 300 declarations over 4 spaces, then
> yes
> that is the indent/unindent that I listed.  If you are talking about adding
> 4 spaces
> in the middle of a line, as in wanting to move the colons (:) in the
> declarations
> over 4 spaces to keep them all lined up, then that is what I called the
> "repeat"
> feature from emacs, which I do miss.  But it is far from a monumental
> problem unless
> you have a huge number of lines involved, which doesn't seem to happen that
> often.
> 
> > The way I open a file in emacs is by hitting ctrl-D to bring up dired-mode
> on
> > one of the file's parent directories. Then I browse down the directory
> tree
> > until I find the file by using the 'f' or "Enter" key. It doesn't sound
> > significatly different.
> 
> You're right, it is similar, but less user friendly and less aesthetically
> pleasing,
> at least to me.
> 
> > Sometimes, using emacs' file name completion I don't need to go through
> all that
> > effort. The Windows Open Dialog has no such capability.
> 
> That's not exactly true, it does have something similar, in that after you
> bring up
> the dialog box (just as in the ObjectAda project window), if you begin
> typing
> characters, it will jump you to the nearest matching name.  Then you can
> pick from
> that part of the list.  Windows Explorer works the same way.
> 
> I really don't want to start an editor war.  Everyone has their own
> preference.
> Emacs is a powerful editor (as is vi).  I just don't like the more primitive
> look
> and feel.
> 
> Frank

Re: powerful editors versus IDEs (was: License to Steal)

[Gary Scott]

Rectangular cut and paste/drag/drop is supported by Kedit also.

Larry Kilgallen wrote:
> 
> In article <hSfK6.8063$vg1.667986@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> > In article <mailman.989428626.10442.comp.lang.ada@ada.eu.org>, Beard, Frank
> > says...
> >>However, the ObjectAda (for Windows) IDE does allow you
> > ..
> >>It has most of what I consider to be necessary features:
> >
> > I consider a macro facility to be necessary (ever needed to space over 4 spaces
> > in 300 declarations, or create a declaration for each number in another file?),
> > and I notice its not in your list.
> 
> Although I prefer TECO (somewhat more powerful than a Macro facility),
> if those 300 lines are adjacent the feature I hear GUI editor fans
> espouse is "rectangular cut and paste".

Re: powerful editors versus IDEs (was: License to Steal)

[Aron Felix Gurski]

Gary Scott wrote:
> 
> If you're using windows, Kedit for Windows has the best of both worlds,
> either GUI or command line or both in whatever mixture you might need.
> Emulate virtually any other editor, extremely powerful macros and native
> command set.  Not sure if there's a syntax highlighting recognition file
> for Ada, but fairly easy to create one that's reasonably comprehensive.
> http://www.kedit.com  I mix usage with Visual Studio by adding Kedit to
> the "tools" menu.

A non-commercial equivalent of KEdit (or IBM's XEdit) is available; it's called
THE and can be found at

	http://www.lightlink.com/hessling/THE/index.html

It's available for the Win* as well as the Un*x platforms.

-- 
        -- Aron

NB: To reply by e-mail, remove "spam-block." from my address.
- - - - - - - - - - -
There has been an alarming increase in the number of things about which you know
absolutely nothing.

Re: powerful editors versus IDEs (was: License to Steal)

[John English]

Matthias Kretschmer wrote:
> vim is very powerfull if you know it, if you don't know it
> at all, you could be get into trouble exiting the editor :-)

We had an attempted hacker break-in at our site last year. The thing
that foiled the attempt was vi -- one of the system files had been
edited, but the edit has been killed, and the recovery log showed
the file to be full of "quit -- exit -- bye -- GET ME OUT OF HERE!"
stuff near the end... :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

RE: powerful editors versus IDEs (was: License to Steal)

[Beard, Frank]

I hope this is not a praise of vi.  An editor
so cryptic a hacker couldn't get out of it.

Frank

-----Original Message-----
From: John English [mailto:je@brighton.ac.uk]
Sent: Friday, May 11, 2001 10:07 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: powerful editors versus IDEs (was: License to Steal)


Matthias Kretschmer wrote:
> vim is very powerfull if you know it, if you don't know it
> at all, you could be get into trouble exiting the editor :-)

We had an attempted hacker break-in at our site last year. The thing
that foiled the attempt was vi -- one of the system files had been
edited, but the edit has been killed, and the recovery log showed
the file to be full of "quit -- exit -- bye -- GET ME OUT OF HERE!"
stuff near the end... :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------
_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: powerful editors versus IDEs (was: License to Steal)

[Simon Wright]

"Beard, Frank" <beardf@spawar.navy.mil> writes:

> I miss the repeat function in emacs, where you could repeat
> an action anywhere in a file.  That would definitely come in
> handy when we have to add an update comment to the end of 
> every line that we modify.

Jings! management gone mad! you need to look into a proper source code
management system. CVS is free (so is SCCS, but why you would want to
use it I don't know ..)

What do your source files look like after a few updates? full of crap
telling me who changed stuff and (perhaps) why, completely obscuring
the program logic and making it look so ugly that anyone with the
faintest sense of aesthetics comes over faint when asked to look at
it.

(Frank, I quite understand that this sort of thing is a policy imposed
from on high, not what you'd necessarily choose to do).

Re: powerful editors versus IDEs (was: License to Steal)

[Anders Wirzenius]

Simon Wright wrote in message ...
>"Beard, Frank" <beardf@spawar.navy.mil> writes:
>
>> I miss the repeat function in emacs, where you could repeat
>> an action anywhere in a file.  That would definitely come in
>> handy when we have to add an update comment to the end of
>> every line that we modify.
>
>Jings! management gone mad! you need to look into a proper source code
>management system. CVS is free (so is SCCS, but why you would want to
>use it I don't know ..)
>
>What do your source files look like after a few updates? full of crap
>telling me who changed stuff and (perhaps) why, completely obscuring
>the program logic and making it look so ugly that anyone with the
>faintest sense of aesthetics comes over faint when asked to look at
>it.

A method I used to practise in a former programmer life was to add comments
at the end of each updated line. When the current updating task was done,
tested and released, the line end comments where removed and replaced by a
short description in the header of the module. With that method we didn't
have to bother what comments to write in the header each time we changed
something. The summary was easy to write by reading through the line end
comments.

Anders Wirzenius

RE: powerful editors versus IDEs (was: License to Steal)

[Beard, Frank]

-----Original Message-----
From: Simon Wright [mailto:simon@pushface.org]

> Jings! management gone mad! you need to look into a proper source code
> management system. CVS is free (so is SCCS, but why you would want to
> use it I don't know ..)
>
> What do your source files look like after a few updates? full of crap
> telling me who changed stuff and (perhaps) why, completely obscuring
> the program logic and making it look so ugly that anyone with the
> faintest sense of aesthetics comes over faint when asked to look at
> it.

I couldn't agree more.  We were forced to do it on Apex, and
now we are being forced to do it with PVCS on Windows NT.

The only justification that I've heard that has any merit is
that it tells you why the change was made.  As you say, that
seems like very little benefit for the amount of noise and
confusion it introduces into the code.  I have yet to see it
resolve anything.

And what's worse, if the change is later discovered to have
problems, then you have update comments on top of update
comments.  Why not just correct the code?  Yuck!

The CM tools provide a fairly good capability of displaying
the differences, making the comments quite redundant.
Granted they can be a little difficult to interpret if the
change history gets very lengthy.

RE: powerful editors versus IDEs (was: License to Steal)

[Beard, Frank]

-----Original Message-----
From: Anders Wirzenius [mailto:anders.wirzenius@pp.qnet.fi]

> A method I used to practise in a former programmer life was to add
comments
> at the end of each updated line. When the current updating task was done,
> tested and released, the line end comments where removed and replaced by a
> short description in the header of the module. With that method we didn't
> have to bother what comments to write in the header each time we changed
> something. The summary was easy to write by reading through the line end
> comments.
>
>Anders Wirzenius

While that sounds perfectly reasonable and better than our current
approach, we are never allowed to go back and do that.  We have to
have a justification for checking the unit out, updating it, and
checking it back in.  To clean up the code is not sufficient.  So,
some poor guy down the road will have to maintain it with the noise
in place.

I would rather not put it there in the first place.

Re: powerful editors versus IDEs (was: License to Steal)

[Marin David Condic]

In a perfect world, Configuration Management and Change Control would be
integrated in such a way that the change history for a given module is not
maintained as comments in the module, but as an attachment of some form that
you can retrieve as needed.

A good CM system I've both developed on and used, had change requests
associated with the check-out/in process. If you had questions about what
changes had been made to a module, you could always find the collection of
change requests that have ever impacted it and could retrieve older versions
of the module to compare against. That way the code (or any other artifact
within the CM system) had no clutter that wasn't relevant to its current
purpose, but you could find out how it had evolved if it was necessary to do
so. At *most* you might see someone having put a comment in the banner of a
module that referenced a CR# - but I never believed any of that anyway
because it was not always up to date. It was far better to ask the computer
to fill you in on the module history.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:mailman.989885292.1844.comp.lang.ada@ada.eu.org...
>
> While that sounds perfectly reasonable and better than our current
> approach, we are never allowed to go back and do that.  We have to
> have a justification for checking the unit out, updating it, and
> checking it back in.  To clean up the code is not sufficient.  So,
> some poor guy down the road will have to maintain it with the noise
> in place.
>
> I would rather not put it there in the first place.
>

Re: powerful editors versus IDEs (was: License to Steal)

[Anders Wirzenius]

Marin David Condic wrote in message <9drct2$gpq$1@nh.pace.co.uk>...
>In a perfect world, Configuration Management and Change Control would be
>integrated in such a way that the change history for a given module is not
>maintained as comments in the module, but as an attachment of some form
that
>you can retrieve as needed.

Agree. The form of the attachement is also then an established standardised
form (XML?) which may be read forwards and backwards by a CM tool to achieve
the historical moment of the code you want to dig out.
To put history lines as comment lines within the code is a poor mans
standardised solution.

Anders Wirzenius

Re: powerful editors versus IDEs (was: License to Steal)

[Marc A. Criley]

Marin David Condic wrote:
> 
> In a perfect world, Configuration Management and Change Control would be
> integrated in such a way that the change history for a given module is not
> maintained as comments in the module, but as an attachment of some form that
> you can retrieve as needed.
> 
I've tried for many years on different projects to push the project's
coding "header" standard away from maintaining CM information--with
mixed results.  CM tools are powerful enough that, when properly
integrated into a well thought out CM process, a full and useful change
history of the unit can now be easily extracted from such tools.

I hate maintaining redundant information in a header, but many people
(managers and developers alike) don't trust the CM environment, don't
want to be bothered with having to learn a few simple procedures with
the tool, and/or want all the change information in the file and are
willing to accept the risk of incompleteness and inaccuracy.  (For the
latter desire, auto-generation of headers has sometimes proved a
workable compromise.)

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: powerful editors versus IDEs (was: License to Steal)

[Marin David Condic]

How it is done is going to depend on the tools you have to do configuration
management and change control. In the particular instance I was talking
about, we had a home-grown tool with a relational database that kept (among
other things) a change request form. The change request had associated
details that pointed to the specific files modified. By proper queries on
the database, one could find all the files associated with a change or all
the changes associated with a file.

It seems you are suggesting some version of hyperlinking a document to a
source code file. I know of no systems built around that sort of technology.
If all it amounted to was an attached collection of comments, it might not
be especially useful. Better than filling the code with so much garbage that
you can no longer clearly see what the code is doing. Not quite as useful as
a full-up cross reference capability one might get with an appropriate CM/CC
system.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:JTpM6.28$R_3.2813@read2.inet.fi...
> Agree. The form of the attachement is also then an established
standardised
> form (XML?) which may be read forwards and backwards by a CM tool to
achieve
> the historical moment of the code you want to dig out.
> To put history lines as comment lines within the code is a poor mans
> standardised solution.
>

Re: powerful editors versus IDEs (was: License to Steal)

[Marin David Condic]

In a real CM system, even if you add no comments in the process of a check
out/in, it at least maintains a record of what was changed and when & the
delta between the two versions. Comments in a banner are notoriously
unreliable and nothing forces them to be updated when a change is made. I
used to regularly ignore the pleas of some of my cohorts to update the
banners on the grounds that I had already explained my changes in the CM
system and didn't want to do it twice. If they wanted the *real* history of
a module, they could get it in a cocaine heartbeat from the CM system with
very nearly zero effort. I wasn't about to update banners with duplicate and
likely unreliable info just because "that's the way we've always done it!"

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Marc A. Criley" <mcqada@earthlink.net> wrote in message
news:3B0263B5.FB21A304@earthlink.net...
> I've tried for many years on different projects to push the project's
> coding "header" standard away from maintaining CM information--with
> mixed results.  CM tools are powerful enough that, when properly
> integrated into a well thought out CM process, a full and useful change
> history of the unit can now be easily extracted from such tools.
>
> I hate maintaining redundant information in a header, but many people
> (managers and developers alike) don't trust the CM environment, don't
> want to be bothered with having to learn a few simple procedures with
> the tool, and/or want all the change information in the file and are
> willing to accept the risk of incompleteness and inaccuracy.  (For the
> latter desire, auto-generation of headers has sometimes proved a
> workable compromise.)
>
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
> www.quadruscorp.com

RE: powerful editors versus IDEs (was: License to Steal)

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Anders Wirzenius et al.
The Annotations in XML, which are conceptually roughly equivalent to a class
of comment types, would be appropriate.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Anders Wirzenius
Sent: Wednesday, May 16, 2001 12:21 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: powerful editors versus IDEs (was: License to Steal)



Marin David Condic wrote in message <9drct2$gpq$1@nh.pace.co.uk>...
>In a perfect world, Configuration Management and Change Control would be
>integrated in such a way that the change history for a given module is not
>maintained as comments in the module, but as an attachment of some form
that
>you can retrieve as needed.

Agree. The form of the attachement is also then an established standardised
form (XML?) which may be read forwards and backwards by a CM tool to achieve
the historical moment of the code you want to dig out.
To put history lines as comment lines within the code is a poor mans
standardised solution.

Anders Wirzenius

Re: powerful editors versus IDEs (was: License to Steal)

[Georg Bauhaus]

Marin David Condic (marin.condic.auntie.spam@pacemicro.com) wrote:

: It seems you are suggesting some version of hyperlinking a document to a
: source code file. I know of no systems built around that sort of technology.

Might I suggest considering PRCS[1],
wich has, among other things that you might say it lacks,
the power of the `prcs execute` command?
It is not automatically doing magic, but from
what I have seen and used, its possibilities are
largely unexplored.

As for comments, it virtually kills RCSs file version comments,
and instead allows a checkin to be annotated in "versions"
(a project's control file). At first I had been missing the
comments per file, but no longer, since the "version", or well
defined parts thereof, can
actually serve as a kind of hyperlinkable document.

Some things could be automated (using the PRCS shell and/or
programming interface), but for now I get away with discipline.



Georg Bauhaus

[1] designed by Paul Hilfinger, whom you no doubt know :-)
http://xcf.berkeley.edu/~jmacd/prcs.html