LeoQtTextBrowser events

[Adrian]

Hello,

I am working to create my own auto completion plugin. 

I am presently using c.frame.body.widget.textChanged.connect to trigger 
popups.  Is this the most leonine and/or pythonic way to go about this?

I struggled to overload LeoQtTextBrowser and make it replace the default. 
 I had it somewhat working, but it would not save nodes, and did not have 
syntax coloring.

Thanks,
Adrian

-- 
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: Cross-file links

[Terry Brown]

On Tue, 20 Jun 2017 13:12:05 -0700 (PDT)
Largo84  wrote:

> I take it this isn't the way it works now? When I try this, it
> appends the ##Text to the URL making it an invalid link.

Ok, try a5409116d - not heavily tested, but seems to work, let me know.

Cheers -Terry
 
> Rob..
> 
> On Tuesday, June 20, 2017 at 2:49:51 PM UTC-4, Largo84 wrote:
> >
> >
> >> I think a descriptive text would be good.  There's a cheap way to
> >> do it, and a more complicated way. 
> >>
> >> Cheap 
> >>
> >> http://www.example.com/##For example 
> >>
> >> just decide that anything following a double hash in the URL is
> >> the descriptive string.  This could be pointed out by the popup
> >> into which URLs are entered.  It would display as 
> >>
> >> For example http://www.example.com/ 
> >>
> >> To change an URL or it's description, you'd have to delete and
> >> replace, when you click a link it appears in the Log pane, so you
> >> can copy from there if you're replacing something existing. 
> >>
> >> Complicated 
> >>
> >> Store URL and description separately and add UI for editing. 
> >>
> >> Kind of think if you're comfortable with getting UNLs (text) from
> >> other files, the ## way is probably sufficient. 
> >>
> >
> > I think the 'cheap' way should work fine.
> >  
> >
> >>
> >> So I could do that and remove any attempt to guess the most
> >> informative part of the URL (what it does now with basename @ full
> >> url) and leave descriptions up to the user. 
> >>
> >> I think though when it automatically creates the reverse link in
> >> the target file, it should use the node name in the source file as
> >> the descriptive text for the reverse link. 
> >>
> >> Sound reasonable? 
> >>
> >> Yes, that works for me.
> >
> > Rob.
> >
> 

-- 
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: Cross-file links

[Terry Brown]

On Tue, 20 Jun 2017 13:12:05 -0700 (PDT)
Largo84  wrote:

> I take it this isn't the way it works now? When I try this, it
> appends the ##Text to the URL making it an invalid link.

Not yet :-}

Cheers -Terry

> Rob..
> 
> On Tuesday, June 20, 2017 at 2:49:51 PM UTC-4, Largo84 wrote:
> >
> >> I think a descriptive text would be good.  There's a cheap way to
> >> do it, and a more complicated way. 
> >>
> >> Cheap 
> >>
> >> http://www.example.com/##For example 
> >>
> >> just decide that anything following a double hash in the URL is
> >> the descriptive string.  This could be pointed out by the popup
> >> into which URLs are entered.  It would display as 
> >>
> >> For example http://www.example.com/ 
> >>
> >> To change an URL or it's description, you'd have to delete and
> >> replace, when you click a link it appears in the Log pane, so you
> >> can copy from there if you're replacing something existing. 
> >>
> >> Complicated 
> >>
> >> Store URL and description separately and add UI for editing. 
> >>
> >> Kind of think if you're comfortable with getting UNLs (text) from
> >> other files, the ## way is probably sufficient. 
> >
> > I think the 'cheap' way should work fine.
> >
> >> So I could do that and remove any attempt to guess the most
> >> informative part of the URL (what it does now with basename @ full
> >> url) and leave descriptions up to the user. 
> >>
> >> I think though when it automatically creates the reverse link in
> >> the target file, it should use the node name in the source file as
> >> the descriptive text for the reverse link. 
> >>
> >> Sound reasonable? 
> >>
> >> Yes, that works for me.
> >
> > Rob.

-- 
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: Cheat Sheet: Executing minibuffer commands

[jkn]

Hi Edward

On Tuesday, June 20, 2017 at 2:58:15 PM UTC+1, Edward K. Ream wrote:
>
> On Tue, Jun 20, 2017 at 3:38 AM, jkn  > wrote:
>
> I haven't been particularly following the discussion about toggle-split 
>> direction, but I think I see things a little different to you.
>>
> ​
> Maybe ;-)​
>
> The Bash history facility (for example) use a file (~/.bash-history by 
>> default) which stores the last N commands entered. So I had in mind 
>> something similar, which could be loaded at the start of a session, 
>> maintained as commands are entered and executed, and saved before exit. I 
>> would keep the number of commands stored relatively small (N = 50 or 100, 
>> perhaps).
>>
>> The 'problem' then would be: how, at the start of a session say, would 
>> the commands in @data command-history be 'reconciled' with the contents of 
>> the .history file? One could imagine them being concatenated, but other 
>> schemes are possible, and I am not sure there is a definitively best answer.
>>
> ​
> Imo, settings are incompatible with automatic operation.  Settings promise 
> stability. Updating them automagically breaks that promise.
>
> Imo, the history settings are good enough. I have no plans to replace them.
>
> Edward
>

I'm not quite sure of your terminology here; I would call @data 
command-history a setting, and ~/.leo-history as persistence, along the 
lines of having the same session as last time.

I agree that there is a tension between these two approaches, and the 
command-history node is working well enough for me to live with, so I 
shan't press the point...

Regards
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: Cross-file links

[Largo84]

>
>
> I think a descriptive text would be good.  There's a cheap way to do 
> it, and a more complicated way. 
>
> Cheap 
>
> http://www.example.com/##For example 
>
> just decide that anything following a double hash in the URL is the 
> descriptive string.  This could be pointed out by the popup into which 
> URLs are entered.  It would display as 
>
> For example http://www.example.com/ 
>
> To change an URL or it's description, you'd have to delete and replace, 
> when you click a link it appears in the Log pane, so you can copy from 
> there if you're replacing something existing. 
>
> Complicated 
>
> Store URL and description separately and add UI for editing. 
>
> Kind of think if you're comfortable with getting UNLs (text) from other 
> files, the ## way is probably sufficient. 
>

I think the 'cheap' way should work fine.
 

>
> So I could do that and remove any attempt to guess the most informative 
> part of the URL (what it does now with basename @ full url) and leave 
> descriptions up to the user. 
>
> I think though when it automatically creates the reverse link in the 
> target file, it should use the node name in the source file as the 
> descriptive text for the reverse link. 
>
> Sound reasonable? 
>
> Yes, that works for me.

Rob.

-- 
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: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tuesday, June 20, 2017 at 10:43:13 AM UTC-5, Edward K. Ream wrote:

Oh great. Now we will have a true fork in Python. Imo, this will be a 
> serious self inflicted wound in the Python world. 
>

On second thought, little will change as far as Leo goes. I'll simply stick 
to whatever is compatible with Python 2.7.  This should allow people to use 
Leo on any Python 3.x system, provided that it doesn't break Qt...

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: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tuesday, June 20, 2017 at 10:27:05 AM UTC-5, Kent Tenney wrote:

I'm not up on the specifics, but folks seem excited about language
> improvements available in [python] 3.6, at some point in time it will make
> sense to use those features, resulting in code that won't work on 2.7.
>

Oh great. Now we will have a true fork in Python. Imo, this will be a 
serious self inflicted wound in the Python world. 
 

> The tipping point if not now, near. That's what I meant.
>

I would be happy to support Python 3 only. Almost all my development work 
starts on Python 3.

But what about Leo's users? How am I to demand that they all switch to 
Python 3? And if I can't do that, how am I going to support two *separate* 
code bases?  The answer is, I won't.

So Leo will perforce have to stick with features common to Python 2.7 up to 
Python 3.5.  This will work for awhile, but will become less and less 
attractive unless bug fixes are back-ported from Python 3.6 to Python 2.7 
and 3.5. I doubt that this will happen for long.

