Re: The color branch has been merged into master

2017-01-31 Thread Edward K. Ream 
On Tuesday, January 31, 2017 at 5:30:12 AM UTC-6, Edward K. Ream wrote:

> #389: New colorizer has problems with multiple @language directives 


Fixed at 588dc01e. The new code is fundamentally more solid than the old. 
Please reopen this issue if there any new 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: Is there a way to avoid conflicts with commit_timestamp.json?

2017-01-31 Thread Kent Tenney 
[insert long pause for fresh clone of leo-editor]

A trick I use all the time is
git clone --depth=1 https://github.com/blah/blah.git

If I'm not interested in history, but just want current trunk (master)
onward ...

saves lots of time and space.

Thanks,
Kent

On Tue, Jan 31, 2017 at 12:29 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:

> The best way, although I think it requires action per clone of the repo.,
> is to add
>
> commit_timestamp.json merge=ours
>
> in the .gitattributes file in the to level folder of the repo. (where .git
> lives, but not in .git).
>
> This just makes git use "ours" whenever there's a conflict.  It doesn't
> really matter which one it chooses.
>
> [insert long pause for fresh clone of leo-editor]
>
> So it doesn't require per clone action, because .gitattributes is part of
> the repo.  So if it's not currently working (i.e.
> commit_timestamp.json merge=ours is in your .gitattributes file but you're
> still getting conflicts, maybe the path's wrong, i.e. it should be
> leo/core/commit_timestamp.json merge=ours
> perhaps.
>
> Cheers -Terry
>
> --
> *From:* Edward K. Ream 
> *To:* leo-editor 
> *Sent:* Tuesday, January 31, 2017 7:25 AM
> *Subject:* Is there a way to avoid conflicts with commit_timestamp.json?
>
> We've discussed this at length in other threads.  I seem to recall that
> Terry said that there was a clever fix for this.  Something better than
> `git checkout --ours leo/core/commit_timestamp.json`. But maybe I'm
> mis-remembering.
>
> Now that I'm using branches, I suspect the way to merge the master *into *a
> branch is to use --theirs, not --ours:
>
> git checkout my_branch
> git merge
> git checkout --theirs leo/core/commit_timestamp.json
> git commit -m "resolved conflicts in .json file"
> git checkout master
> git merge my_branch # nothing should happen, by definition.
>
> I've just merged both the color and and demo branches into master with
> this work flow. Only the merge from master into the demo branch caused a
> conflict in the .json file.
>
> Does all this make sense to everyone?
>
> 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: Is there a way to avoid conflicts with commit_timestamp.json?

2017-01-31 Thread Edward K. Ream 


On Tuesday, January 31, 2017 at 12:29:22 PM UTC-6, Terry Brown wrote:
>
> The best way, although I think it requires action per clone of the repo., 
> is to add
>
> commit_timestamp.json merge=ours  
>   
>
> in the .gitattributes file in the to level folder of the repo. (where .git 
> lives, but not in .git).
>

...
 

> maybe the path's wrong, i.e. it should be 
> leo/core/commit_timestamp.json merge=ours
> perhaps.
>

Thanks Terry. 8ac6c6a adds the leo/core prefix.  Let's see if that works.

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: The demo branch and plugin

2017-01-31 Thread Edward K. Ream 
On Tuesday, January 31, 2017 at 12:24:23 PM UTC-6, Edward K. Ream wrote:

> I plan no further work in leoKeys.py, so this branch will be merged into 
master fairly soon.

Done at cc48814.  Happy demoing.

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: Is there a way to avoid conflicts with commit_timestamp.json?

2017-01-31 Thread 'Terry Brown' via leo-editor 
The best way, although I think it requires action per clone of the repo., is to 
add
commit_timestamp.json merge=ours 
in the .gitattributes file in the to level folder of the repo. (where .git 
lives, but not in .git).
This just makes git use "ours" whenever there's a conflict.  It doesn't really 
matter which one it chooses.
[insert long pause for fresh clone of leo-editor]
So it doesn't require per clone action, because .gitattributes is part of the 
repo.  So if it's not currently working (i.e. commit_timestamp.json merge=ours 
is in your .gitattributes file but you're still getting conflicts, maybe the 
path's wrong, i.e. it should be leo/core/commit_timestamp.json merge=ours
perhaps.
Cheers -Terry

 
  From: Edward K. Ream 
 To: leo-editor  
 Sent: Tuesday, January 31, 2017 7:25 AM
 Subject: Is there a way to avoid conflicts with commit_timestamp.json?
   
