Re: Leo and fossil

[john lunzer]

Nice, pretty much what I imagined it would look like. Now that I think about it 
statistical analysis of nodes can be done completely separately from node 
history. Just need to track each edit with a timestamp.

-- 
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: The trunk should be stable again

[lewis]

Usually my leo repository shows as 
/n/git/leo-editor (master) not
/n/git/leo-editor (master|MERGING)

OK I read up on *git checkout --theirs*
and tried it out. You can see from the git log I did a *git reset --hard* *and 
I am back to where I started.* 


git log:
lewis@Argon MINGW64 /n/git/leo-editor (master|MERGING)
$ git checkout --theirs leo/test/unitTest.leo leo/core/leoColorizer.py 
leo/core/
commit_timestamp.json

lewis@Argon MINGW64 /n/git/leo-editor (master|MERGING)
$ git pull
error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm '
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

lewis@Argon MINGW64 /n/git/leo-editor (master|MERGING)
$ git reset
Unstaged changes after reset:
M   leo/core/commit_timestamp.json
M   leo/core/leoAtFile.py
M   leo/core/leoColorizer.py
M   leo/core/leoCommands.py
M   leo/core/leoGlobals.py
M   leo/test/activeUnitTests.txt
M   leo/test/unitTest.leo

lewis@Argon MINGW64 /n/git/leo-editor (master)
$ git pull
error: Your local changes to the following files would be overwritten by 
merge:
leo/core/commit_timestamp.json
leo/core/leoAtFile.py
leo/core/leoColorizer.py
leo/core/leoCommands.py
leo/core/leoGlobals.py
leo/test/activeUnitTests.txt
leo/test/unitTest.leo
Please commit your changes or stash them before you merge.
Aborting

lewis@Argon MINGW64 /n/git/leo-editor (master)
$ git reset --hard
HEAD is now at 4b5b74408 Re-enabled continuations for multi-line 
constructructs.
 They are needed for docstrings!

lewis@Argon MINGW64 /n/git/leo-editor (master)
$ git pull
Auto-merging leo/test/unitTest.leo
CONFLICT (content): Merge conflict in leo/test/unitTest.leo
Auto-merging leo/core/leoColorizer.py
CONFLICT (content): Merge conflict in leo/core/leoColorizer.py
Auto-merging leo/core/commit_timestamp.json
CONFLICT (content): Merge conflict in leo/core/commit_timestamp.json
Automatic merge failed; fix conflicts and then commit the result.

lewis@Argon MINGW64 /n/git/leo-editor (master|MERGING)

Thanks
Lewis

-- 
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: The trunk should be stable again

['Terry Brown' via leo-editor]

Strange, not sure what's happening.  You could try:
git checkout --theirs leo/test/unitTest.leo leo/core/leoColorizer.py 
leo/core/commit_timestamp.json
then 
git pull
again, but that's a bit of a guess
Cheers -Terry
 
  From: lewis 
 To: leo-editor  
 Sent: Wednesday, January 25, 2017 4:24 PM
 Subject: Re: The trunk should be stable again
   
When I ran 'git pull' I got this message:

$ git pull
remote: Counting objects: 85, done.
remote: Compressing objects: 100% (54/54), done.
remote: Total 85 (delta 59), reused 57 (delta 31), pack-reused 0
Unpacking objects: 100% (85/85), done.
>From git://github.com/leo-editor/leo-editor
 + 4b5b74408...4efb5f58a master -> origin/master  (forced update)
 * [new branch]  color  -> origin/color

*** Please tell me who you are.

So I logged in and retried

$ git pull
Auto-merging leo/test/unitTest.leo
CONFLICT (content): Merge conflict in leo/test/unitTest.leo
Auto-merging leo/core/leoColorizer.py
CONFLICT (content): Merge conflict in leo/core/leoColorizer.py
Auto-merging leo/core/commit_timestamp.json
CONFLICT (content): Merge conflict in leo/core/commit_timestamp.json
Automatic merge failed; fix conflicts and then commit the result.

Any tips from here?

Thanks
Lewis

