Rev 0271a0 in sessions completes #1107

[Edward K. Ream]

#1107  contains a 
full report.  Here, I'd like to emphasize the highlights, as pre-writing 
for documentation.

1. The --session-save and --session-restore command-line options are 
deprecated. Leo will ignore them with a warning if they exist on the 
command line.

2. Leo saves and restores session data to sessions.leo *only* if the 
command line *doesn't* specify file names explicitly.  This convention is 
*much* better than the old clumsy way, and pretty much matches how pyzo 
works.

3. The code changes were small, though not trivial.  I botched the first 
attempt, but it's unlikely any bugs remain.

*Summary*

This is an amazingly useful addition to Leo. The new recommended usage is:

- Invoke Leo *without  *files on the command line to resume where you left 
off.
- Invoke Leo *with* files on the command line to invoke a specialized 
(named) session.

Edward

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

Re: Ahas: the way forward

[Kent Tenney]

=snip=
> ignore Kent
=snip=

I get that a lot. :-]

I usually am at a text console, which benefits greatly from
tmux and it's Python wrapper tmuxp.

tmuxp uses a yaml or json file which describes a tmux
session: windows, panes, commands to run etc.
$ tmuxp load dbdev.yml

dbdev.yml defines a work environment appropriate for
the directories, files, commands used for db development

The effect is similar to Edwards suggestion to create a
batch file, but instead of os specific script, the file consists
of standards based definitions.

That's all.


On Tue, Apr 9, 2019 at 11:31 AM Terry Brown  wrote:

> On Tue, 9 Apr 2019 08:57:03 -0700 (PDT)
> "Edward K. Ream"  wrote:
>
> > On Tuesday, April 9, 2019 at 8:28:22 AM UTC-5, Edward K. Ream wrote:
> >
> > > Neither Leo's code base nor Leo's ecosystem will change in any
> > incompatible way.
> >
> > I plan to experiment with using a QDockWidget at Leo's top level.  As
> > mentioned recently, the QDockWidget is not as flexible as I would
> > like. One trick might be to use a tiny/invisible central widget, with
> > the goal of allowing more flexible placements of *all* widgets.  An
> > easy, standalone, prototype will soon show whether this has any
> > chance of working.
> >
> > Using QDockWidget in any way *might* require changes to plugins that
> > put widgets in Leo's Log pane. I'll consider making such widgets
> > dockable, provided of course that Leo does, in fact, ever use
> > QDockWidget.
>
> I had done, meh, 72% of this work in the qdock-layout branch, not to be
> confused with the qt_docks branch, an earlier attempt that didn't get
> as far.
>
> It's not that hard if you ignore Kent, who will want persistence of
> multiple named layouts.  Unfortunately he's right, having to rearrange
> your workspace every time you start is unacceptable, and persistence
> makes it much harder.
>
> At least you can avoid my earlier mistake of failing to properly
> understand QMainWindow.saveState().  I spent a lot of time with
> complicated code trying to save and restore the layout myself with
> QDockWidget's rather limited API, before realizing the
> QMainWindow.saveState() was what I needed.
>
> I never completed the project because of what was, for me, an
> insurmountable amount of complexity in initialization with find and
> spell tabs in the log pane etc.
>
> 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.

Re: Ahas: the way forward

[jkn]

On Tuesday, April 9, 2019 at 5:31:02 PM UTC+1, Terry Brown wrote:
>
> [...] 
>
I never completed the project because of what was, for me, an 
> insurmountable amount of complexity in initialization with find and 
> spell tabs in the log pane etc. 
>
> Cheers -Terry 
>

This is not really germane to the thread topic, but Terry's last paragraph 
reminded me: Is anyone else seeing multiple 'Find' Tabs come up in the log 
window? I have had this for a while; Ctrl-F brings up a new, empty, 'Find', 
tab, but the actual action remains with the first such tab.

Jon N

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

Re: Ahas: the way forward

[Terry Brown]

On Tue, 9 Apr 2019 08:57:03 -0700 (PDT)
"Edward K. Ream"  wrote:

