From: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: EMACS problem
Date: 3 Nov 1997 07:36:29 GMT
Organization: The National Capital FreeNet
Lines: 77
Message-ID: <63jutt$ple@freenet-news.carleton.ca>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 971102143551 DOT 11098V-100000 AT is>
Reply-To: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host: freenet5.carleton.ca
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) writes:
> On 31 Oct 1997, Paul Derbyshire wrote:
> 
>> Two things that together may ensure a fix in a future EMACS:
> 
> Such advice should go to the maintainer of cc-mode (the Emacs module
> that handles C- and C++-specific indentation), not to this group.

The article was in the group, hence so was the follow-up. This comment
might be better directed at the original poster. Also, didn't it pertain
specifically to the DJGPP version of Emacs?

>> One, be sure
>> to use STL ropes or something similar for buffer contents
>> representation.
> 
> I'm not sure if this advice is at all applicable to the case in point,
> since it is written in a dialect of Lisp.  When you work in Lisp, you
> need to think Lisp, not C++, otherwise you get bad code.

CC-mode is in Lisp. I was under the impression the bulk of Emacs itself is
in C/C++. If it is in C++, buffer representation with ropes will improve
performance of the base code and any elisp code that random-accesses the
buffer, since the elisp code will simply call some function in emacs' C
code, which in turn accesses the buffer for real.

>> Two, use an indent logic that is "local", i.e. only needs to look at the
>> immediate neighborhood of the insertion point to know what to do. I.e.
>> indent same as line above, unless it ends with a hanging {, then indent by
>> two more, or if it has a } with no matching {, indent two less (with two a
>> user-configirable parameter)...
> 
> If you have ever tried to implement such a feature in an editor, you
> must know that it will not work.  The problem is that indentation must
> ignore comments and pre-processor directives.  In the following
> fragment, you want "bar" to be aligned with "foo":

Then the cc-mode might create a list of lines, how much they're indented,
and the "parent" line and "child" line: a line's parent line pointer points to
the line above it that is not a comment or a preprocessor directive, and
thus determines its indenting, and the child pointer the likewise line
below it. Then the line insert needs to manag the pointers as well,
but it is still an O(1) algorithm instead of an O(n) one, since it deals
with only:
* The inserted line
* The line pointed to by parent pointer
* The line pointed to by the child pointer

(Remember the implementation of a bilinear linked list.)

If previous line is not comment nor preprocessor:
  make it your parent.
Else:
  Check previous line's parent. Set new line's parent same.
End if
If the inserted line is a comment or preprocessor line:
  Do nothing further
Else:
  Point child pointer of new line to equal that of parent line.
  Point child pointer of parent line to new line.
  Point parent pointer of child to new line.
  Use parent's indent to determine new line's indent.
End if.

Reindent any children as necessitated by insertion. (This is O(n) only
if you add an unmatched { or } or whatever in the inserted line.)
Similarly, things must be checked, pointers reaimed and children
reindented if:
* The line is deleted
* The line is edited and becomes a comment or preprocessor directive.
* The line is edited and ceases to be a comment or preprocessior directive.
--
    .*.  Where feelings are concerned, answers are rarely simple [GeneDeWeese]
 -()  <  When I go to the theater, I always go straight to the "bag and mix"
    `*'  bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh