Re: Documenting cff, cfm, cfa, cfam

2016-03-07 Thread john lunzer 
This is sound logic, I can't find fault with it. It may make sense for 
somebody who types these many times a day but some people will use clones 
far less. In this case the three letter abbreviations will obscure and 
hinder "discovery". I like the idea of command aliases for those that used 
certain commands frequently.

On Monday, March 7, 2016 at 5:31:54 PM UTC-5, Offray Vladimir Luna Cárdenas 
wrote:
>
> Hola
>
> I think that the "ola" or "one letter abbreviations" are bad style and 
> they difficult the reading of code and commands. I know that typing results 
> easier but that sacrifices reading by writing. In some languages that use 
> long descriptive words there is an active use of self-completion hints in 
> the environment, so a balance between reading and writing can be found. 
> From the usability/readability point of view, some kind of code/completion 
> suggestions in the node body and/or mini-buffer would be a good direction 
> in helping leo to cause the best first impression that is looked in 5.2 
> releases.
>
> Anyway the new energy in the community (with Edward as a driving force) is 
> really good and I imagine that some kind of personal configuration could be 
> enable to let short aliases to be used (but hopefully they'll not be the 
> default).
>
> Cheers,
>
> Offray
>
> On 06/03/16 20:06, SegundoBob wrote:
>
> For almost all commands, print-commands tells you something about the 
> command because the commands contain at least some full works.  For 
> example, search-forward and search-backward.  These new cf* commands are 
> inconsistent with this pattern.  Perhaps a description could be appended to 
> the cf* command lines:
>
> cff - Clone Find Flattened
> cfa - Clone Find All
>
> So I tried Alt-H, C (open CheatSheet.leo) and found nothing about the cf* 
> commands.
>
> So I tried F11, "cff"  and got "no docstring available"
>
> Alt-H, F (Help for Find Commands) --- I found nothing about the cf* 
> commands.
>
> Finally, I tried Alt-H, D (open LeoDocs.leo) and I found good 
> documentation for the cf* commands.
>
> Perhaps the current state of the documentation is optimal.  Making 
> print-commands, the CheatSheet.leo, etc. more complete and consistent could 
> easily make them too large to be useful.  But I think it is annoying that 
> F11 (Help for command) has no help for some commands.
> -- 
> 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+...@googlegroups.com .
> To post to this group, send email to leo-e...@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: Documenting cff, cfm, cfa, cfam

2016-03-07 Thread Offray Vladimir Luna Cárdenas 

Hola

I think that the "ola" or "one letter abbreviations" are bad style and 
they difficult the reading of code and commands. I know that typing 
results easier but that sacrifices reading by writing. In some languages 
that use long descriptive words there is an active use of 
self-completion hints in the environment, so a balance between reading 
and writing can be found. From the usability/readability point of view, 
some kind of code/completion suggestions in the node body and/or 
mini-buffer would be a good direction in helping leo to cause the best 
first impression that is looked in 5.2 releases.


Anyway the new energy in the community (with Edward as a driving force) 
is really good and I imagine that some kind of personal configuration 
could be enable to let short aliases to be used (but hopefully they'll 
not be the default).


Cheers,

Offray

On 06/03/16 20:06, SegundoBob wrote:
For almost all commands, print-commands tells you something about the 
command because the commands contain at least some full works.  For 
example, search-forward and search-backward.  These new cf* commands 
are inconsistent with this pattern.  Perhaps a description could be 
appended to the cf* command lines:


cff - Clone Find Flattened
cfa - Clone Find All

So I tried Alt-H, C (open CheatSheet.leo) and found nothing about the 
cf* commands.


So I tried F11, "cff"  and got "no docstring available"

Alt-H, F (Help for Find Commands) --- I found nothing about the cf* 
commands.


Finally, I tried Alt-H, D (open LeoDocs.leo) and I found good 
documentation for the cf* commands.


Perhaps the current state of the documentation is optimal.  Making 
print-commands, the CheatSheet.leo, etc. more complete and consistent 
could easily make them too large to be useful.  But I think it is 
annoying that F11 (Help for command) has no help for some commands.

--
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: New easy-install files on SourceForge

2016-03-07 Thread Offray Vladimir Luna Cárdenas 
Method 1, its a blessing :-). Nice to have this so long dreamed feature 
now. Keep the good work.


Cheers,

Offray

On 04/03/16 17:15, Edward K. Ream wrote:
On Fri, Mar 4, 2016 at 3:35 PM, Paul > wrote:


Tried recommended method 1 (folder based, not method 2, exe
file),per instructions at
https://sourceforge.net/projects/leo/files/Leo/Quick%20Install/
and working fine so far.


​Thanks for this report.​


However, default settings to unzip folder (using both WinRAR and
7-Zip) leave one still zipped file: base-library.zip

Might that be important?


