As my experiments proved it is possible to collect and transfer all settings from traditional .leo settings files into sqlite database. If we use sqlite as file format for outline data it is trivial to keep the collected settings in the same file.
A problem can arise when user changes any of relevant settings files: some .leo.db files can have outdated settings embedded. One possible solution would be to have sqlite database files in every folder where traditional .leo settings files are located and to automatically keep them in sync whenever saving .leo settings file. Let us imagine we already have done this. In that case, during the init phase, Leo can instead of reading and parsing all traditional .leo settings files, read settings directly from the db settings files. It is certainly possible to make it this way. However, let us discuss what would be the consequences of outdated settings? First of all, we can have new command `update-embedded-settings` which can parse relevant files and collect current version of settings in .leo files and update .db file settings table. Leo can warn user that the settings in db document are outdated and to offer updating them or keeping old values. It can be done automatically behind the scene and then executing reload-settings command. It will happen once per every leo document after each change in settings files. When creating a new Leo document it would get all current settings embedded in database file. But let us discus how and when settings files change? There are two cases I believe: 1. git pull and leoSettings.leo has been changed 2. user edits myLeoSettings.leo or any other settings file. Now, whenever leoSettings.leo is changed we can also update leoSettings.db and both files would be pulled at the same time. Global leoSettings.leo file has unique location per installation and it is trivial to find path to it and to its .db version. So syncing automatically those settings is trivial. In the second case we can perhaps assume that myLeoSettings.leo file won’t be edited by some other editor than Leo itself. Perhaps we can also assume that user would use menu command to open settings file. This may be a bold assumption because user can manually navigate and open that file. But let us just pretend that it is a fair assumption to make. In that case user would have to open myLeoSettings.leo through the menu command. What if we recreate outline of that file based on values and unls directly from database not from actual file on disk. User is then able to edit settings the way he/she likes and when the editing is done outline is stored once again in database and maybe in .leo file on disk. When I say in database I didn’t specify which database file. Well it could be one fixed database file located in leoHome directory. It can have all settings kept in a table along with their unl origins. In that case all settings documents can be recreated from the one database file just by selecting a group of settings with unl that starts with some path. If implemented that way, Leo would on start check two databases at well known locations (one in installation folder and one in ~/.leo). It would collect all the settings from the first (installation folder database), and only those settings from the second database that have unls that starts with one of the paths that Leo would look up for settings: (settings per user, or per folder). From all those collected settings Leo can update the settings table in db Leo document itself. That way g.app.config and c.config can be available in just a few lines of code at the very beginning of init phase. The only restriction for user is that they must not open any <settings>.leo file directly from disk but through the menu command. IMHO it would be very small restriction for users to suffer and it would bring in the future opportunity to considerably simplify init code. For the period of adoption we could keep current settings mechanism but on every save we can behind the scene build and update those two database files. After period of adoption, we can deprecate and remove old <settings>.leo files so that users can never see them again unless through menu command. Then we can start simplifying the init code. Your opinions please. Vitalije PS: I would be glad to implement any of the two possible solutions, but my choice would be to restrict users to open settings file only through menu commands and in the future get rid of those files and keep them only in two databases. -- 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.