We've discussed this at length in other threads.  I seem to recall that Terry 
said that there was a clever fix for this.  Something better than `git checkout 
--ours leo/core/commit_timestamp.json`. But maybe I'm mis-remembering.

Now that I'm using branches, I suspect the way to merge the master into a 
branch is to use --theirs, not --ours:

git checkout my_branch
git merge
git checkout --theirs leo/core/commit_timestamp.json
git commit -m "resolved conflicts in .json file"
git checkout master
git merge my_branch # nothing should happen, by definition.

I've just merged both the color and and demo branches into master with this 
work flow. Only the merge from master into the demo branch caused a conflict in 
the .json file. 

Does all this make sense to everyone?

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: The demo branch and plugin

2017-01-31 Thread Edward K. Ream 
On Tuesday, January 31, 2017 at 10:01:57 AM UTC-6, Edward K. Ream wrote:

> [demo.new_key_event should call the method that processes *input* keys, 
as opposed to settings. 

Exactly.  The proper input method is LeoQtEvent.create_key_event.

Rev 360fb0e (in the demo branch) completes all the essential work on the 
demo plugin.  It is ready for serious testing. I plan no further work in 
leoKeys.py, so this branch will be merged into master fairly soon.

Helpers could always be improved, especially the caption helper. But demos 
can always provide better.

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: The demo branch and plugin

2017-01-31 Thread Edward K. Ream 
On Tuesday, January 31, 2017 at 6:17:01 AM UTC-6, Edward K. Ream wrote:


>
> *Handling demo-next cleanly*At present, the demo-next command completely 
> alters Leo's key-handling state ivars. Adding state-handling back to the 
> demo plugin is out of the question.
>
> Instead, k.masterKeyHandler will special-case the shortcut for demo-next 
> *without* changing any of the myriad of state ivars in the KeyHandler 
> class. It will work much like the special case code for Ctrl-g 
> (keyboard-quit).
>
> This will allow two demo scripts to work together to execute a command 
> from the minibuffer.  The first demo script could do:
>
> demo.key('Alt-x')
> demo.keys('insert-node')
>
> The second demo script could actually invoke the command with:
>
> demo.key('\n')
>

This now all works exactly as described above.

When I started this project two days ago, I never dreamed that this plugin 
could tread so lightly on the rest of Leo. There has been a lot of futzing, 
but the new code is gorgeous.  For example, here is demo-next:

def next(self):
'''Execute the next demo script, or call end().'''
# Don't delete widgets here. Leave that up to the demo scripts!
# self.delete_widgets()
if self.script_list:
# Execute the next script.
script = self.script_list.pop()
self.exec_node(script)
if not self.script_list:
self.end()

It can't possibly get any simpler than this.

The rest of this post could be called an Engineering notebook entry. You 
can stop reading now ;-)

There are still some futzing to do with key handling.  The problem is 
simply stated.  We want to allow the user to call demo.key(s) with *any* 
specification s (a string) that would be valid in an @shortcuts node.  The 
following *shortcuts *should all be equivalent:

Alt-x, alt+x, alt+X

none of which is the same as alt-shift-x.

You would think this would be easy.  But n. The distinction between 
"canonicalized" *strokes *and free-form shortcuts is really, really hard to 
keep straight, even though the Stroke class is intended to make the 
distinction clear.

In particular, we obviously want to all demo.key('\n') or 
demo.keys('insert-node\n'), but '\n' is *not* a valid shortcut(!) So it 
looks like some new code will be required. It's already way too messy.

Happily, I think I know the way forward--call the method that processes 
*input* keys, as opposed to settings. The proper input method (wherever it 
is) should deliver proper stokes for all keys, including '\n', '\t' 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.

Re: Should ctrl-left/right arrows move selected text?

2017-01-31 Thread jkn 
Hi Edward

On Tuesday, January 31, 2017 at 1:33:16 PM UTC, Edward K. Ream wrote:
>
> I was about to file an enhancement item, but perhaps we should discuss 
> this first.
>
> I have grown fond of using ctrl-up/down arrows to move entire lines. Much 
> easier than copy/paste, and easier on my hands and wrists.
>
> I would like to use ctrl-left/right arrows in a similar manner, but the 
> standard bindings move the cursor by words.  I don't think we can change 
> that.  However, if there is a text selection, I think ctrl-left/right could 
> move the selected text left or right by one character.
>
> Your comments, please.
>
> Edward
>