On Thursday, January 26, 2017 at 2:44:19 AM UTC+11, Edward K. Ream wrote:
The fixes were minor, and the new colorizer code now resides in a branch.

Still, even a few hours of badness isn't exactly the best advert for using the 
git repo.

Let me know if there are further problems.

-- 
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: The trunk should be stable again

[lewis]

When I ran 'git pull' I got this message:

$ git pull
remote: Counting objects: 85, done.
remote: Compressing objects: 100% (54/54), done.
remote: Total 85 (delta 59), reused 57 (delta 31), pack-reused 0
Unpacking objects: 100% (85/85), done.
>From git://github.com/leo-editor/leo-editor
 + 4b5b74408...4efb5f58a master -> origin/master  (forced update)
 * [new branch]  color  -> origin/color

*** Please tell me who you are.

So I logged in and retried

$ git pull
Auto-merging leo/test/unitTest.leo
CONFLICT (content): Merge conflict in leo/test/unitTest.leo
Auto-merging leo/core/leoColorizer.py
CONFLICT (content): Merge conflict in leo/core/leoColorizer.py
Auto-merging leo/core/commit_timestamp.json
CONFLICT (content): Merge conflict in leo/core/commit_timestamp.json
Automatic merge failed; fix conflicts and then commit the result.

Any tips from here?

Thanks
Lewis

*On Thursday, January 26, 2017 at 2:44:19 AM UTC+11, Edward K. Ream wrote:*
>
>
>
>
>
> *The fixes were minor, and the new colorizer code now resides in a 
> branch.Still, even a few hours of badness isn't exactly the best advert for 
> using the git repo.Let me know if there are further problems.*
>

-- 
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: Leo's real strengths

[Offray Vladimir Luna Cárdenas]

Hi,

Such strengths could evolve in a superb literate computing tool, even if 
it is "restricted" to Python (is something I'm exploring for 
Pharo/Smalltalk). Of course is easier said that done, but maybe starting 
with a focus on Python could help to bring some prominence to Leo, for 
non programmers, taking advantage of the huge Python's ecosystem in 
several scientific fields. Using Pyzo and Yoton as inspiration to bring 
powerful colorizing, auto-completion and interactive nodes could use 
Leo's strengths as an advantage to make it appealing to a broader audience.


Cheers,

Offray


On 23/01/17 06:02, Edward K. Ream wrote:
emacs org-mode has found a sweet spot, and Leo will not easily 
dislodge org-mode from its prominent place.  And now it /is/ possible 
to think thoughts in org-mode that previously could only be thought in 
Leo.


Still, Leo does have real strengths compared with all other editors 
and IDE's:


- Scripting in Python, not elisp.
- A DOM (Document object model) easily accessed via a Python api.
- The Qt toolkit.
- @file & @clean: org-mode has only @nosent.
- Outline-oriented configuration.
- Clones.
- @button scripts and @test unit tests.

etc.

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: Leo and fossil

[Offray Vladimir Luna Cárdenas]

Hi,

Core object provides outlining with node versioning:

http://coreobject.org/

Still on early stages, but I think that it helps into making a point 
about these possibilities (which doesn't mean that they should be 
implemented on Leo ;-) ).


Cheers,

Offray


On 23/01/17 13:39, john lunzer wrote:
Been mostly on the sidelines on this one, mostly because I didn't have 
time to think about it.


I think node versioning is a potentially "killer app". Having a fully 
automatic document versioning system at the .leo file level and node 
level would be a turbo boost in project organization and development 
tracking, a fine-grained full-fledged document history. At this level 
you could truly be able to see a piece of software unfold and develop 
in ways that aren't foreseeable with manual operation. I think it 
would also provide robustness to the concept of "undo". Being able to 
"undo" node level edits at any time and location is an awesome idea. 
There are potential statistical and visualization concepts that can 
aid development as well.


I'm going to have to agree with Terry. In this context Fossil is a 
backend. The concepts of document/node versioning need to be 
abstracted to fit Leo and then a backend can be plugged into what Leo 
is trying to accomplish.


On Saturday, January 21, 2017 at 6:11:29 PM UTC-5, Edward K. Ream wrote:

On Tue, Jan 17, 2017 at 9:32 AM, Offray Vladimir Luna Cárdenas
> wrote:

​​
Richard Hipp, Fossil and SQLite author, makes that distinction
and about the "pile of files" database (like the .git folder)
instead of the single file approach[2]. There is a lot of
querying capabilities of the last one, as you can see on [4]

[2] https://www.youtube.com/watch?v=8y_ABXwYtuc

[3] https://www.youtube.com/watch?v=ghtpJnrdgbo

[4]
http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md



If the emphasis is on node versioning, there's this:

https://groups.google.com/d/msg/leo-editor/LIUGtgP8T_s/oSQD4RQGeogJ



which points to a couple of older posts.


​I have copied these links and watch them soon.

As just mentioned in another thread, fossil stuff will likely
happen later this year.  That is, I personally have higher
priority work.

I would encourage everyone interested in fossil to continue their
work, even as I work on other things.  And later, if I seem to
forget fossil, please remind me ;-)

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.

another possible candidate for Leo core: toggle-expand-state

[jkn]

Hi Edward
I don't think this command exists already, and it is useful to me: 
instead of discrete 'expand node' and 'contract node' commands, this 
toggles the expand state of the current node.

def toggleExpandState():
""" expand or contract the current node
"""
# set up the functions to call
if p.isExpanded():
fa = p.contract
frd = c.redraw_after_contract
else:
fa = p.expand
frd = c.redraw_after_expand
# perform the calls
fa()
if p.isCloned():
# if trace: g.trace('***redraw')
c.redraw()
else:
frd(p,setFocus=True)



As an Ecco Pro sort-of refugee, I bind this to Ctrl-E, but others may of 
course choose different.

HTH
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: The trunk should be stable again

[Edward K. Ream]

On Wednesday, January 25, 2017 at 11:12:21 AM UTC-6, Edward K. Ream wrote:

I am now a bit more comfortable with branches.
>

This 
is
 
a great page about git branches. Follows "The less said the better" 
principle.

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.

Re: new cursor motion routines for useful Brief/Crisp-styl Body navigation

[jkn]

Hi Edward

On Wednesday, January 25, 2017 at 4:56:24 PM UTC, Edward K. Ream wrote:
>
> On Wed, Jan 25, 2017 at 7:56 AM, jkn 
> > wrote:
>
>>
>> Edward, I am thinking that it might be worth having the functionality of 
>> cursorToTopOfPane() and cursorToEndOfPane() in Leo's (Qt) core?
>>
>
> ​Yes.  I'll move them there soon.  Thanks for this code.
>

cool! ;-)
 

>
> BTW, It was easy to convert your flattened code (good for review) to 
> separate nodes using parse-body.
>
> I don't think the 'use lossage()' key functions should be in the core, 
>> unless you know better...
>>
>
> ​Is this a problem?  view-lossage is not bound to any key by default.​
>  
> ​Why not use it.  Your code does.​
>

I didn't mean view-lossage, or my showLossage(); I meant the  
doMy[Ctrl]HomeKey() and doMy[Ctrl]EndKey() functions. See more below...


> - there can be a small amount of 'micro-scrolling' as you move the cursor 
> to the top/bottom of the pane. I think my other editor resizes the pane so 
> as not to have partial text lines. The current behaviour seems liveable 
> with, although I might be interested in learning how to 'fix' this.
>
> ​In some cases Leo saves/restores scrollbars.  Not sure this is 
> applicable.​
>

I don't think this is relevant, it is to do with what Qt reports as the 
top/end of client coordinates, and how this is converted into what I am 
calling a text position. There is probably an approach along the lines of: 

get suggested new position
if (moving cursor to this position would cause a scroll):
tweak new position

but I am not rushing to look at this.

>
> - I don't currently deal with any existing selected region. If this 
> were to go into the core this would probably all be refactored, maybe using 
> some of the existing helper functions
> ​.
>
> You should definitely use the helpers, defined in the node:
> qtm.Generic high-level interface.
> ​
>

Yes, I started looking at these but wanted to get the basics operational 
first.
 

