On Mon, Feb 17, 2014 at 6:32 PM, Edward K. Ream <[email protected]> wrote:
> This is an Engineering Note Book post. It consists of notes to myself. > Feel free to ignore. > ... ===== Handling leading whitespace > The present code *assumes* that it knows how to generate the indentation > of @others directives, thereby baking in a minimum indentation for all > methods of a class. This may be reasonable for Python, but it is simply > wrong for most other languages. For example, there is no required > indentation at all in C++ or JavaScript. > > Instead, what should happen is that all method nodes are "undented" by the > indentation of the @others directive. To make this work, the indentation > of the @others directive should be the minimum indentation of *all* the > methods of the class. > Handling leading indentation correctly leads to unavoidable complications. These won't go away in the new code, but perhaps they will be handled more cleanly. 1. Intermixed leading spaces and tabs are always going to cause problems of one kind or another. The code took one of various policies, including at least the following: - Automatically regularize leading whitespace, with or without a warning. - Refusing to remove leading indentation containing intermixed leading whitespace, with or without generating an @ignore directive. At present, both the code generators and the perfect import code choose different policies depending on the language in effect. The "strict" ivar determines whether leading whitespace is significant. However, leading whitespace can be significant in strings even in non-strict languages, a fact that I'm not sure the present code handles properly. ===== Eliminating or greatly simplifying perfect import checks My goal/fantasy is to be able to eliminate perfect import checks, or perhaps greatly speed them. However, this seems a bit implausible for a straightforward reason: the @auto write code in leoAtFile.py is far from trivial: it uses the most general write code, but with various switches to eliminate sentinels, etc. It will be hard to prove that the present read code, applied to *any* particular outline, will produce exactly the same external file as the original. An alternative would be to use simpler write code in leoAtFile.py for @auto files. This will not be a trivial project, but it would seem necessary if there is any hope of eliminating the perfect import checks. For now, it's an open question whether it would be a good idea. ===== The way forward For now, the real goal is to find a way forward so that the code gets simpler without requiring a massive rewrite. As usual, I'll start with a compile-time switch, new_gen, in leoImport.py. I'll also start with a unit test for failing JavaScript imports. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
