On Tue, 19 Apr 2016 11:16:33 -0500
"Edward K. Ream" <[email protected]> wrote:

> On Tue, Apr 19, 2016 at 9:23 AM, 'Terry Brown' via leo-editor <
> [email protected]> wrote:
[snip]
> As soon as you save a layout using
> > ​ ​
> > free_layout that becomes the persistent layout for that outline
> > (based ​ ​
> > on the path, as with other things in c.db).
> 
> What commands save this data?

free-layout-context-menu :-/  That is an Alt-x command, but not the
answer you were looking for.  The Save item on that menu saves layouts.

> > So if there is a saved
> > ​ ​
> > layout, which would be the recommended way of setting initial
> > ​ ​
> > appearance, initial_split_orientation should be ignored.
> > c.db.get('_ns_layout') will tell you if there is a saved layout.
> 
> ​Big sigh. The startup code, including settings, is pretty
> mind-boggling.
> 
> Maybe we should just retire @string initial_split_orientation??? But
> that seems a bit extreme for those who never use layouts.

I don't think it's too much of a job, assuming
initial_split_orientation is only applied in one place, it can just be
ignored there if c.db.get('_ns_layout') is not None, or whatever the
free_layout equivalent is can be applied.  

c.free_layout.get_top_splitter().rotate()

might be sufficient.

> a) there's a bug in c.db, when you create and save a new file, c.db
> >     in that file gives a key error
> 
> ​Is it reasonable simply to catch that error and ignore it?​

This is a separate issue of course, purely c.db related.  Trouble with
ignoring it is that c.db functionality should work without having to
close and reload the file, or maybe even save the file.  New files, in
particular new never saved files, are a sort of edge case
(surprisingly, I guess we don't create new .leo files too much).  But
all it needs is c.db to behave like a defaultdict and create an empty
entry for paths that didn't exist at app. level start up.
 
> b) when your new file's called ~/r/test.leo (~/r is a RAM disk I use
> >     for temp things) it remembers the saved layout name from a
> > previous ~/r/test.leo, but ~/r/notthattest.leo worked as expected,
> > i.e. c.db.get('_ns_layout') == None
> 
> ​I don't understand.  Yes, the two "test" files aren't the same, but
> how is the cache to know that?

It can't, I just thought it was funny, particularly given the
volatility of a RAM disk.  I'm trying to check that free_layout doesn't
do something clever like creating a "Default" saved layout for a new
file (it doesn't), but my first attempt told me the brand new file's
saved layout has somehow been set to "Bookmarks".  I don't think
there's any issue to address here though.

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 [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.

Reply via email to