On Thu, 29 Jun 2017 08:47:01 -0500 Kent Tenney <kten...@gmail.com> wrote:
> >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 I think outline will cover that - if an outline is specified, the setting applies to that outline. If not, the search order for DB files will be similar to that for (my)leoSettings.leo files. But yes, the obvious implementation allows settings for files without touching the file. Trouble is I'm still not sure how to handle the "file specific settings no longer in .leo file" issue - on the one hand it seems no big deal that copying a .leo file to another system leaves behind $HOME/myLeoSettings.leo, but having any settings that were in the copied file (under the current system) not follow along seems like a regression. Cheers -Terry > 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 copletely, 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 > >LMI.201505.nc > > (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.