I have a bad feeling about this.

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: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tuesday, June 20, 2017 at 10:09:29 AM UTC-5, Edward K. Ream wrote:

In the interests of reaching the widest possible audience, here is a 
> shorter summary of my intentions, from #505:
>

And here is some thinking out loud about implementation.  This is a repeat 
of comments in #505. 

*Positions vs vnodes*

I would like to make minimal changes to the read code. The code is 
inherently complex, and starting over is not likely to clarify matters.

The priority rules given above depend on a clone's ancestor @file node. But 
this depend on the clone's position within the outline. The clone's 
vnode/gnx does not suffice. This creates at least two problems:

1. Positions will change when reading @file trees.
2. The present code is (for good reasons) based on vnodes (gnx's) rather 
than positions.

It may be necessary (and simplest) to defer the final assignment of 
headlines and body text until all positions have stabilized. That can be 
done easily: vnodes could contain *lists *of possible values for v.h and 
v.b, along with the vnode (probably) of the corresponding ancestor root 
@file node, if any. A post-pass will pick the highest priority item in the 
list, creating Recovered Nodes entries only when there are two entries with 
the same priority, higher than any other item in the list.

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: ENB: Severe problems switching between git branches

[Offray Vladimir Luna Cárdenas]

Ohh... nice to know anyway that such separate project exist :-).

Offray


On 20/06/17 10:16, Edward K. Ream wrote:
> On Tuesday, June 20, 2017 at 9:44:17 AM UTC-5, Offray Vladimir Luna
> Cárdenas wrote:
>
> > Is good to see that closer integration with DVCS is finally coming.
>
> That's a separate project
>  :-) In fact,
> #505 merely proposes to fix ancient bugs that bite more vigorously
> when switching between git branches.
>
> 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.

-- 
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: ENB: Severe problems switching between git branches

[Kent Tenney]

I'm not up on the specifics, but folks seem excited about language
improvements available in 3.6, at some point in time it will make
sense to use those features, resulting in code that won't work on 2.7.
The tipping point if not now, near. That's what I meant.



On Tue, Jun 20, 2017 at 10:07 AM, Edward K. Ream 
wrote:

> On Tuesday, June 20, 2017 at 9:20:42 AM UTC-5, Kent Tenney wrote:
>>
>> "the simplest thing that could possibly work"
>>
>
>
>> always makes me cringe, since it implies a grasp of All Possibilities,
>> I settle for a bit of complexity collapse.
>>
>
> Imo, the principle encourages us to avoid complexity, not to imagine all
> the complex possibilities! It suggests starting with the simplest thing
> that comes to mind, not the most complex.
>
>
>> Considering a re-write of core code sounds exciting, in addition to
>> desired
>> improvements, opportunity to make core more accessible to hacking by
>> non Edward/Terry folk.
>>
>
> I'm afraid that you hope in vain.  The read code is never going to be
> easy.
>
> In fact, I plan to change as little as possible of the read code.
>
> Write to 3.6? It seems we're at the point has been tipped towards it.
>>
>
> I don't understand this.
>
> 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.
>

-- 
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: Rev 42135f: toggle-at-auto-at-edit command

[Edward K. Ream]

On Tue, Jun 20, 2017 at 10:04 AM, Kent Tenney  wrote:

Cool, having fun switching from " command" to shortcuts.
>

​That's good.  I use fewer shortcuts than you might imagine. I find it
easier to remember minimal tab completions.  Examples:

sort-l  ==> sort-lines
delete-c ==> delete-comments
toggle-at ==> toggle-at-auto-edit.

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: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tuesday, June 20, 2017 at 6:28:00 AM UTC-5, Edward K. Ream wrote:

>> This is...Engineering Notebook post...will form the basis of an urgent 
enhancement item.

> Done at #505 : Leo's 
read code must be rewritten.

In the interests of reaching the widest possible audience, here is a 
shorter summary of my intentions, from #505:

**Clone precedence**

