I've been feeling a bit under the weather for several days. I'm feeling a bit better now.
While I've been down I've been fiddling with making @auto recreate whitespace exactly in all situations. Similar remarks will, presumably, apply to @shadow, though the implementation might be different. The following are notes to myself, but I think anyone interested in @auto and @shadow should pay close attention. Important: the focus of my attention is to make Leo easy to use in the upcoming Zope sprint. I think this focus clarifies matters... The essence of the problem is that without a special convention there is no way to represent underindented lines. As a special case, there is no way to determine whether to delete leading whitespace in an otherwise blank line. Leo does, in fact, have a convention for handling underindented lines. A line starting with \-4<whatever> will cause Leo to write <whatever> with 4 few leading spaces than would otherwise happen. I will soon support this convention in @auto and @shadow trees. But notice, this will show "truly" blank lines as \-N where N is the indentation of the "leftmost" column in a node. And as I write this, I realize that this convention is fragile: it may give imperfect results when nodes are moved left or right. As an alternative to the \-N convention, Leo supports the write_strips_blank_lines option. When this option is in effect, the @auto and @shadow import code strip away all blanks and tabs from lines that would otherwise be blank. In that case there would be no need for the read (import) code to create \-N prefixes, and the write code would do the actual stripping. In short, we have a not-too-pleasant choice: 1. Use a truly ugly convention to handle distinctions between lines that don't often make any difference. 2. Use a setting that will force the "cleaning" of @auto and @shadow files. There is a third way. Let us say that an external file is "Leo-clean" if: a) No (visually) blank line contains any leading tabs or spaces and b) No non-blank is underindented. That is, every non-blank line contains at least as much leading whitespace as the leftmost characters in the node in which it will be imported. Suppose I write a script that will make a file Leo-clean. When working on a file in the Zope sprint, it would be good to run this script before using Leo on any file. That way the "cleaning" step can be checked in separately. Thereafter, we would expect all changes made by Leo to be "real" changes Conclusion - Whitespace issues are surprisingly important in cooperative environments. Nobody likes unexpected changes to files. It creates the illusion of unreliability. - Cleaning files (making them Leo-clean) before using Leo in a sprint should cause little upset. It's a will defined process, and checking the diffs should verify that nothing important has changed. - In contrast, the write_strips_blank_lines option is of little use in a cooperative environment: it will cause unexpected diffs the first time an @auto file is written. It's not exactly an evil option, but it will be off-putting in too many cases. - Imo, Leo must support the \-N convention for @auto files, and probably @shadow files as well. This is the only way to keep people happy if they don't want to allow files to be Leo-cleaned. In short, cleaning files is the simplest and best way, provided cleaning is acceptable. Otherwise, the \-N convention looks unavoidable. Your comments, please. Edward P.S. I plan to ask the Zope people how they feel about cleaning leading whitespace from their source files. I'll omit the gruesome details in this post, and simply say that it would help me use Leo. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
