I am so fed up with --use-docks that I've given up on it and gone back to
the older no-docks configuration. With docks, I can never count on the
panes being the same next time I re-open an outline or restart Leo.
Sometimes they are hard to restore to my liking, too. Especially during
plugin
This commit on Aug 16th introduced the LeoDocs.leo.orig file:
https://github.com/leo-editor/leo-editor/commit/acd73c59151c9f5304daa4ce08017c6cc7ec3857
I don't see any related PR merge commit, so probably it was pushed directly
to the devel branch without a PR. Git only tracks information about
On Thu, Aug 27, 2020 at 9:51 AM k-hen wrote:
> Thanks guys, yes it does certainly help :-)
>
> I'm really liking the idea of the single extra dimension for the
> attributes, and I'd like to help make them more prominent,
> there doesn't seem to be anything from the front-end to be able to
>
And thank you also in turn Edward! You welcomed and advised on my first
fumbling attempts, and other similarly not-great ones afterwards until I
reached stable enough ground to meaningful things. As did Terry and Ville
and Kent and Jacob and a host of others I am failing to recall at the
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
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:
Thanks guys, yes it does certainly help :-)
I'm really liking the idea of the single extra dimension for the
attributes, and I'd like to help make them more prominent,
there doesn't seem to be anything from the front-end to be able to natively
interact with them (like maybe a attribute subtree
(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,
On Tue, Aug 25, 2020 at 5:53 PM k-hen wrote:
> Yes, I think that workflow is extremely compelling!
> I think a full graph database integration is my ultimate goal, but this
> could be something really excellent to build off of.
>
> See here: https://github.com/totogo/awesome-knowledge-graph
>
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
On Wed, Aug 26, 2020 at 6:20 PM Matt Wilkie wrote:
>
> As you've noticed I've kind of dropped out of Leo participation this
> summer. My life seems to have arrived on a pivot and I don't know what
> might happen next.
>
You and everyone else :-)
> ...attention on things computery outside of
12 matches
Mail list logo