- 1 (top): clones in external files not containing @all
- 2 (medium): clones in external files containing @all.
- 3 (bottom): clones existing only in the .leo file.

**Design**

- Leo should warn about clone conflicts (and create recovered nodes) only 
when the conflict arises from two conflicting external files of the same 
priority. Otherwise, the **data in the higher-priority external file must 
rule**.
- The "last clone wins" rule must go. Position within the outline is 
unimportant.
- Headlines must *always* come from sentinels (for @file nodes).
- Leo should *never* report resurrected" nodes.

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: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tuesday, June 20, 2017 at 9:20:42 AM UTC-5, Kent Tenney wrote:
>
> "the simplest thing that could possibly work"
>
 

> always makes me cringe, since it implies a grasp of All Possibilities,
> I settle for a bit of complexity collapse.
>

Imo, the principle encourages us to avoid complexity, not to imagine all 
the complex possibilities! It suggests starting with the simplest thing 
that comes to mind, not the most complex.
 

> Considering a re-write of core code sounds exciting, in addition to desired
> improvements, opportunity to make core more accessible to hacking by
> non Edward/Terry folk.
>

I'm afraid that you hope in vain.  The read code is never going to be easy. 

In fact, I plan to change as little as possible of the read code.

Write to 3.6? It seems we're at the point has been tipped towards it.
>

I don't understand this.

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: Rev 42135f: toggle-at-auto-at-edit command

[Kent Tenney]

Cool, having fun switching from " command" to shortcuts.

Thanks,
Kent

On Mon, Jun 19, 2017 at 2:07 PM, Terry Brown  wrote:

> On Mon, 19 Jun 2017 13:31:47 -0500
> Kent Tenney  wrote:
>
> > > Well that's getting a key binding.
> >
> > Must admit ... how to add a key binding?
> >
> > Tried
> > @settings
> >   @keys
> >   toggle-at-auto-at-edit = F5
>
> @settings
>   @keys
> @shortcuts
>toggle-at-auto-at-edit = F5
>
> Cheers -Terry
>
> > but that didn't do it.
> >
> > Thanks,
> > Kent
> >
> > On Sun, Jun 18, 2017 at 10:33 AM, Terry Brown 
> > wrote:
> >
> > > On Sun, 18 Jun 2017 02:15:27 -0700 (PDT)
> > > "Edward K. Ream"  wrote:
> > >
> > > > This completes #482
> > > > , one of the
> > > > Ashland items.  This command is surprisingly useful.  It toggles
> > > > between a flattened view (@edit) and an outline view (@auto) of an
> > > > external file containing no sentinels.
> > >
> > > Well that's getting a key binding.  Extremely useful.  Thanks Kent
> > > for the idea and Edward for the implementation.  My two common use
> > > cases, where some directory import has imported files as @auto or
> > > @edit when I would (perhaps later) prefer the other, and for one
> > > pager programs imported as @auto where @edit makes more sense.
> > >
> > > Cheers -Terry
> > >
> > > > As Kent pointed out when we met in Ashland, the real value added
> > > > by this command is preserving the presently selected line when
> > > > flattening/un-flattening the outline. To make this useful in
> > > > practice, you can run this command from any descendant of an @auto
> > > > node. There aren't any descendants of @edit trees :-)
> > > >
> > > > The code is just a bit tricky.  Please report any problems.
> > > >
> > > > 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.
>
> --
> 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: ENB: Severe problems switching between git branches

[Offray Vladimir Luna Cárdenas]

On 20/06/17 02:40, Edward K. Ream wrote:
>
> *Summary*
>
> Leo's existing read logic is at least a decade old. There have been
> hints of trouble in the past, but the troubles with git branches are
> now intolerable.  Happily, git also provides recovery options that did
> not exist 10 years ago.
>
[...]
> All comments welcome.
>

Is good to see that closer integration with DVCS is finally coming. Some
experiments were propossed using Fossil instead of Git, which provides
less cognitive and technical overhead, but is less popular. At some
point abstracting reading logic DVCS support for Git would enable a more
neutral approach that could be used for others, but going with the
popular option as a first implementation is wise (is happening now with
Git and native DVCS in the Pharo Community).