> - the doKey() function has to know about the key(s) that are calling 
> it, "Home" or "End" in the lossage() list. How might I improve this?
>
> ​I don't see any doKey function.​
>

Sorry, the perils of editing actual code before posting! I mean the 
(equivalent) functions which are called when one of [Ctrl]Home or [Ctrl]End 
are pressed, eg. doMyCtrlHomeKey().

These have to check lossage() for "previous instances of the same character 
that got me here", and currently nastily hard-coded those characters as 
"Ctrl+Home" or "Ctrl+End"

This is the stuff I don't think should go into core - the functions cannot 
be rebound to another key (without work, at least). Suggestinos for 
improvement welcome.

>
> - I had some trouble calling the pre-existing editor commands, like 
> c.editCommand.
> ​​
> beginningOfBuffer() etc. Not 100% sure I am doing this correctly.
>
> ​I would have to see your code.
>

I was looking at the scripting guide 
http://leoeditor.com/scripting-miscellany.html?highlight=docommand#id13

and trying things like:

c.doCommand(c.beginningOfLine,label="beginningofline")
c.beginningOfLine()

But I think you are meaning something different here by 'commands'?


> It's great that you are giving this a go.  Feel free to ask questions.
>

I'm glad it's of interest! I have another small tweak to suggest in another 
post.

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: The trunk should be stable again

[Edward K. Ream]

On Wednesday, January 25, 2017 at 9:44:19 AM UTC-6, Edward K. Ream wrote:
>
> The fixes were minor, and the new colorizer code now resides in a branch.
>

I am now a bit more comfortable with branches.  I'll certainly do all the 
next colorizer work in a branch.  I've learned a lot about Leo's colorizing 
over the last day or so.  First, I'll be folding improved tracing into the 
new branch.  Then I'll see what changes actually broke the coloring for 
python strings...

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.

Re: new cursor motion routines for useful Brief/Crisp-styl Body navigation

[Edward K. Ream]

On Wed, Jan 25, 2017 at 7:56 AM, jkn  wrote:

>
> Edward, I am thinking that it might be worth having the functionality of
> cursorToTopOfPane() and cursorToEndOfPane() in Leo's (Qt) core?
>

​Yes.  I'll move them there soon.  Thanks for this code.

BTW, It was easy to convert your flattened code (good for review) to
separate nodes using parse-body.

I don't think the 'use lossage()' key functions should be in the core,
> unless you know better...
>

​Is this a problem?  view-lossage is not bound to any key by default.​

​Why not use it.  Your code does.​

- there can be a small amount of 'micro-scrolling' as you move the cursor
to the top/bottom of the pane. I think my other editor resizes the pane so
as not to have partial text lines. The current behaviour seems liveable
with, although I might be interested in learning how to 'fix' this.

​In some cases Leo saves/restores scrollbars.  Not sure this is applicable.​

- I don't currently deal with any existing selected region. If this
were to go into the core this would probably all be refactored, maybe using
some of the existing helper functions
​.

You should definitely use the helpers, defined in the node:
qtm.Generic high-level interface.
​

- the doKey() function has to know about the key(s) that are calling
it, "Home" or "End" in the lossage() list. How might I improve this?

​I don't see any doKey function.​

- I had some trouble calling the pre-existing editor commands, like
c.editCommand.
​​
beginningOfBuffer() etc. Not 100% sure I am doing this correctly.

​I would have to see your code.

It's great that you are giving this a go.  Feel free to ask questions.

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.

The trunk should be stable again

[Edward K. Ream]

The fixes were minor, and the new colorizer code now resides in a branch.

Still, even a few hours of badness isn't exactly the best advert for using 
the git repo.

Let me know if there are further problems.  Let the wild rumpus start!

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: Warning: 3 Major problems in the trunk

[Edward K. Ream]

On Wed, Jan 25, 2017 at 9:19 AM, Edward K. Ream  wrote:

Rev 69fe246 fixes/ works around the three problems as follows:
>
​...​


> #3 @button problem: Disables g.extractExecutableString.  A complete,
> simple fix is next.
>

​Done at 4efb5f5. This is experimental code​, but it is likely good enough.
Please report any further problems immediately.

