> > > For example, yesterday I discovered a settings table that inited several > commander ivars. My first thought was, maybe this table could go away. > But no. These ivars appear all over Leo. It would be horrible to use > c.config.getInt or c.config.getBool in their stead. So this table creates > a major convenience in Leo's code, even while it complicates the startup > code and (eventually) will complicate the reload-settings command. It a > choice, and I think the tradeoff is a good one. > > Edward >
Every ivar that caches settings can be turned into property that gets its value from c.config.get<somethnig>. 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. That way Leo would have single source of settings data and every change in the source would be visible every where instantaneously. Last few months I have been studying ClojureScript and experimenting with it. Maybe last 5 years or so, my programming was mostly oriented towards client scripting in web browsers. Until recently I was using almost exclusively CoffeeScript for all programming tasks. 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. For all my computer related work I use Leo as editor, as a database as scripting environment, for processing all sorts of files, for all types of scripting. And I am very grateful to Edward and whole community for all the work they all put in this project. I am no newbie in Leo world nor I am newbie in python or for that matter almost to any programming language from Z80 and 6502 assembly language to C, C++, Java, Scala, Groovy, Javascript ActionScript, ... up to Clojure and ClojureScript. @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? Well if I were able to explain that idea better @clean feature could have been implemented few years earlier. But at that time my suggestion was refused and I didn't care too much because I work almost exclusively alone and I have never had problems with synchronizing files nor with the sentinel lines. 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(). 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. 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. If you are lucky and everything work as advertised you have to open settings file make change and then reopen all your documents. 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. 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. 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. 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. 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 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. I will be posting the progress of my work. When/if I make a working prototype I will make a list of changes I have made and then perhaps we can discus about the best way to package it. @Edward, I would like very much that you don't take any of my criticism personally. I have very high respect for your engineering skills and I was enjoying every bit of your ENB-s and have learnt a lot from you. Maybe you won't like that much my idea, but even if you dislike it I would be very thankful if you help me by answering some questions about how Leo works ATM. Here is the first question. I wander what is the meaning of tnodeList attribute of SaxNodeClass in leoFileCommands module? In my experiments I intercepted the call to readSaxFile and instead of parsing an xml file, I wanted to provide the tree of SaxNodeClass items retrieved from database. My experiments were successful so far, but I have found that those tnodeList attributes were always empty. I don't know if they are supposed to be empty at that time or maybe in some special Leo files they can contain some information? I have tried to export LeoPyRef.leo to sqlite database and then to read it and combine them in tree of SaxNodeClass. LeoPyRef.leo can be opened that way but maybe that file doesn't use all of the supported features. Vitalije -- 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.