Cheers,

Offray

-- 
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: ENB: Severe problems switching between git branches

[Kent Tenney]

"the simplest thing that could possibly work"
always makes me cringe, since it implies a grasp of All Possibilities,
I settle for a bit of complexity collapse.
:-]

Considering a re-write of core code sounds exciting, in addition to desired
improvements, opportunity to make core more accessible to hacking by
non Edward/Terry folk.

Write to 3.6? It seems we're at the point has been tipped towards it.

On Tue, Jun 20, 2017 at 8:54 AM, Edward K. Ream  wrote:

> On Tue, Jun 20, 2017 at 7:14 AM, Terry Brown 
> wrote:
>
>> I'm not sure refresh - from - disk is immune to these problems. Nothing
>> specific, sorry, but I feel like I've seen it so some of the headline /
>> recovered node type stuff. Not sure though. Surely it uses a lot of the
>> same read code?
>>
>
> ​Yes.  refresh-from-disk just deletes all the children of the root node
> and then calls the appropriate atFile helper.
> ​
>
>
>> Perhaps assessing the differences between @ types is important?
>>
>
> I tried to indicate my own uncertainties with parenthetical question. The
> initial post, and the comments in #505, are merely starting points.
>
> Certainly the differences between @ types is important, but I
> suspect that @file is the acid test.
>
> I have two new tools at my disposal since writing the code so long ago.
> One is the principle of "the simplest thing that could possibly work".  The
> other is cff.  I am confident that Leo's new read code will be much better
> than the old. It's worth any amount of effort.
>
> 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.
>

-- 
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: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tuesday, June 20, 2017 at 8:54:48 AM UTC-5, Edward K. Ream wrote:

I have two new tools at my disposal since writing the code so long ago.  
>

 And a third: the queued error dialogs created by c.raise_error_dialogs. 
This is surprisingly important. It means that important messages will not 
disrupt the load process.

And a fourth: the "Recovered Nodes" pattern. It will be re-purposed to 
report only serious clone conflicts in separate (non-catch-all) external 
files.  I expect this pattern will seldom be used, but testing it should be 
straightforward. 

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: Cheat Sheet: Executing minibuffer commands

[Edward K. Ream]

On Tue, Jun 20, 2017 at 3:38 AM, jkn  wrote:

I haven't been particularly following the discussion about toggle-split
> direction, but I think I see things a little different to you.
>
​
Maybe ;-)​

The Bash history facility (for example) use a file (~/.bash-history by
> default) which stores the last N commands entered. So I had in mind
> something similar, which could be loaded at the start of a session,
> maintained as commands are entered and executed, and saved before exit. I
> would keep the number of commands stored relatively small (N = 50 or 100,
> perhaps).
>
> The 'problem' then would be: how, at the start of a session say, would the
> commands in @data command-history be 'reconciled' with the contents of the
> .history file? One could imagine them being concatenated, but other schemes
> are possible, and I am not sure there is a definitively best answer.
>
​
Imo, settings are incompatible with automatic operation.  Settings promise
stability. Updating them automagically breaks that promise.

Imo, the history settings are good enough. I have no plans to replace them.

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: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tue, Jun 20, 2017 at 7:14 AM, Terry Brown  wrote:

> I'm not sure refresh - from - disk is immune to these problems. Nothing
> specific, sorry, but I feel like I've seen it so some of the headline /
> recovered node type stuff. Not sure though. Surely it uses a lot of the
> same read code?
>

​Yes.  refresh-from-disk just deletes all the children of the root node and
then calls the appropriate atFile helper.
​


> Perhaps assessing the differences between @ types is important?
>

I tried to indicate my own uncertainties with parenthetical question. The
initial post, and the comments in #505, are merely starting points.

Certainly the differences between @ types is important, but I suspect
that @file is the acid test.

I have two new tools at my disposal since writing the code so long ago.
One is the principle of "the simplest thing that could possibly work".  The
other is cff.  I am confident that Leo's new read code will be much better
than the old. It's worth any amount of effort.

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: Cross-file links