Hmm - as you will have seen recently I have been trying to get back to a 
'microproject' of adding some editing primitives to Leo to allow it to 
(optionally) work a bit more like CRiSP (Brief editor bindings)

As it happens I have just now been working on the functionality of:

ALT+D = delete current line
ALT+K = delete to end of (current) line

and some other ways of working that I find make the Brief bindings very 
usable:

KeyPad-Minus = 'cut current selection to clipboard'; if nothing 
currently selected then default to 'cut current line to clipboard'
KeyPad-Plus = 'copy current selection to clipboard'; if nothing 
currently selected then default to 'copy current line to clipboard'
KeyPad-Insert = 'paste current clipboard'

(We have previously discussed, I think, that there are problems with 
binding to these 'KeyPad-XXX' keys; I was hoping to press you about those 
when I have the underlying functionality working!)

Together these make moving or copying single lines up and down quite easy;
Keypad-Minus # or KeyPad-plus for copy
move cursor
Keypad-Insert

I can see the benefit of using similar bindings to the tree 'move node' 
commands in the body as 'move line' commands. I guess I would just like to 
flag some of the above as alternate ways of working (and give you a heads 
up on some candidates for inclusion in core)...

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.

Should ctrl-left/right arrows move selected text?

2017-01-31 Thread Edward K. Ream 
I was about to file an enhancement item, but perhaps we should discuss this 
first.

I have grown fond of using ctrl-up/down arrows to move entire lines. Much 
easier than copy/paste, and easier on my hands and wrists.

I would like to use ctrl-left/right arrows in a similar manner, but the 
standard bindings move the cursor by words.  I don't think we can change 
that.  However, if there is a text selection, I think ctrl-left/right could 
move the selected text left or right by one character.

Your comments, please.

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.

Is there a way to avoid conflicts with commit_timestamp.json?

2017-01-31 Thread Edward K. Ream 
We've discussed this at length in other threads.  I seem to recall that 
Terry said that there was a clever fix for this.  Something better than 
`git checkout --ours leo/core/commit_timestamp.json`. But maybe I'm 
mis-remembering.

Now that I'm using branches, I suspect the way to merge the master *into *a 
branch is to use --theirs, not --ours:

git checkout my_branch
git merge
git checkout --theirs leo/core/commit_timestamp.json
git commit -m "resolved conflicts in .json file"
git checkout master
git merge my_branch # nothing should happen, by definition.

I've just merged both the color and and demo branches into master with this 
work flow. Only the merge from master into the demo branch caused a 
conflict in the .json file. 

Does all this make sense to everyone?

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: Two snakes on a plane?

2017-01-31 Thread Israel Hands 
Hi Mike and Edward - thanks for your help - the reason I haven't been 
quicker in my thanks is that I've struggled to get the solution to work. If 
I type python at the command prompt (win 10 64 bit) I get the Miniconda 
Python environment. My path in environment variables points to the 
miniconda installation. However if I run leo I end up in my C:\python34 
environment. 

Having got a bit sick of this and wanting to update python to 3.6 I 
uninstalled 3.4 and used conda to upgrade to 3.6. If I run python from a 
command line it runs 3.6 as you might expect. 

My batch file looks like this

C:\users\Israel\miniconda\python.exe C:\Users\Israel\leo-editor\launchLeo.py

And now Leo doesn't run at all. The log is brief

leoID=IH (in C:\emacs-24.3\.leo)
reading settings in C:\Users\Israel\leo-editor\leo\config\leoSettings.leo
reading settings in C:\emacs-24.3\.leo\myLeoSettings.leo

And now I'm not sure what to do!


I'm on firmer ground with  a Raspberry Pi 3 - it can be used as a tidy 
media streamer - there's a European company making a really nice analogue 
audio output plug in card - EKR - if you are  a media streaming kind of guy 
who wants to play high quality audio from the Pi, drop me  a line on inbox 
at mcghees.com with your address and I'll send one over.

IH


