>setting: long - primary key for settings table >name: text - setting name >body: text - text data for setting for docs. and @data settings >type: long - link to types table (@bool, @int, @data, etc.) >parent: long - link to settings table for hierarchy >outline: long - link to outline table
Hows about a 'scope' field: one of default, global, user, curdir, fname which are listed by increasing weight ... the 'fname' one would allow specifying settings for a file without touching it, which strikes me as kind of cool. Maybe that's what is accomplished by the 'parent' and 'outline' fields, if so, please ignore this. On Wed, Jun 28, 2017 at 3:55 PM, Terry Brown <terrynbr...@gmail.com> wrote: > On Wed, 28 Jun 2017 12:48:06 -0700 (PDT) > vitalije <vitali...@gmail.com> wrote: > > > > 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. > > > > > As I wrote in the earlier post today, it is trivial in sqlite to > > open connection to several different databases (files). So it is easy > > to have one database file for settings machine wide, another one for > > settings per user, and yet another one for settings per folder (if I > > am not mistaken there used to be possible for user to define settings > > per project/folder, although I have never used that possibility). It > > is easy to make script to dump all relevant (leo, > > myLeo) settings-files in separate databases. > > The docs. on settings location are here: > http://leoeditor.com/customizing.html#id3 > > not 100% sure but I assume `homeDir` is ~/.leo or $HOME\.leo and > `configDir` is .../leo/config/, and `localDir` is the folder containing > the .leo file. > > Hmm, I'd forgotten about the machine-name variation, although it can be > very useful when the same filesystem is accessed from different > hardware setups. > > Essential: 1a, 2b, 3 > Consider dropping: 1b, 1c, 2a - really when would you use these? > Useful: 2c, 2d - 2d when you want .leo files in a folder to share > settings > > So there's a question of when to use separate DB files vs. info. in the > DB to separate contexts. > > 1a and 2b would obviously be their own DB files, with a search that > fails in 2b being repeated in 1a, trusting for now that that won't be a > performance issue. > > 3 is trickier. We're going to (ok, proposing to ;-) separate the > settings data from the rest of the .leo file(*). Managing two files > side by side seems obnoxious, from the users point of view. I think it > would be better to put the outline specific info. in the same DB as > used for 2b (e.g. ~/.leo/myLeoSettings.sqlite3). So the setting table > might look like: > > setting: long - primary key for settings table > name: text - setting name > body: text - text data for setting for docs. and @data settings > type: long - link to types table (@bool, @int, @data, etc.) > parent: long - link to settings table for hierarchy > outline: long - link to outline table > > We'd start by looking at c.db to see how the outline table might manage > outline identities. > > (*) this separation is a high cost thing. It means the user can't just > move the .leo file to another system and have that file's local > settings follow along. This is consistent with myLeoSettings.leo also > not following along, but still seems like a regression. > > Which suggests that at least for file local settings we might want to > continue to support .leo file @settings trees. Hmm. > > That leads to wanting to make .leo file @settings trees more writable > than they are now, which leads to the possibility of using Leo outlines > rather than sqlite as a storage format. Before this is interpreted as > scraping the idea completely, I'll point out the leosax.py module which > reads .leo files into a light weight dict representation of an outline > many many times faster than Leo's regular read code. It ignores > external files, and is read only. > > Alternatives are > > (a) keeping the .leo and settings DBs side by side, > something.leo and something.leo.settings.sqlite? > (b) embedding the sqlite data in a the .leo XML file - > that seems like a horrible idea. > > So I think the question of the cost of separating file-local settings > from the .leo file is an issue here. It sort of runs contrary to the > idea of XML, which should allow everything to be in one file. > > But anything that deviates from simple vanilla use of sqlite DB files > starts to lose the simplicity gain. Hmm. > > Cheers -Terry > > > -- > 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. > -- 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.