[Terry Brown]

On Mon, 19 Jun 2017 19:10:14 -0700 (PDT)
Largo84  wrote:

> Hmm, didn't think about what it would look like in small screen mode.
> I usually run maximized. Just wondering about possibilities, would it
> be useful (and doable) to ask for descriptive text in addition to the
> URL when creating the link? I envision for some node that might have
> multiple links that would be very helpful. Don't want to over
> complicate it, as it's a really cool new feature as it is.

I think a descriptive text would be good.  There's a cheap way to do
it, and a more complicated way.

Cheap

http://www.example.com/##For example

just decide that anything following a double hash in the URL is the
descriptive string.  This could be pointed out by the popup into which
URLs are entered.  It would display as

For example http://www.example.com/

To change an URL or it's description, you'd have to delete and replace,
when you click a link it appears in the Log pane, so you can copy from
there if you're replacing something existing.

Complicated

Store URL and description separately and add UI for editing.

Kind of think if you're comfortable with getting UNLs (text) from other
files, the ## way is probably sufficient.

So I could do that and remove any attempt to guess the most informative
part of the URL (what it does now with basename @ full url) and leave
descriptions up to the user.

I think though when it automatically creates the reverse link in the
target file, it should use the node name in the source file as the
descriptive text for the reverse link.

Sound reasonable?

Cheers -Terry

> Rob.
> 
> On Monday, June 19, 2017 at 5:26:45 PM UTC-4, Terry Brown wrote:
> >
> >
> > Sure, I usually run backlinks in a small window and thought it
> > would be easier to see: 
> >
> > Manfrotto.html @ https://www.bhp 
> > Nikon_D70.html @ https://www.bhp 
> > Canon_A600_SLR.html @ https://ww 
> >
> > as opposed to 
> >
> > https://www.bhphotovideo.com/c/p 
> > https://www.bhphotovideo.com/c/p 
> > https://www.bhphotovideo.com/c/p 
> >
> > In either case you can scroll or hover the mouse for a tool tip of
> > the whole URL. 
> >
> > Trying to think what the best option is - a @setting to control 
> > formatting of the text?  Maybe defaults to 
> >
> >   {basename} @ {fullurl} 
> >
> > but can be changed to 
> >
> >   {fullurl} 
> >
> > or 
> >
> >   {site}/{path} 
> >
> > or something like that? 
> >
> > 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: ENB: Severe problems switching between git branches

[Terry Brown]

I'm not sure refresh - from - disk is immune to these problems. Nothing 
specific, sorry, but I feel like I've seen it so some of the headline / 
recovered node type stuff. Not sure though. Surely it uses a lot of the same 
read code? Perhaps assessing the differences between @ types is 
important? 

Cheers - Terry