g.extractExecutableString now works as follows:

- Always returns the script unchanged if unit testing.
  Regrettable, but the affected unit tests can not easily change.

- Always starts scanning as if @language python were in effect.
  This is likely the best way of handling recent problems.

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.

Re: Warning: 3 Major problems in the trunk

[Edward K. Ream]

On Wednesday, January 25, 2017 at 7:04:47 AM UTC-6, Edward K. Ream wrote:
>
> The master branch now suffers *three* serious problems.
>

Rev 69fe246 fixes/ works around the three problems as follows:

#1 File problems: Completely fixed, with a new unit test to ensure it never 
happens again.  All of Leo's core files now round-trip as expected.

#2 Syntax coloring: reverts to previous (good enough) code.

#3 @button problem: Disables g.extractExecutableString.  A complete, simple 
fix is next.

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: Warning: 3 Major problems in the trunk

[Edward K. Ream]

On Wednesday, January 25, 2017 at 7:04:47 AM UTC-6, Edward K. Ream wrote:
>
> The master branch now suffers *three* serious problems.  I recommend you 
> immediately do git checkout 570f296e7 to restore things to a safer state of 
> affairs.  Fixing the master branch may take an hour or more.
>

Master is now on 570f296e7.  This will fix the syntax coloring, but not the 
file problems.  I'll do that next.

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.

new cursor motion routines for useful Brief/Crisp-styl Body navigation

[jkn]

Hi all
a long time ago (2013, gulp), I asked a question here about supporting 
a key-binding feature of my favourite editor, CRiSP/Brief. This is the use 
of multiple 'Home' or 'End' keypresses to move the cursor in different ways:

Home key pressed once, Cursor moves to beginning of line
Home key pressed twice, Cursor moves to beginning of 'screen' (ie. 
first visible character in pane)
Home key pressed three times, Cursor moves to beginning of buffer
and
End key pressed once, Cursor moves to end of line
End key pressed twice, Cursor moves to end of 'screen' (ie. first 
visible character in pane)
End key pressed three times, Cursor moves to end of buffer

Edward gave me some pointers including the 'lossage' feature - 
g.app.lossage(). I have finally got around to getting something like this 
to work - see below.

There are basically two new cursor motion functions, which move the cursor 
within the Body pane. I have called them cursorToTopOfPane() and 
cursorToEndOfPane().

There is then the function which uses lossage() to see whether the 
combination of up to three last keys pressed should be used for 'special' 
behaviour. Below I actually use Ctrl-Home and Ctrl-End keys to try things 
out, rather than the actual Home and End keys that I intend to use normally.

Edward, I am thinking that it might be worth having the functionality of 
cursorToTopOfPane() and cursorToEndOfPane() in Leo's (Qt) core?

I don't think the 'use lossage()' key functions should be in the core, 
unless you know better...

A few things:

- depending on the actual size of the Body pane, there can be a small 
amount of 'micro-scrolling' as you move the cursor to the top/bottom of the 
pane. I think my other editor resizes the pane so as not to have partial 
text lines. The current behaviour seems liveable with, although I might be 
interested in learning how to 'fix' this.
- I don't currently deal with any existing selected region. If this 
were to go into the core this would probably all be refactored, maybe using 
some of the existing helper functions 
- the doKey() function has to know about the key(s) that are calling 
it, "Home" or "End" in the lossage() list. How might I improve this?
- I had some trouble calling the pre-existing editor commands, like 
c.editCommand.beginningOfBuffer() etc. Not 100% sure I am doing this 
correctly.
- as per the comments I am currently assuming that lossage() has at 
least three entries. I'll fix this shortly.

Anyway, here's what I have. I am currently using two @command nodes
@command myCtrlHome @key=Ctrl+Home
@command myCtrlEnd @key=Ctrl+End
with content like below (merged a bit from two nodes for 'clarity')


from leo.core.leoQt import QtCore

def cursorToEndOfPane():
""" move the text cursor to the last character visible in the body pane
"""
w = c.frame.body.widget
# get viewport of the body widget
vp = w.viewport()

