Realized it was silly, & changed my mind about the 'saved with the leo
file' part. I removed the last message
On Thursday, August 27, 2020 at 10:00:54 AM UTC-4, Félix wrote:
>
> (continuing my example)
>
> It's not about which command to run if expanded/collapsed, its about which
> will be selec
forgot to add that although I would consider the collapse-state part of the
model, just like structure, headline lable and body, it's *not *to be saved
with the file, (it is volatile) and is lost / reset when opening the Leo
file.
On Thursday, August 27, 2020 at 10:00:54 AM UTC-4, Félix wrote:
(continuing my example)
It's not about which command to run if expanded/collapsed, its about which
will be selected when the command is run. (if we're considering the command
'selectNextVisible', for instance...
So what is computed by the controller, is which p node to set the selection
to, b
On Wednesday, August 26, 2020 at 11:19:56 AM UTC-5, vitalije wrote:
I doubt this would be a very good idea. Undo/redo already has a lot of
> things to do. Adding some more chores to them will likely make things more
> complicated, slower and probably introduce more bugs.
>
Yes, what I now call
On Wednesday, August 26, 2020 at 9:16:54 AM UTC-5, Edward K. Ream wrote:
For several years now, Vitalije has rightly complained that copied
> positions can become invalid when the outline changes.
>
Let me restate the problem I am trying to solve:
1. I would like a subset of positions to remain
> It is visualised as expanded/collapsed in the gui, indeed right, but its
> important in the model/controller as much as the 'headline string' or 'body
> content' because of those commands which set the selected node based on
> whats collapsed/expanded. So it is real model data/state as muc
Hello dear Leonista friends !
When I think of commands such as 'selectNextVisible' (or something similar,
i'm not at my computer right now) and consider the state of the 'currently
selected node' as having importance when executing some model/controller
related commands, I fail to consider the
On Wed, Aug 26, 2020 at 11:19 AM vitalije wrote:
> Now, regarding the initial problem (I believe it was about
expanded/collapsed state of nodes)...The simplest possible solution will be
just to delegate the p.isExpanded method to the GUI and find the
corresponding tree item and ask it if it is ex
I doubt this would be a very good idea. Undo/redo already has a lot of
things to do. Adding some more chores to them will likely make things more
complicated, slower and probably introduce more bugs.
Instead I suggest another approach. Please consider the rest of this
message not as a critic of
Maybe the copied position list could be a reference and not a copy if the
positions have not changed since the last undo - which would usually be the
case. A dirty flag for the list would have to be carried somewhere.
On Wednesday, August 26, 2020 at 11:45:19 AM UTC-4, Edward K. Ream wrote:
>
>
On Wed, Aug 26, 2020 at 10:11 AM Thomas Passin wrote:
> I think that if a copy of the current list of all positions were included
> in the undo data, then it could be restored upon undo and everything would
> work. I don't know if that would be too slow, so that it would affect the
> perceived s
I think that if a copy of the current list of all positions were included
in the undo data, then it could be restored upon undo and everything would
work. I don't know if that would be too slow, so that it would affect the
perceived speed of the keystrokes.
On Wednesday, August 26, 2020 at 10:
For several years now, Vitalije has rightly complained that copied
positions can become invalid when the outline changes.
Just now, after a bicycle ride, I saw what seemed at first to be an elegant
solution, namely p.cloned_positions. This would be a list of *copied*
positions that Leo will aut
13 matches
Mail list logo
