Re: Smart textual editors

jacob@jacob.remcomp.fr (Jacob Navia) writes:


|> > I was looking for smart textual editors. By smart, I mean editors
|> > which might be doing data flow analysis and such things even while the
|> > editing is in progress so that they can point out the errors to the
|> > programmer. (e.g. if certain part of the code is unreachable, then it
|> > might give hints to the programmer etc.)
|> [snip]


|> > [I've seen plenty of syntax editors, none of which seemed to me to be worth
|> > the grief they cause. (Many common editing operations are hard to express
|> > in syntactical terms, e.g. moving parens around.) But I've never seen one
|> > that tries to analyze the semantics of the code you're typing. -John]


|> Having implemented a syntax analyzing editor, I think the editor you want
|> is out of the question for the foreseeable future (2-3 years...).


|> My editor limits its job to display keywords in a different color than
|> normal program text, highliting comments as well. The updates are done in
|> real time of course.


What platform are you working on? I think most Unix editors do this.
(Emacs and xemacs, at least, do, and I've been told that the latest
releases of vim do as well.)


|> This simple analysis is very difficult to do in real time: If you happen
|> to type a '/' just before a '*' all the text until the end of the file
|> will be a comment, and has to be changed (redrawn). The editor has to
|> scan each character you type looking for 'interesting' ones, like '/', to
|> avoid rescaning the whole file at each character typed.


You need some heuristics. If you insert a /* in a line containing text,
xemacs will only mark the comment to the end of the line. If you insert
a /* on an empty line, xemacs will not mark anything until you enter the
*/.


Xemacs knows quite a bit about the language, which it uses to do some
very good automatic indenting. You can fool it, but it doesn't happen
too much in actual practice.


|> The algorithms I used were based in simple heuristics: I limited myself
|> to the current screenfull of text, keeping a pointer to the comment just
|> before the start of the text (if there was any). I rescanned the text
|> starting there, since the user can't modify anything outside the
|> currently displayed screen. This had a certain impact at the
|> responsiveness of the editor for fast typists. With the progress of
|> hardware, more extensive analysis becomes possible.


I believe the basic xemacs heuristic involves being able to find the
beginning of a function by scanning backwards, and starting its syntax
analysis there.


|> Just before I save a file, I check for obvious syntax errors (mismatched
|> parentheses and such). I am thinking of doing this in real time too. This
|> would be doable.


Are there editors which don't show matching parentheses in real time.
Even the stone age vi does. The current version of xemacs (and I
suppose emacs) even handle parentheses in quotes or comments correctly
when showing the match.


One of the nicer points of xemacs automatic indenting is that when you
enter a new line, if the next line doesn't line up where you thought it
should, it generally means that there is an error in the line you just
typed.


|> But doing a DATA FLOW ANALYSIS in real time?


|> First, a representation of all the globals/variables of the current
|> procedure would be necessary. This information would have to be updated
|> constantly, since the user is constantly modifying the program text!!!
|> Syntax errors would have to be ignored, and I do not know how: what do
|> you do when the user just typed a ' { ' ???


|> Where you will put the missing closing brace?


I'm not sure what advantage data flow analysis would bring to an editor.
As far as I know, compilers only do it when optimizing.


|> I display the name of the current procedure at the right of the window
|> frame. Keeping only this MINIMAL information is very difficult with the
|> user constantly moving the cursor with PgUp or PgDown or changing from
|> one file to another.


The trick is, of course, to be able to find the start of the function by
scanning backwards from the current position.


|> I think a better alternative is to build a dictionary at each
|> compilation. I have modified the compiler that goes with the editor to
|> generate the dictionary, and then the editor only has to use this
|> information.


I am aware of at least one vendor who is developing something along
these lines. Typically, at least in a C++ environment, such information
would be used for brouzing.


|> This solves the syntax error problem. As the moderator rightly pointed
|> out, syntax errors MUST be accepted by the editor's parsers to let the
|> user type what he wants without the editor becoming an obstacle to the
|> user.


Check out xemacs (although I think emacs is exactly the same on this
point). I use it for C++ extensively, and it works. And you can
certainly enter syntax errors with it; I generally type my comments in
as free text (without prepending the // at each line), then pass them
through a filter to format and insert the comment tokens. I've never
yet not been able to enter something in a comment.
--
James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
--

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