# get the coordinates of the bottom of the visible area
vWidth = vp.width() -1
vHeight = vp.height() -1
# g.es("width", vWidth, "height", vHeight)

# create a QPoint from this
bottom_right = QtCore.QPoint(vWidth, vHeight)

# get the (text)'position' within the widget of the bottom right QPoint
end_pos = w.cursorForPosition(bottom_right).position()

# create a cursor and set it to this position
cursor = w.textCursor()
cursor.setPosition(end_pos)
# set the Leo cursor from this
w.setTextCursor(cursor)

c.bodyWantsFocusNow()

def cursorToTopOfPane():
""" move the text cursor to the first character visible in the body pane
"""
w = c.frame.body.widget

# create a QPoint of the top of the widget (client area)
top_left = QtCore.QPoint(0, 0)

# get the (text)'position' within the widget of the top left QPoint
start_pos = w.cursorForPosition(top_left).position()

# create a cursor and set it to this position
cursor = w.textCursor()
cursor.setPosition(start_pos)
# set the Leo cursor from this
w.setTextCursor(cursor)

c.bodyWantsFocusNow()

# arrive here with 'Ctrl-Home' the first entry in lossage
# XXX for now, assume we have pressed more than three keys...
def doMyCtrlHomeKey():
if g.app.lossage[1][1] == "Ctrl+Home":
if g.app.lossage[2][1] == "Ctrl+Home":
g.es("would move to top of buffer")
c.editCommands.beginningOfBuffer(None)
else:
g.es("would move to top of body")
cursorToTopOfPane()
else:
g.es("would move to beginning of line")
c.editCommands.beginningOfLine(None)

doMyCtrlHomeKey()

