On Friday, June 1, 2018 at 2:57:52 PM UTC-5, vitalije wrote: This is exactly why I was reluctant to share unfinished prototype. I did > beg you though, not to make any decisions before the prototype is finished, > but it seems too hard to resist. I couldn't resist the temptation to share > the unfinished code, you couldn't resits to make decisions. >
On my walk just now, before reading Terry's comment, I realized that I should have responded to you, here, directly. *I apologize for unjust criticism * Very likely I have caused you severe pain in several recent comments, by criticizing your work unfairly. I apologize profusely. For me, unjustified criticism is almost unbearably painful. I particularly regret the choice of the word "edict". It's a principle, a suggestion. Moreover, it was totally unfair for me to criticize *any* style choices you made in the prototype. The last thing I want is for people to worry about criticism of unfinished code. Again, I sincerely apologize. I also regret other comments about your code. I was attempting to understand all the ramifications of helper *functions*, as contrasted with helper methods. But again, my comments must have seemed like clueless criticisms. Again, I apologize. BTW, face to face communication has its own failure modes :-) Thoughtless spoken comments might even be more painful. Which is why I like slower, more exact communication. Let's move on... *The prototype* Vitalije, you may feel that the prototype has been misunderstood. I'm not sure that's so, so let me explain. Imo, the prototype has/had at least 5 purposes. For me, the first three have already succeeded spectacularly. The other two, not so much, *at present.* 1. The prototype demonstrates that .leo files and external files can be read must faster than at present. *In this regard*, the prototype needs no further work. It is a *complete* success. 2. The prototype demonstrates that redrawing Leo's outline pane might also be *orders of magnitude* faster than at present. I am completely convinced, so prototype is a complete success, as it is. 3. The prototype demonstrates several new (to me) aspects of programming style. I'm pretty sure I understand the benefits of helper *functions* instead of helper methods. Dereferencing local vars is quicker, and there is no "self" clutter. The fast-read branch uses this style where appropriate. It's not needed everywhere, but it is spectacularly good in crucial places. Once again, the prototype is a complete success, as it is. Now to the less successful (so far) aspects of the prototype. 4. The prototype contains several examples of what I'll call "iterator style". The code builds up lists (or bunches), and delivers them to code that then uses the lists/bunches. This style is still confusing to me, even after detailed study. A different prototype, might reveal why this style appeals to you. 5. The prototype may be attempting to demonstrate that new positions/vnodes would be better. At present, I am completely unconvinced. I see nothing in the prototype code that is persuasive. Perhaps the reverse. Perhaps you could explain, with words, not code, why new positions would be better. In particular, I do not understand what it means to have a position "persist" when the outline changes. I need a picture as good, say, as the git branch picture. That made all the difference. *Future prototypes* I do hope I haven't made you shy about making further contributions. That would be a big loss to the whole Leo community. It would be great to see a Qt prototype of fast screen redrawing. The Tk prototype is completely finished, imo. I've written Tk drawing code, and the prototype Tk code was furlongs ahead of mine. But Tk is way different from Qt, so the Tk prototype demonstrates only that Leo's Qt drawing code *might* be way faster than it is. Aside: I now remember why I gave up incremental drawing in Qt. It was just too difficult for me to handle scrolling. The skip argument to ltm.display_items is really clever, though I'm not sure exactly how it works ;-) It would be great if you could adapt that idea to Qt. That would be a huge contribution. *Summary* I regret some of my recent comments. I apologize for them I promise not to criticize future prototypes! I particularly regret the edict post. Style considerations need not apply to prototypes! The miniTkLeo prototype has been a great success. Imo, no further work on it is needed. It might have been just as useful if it had come even earlier! In future, I hope you will publish early and often. I would very much like to see a prototype of Qt incremental drawing. I still do not understand iterator style. I'm not sure what it would take to open my eyes. Code alone will not convince me that new positions are worth having. I'll probably need a simple picture. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