On June 20, 2017 2:40:49 AM CDT, "Edward K. Ream"  wrote:
>This is an Engineering Notebook post--notes to myself.  It will form
>the 
>basis of an urgent enhancement item.
>
>Terry, please read this carefully.  This is a big deal.
>
>There are several severe problems when switching between git branches, 
>arising from long-standing quirks in Leo's read logic.  This quirks are
>no 
>longer tolerable.
>
>The quirks gives rise to the "Recovered Nodes" tree. Imo, this whole 
>mechanism probably should be scrapped.
>
>This is ironic, for several reasons.  First, someone has just called
>this 
>mechanism a work of genius.  Second, I recently suggested that the
>*form* 
>of the recovered nodes might be the basis of a set of git diff
>commands. 
>(That's still true.) Third, just yesterday I swapped the args to 
>difflib.Differ.compare used to create the summary diff in each
>recovered 
>node.  At least in *some* cases, the diffs are backwards!
>
>*The problems*
>
>*Clones in the .leo file have too much influence.* Particularly when 
>switching git branches, we want the external file to override clones 
>appearing in the .leo file.  Yes, clones could be defined in two
>separate 
>external files.  Imo, Leo should warn about clone conflicts *only* when
>the 
>conflict arises from two conflicting external files.  In all other 
>"conflicts", *the data in the external file must rule*.
>
>*Headlines in the .leo file have too much influence.*  It's incredibly 
>annoying when headlines in the .leo file override the corresponding 
>sentinels in the external file. Not sure exactly how and why this
>happens, 
>but it does happen.
>
>*The "last clone wins" rule is dangerous nonsense.* This rule says that
>
>when there is a conflict between clones, the data in last clone in the
>.leo 
>file wins. This is wrong, wrong, wrong. Again, the data in the external
>
>file must rule. 
>
>Alas, there is some reason for this nonsense. "Summary" files, like 
>leoProjects.txt, contain a mishmash of clones in an @all tree.
>Typically (I 
>think) these clones are written in sync with changes to the "master" 
>external file, but I should verify this.  Anyway, these summary/@all
>files 
>should have lower priority in case of clone conflicts, *regardless* of 
>their place in .leo files!
>
>*Recovered Nodes trees are misleading.* Switching git branches often 
>results in wholesale changes to code, but Leo reports changes only in 
>*cloned* nodes. Imo, this makes no sense whatever. There is *nothing* 
>special about changes to cloned nodes!
>
>*A workaround: refresh-from-disk*
>
>Yesterday I realized that the refresh-from-disk command (probably)
>suffers 
>from none of the problems listed above.  In particular,
>refresh-from-disk 
>deletes all children of the @ node before reloading the file. 
>This 
>makes it impossible for Leo to generate so-called "resurrected" nodes, 
>another confusing feature of Leo's read logic. It also makes it
>impossible 
>(less likely?) for headlines in the outline to override corresponding 
>sentinels in the external file.
>
>*Summary*
>
>Leo's existing read logic is at least a decade old. There have been
>hints 
>of trouble in the past, but the troubles with git branches are now 
>intolerable.  Happily, git also provides recovery options that did not 
>exist 10 years ago.
>
>Recovered nodes trees are wildly misleading. They highlight only
>changes to 
>cloned nodes, ignoring all other changes. Imo, such trees should be
>created 
>only for conflicts involving two separate external files. Also, 
>"resurrected" nodes should never, ever, be reported.  The node
>structure of 
>external files should rule, without warnings. Period.
>
>refresh-from-disk is a *proof of concept *of a "proper" read logic, one
>
>that makes data in external files override clones that appear outside
>of 
>any @ node.  Alas, refresh-from-disk has no way of detecting
>clones 
>that may be defined in multiple external files. For this and other
>reasons, 
>I doubt that refresh-from-disk can be a drop-in replacement for Leo's
>read 
>logic. Major, dangerous, changes will be required. The work clearly
>must be 
>done in a separate branch.
>
>All 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.

-- 
Sent from my Android device 

Re: ENB: Severe problems switching between git branches

[Edward K. Ream]

On Tuesday, June 20, 2017 at 2:40:49 AM UTC-5, Edward K. Ream wrote:

> This is...Engineering Notebook post...will form the basis of an urgent 
enhancement item.

Done at #505 : Leo's 
read code must be rewritten.

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: Cheat Sheet: Executing minibuffer commands

[jkn]

Hi Edward

On Monday, June 19, 2017 at 9:59:49 PM UTC+1, Edward K. Ream wrote:
>
> On Wed, May 3, 2017 at 5:00 AM, jkn  
> wrote:
>
>>
>> Also, I thought I had read that Leo saves command history between 
>> sessions, but this doesn't seem to be the case.
>>
>
> ​I found this unanswered question while documenting what you did.
>
> The only way to "remember" command history between sessions is to update 
> the @data command-history node.
>
> The situation is similar to trying to "remember" the 
> toggle-split-direction command.  That's also not possible because there is 
> already a setting that specifies the initial split direction.
>
> Edward
>

I haven't been particularly following the discussion about toggle-split 
direction, but I think I see things a little different to you.

The Bash history facility (for example) use a file (~/.bash-history by 
default) which stores the last N commands entered. So I had in mind 
something similar, which could be loaded at the start of a session, 
maintained as commands are entered and executed, and saved before exit. I 
would keep the number of commands stored relatively small (N = 50 or 100, 
perhaps).

The 'problem' then would be: how, at the start of a session say, would the 
commands in @data command-history be 'reconciled' with the contents of the 
.history file? One could imagine them being concatenated, but other schemes 
are possible, and I am not sure there is a definitively best answer.

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.

ENB: Severe problems switching between git branches

[Edward K. Ream]

This is an Engineering Notebook post--notes to myself.  It will form the 
basis of an urgent enhancement item.

Terry, please read this carefully.  This is a big deal.

There are several severe problems when switching between git branches, 
arising from long-standing quirks in Leo's read logic.  This quirks are no 
longer tolerable.

The quirks gives rise to the "Recovered Nodes" tree. Imo, this whole 
mechanism probably should be scrapped.

This is ironic, for several reasons.  First, someone has just called this 
mechanism a work of genius.  Second, I recently suggested that the *form* 
of the recovered nodes might be the basis of a set of git diff commands. 
(That's still true.) Third, just yesterday I swapped the args to 
difflib.Differ.compare used to create the summary diff in each recovered 
node.  At least in *some* cases, the diffs are backwards!

*The problems*

*Clones in the .leo file have too much influence.* Particularly when 
switching git branches, we want the external file to override clones 
appearing in the .leo file.  Yes, clones could be defined in two separate 
external files.  Imo, Leo should warn about clone conflicts *only* when the 
conflict arises from two conflicting external files.  In all other 
"conflicts", *the data in the external file must rule*.

*Headlines in the .leo file have too much influence.*  It's incredibly 
annoying when headlines in the .leo file override the corresponding 
sentinels in the external file. Not sure exactly how and why this happens, 
but it does happen.

*The "last clone wins" rule is dangerous nonsense.* This rule says that 
when there is a conflict between clones, the data in last clone in the .leo 
file wins. This is wrong, wrong, wrong. Again, the data in the external 
file must rule. 

Alas, there is some reason for this nonsense. "Summary" files, like 
leoProjects.txt, contain a mishmash of clones in an @all tree. Typically (I 
think) these clones are written in sync with changes to the "master" 
external file, but I should verify this.  Anyway, these summary/@all files 
should have lower priority in case of clone conflicts, *regardless* of 
their place in .leo files!

*Recovered Nodes trees are misleading.* Switching git branches often 
results in wholesale changes to code, but Leo reports changes only in 
*cloned* nodes. Imo, this makes no sense whatever. There is *nothing* 
special about changes to cloned nodes!

*A workaround: refresh-from-disk*

Yesterday I realized that the refresh-from-disk command (probably) suffers 
from none of the problems listed above.  In particular, refresh-from-disk 
deletes all children of the @ node before reloading the file.  This 
makes it impossible for Leo to generate so-called "resurrected" nodes, 
another confusing feature of Leo's read logic. It also makes it impossible 
(less likely?) for headlines in the outline to override corresponding 
sentinels in the external file.

*Summary*

Leo's existing read logic is at least a decade old. There have been hints 
of trouble in the past, but the troubles with git branches are now 
intolerable.  Happily, git also provides recovery options that did not 
exist 10 years ago.

Recovered nodes trees are wildly misleading. They highlight only changes to 
cloned nodes, ignoring all other changes. Imo, such trees should be created 
only for conflicts involving two separate external files. Also, 
"resurrected" nodes should never, ever, be reported.  The node structure of 
external files should rule, without warnings. Period.

refresh-from-disk is a *proof of concept *of a "proper" read logic, one 
that makes data in external files override clones that appear outside of 
any @ node.  Alas, refresh-from-disk has no way of detecting clones 
that may be defined in multiple external files. For this and other reasons, 
I doubt that refresh-from-disk can be a drop-in replacement for Leo's read 
logic. Major, dangerous, changes will be required. The work clearly must be 
done in a separate branch.

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