freeride-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FR-devel] Introduction / Folding and Smart Indent


From: Baptiste Lepilleur
Subject: Re: [FR-devel] Introduction / Folding and Smart Indent
Date: Tue, 7 May 2002 15:26:12 +0200

----- Original Message -----
From: "Brian Denny" <address@hidden>
To: <address@hidden>
Sent: Monday, May 06, 2002 11:14 PM
Subject: Re: [FR-devel] Introduction / Folding and Smart Indent


>
>
> > Give a look to my mail on folding and smart indent. See if you have
other
> > ideas. What is needed here is basically a small parser that identify the
> > code structure. It has the advantage of being fairly easy to unit test.
>
> i looked at your e-mail and tried it out in Practical Ruby.  Very cool how
> much is accomplished by such a simple algorithm!

I found an additional status for a line of text:
- line is a continuation of the previous line.

For example:

    if ['a'..'z'] === char  ||
        ['0'..'9'] === char                #  <== this line is a
continuation of the previous line and should have a special indentation.

>
> i noticed that "begin/rescue" and "elsif" were missing.  i believe this
> can be handled the same way as the other keywords?  (diff follows this
e-mail)

Thanks, I added them.

> i suppose the next step would be to handle:
>
>   [1, 2, 3].each do |n|
>     puts n
>   end
>
> ... which i guess is a matter of dealing with keywords that don't begin
> the line.

Indeed. You also need to deal with operator:

[1,2,3].each { |do|
  puts n
}

And the fact that a structure can begin and end on the same line:
[1,2,3].each do |do| puts n; end

> i imagine that some of the other smart editing features may require that
we
> actually run the document through a full-blown ruby parser.  do you think
> it would be advantageous to use the resulting parse tree for smart indent
> and folding as well?

Indeed. Autocompletion and Calltips require to know the full context at a
given position. The resulting parse tree could probably be reused.

One issue here is performance: when you have a good implementation of a
smart indent, you want it to be called each time a single character is
called (so that as soon as you type 'end', the line is reindented...). This
could be worked around with a good incremental update. Another is
consistency: suppose you are adding a condition in a method:

def x( y )
  if @threshold < y then            # <== adding this line
end

The source is invalid for a short while ( the 'def' does not have an
associated 'end').  I'm not sure how this should be dealt with, probably
something based on the fact that change done to the source are incremental.
Not so easy anyway...

The 'simplistic' approach to smart indent as the advantage to work well even
on a completly broken source.

Baptiste.
---
Baptiste Lepilleur <address@hidden>
http://gaiacrtn.free.fr/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]