Re: History of code completion (Gene Wirchenko)
8 Nov 2001 01:16:55 -0500

          From comp.compilers

Related articles
History of code completion (2001-10-20)
Re: History of code completion (Lex Spoon) (2001-10-21)
Re: History of code completion (2001-10-23)
Re: History of code completion (Jan Gray) (2001-10-23)
Re: History of code completion (2001-10-23)
Re: History of code completion (Geoff Wozniak) (2001-10-27)
Re: History of code completion (Marco van de Voort) (2001-11-05)
Re: History of code completion (2001-11-08)
Re: History of code completion (Richard Heathfield) (2001-11-08)
Re: History of code completion (Lex Spoon) (2001-11-08)
Re: History of code completion (2001-11-11)
Re: History of code completion (Rodney M. Bates) (2001-11-11)
Re: History of code completion (Joachim Durchholz) (2001-11-14)
| List of all articles for this month |

From: (Gene Wirchenko)
Newsgroups: comp.compilers,comp.programming
Date: 8 Nov 2001 01:16:55 -0500
Organization: Posted via Supernews,
References: 01-10-091 01-10-112
Keywords: editor
Posted-Date: 08 Nov 2001 01:16:55 EST

Lex Spoon <> wrote:

>> So I'm quite interested in the history of code completion in IDE's &
>> code editors. Does anyone have any info or personal recollections,
>> or even opinions on the merits/demerits of code completion?

>It used to be much biger than it is nowadays, as I understand it. One
>name for the general area is "syntax-directed editting". I'm a little
>curious, myself, why it hasn't caught on more than it has. I wonder
>how much it's due to a still-prevailing attitude that Real Programmers
>can do it themselves and don't need the help?

          I can do it myself. When I know what I want, I don't want
programs "helping" because they often get it wrong. Word is infamous
for helping (read "sabotaging") in this way. I finally have all of
its nonsense shut off, I think.

          Microsoft Word has the setting for handling automatically
numbering paragraphs under AutoCorrect. Considering that I was doing
what I wanted correctly, I didn't look there until someone else
pointed me to it. I think Microsoft has lots of gall doing that.

          Most of us can type well. I'd rather just type than also have to
worry that a program is going to change what I type.

>Two styles are available for syntax-directed editting. First, the
>editor can force you to only generate syntactic forms. To enter a
>statement, you select from some kind of menu or keyboard command what
>kind of statement you want, and the editor will fill in defaults.

          I'd just as soon type than select from a menu. It's generally
much faster. If the selection involving mousing, it's even worse.
Taking ones hands off the home row is expensive for a touch typist.

>Now, the editor can have a compiled version of the program at all
>times. If you want to change the name of a function, you can select
>that function and then bring up a menu -- the editor will know that
>(a) you have selected a function name, and (b) what functions are in
>scope at that point. Squeak's end-user programming tool is a current
>system that works like this, but it's not practical for general
>programming. (Though there is talk....)

          Will it change all calls, including in other programs? No?
Then, I had better keep track of things. Will it adjust comments to
line them up if the new name is a different length than the old name?
How do I specify this? Whichever way it works, it's unlikely to do it
my way exactly.

>As I understand, programmers who have used traditional tools tend to
>get irritated in systems of this first style. That's too bad; it
>actually sounds to me like it could be a very smooth programming
>experience! Imagine, no syntax errors.... But, I've never actually
>tried it.

          No syntax errors is easy. No semantic errors is the problem.
I'd just as soon look up how a function works if I'm uncertain than to
rely on a program's suggestion.

>The other style is to leave the programmer with a general text editor,
>and then have the editor maintain a parse tree for what the user has
>typed -- essentially compiling while the user types. There are
>algorithms for incremental parsing and incremental analysis, e.g.:
> Thomas Reps, Tim Teitelbaum, Alan Demers.
> Incremental Context-Dependent Analysis for Language-Based Editors.
> ACM Transactions on Programming Languages and Systems,
> Vol. 5, No. 3, July 1983, 449-477.
>It's tricky, though -- a lot of the intermediate stages aren't going
>to be legal code!

          It depends on the language. C won't work when there are fancy
compile-time substitutions.

>This style is used in VB and Smalltalk, and it's used in syntax
>highlighters in, e.g., Emacs. The syntax highlighters in particular
>often rely on heuristics instead of doing strictly correct parses, at
>least if the current buffer has unsyntactic code in it. I honestly
>don't know whether this is due to theoretical limitations or just due
>to a lack of effort by the authors.

          It depends on the language, but I expect theoretical limitations
bite often. Compiler preprocessors probably raise much havoc with
such editors.

>In either style, note that you *have* to have a language-specific
>editor or editor mode for this kind of tool to work. For it to work
>well, you furthermore need the editor to be integrated with the
>compiler (or at least, the editor needs to know about the compiled
>codebase.) For some reason, there is a lot of resistance to such
>integrated development environments, partially because they tend to
>not cooperate well with other languages.

          A language-specific editor means that I may have to work with a
number of editors rather than just one that I prefer.

>In my more cynical moments, I sometimes wonder if software-development
>tools are driven by a desire to make programming remain "fun". What a
>crazy bunch we are!

          I agree with that.

>[I've used both kinds of editors. The first kind is incredibly
>annoying, because there are lots of common and simple text changes
>that are large changes in the parse tree, e.g, move a close brace
>down a few lines past some other statements. The second kind is still


>around. Teitelbaum et al started a company and turned their stuff
>into products. See -John]

          I haven't found them of use.


Gene Wirchenko

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.