# arrive here with 'Ctrl-End' the first entry in lossage
# XXX for now, assume we have pressed more than three keys...
def doCtrlEndKey():
showLossage()
if g.app.lossage[1][1] == "Ctrl+End":
if g.app.lossage[2][1] == "Ctrl+End":
g.es("would move to end of buffe

Warning: 3 Major problems in the trunk

[Edward K. Ream]

The master branch now suffers *three* serious problems.  I recommend you 
immediately do git checkout 570f296e7 to restore things to a safer state of 
affairs.  Fixing the master branch may take an hour or more.

If you have pulled the master recently, *please read the following 
carefully*, especially point 1 below. My sincere apologies for this mess.

1. The most serious problem is with Leo's write logic. Leo *will change 
external files unnecessarily* in some circumstances. An incredible blunder 
at ea3273a84 causes Leo to write *all* lines starting with '@' as if they 
were Leo directives. This isn't fatal: Leo reads such lines correctly. 
Small consolation: the changes are completely unnecessary.

2. Rev 4b5b744 broke syntax coloring for python strings.  Starting the 
strings colors until the next string delimiter, as usual, but *completing* 
the string doesn't undo the coloring for the following lines.  This is a 
great clue for me, but it is unbearable in practice.

3. The recent "improvement" to Leo's scripting code can break @button nodes 
that don't explicitly start with @language python. This only happens if the 
.leo file's default target language is rest or markdown/md.

I'll fix all these asap. Again, my sincere apologies.

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 4b5b744: better, not perfect, colorizing

[Edward K. Ream]

On Wednesday, January 25, 2017 at 5:51:09 AM UTC-6, Edward K. Ream wrote:

A very long day yesterday working on #380 
> . Rev 4b5b744 is, I 
> think, significantly better than previous versions
>

Alas not.  Please don't pull this rev.  You won't like it.

There are two other *serious *problems on master at present.  Full details 
in another thread.

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.

Re: console - can not find gnx:

[Edward K. Ream]

On Wed, Jan 25, 2017 at 5:57 AM, Edward K. Ream  wrote:

>
> when in  @button node is not explicitly set *@language python*, this last
>> call returns language '*rest*' for me.
>>
>
> ​Many thanks for this sleuthing.  Perhaps the new
> g.extractExecutableString function is the culprit.
>

​Almost certainly true.  ​AtButtonCallback.__call__ looks for a script
(using a gnx) only if the script is empty.  If the default is 'rest', the
the script *will* be empty.

I'll fix this immediately.

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: console - can not find gnx:

[Edward K. Ream]

On Tue, Jan 24, 2017 at 8:54 PM, lewis  wrote:

> Interestingly I created a new @button in myLeoSettings.leo file. Not a
> copied/edited button, but created from scratch.
> This new button executes correctly, with output to the console.
>
> The old button with identical text does not work. It should perform
> exactly the same function but it doesn't.
>

​This is a good clue.
​


> So the gnx is created and readable for a new button node, but not an
> existing one? Is it possible this may be related to Goto Script query
>  ?
>

​Not likely. It's probably related to some recent change.

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.

Re: console - can not find gnx:

[Edward K. Ream]

On Wed, Jan 25, 2017 at 2:18 AM, Milan Melena 
wrote:

> Hello,
>
> I have the same problem. When you investigate method call order, you will
> see:
>
> mod_scripting: ScriptingController.createCommonButtons ->
> ScriptingController.getScript -> g.getScript ->
> ​​
> g.extractExecutableString -> *language = g.scanForAtLanguage*
>
> when in  @button node is not explicitly set *@language python*, this last
> call returns language '*rest*' for me.
>

​Many thanks for this sleuthing.  Perhaps the new g.extractExecutableString
function is the culprit.

You can test this for yourself by having ​g.extractExecutableString simply
return s.​ Does this help?

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.

Rev 4b5b744: better, not perfect, colorizing

[Edward K. Ream]

A very long day yesterday working on #380 
. Rev 4b5b744 is, I 
think, significantly better than previous versions, so I have chosen to 
push it for your testing, despite problems discussed below.

I am eating my own dog food, and will push corrections for any serious 
problems immediately. It's likely that I'll find problems before you do, 
but do please report any problem not discussed here.

The colorizer now handles interspersed @language, @color, @nocolor, 
@nocolor-node, @killcolor directives well when initially colorizing a node. 
In the majority of cases, that's all that is needed.

Deleting @nocolor directives is still a problem, as is inserting and 
deleting @language directives. The symptom of these problems is that 
QSyntaxHighlighter doesn't call Leo's colorizer for enough lines. Probably 
a subtle bug in Leo's code, or a misunderstanding of how QSyntaxHighlighter 
works. I *might* be a bug in the Qt code, but that's unlikely.

This is an extremely hard problem, much harder than the problem pyzo has 
solved. I am considering adding a recolor command that would force a full 
recolor.  That might also be useful for debugging.

Edward

P.S.  A few technical notes.  Studying pyzo's code has not helped (because 
Leo must solve a harder problem), but studying pyzo's *behavior* has been 
useful.

Pyzo treats docstrings like Leo presently treats all forms of strings.  
Typing """ or ''' causes the "polarity" of all following code to switch.  
There is *no* reasonable alternative to this behavior.  Not colorizing 
unterminated docstrings at all would be off-putting, and once colorizing 
begins, there is no feasible way to know when to end the colorizing.

pyzo has no problem distinguishing docstrings from regular strings.  Leo's 
general pattern-based matchers do. I will likely add a hack to the 
match_span matcher and its restart method so that Leo can use pyzo's scheme 
of marking unterminated single-quoted strings with dotted underlines.

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.

Re: console - can not find gnx:

[Milan Melena]

Hello,

I have the same problem. When you investigate method call order, you will 
see:

mod_scripting: ScriptingController.createCommonButtons -> 
ScriptingController.getScript -> g.getScript -> g.extractExecutableString 
-> *language = g.scanForAtLanguage*

when in  @button node is not explicitly set *@language python*, this last 
call returns language '*rest*' for me.

Hope this help you.

Milan Melena


Dne středa 25. ledna 2017 3:54:04 UTC+1 lewis napsal(a):
>
> Interestingly I created a new @button in myLeoSettings.leo file. Not a 
> copied/edited button, but created from scratch.
> This new button executes correctly, with output to the console.
>
> The old button with identical text does not work. It should perform 
> exactly the same function but it doesn't.
> So the gnx is created and readable for a new button node, but not an 
> existing one? Is it possible this may be related to Goto Script query 
>  ?
>
> Lewis
>

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