On Wed, Jun 28, 2017 at 11:01 AM, vitalije <[email protected]> wrote:
Every ivar that caches settings can be turned into property that gets its >> value from c.config.get< >> something>. >> > Excellent idea. There is a performance penalty, but it is not likely significant. It wouldn't be so hard to even make a script that would search and find > every occurrence in Leos code of such ivars and turned them into properties. > Yes. > By transferring to ClojureScript I have discovered some very cool projects > that I could not imagine were possible at all. One of the coolest things is > writing reloadable code. > > I am amazed how cool it is to make small change in your code and in a few > milliseconds browser shows the effect of changed code. It is impossible to > express in words the feeling. Once you try it and feel it for yourself you > can never tolerate again any tool that requires you to reload or to wait > more than a second for the effect of your action to be visible. Maybe I > become a bit spoiled after experiencing all that and now I am expecting > from each tool I use to have such feature. > Very cool. This is purpose-level thinking. > @Edward, you have mention the Aha moment when @clean file become possible. > I had proposed that few years earlier but you didn't understand my idea. I > don't know is it possible to find those messages on this list but I > remember that I proposed for shadow files that were used to be kept in > hidden folder as ordinary files that their content could be stored inside > Leo document itself. That is precisely what @clean nodes do today. Isn't it? > Close enough. The "diff" is between the external file (without sentinels) and and the results of simulating writes from the @clean tree to two strings*, with and without* sentinels. Well if I were able to explain that idea better @clean feature could have > been implemented few years earlier. > I see. My biggest regret is not realizing @shadow was sound (ambiguities don't permanently matter) before Bernhard Mulder died. He may have thought the theorem was trivial, so didn't bother to state and prove it. > In Leo's site there is paragraph where Edward explains why he likes Python > (here <http://leoeditor.com/appendices.html#safety>) > > Before using Python I never fully realized how difficult and dangerous > memory allocation is in C++. Try doing: > > aList[i:j] = list(aString) > > in C. You will write about 20 lines of C code. Any error in this code will > create a memory allocation crash or leak. > > Now I am trying to say the same thing about settings code. All settings > could be present in just about two lines of code: sqlite3.connect(...) and > conn.execute('select ...').fetchone(). > That would be great internally. Can you init sqlite from leoSettings.leo, myLeoSettings.leo and the local .leo files? > Surely, Leo has proven that it is possible to keep settings in the same > file format in which Leo documents are kept. But it was achieved by writing > a lot lines of code and that means lot of possible places for bugs to hide. > It would not make a memory leak or hard crash, but nevertheless it can > cause a lot of frustration to the user (especially to spoiled one) . What > is more important it can prevent (and if I may say so it does prevent) > achieving such a cool feature as reloadability. Who knows what other > features could be discovered once the reloadability is achieved. > Reloadability is a separate issue. Leo could cache settings so that reload time is minimized. > > Present scheme for keeping settings allows hierarchical management. Well > it does. But honestly speaking how big is that benefit? I for example don't > remember when I touched myLeoSettings.leo file last time. But I do remember > that it was painful every time I did. Being able to see my settings > in hierarchical view isn't that useful if you must read a ton of > documentation to figure out what is the proper way to set something. > Leo has hundreds of settings. I change them in myLeoSettings.leo or a local .leo file all the time for testing. There have been few complaints about @bool, @int, etc. The confusion comes from knowing which settings are in effect. I suppose we could say that *all* settings come only from myLeoSettings.leo. This would mean a) copying settings from leoSettings.leo and b) foregoing the possibility of per-file settings. This does not seem attractive to me. > If you are lucky and everything work as advertised you have to open > settings file make change and then reopen all your documents. > The full reload-settings command is supposed to do this without reloading files. > But if it doesn't work you have to go through the documentation to figure > where you went wrong and why your new setting is not accepted. If you are > very unlucky, there can be a bug somewhere that prevents your settings to > take place and there would be a lot of combinations to try (as there was > for shortcut combinations). After you have tried all the combinations you > finally start to suspect that maybe a bug is somewhere present. > Bugs do not invalidate the advantages of having hierarchical settings. But if you really like two have hierarchical view, you can have it very > easily even if the data is kept in database. It would be straightforward to > implement script for populating Leo tree with the values from database. > That's good. Imo, this would be an essential script to have. I am not fooling myself that the init code can be simple. I can understand > that it is inherently complex. But I would argue that by insisting on > reading settings from Leo document makes it even more complex. > Yes, it does. But per .leo file settings are important to some people. > Put it this way. After how many executed lines of code Leo has all needed > information (means all relevant settings) to start reading user document? > If it is N lines of code. I would argue that in that complex code it could > be eliminated no less than 20% of N just by using database for keeping > settings data. > I would be happy with that, provided that a) settings can be organized and b) per-document (.leo file) settings are possible. The best way of organizing anything is in a .leo file. Finally I want to say that I am pretty determined to make an experiment of > switching from present Leo document format to sqlite database. > I encourage you to do so. There have been many times that I have failed to understand an important idea at first, second or third glance. > I have made few years ago a script to pack/unpack the whole Leo tree in > fossil repository which in fact is a sqlite database. I am certain it is > possible. I don't know how caching is implemented in Leo ATM. I remember > that there was some discussion about the problems with the filenames and > paths regarding caching mechanism. Well if Leo document was actually > database it wouldn't need any other type of caching, because content of all > nodes would be available from database. It just needs to check every node > for possible external changes. I believe Leo is already doing this sometime > during the opening document. > Yes, Leo reads and updates the cache when reading external files, and updates the cache when writing external files. > @Edward, I would like very much that you don't take any of my criticism > personally. > I don't. I want to make sure that we don't remove useful features of Leo so that Leo's code can be simpler or that load time can be faster. Another principle I have is: two steps forward and one back is not good enough. > Here is the first question. I wander what is the meaning of tnodeList > attribute of SaxNodeClass in leoFileCommands module? > Iirc, the tnode list is to support old Leo file formats. I just saw a comment to that effect in the code. It may be time to announce the end of that support. 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 [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.