On Tuesday, 24 January 2017 17:46:21 UTC, Edward K. Ream wrote:
>
>
>
> On Tue, Jan 24, 2017 at 11:44 AM, Edward K. Ream  > wrote:
>
>> On Tue, Jan 24, 2017 at 11:40 AM, Mike Hodson > > wrote:
>>
>> ​> ​One of the easier things to do is to make a .cmd/.bat file that 
>> launches the proper Python interpreter against the launchLeo.py file. This 
>> should have the effect of running Leo always in the same interpreter 
>> regardless of what you have on your system otherwise.
>>
>> ​I agree.  That's what I do.
>>
>> Having said that, I only use Anaconda anymore.
>>
>
> ​I use both Anaconda 2 and 3.  I have batch/shell files called e, e2, s, 
> s2, u and u2.  For each pair, the first runs Python 3 (preferred) while the 
> second runs Python 2, for regression testing.
>
> 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: The demo branch and plugin

2017-01-31 Thread Edward K. Ream 
On Monday, January 30, 2017 at 8:57:27 AM UTC-6, Edward K. Ream wrote:

> I'll probably merge the demo branch into master later today.

That's not going to happen until all work is complete. Indeed, the most 
interest remaining work involves changes to leo/core/leoKeys.py.

The rest of this post is a progress report.

*tl;dr:* The plugin is a great success. At least a day's more work is 
needed. 

The guiding principle is that the plugin can and *should *do as little as 
possible.

The only *essential* function is to support the demo-next and demo-end 
commands. In addition, it's ok to provide a  *few *convenience methods for 
showing menus, putting up callouts, changing text magnification etc. These 
*could* be done in demo scripts, but the code isn't so obvious.

But everything else can, and should, be done in the demo scripts 
themselves. For example, instead of providing multiple methods for 
animating text in various places, the demo.keys method will animate the 
typing of keys *anywhere*, that is, in any widget.  Demo scripts can use 
c.editHeadline to type in the headline or c.bodyWantsFocusNow() to put 
focus in the body pane.

Instead of providing endless "faux-convenience" methods, the documentation 
will *teach by examples*, a new application of the "less said the better" 
principle.

*Undo*

Undo is the hidden driver of the design. I'll skip most of the details here.

The new philosophy is to have demo scripts handle undo themselves. 
Furthermore, undo eliminates the need for demo-back. Without an internal 
state handler, demo scripts *can* handle undo.



*Handling demo-next cleanly*At present, the demo-next command completely 
alters Leo's key-handling state ivars. Adding state-handling back to the 
demo plugin is out of the question.

Instead, k.masterKeyHandler will special-case the shortcut for demo-next 
*without* changing any of the myriad of state ivars in the KeyHandler 
class. It will work much like the special case code for Ctrl-g 
(keyboard-quit).

This will allow two demo scripts to work together to execute a command from 
the minibuffer.  The first demo script could do:

demo.key('Alt-x')
demo.keys('insert-node')

The second demo script could actually invoke the command with:

demo.key('\n')

The present workaround is to do it all in one node:

demo.key('Alt-x')
demo.keys('insert-node')
demo.wait(3)
demo.key('\n')

I estimate this work will take at least one more day. It may be put on hold 
while I fix urgent colorizing bugs.

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: The color branch has been merged into master

2017-01-31 Thread Edward K. Ream 
On Tuesday, January 31, 2017 at 5:30:12 AM UTC-6, Edward K. Ream wrote:

> There are now two serious problems reported against the new colorizer 
code:

I'll continue the colorizer work in the color branch, after merging recent 
changes from master to color.

At last I am beginning to understand why branches are our friends.

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: Python parsing issue

2017-01-31 Thread Edward K. Ream 
On Monday, January 30, 2017 at 10:21:37 AM UTC-6, Kent Tenney wrote:
>
> commit 1c28e916c37153df427e93c8cb97b635f58f5cbd
> declaration appended to class definition, this looks like a bug.
>

Thanks for this report. Please create an official bug report here 
.

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: The color branch has been merged into master

2017-01-31 Thread Edward K. Ream 
On Sunday, January 29, 2017 at 6:42:36 AM UTC-6, Edward K. Ream wrote:
>
> All appears to have gone smoothly. Please report any problems.
>

There are now two serious problems reported against the new colorizer code:

#389: New colorizer has problems with multiple @language directives 

and
#383: Additional body editors are not colorized 


Both these issues are release blockers. Leo 5.5b1 can't go out the door 
until they are fixed.

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.