On Tue, 13 Dec 2011 16:55:29 -0800 (PST) HansBKK <[email protected]> wrote:
> Given widespread support for extended character sets and unicode, it then > becomes trivial (for the user) to select characters guaranteed not to > conflict with the source content. > > However if this will be a difficult to implement, and the issue hasn't been > a significant problem for decades, then a quicker fix that handles most use > cases would be worth further complicating the differences between the > different @ <file> directives. The issue is not dynamically defining the delimiters, although that's currently not supported. The issue is working out what the delimiters in a derived file are, without embedding that information in the derived file. Or breaking legacy derived files, which assume "<<", ">>". So I think the simplest most bang for the buck solution now is to make sure that Leo ignores the delimiters in @<file> types where they make no sense. This is Edward's area of expertise: Should ignore: @auto Can't ignore: @file @thin I don't know: @nosent @shadow @edit @auto-rst etc. If most of the "I don't know" list ended up on the "Should ignore" list, all would be well. Let's see where they go. Cheers -Terry -- 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.
