A few comments on the archives

[Hans-Dieter.Dreier@materna.de]

--CCSTqOx4S4eV5M6aN7OJ0JbzuvQMlNRC
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

>
>On Fri, 14 May 1999 Hans-Dieter.Dreier@materna.de wrote:
>
>> >can write code so much faster in vi, the GUI editor becomes
>> >frustrating.
>> =

>> Interesting. In what respect are GUI text editors slower to use than vi?
>
>I think this is only the case when you have been using vi for a while
>and are used to all of its features. A lot of GUI editors don't have
>support for regex search and replace. Even fewer allow me to restrict
>that replace to a range of lines without taking my fingers off of the
>keys. If I am going to have a lot of similar lines of code, but just
>part of an argument name is different, I can copy and paste the exact
>number of lines I need with only 4 keystrokes. Then there all of the
>options for editing single words, an entire line, etc. I have just
>gotten to the point where it takes me longer to lift my hand, move the
>mouse, and select a menu item than it takes to just type in a short
>command. Again though, most people would disagree with me vehemently on
>this. Shame on me for bringing up a religious issue (editors). :-)

No problem (at least for me). When it eventually comes to designing the edi=
tor UI, your experience with the keyboard interface will be most valuable. =
If support for the mouse interface doesn't suffer, a good keyboard interfac=
e can only be an advantage.

>> The intention is that you wouldn't need indent, lint, etc. anymore,
>> because e.g. "indentation" already would be done automatically as you en=
ter
>the text.
>
>Good point. Any good code editor would have this. Which reminds me of a
>Windows program called UltraEdit (I think that's it). A buddy showed it
>to me and I was amazed. I believe it has a "plug in"type of facility
>which allows you to add support for different languages.

We're planning sort-of plug-ins as well, but more fine-grained (on a per-ed=
ited class basis) to allow flexible layout & verification of constructs lik=
e functions, variables, classes, namespaces...

>> >I should also admit that I have a dislike of GUIs because I have had to
>> >write a number of the things recently. :P
>> =

>> You're referring to writing GUI applications, not to GUI IDE's, if I
>> understand right. Whereas creating a GUI might be involve a lot of
>> work, actually using the product *should* save work (at least that was
>> the reasons why GUI were developed in the first place).
>
>Yes, I was referring to applications, not IDE's. I was thinking more of
>our development of the IDE at that moment. I have started using Java a
>lot because trying to write a multiplatform GUI was going to make me an
>alcoholic. Ever try to write an X app? Yuck.
>
>I agree that a GUI is pretty much pointless if it isn't designed well.

I think we'll try to take as much of the GUI support code from others as is=
 possible unless someone enjoys writing a new one. I'm considering the GUI =
interface as a commodity (like floating point support or file I/O).

>I should also point out that I have never worked on a really HUGE
>software project like the kind tackled at MS. Perhaps in a project with
>multiple coders and numerous files an IDE would be a lifesaver. I just
>don't know.

No, I think it there would be a difference for ongoing work. Being able to =
use a GUI might be more inviting to new project members than a command inte=
rface though.

>My recent fascination with CWEB makes me ask if we want to build in
>support for "literate programming" with Ultra. Not sure if this has
>been brought up yet. A more recent example of this idea is Java's
>javadoc spec.

IMO we definitely should try to include the doc into the source. Docs that =
are separated from the source tend to describe a different (mostly older) v=
ersion of the software. But I don't like the idea of having yet another man=
datory preprocessor run (to generate the compileable source). Tools like Au=
toduck also have a (admittedly very limited) parsing capability, which redu=
ces the amout of text to be written to generate the doc.

>Cheers,
>
>Peter
>
>
>---
>Software Engineer
>EarthLink Network

--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--CCSTqOx4S4eV5M6aN7OJ0JbzuvQMlNRC
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a14898a.txt IA5 DX-MAIL X.400 User Agent=

--CCSTqOx4S4eV5M6aN7OJ0JbzuvQMlNRC--