​Not if everything works :-) I suspect that base-library.zip is part 
of the PyInstaller plumbing. There is a lot going on beneath the surface.


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: Bug: move lines up/down triggers body redraw/rehighlight

2016-03-07 Thread john lunzer 
Can confirm seeing what Terry saw as well. Body frame thought it was at end 
of document but wasn't. I was able to get it to reset by simple scrolling 
up and scrolling back down.

On Monday, March 7, 2016 at 6:53:25 AM UTC-5, john lunzer wrote:
>
> No, actually the move-line-up or move-line-down command. And I confirmed 
> that the body text needs to be longer than the screen (ie there needs to be 
> a scroll bar). 
>
> I've found several situations where the the rehighlight doesn't trigger, 
> but the body will scroll. The two may be unrelated.
>
> Mostly I see it scroll one line up if the scroll position is all the way 
> to the end of the body. I see this behavior if my text cursor is near the 
> bottom of the body and I use move-line-down, this is the desired behavior. 
> But this same behavior seems to be taking place as I said when the scroll 
> position is at the very bottom and I use a move-line-up OR move-line-down.
>
> On Sunday, March 6, 2016 at 9:31:11 PM UTC-5, Terry Brown wrote:
>>
>> On Sun, 6 Mar 2016 13:46:02 -0800 (PST) 
>> john lunzer  wrote: 
>>
>> > Yes, see OP, based on my memory this is brand new behavior. I can 
>> > check out a previous rev if necessary. 
>> > 
>> > It may require a body that is longer than the length of the screen. 
>>
>> Not sure if this is related, but I think I'm seeing a new bug where 
>> sometimes the end of the text in the body pane is not displayed, i.e. I 
>> know there's more but it won't scroll down any further, leaving the 
>> node and returning to it seems to fix it. 
>>
>> Don't currently have a path to reproduce, but only just started seeing 
>> it after a recent pull from github, after not having pulled for 2-3 
>> weeks. 
>>
>> John - I wasn't 100% clear on what you meant by moving lines up and 
>> down, you mean moving the cursor between lines? 
>>
>> Cheers -Terry 
>>
>> > On Sunday, March 6, 2016 at 4:23:39 PM UTC-5, Edward K. Ream wrote: 
>> > > 
>> > > On Sun, Mar 6, 2016 at 10:50 AM, john lunzer > > > > wrote: 
>> > > 
>> > >> Just as the subject says. At rev 3cf3c17. 
>> > > 
>> > > ​Is this something new? 
>> > > 
>> > > EKR 
>>
>

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

making "identical" clones truly identical

2016-03-07 Thread Phil 
I caught this in my code today:

I have a <> node that I clone all over the place so that 
I can update all affected files from a single clone. However, I apparently 
copied some code into my outline at some point that created a 2nd clone 
with the exact same headline and contents as the first clone, but the two 
are not clones of the same node! Is there a way to combine these so that 
they really are clones of the exact same node?

Thanks,
Phil

-- 
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: Bug: move lines up/down triggers body redraw/rehighlight

2016-03-07 Thread john lunzer 
No, actually the move-line-up or move-line-down command. And I confirmed 
that the body text needs to be longer than the screen (ie there needs to be 
a scroll bar). 

I've found several situations where the the rehighlight doesn't trigger, 
but the body will scroll. The two may be unrelated.

Mostly I see it scroll one line up if the scroll position is all the way to 
the end of the body. I see this behavior if my text cursor is near the 
bottom of the body and I use move-line-down, this is the desired behavior. 
But this same behavior seems to be taking place as I said when the scroll 
position is at the very bottom and I use a move-line-up OR move-line-down.

On Sunday, March 6, 2016 at 9:31:11 PM UTC-5, Terry Brown wrote:
>
> On Sun, 6 Mar 2016 13:46:02 -0800 (PST) 
> john lunzer > wrote: 
>
> > Yes, see OP, based on my memory this is brand new behavior. I can 
> > check out a previous rev if necessary. 
> > 
> > It may require a body that is longer than the length of the screen. 
>
> Not sure if this is related, but I think I'm seeing a new bug where 
> sometimes the end of the text in the body pane is not displayed, i.e. I 
> know there's more but it won't scroll down any further, leaving the 
> node and returning to it seems to fix it. 
>
> Don't currently have a path to reproduce, but only just started seeing 
> it after a recent pull from github, after not having pulled for 2-3 
> weeks. 
>
> John - I wasn't 100% clear on what you meant by moving lines up and 
> down, you mean moving the cursor between lines? 
>
> Cheers -Terry 
>
> > On Sunday, March 6, 2016 at 4:23:39 PM UTC-5, Edward K. Ream wrote: 
> > > 
> > > On Sun, Mar 6, 2016 at 10:50 AM, john lunzer  > > > wrote: 
> > > 
> > >> Just as the subject says. At rev 3cf3c17. 
> > > 
> > > ​Is this something new? 
> > > 
> > > EKR 
>

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