One possible use of these generators is for calculating line number in external files. Currently command goto-global-line is implemented in such a way that it generates whole content of external file, then it splits generated content into lines and then starts counting. It is rather expensive operation not suitable to give a real file line number in status line. In status line we have line, col and fcol, but we don't have f_line because it would be just too slow to calculate on the fly whenever text cursor moves. However counting lines is nothing more than summing integers. If there were an easy way to find out how many lines in output file would produce any given line of body in any given node, then calculating f_line would be really cheap operation and we could easily have it displayed in status line and perhaps in gutter also. Basis for these calculations is that the answer to a question what is the content of n-th line of this node is available without too much calculations. If v.lines is ready then it is just matter of indexing in tuple. If every leaf node has the answer to a question: "how many lines in output do you generate?", and if this answer is also readily available without to much calculation, then its ancestors with at-others directive should just ask and add up all of their at-others children. My point is that it should not be too hard to answer a question: "How many lines in output file is generated by this particular line of this particular node?" just by looking in the line itself and its p (position instance). This is something I felt might be possible before but wasn't sure and now after the experiment I become more and more confident that it is possible. Wouldn't it be nice to have real file line numbers displayed in gutter. In many cases running command goto-global-line would not be necessary.
I have started this experiment looking for a good use case for lines property. It turned out to be a useful experiment on its own, but I still have a feeling that the combination of the two would be also great. Vitalije PS: I have stated in the beginning of this thread that the experiment is just dealing with python files. That's why I have hard-coded '#' as comment delimiter. Naturally it needs to be refined and to allow even switch of delimiters, but I haven't had example file demonstrating this feature. Edward it would be great help if you can provide example files which exhibit all supported features of Leo read/write code. Those files can be used as a proof of the equality between new and old code. If I had those example files, I would try to make a script that generates infinite number of pseudo random examples and tests them by both versions of code comparing the results and reporting differences. Such script can possibly discover (if it exist) some hard to find secret bug that nobody has yet reported. If it runs long enough and doesn't find anything to report, we can be pretty sure that code is bug free. -- 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