> On Tuesday, April 9, 2019 at 8:28:22 AM UTC-5, Edward K. Ream wrote:
> 
> > Neither Leo's code base nor Leo's ecosystem will change in any 
> incompatible way.
> 
> I plan to experiment with using a QDockWidget at Leo's top level.  As 
> mentioned recently, the QDockWidget is not as flexible as I would
> like. One trick might be to use a tiny/invisible central widget, with
> the goal of allowing more flexible placements of *all* widgets.  An
> easy, standalone, prototype will soon show whether this has any
> chance of working.
> 
> Using QDockWidget in any way *might* require changes to plugins that
> put widgets in Leo's Log pane. I'll consider making such widgets
> dockable, provided of course that Leo does, in fact, ever use
> QDockWidget.

I had done, meh, 72% of this work in the qdock-layout branch, not to be
confused with the qt_docks branch, an earlier attempt that didn't get
as far.

It's not that hard if you ignore Kent, who will want persistence of
multiple named layouts.  Unfortunately he's right, having to rearrange
your workspace every time you start is unacceptable, and persistence
makes it much harder.

At least you can avoid my earlier mistake of failing to properly
understand QMainWindow.saveState().  I spent a lot of time with
complicated code trying to save and restore the layout myself with
QDockWidget's rather limited API, before realizing the
QMainWindow.saveState() was what I needed.

I never completed the project because of what was, for me, an
insurmountable amount of complexity in initialization with find and
spell tabs in the log pane etc.

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.

Re: Ahas: the way forward

[Edward K. Ream]

On Tuesday, April 9, 2019 at 8:28:22 AM UTC-5, Edward K. Ream wrote:

> There is no need for Leo's --session-save & --session-restore 
command-line arguments!

I have just created #1107 
 for this, and the 
sessions 
branch  in which to 
do the work.

Edward

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

Re: Ahas: the way forward

[Edward K. Ream]

On Tuesday, April 9, 2019 at 8:28:22 AM UTC-5, Edward K. Ream wrote:

> Neither Leo's code base nor Leo's ecosystem will change in any 
incompatible way.

I plan to experiment with using a QDockWidget at Leo's top level.  As 
mentioned recently, the QDockWidget is not as flexible as I would like.  
One trick might be to use a tiny/invisible central widget, with the goal of 
allowing more flexible placements of *all* widgets.  An easy, standalone, 
prototype will soon show whether this has any chance of working.

Using QDockWidget in any way *might* require changes to plugins that put 
widgets in Leo's Log pane. I'll consider making such widgets dockable, 
provided of course that Leo does, in fact, ever use QDockWidget.

Edward

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

Re: Ahas: the way forward

[Edward K. Ream]

On Tuesday, April 9, 2019 at 8:57:19 AM UTC-5, Terry Brown wrote:

I'm not familiar with --session-save & --session-restore, but I assume 
> they support multiple named sessions?  


As Chris mentions, there is no *explicit *support for named sessions.

Happily, you can simulate a named session, right now, as follows:

Create a shortcut/.bat file.  The name of the shortcut/.bat file is the 
name of the session.  The file names on the command line define the meaning 
of the (simulated) named session.

The proposed new scheme will be fully compatible with this scenario.

Edward

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

Re: Ahas: the way forward

[Chris George]

["/home/chris/Working/MegaSync/writing/Origins/Origins.db#Das 
Book:1-->Writing Exercises:2-->Creating Your Premise\u2014Writing Exercise 
1:0", "/working/working/MegaSync/writing/myLife.leo#Root:0-->Notes and 
Such:9-->Song Lyrics:4-->A Capella:1"]

This is my most recent session.leo file which is written on exit to .leo in 
my home directory.

There is no provision for saving different sessions and loading them short 
of a bash script. Leo loads only the sessions.leo file.

So no, there is no provision for multiple named sessions. It was a feature 
I requested a while back but the bash script does the trick for my use 
case. I am not sure if the new scheme will support it either. We'll see.

Chris

On Tuesday, April 9, 2019 at 6:57:19 AM UTC-7, Terry Brown wrote:
>
> On Tue, 9 Apr 2019 06:28:22 -0700 (PDT) 
> "Edward K. Ream" > wrote: 
>
> > 1. There is no need for Leo's --session-save & --session-restore 
> > command-line arguments! 
> > 
> > Doh!  Leo can adopt the following strategy: 
> > 
> > - If the command line contains file names, Leo will load only those 
> > files. 
> > - When Leo exits, it will always act as if --session-save were given. 
> > - When Leo starts without file arguments, it will use the 
> > --session-save data, if those data have ever been saved before. 
> > - Otherwise, this is the very first time Leo has ever started, in 
> > which case Leo will load the workbook file. 
>
> I'm not familiar with --session-save & --session-restore, but I assume 
> they support multiple named sessions?  Not sure how the new scheme 
> manages switching between sessions. 
>
> 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.

Re: Ahas: the way forward

[Terry Brown]

On Tue, 9 Apr 2019 06:28:22 -0700 (PDT)
"Edward K. Ream"  wrote:

> 1. There is no need for Leo's --session-save & --session-restore
> command-line arguments!
> 
> Doh!  Leo can adopt the following strategy:
> 
> - If the command line contains file names, Leo will load only those
> files.
> - When Leo exits, it will always act as if --session-save were given.
> - When Leo starts without file arguments, it will use the
> --session-save data, if those data have ever been saved before.
> - Otherwise, this is the very first time Leo has ever started, in
> which case Leo will load the workbook file.

I'm not familiar with --session-save & --session-restore, but I assume
they support multiple named sessions?  Not sure how the new scheme
manages switching between sessions.

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.

Ahas: the way forward

[Edward K. Ream]

I spend so much time writing these posts because they save so much time:

- Issues become clearer as I write.
- Writing primes the mental pump, so that further Ahas appear later.

*Minimize regrets*

This principle implies the following:

1. Leo will support Python 2 indefinitely.

There is no real advantage to *requiring *Leo's py3 branch. This branch 
will likely be Leo's one and only *permanent* branch, for those who, for 
whatever reason, want a Python 3 code base to work from.

This policy's only cost: merging devel into py3 periodically. For now, that 
cost does not even remotely justify sacrificing compatibility with Python 2.

2. Neither Leo's code base nor Leo's ecosystem will change in any 
incompatible way.

Leo will access pyzo's actual code using a *pyzo plugin*.  If pyzo requires 
Python 3 (I'm not sure) the pyzo plugin, and *only* the pyzo plugin, will 
require Python 3.  Indirectly, this gave rise to a big Aha...

*Aha: add pyzo's features incrementally*

Some of pyzo's features don't require pyzo!

1. There is no need for Leo's --session-save & --session-restore 
command-line arguments!

Doh!  Leo can adopt the following strategy:

- If the command line contains file names, Leo will load only those files.
- When Leo exits, it will *always* act as if --session-save were given.
- When Leo starts *without* file arguments, it will use the --session-save 
data, if those data have *ever* been saved before.
- Otherwise, this is the *very first time* Leo has ever started, in which 
case Leo will load the workbook file.

This will closely simulate pyzo's approach, and will work as usual for 
newbies. I see no drawbacks to this scheme.

2. Leo can support Qt styles *right now *without using pyzo.

A particular Qt style, not anything pyzo does, gives pyzo its clean look.  
Leo will likely provide the style as a setting.  My hope is that this 
setting will be independent of Leo's style sheets.  Otherwise, we'll go 
with the default Qt style by default.  Clear?

3. Leo can replace the Easter Egg interface with menus & commands, at any 
convenient time.

4. Integrating pyzo's cool pyzo file browser will likely be a first Pyzoic 
improvement.

This should be a modest project. Pyzo's code can be copied "bodily" into 
Leo if necessary.  In any case, Leo must support the signals that the file 
browser emits.  These may be the *only* changes to Leo's core.


*Aha: the pyzo branch is a laboratory*

I *must* make Leo's outline pane fully functional in the pyzo branch. Today 
I see there are *three *reasons for this:

1. Obvious: It's always unbearable to leave a project in an 
almost-but-not-quite-finished state.

2. Important: Once the outline pane works, the pyzo branch will be a superb 
framework to explore the interaction between pyzo and Leo. I can easily add 
traces or even calls to g.pdb anywhere within pyzo's code.  This is a big 
deal.

3. Useful: The work may remove cruft from the difficult DynamicWindow class.

*Summary*

There is hardly any cost to supporting Python 2 indefinitely.

I'll soon add several nifty Pyzo features to Leo 5.8.2.  None of features 
will use pyzo's code.

Leo's outline pane must be made fully functional in the pyzo branch. The 
pyzo branch will then be a superb lab for studying interactions between Leo 
and Pyzo.  The goal: simplify Leo using Pyzoic signals, without actually 
using pyzo's code.

Eventually, a new pyzo plugin will add Pyzo's major feature, the Shell 
window, including debugging. This plugin will likely require Python 3.

All questions and comments welcome.

Edward

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