Re: a portable Leo.exe, maybe

[Viktor Ransmayr]

Hello Matt,

Am Donnerstag, 7. Mai 2020 08:33:45 UTC+2 schrieb Matt Wilkie:
>
>
> I'm taking a run at creating a single executable package of Leo that can 
> be unpacked on any machine and just run, no installing!
>
> Only Windows 64bit so far. Initial results are promising, but much testing 
> still needed. First working draft with commit 1579844 
> 
>  
> and resulting exe in a google drive folder: 
> https://drive.google.com/drive/folders/1eOekkp53j1dPb3ewDhW5TAuNgrAeKzWm
>
>1. Download leo-devel-2020-05-06-11-19.zip (140mb)
>2. unpack it somewhere, say C:\apps\Leo
>3. run c:\apps\leo\leo.exe
>
> Report any successes and failures (open new issues on github).
>

Installation worked w/o any issues for me.

Here's the log after Leo's startup:

###

Leo Log Window
Leo 6.3-devel
Python 3.6.10, PyQt version 5.14.2
Windows 10 AMD64 (build 10.0.18362) SP0
current dir: C:/Users/viktor/programs/leo/leo-devel-2020-05-06-11-19/leo
load dir: 
C:/Users/viktor/programs/leo/leo-devel-2020-05-06-11-19/leo/leo/core
global config dir: 
C:/Users/viktor/programs/leo/leo-devel-2020-05-06-11-19/leo/leo/config
home dir: C:/Users/viktor
reading settings in 
C:/Users/viktor/programs/leo/leo-devel-2020-05-06-11-19/leo/leo/config/leoSettings.leo
reading settings in C:/Users/viktor/.leo/myLeoSettings.leo
reading settings in C:/Users/viktor/.leo/myLeoSettings.leo
read outline in 0.05 seconds

###

With kind regards,

Viktor

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/528aea2f-5651-4a2f-883f-0ee69dc36955%40googlegroups.com.

Re: Qt-prototype report and some thoughts about executeScript command

[Brian Theado]

Vitalije,

On Thu, May 7, 2020 at 2:42 PM vitalije  wrote:

> First of all I must say that testing with hypothesis is really great way
> to discover hidden bugs. Several bugs were found in the previous
> implementation that are very hard to imagine as a possible scenario. Of
> course most of these bugs were related to clones. Hypothesis did find them
> really quickly and I had to think hard how to solve them. After several
> iterations of running hypothesis and solving found bugs, prototype is now
> able to survive 5000 test sessions. At first I have started each test with
> the complete LeoPyRef.leo outline, test would choose and select a random
> position in this outline, and then it would perform a random sequence of
> commands, checking after each command that both models (v-nodes and tree
> widget items) are in sync. It used to take several minutes for a series of
> 500 tests.
> To speed up tests, I have changed test to use a smaller outline as
> starting position. At start it inserts just five ordinary nodes
> interspersed with five cloned nodes (total of 15 node). Now hypothesis runs
> 5000 tests in about minute. After several executions no bug has been found.
>

That's awesome. A while back when I read about hypothesis property based
testing, I was wondering how to apply it to leo outlines. I knew it would
have to be done either by creating a strategy which could generate
recursive structures or a strategy which could perform sequences of
commands. I didn't see how to proceed. Looks like you nailed it with the
second approach. Nice work!

I looked at the code but I don't understand how to run the hypothesis
tests. I would love to see it in action. Could you share the steps?


> It is highly unlikely that a new bug will be discovered using this test.
> That means we can be pretty sure that no matter what operations and in
> whichever order user executes both models: v-nodes and tree widget items
> will always remain in sync. The outline represented by each of them is
> exactly the same.
>

Have you also considered using the property of random operation + undo =
original tree widget state? And random operation + undo + redo = 2nd state?
I'm not sure that would reveal anything from what you are already testing.
Just a thought.

Brian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAO5X8CxszLQDNx%3DxWfUK37DiNXjHQH9r7jnKK-vSiMA2wskYqA%40mail.gmail.com.

Re: a portable Leo.exe, maybe

[Offray Vladimir Luna Cárdenas]

Thanks Matt. Those are good news. Recently I had problems installing Leo
on my machine (Manjaro Gnu/Linux), which lead me to test finally Org
Mode on Spacemacs (I may share the experience later). Anyway having more
multiplatform self-contained programs ala Nim, Go, in Python is really
appealing. Hard disk space is cheaper that human time those days.

Cheers,

Offray

On 7/05/20 1:33 a. m., Matt Wilkie wrote:
> Hi Folks,
>
> I'm taking a run at creating a single executable package of Leo that
> can be unpacked on any machine and just run, no installing!
>
> Only Windows 64bit so far. Initial results are promising, but much
> testing still needed. First working draft with commit 1579844
> 
> and resulting exe in a google drive folder:
> https://drive.google.com/drive/folders/1eOekkp53j1dPb3ewDhW5TAuNgrAeKzWm
>
>  1. Download leo-devel-2020-05-06-11-19.zip (140mb)
>  2. unpack it somewhere, say C:\apps\Leo
>  3. run c:\apps\leo\leo.exe
>
> Report any successes and failures (open new issues on github).
>
> cheers,
>
> -matt
> -- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/635d37d5-1771-4fdc-84ba-70d2888340f7%40googlegroups.com
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5affa9d7-66ea-c96d-9ded-bd4683ba2a91%40riseup.net.

Re: Qt-prototype report and some thoughts about executeScript command

[vitalije]

On Thursday, May 7, 2020 at 8:55:31 PM UTC+2, Thomas Passin wrote:
>
> Do you think it would be feasible to simply copy the root of the tree to 
> be operated on?   Then the undo would entail pointing the tree's original 
> parent to the copy and then redrawing.  I don't know about copy performance 
> (I suppose that a deep copy would be needed) on Leo nodes, but as a naive 
> idea it seems simple.
>
>
QTreeWidgetItem class has a clone method which runs quite fast. Cloning 
entire tree using this method is not problem at all. The problem is that if 
a script changes vnodes we need to synchronize them after script has 
finished. This synchronization can drop some items that are required for 
undoing earlier operations. To avoid this Leo should add to the undo list a 
new step which contains the copy of the tree items before executing script. 
All these operations are pretty cheap. The time will be spent in the 
redrawing tree from scratch after the script execution.

As I write this I've just realize that it would be possible to use diffing 
algorithm to update tree after the script. The only thing that is necessary 
is to make execute script undoable. Updating the tree using the diff 
algorithm will have exactly the same tree items as they were before the 
script. Nothing would be lost. All changes that must be made can be easily 
recorded in the undo bead for later undo/redo. This has a chance to make 
things a lot faster.

Vitalije

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/55ae6e96-1e5a-4863-8d1f-48aea3c63dc3%40googlegroups.com.

Re: Qt-prototype report and some thoughts about executeScript command

[Thomas Passin]

Do you think it would be feasible to simply copy the root of the tree to be 
operated on?   Then the undo would entail pointing the tree's original 
parent to the copy and then redrawing.  I don't know about copy performance 
(I suppose that a deep copy would be needed) on Leo nodes, but as a naive 
idea it seems simple.

On Thursday, May 7, 2020 at 2:42:24 PM UTC-4, vitalije wrote:
>
> In last few days I've been working on tests to be sure that all commands 
> in new prototype are working correctly and that no crash will ever occur. I 
> am pretty sure now that the implementation is correct and there are no 
> remaining bugs in the prototype.
>
> First of all I must say that testing with hypothesis is really great way 
> to discover hidden bugs. Several bugs were found in the previous 
> implementation that are very hard to imagine as a possible scenario. Of 
> course most of these bugs were related to clones. Hypothesis did find them 
> really quickly and I had to think hard how to solve them. After several 
> iterations of running hypothesis and solving found bugs, prototype is now 
> able to survive 5000 test sessions. At first I have started each test with 
> the complete LeoPyRef.leo outline, test would choose and select a random 
> position in this outline, and then it would perform a random sequence of 
> commands, checking after each command that both models (v-nodes and tree 
> widget items) are in sync. It used to take several minutes for a series of 
> 500 tests.
> To speed up tests, I have changed test to use a smaller outline as 
> starting position. At start it inserts just five ordinary nodes 
> interspersed with five cloned nodes (total of 15 node). Now hypothesis runs 
> 5000 tests in about minute. After several executions no bug has been found.
>
> It is highly unlikely that a new bug will be discovered using this test. 
> That means we can be pretty sure that no matter what operations and in 
> whichever order user executes both models: v-nodes and tree widget items 
> will always remain in sync. The outline represented by each of them is 
> exactly the same.
>
> *Now the question of executing scripts*
>
> How should we re-synchronize tree widget with the possible changes in the 
> outline made by user script? The more I think about this problem, the more 
> I am sure that my initial plan of using diff algorithm won't work. It would 
> mess up with the undo system. Undo operations rely on the stability of tree 
> widget items. If any of items is destroyed and replaced with the new one, 
> undo blocks containing this item will be broken. But not all hope is lost. 
> It is possible to execute full redraw after executing any script. The 
> prototype contains now the `performance` command. This command measures the 
> time required for full redraw and storing all the information necessary to 
> undo the execute script command. On my computer this takes about 80ms for 
> LeoPyRef.db. On little older computers it may take even 200-300ms. That 
> means that every execute script command will take that much time longer to 
> execute. This is the worst case scenario. Usually outlines are smaller than 
> LeoPyRef.leo and this time delay will be much smaller in most cases. In 
> return we gain something that we didn't have before: the executeScript 
> command now becomes undoable as any other command.
>
> I can't speak for everyone else but I would gladly accept this delay on 
> each executeScript command and in return have an insurance that no error in 
> my script will destroy my outline irrecoverably. I would like to be sure 
> that in case of an error in script I still can undo the whole operation and 
> return to the previous state. I know for certain that on more than one 
> occasion I've missed this undo ability very much.
>
> Your comments please.
>
> Vitalije
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/97a43fe8-1bfe-436d-b8fa-542bab60a0a7%40googlegroups.com.

Qt-prototype report and some thoughts about executeScript command

[vitalije]

In last few days I've been working on tests to be sure that all commands in 
new prototype are working correctly and that no crash will ever occur. I am 
pretty sure now that the implementation is correct and there are no 
remaining bugs in the prototype.

First of all I must say that testing with hypothesis is really great way to 
discover hidden bugs. Several bugs were found in the previous 
implementation that are very hard to imagine as a possible scenario. Of 
course most of these bugs were related to clones. Hypothesis did find them 
really quickly and I had to think hard how to solve them. After several 
iterations of running hypothesis and solving found bugs, prototype is now 
able to survive 5000 test sessions. At first I have started each test with 
the complete LeoPyRef.leo outline, test would choose and select a random 
position in this outline, and then it would perform a random sequence of 
commands, checking after each command that both models (v-nodes and tree 
widget items) are in sync. It used to take several minutes for a series of 
500 tests.
To speed up tests, I have changed test to use a smaller outline as starting 
position. At start it inserts just five ordinary nodes interspersed with 
five cloned nodes (total of 15 node). Now hypothesis runs 5000 tests in 
about minute. After several executions no bug has been found.

It is highly unlikely that a new bug will be discovered using this test. 
That means we can be pretty sure that no matter what operations and in 
whichever order user executes both models: v-nodes and tree widget items 
will always remain in sync. The outline represented by each of them is 
exactly the same.

*Now the question of executing scripts*

How should we re-synchronize tree widget with the possible changes in the 
outline made by user script? The more I think about this problem, the more 
I am sure that my initial plan of using diff algorithm won't work. It would 
mess up with the undo system. Undo operations rely on the stability of tree 
widget items. If any of items is destroyed and replaced with the new one, 
undo blocks containing this item will be broken. But not all hope is lost. 
It is possible to execute full redraw after executing any script. The 
prototype contains now the `performance` command. This command measures the 
time required for full redraw and storing all the information necessary to 
undo the execute script command. On my computer this takes about 80ms for 
LeoPyRef.db. On little older computers it may take even 200-300ms. That 
means that every execute script command will take that much time longer to 
execute. This is the worst case scenario. Usually outlines are smaller than 
LeoPyRef.leo and this time delay will be much smaller in most cases. In 
return we gain something that we didn't have before: the executeScript 
command now becomes undoable as any other command.

I can't speak for everyone else but I would gladly accept this delay on 
each executeScript command and in return have an insurance that no error in 
my script will destroy my outline irrecoverably. I would like to be sure 
that in case of an error in script I still can undo the whole operation and 
return to the previous state. I know for certain that on more than one 
occasion I've missed this undo ability very much.

Your comments please.

Vitalije

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/382b638d-f286-46ad-8ae0-d7cdadb0481c%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

Edward writes: 

The great advantage Qt has (or had) over Tk was in the appearance of text. 
> Has Tk improved in that regard?
>

My guess is that tkinter as shipped with Python 3.6.8 and 3.7.7 and 3.8.2 
would need careful testing. The macOS interface via Tcl/Tk is undergoing 
work - at present, the ball is in the court of the developers of Tcl/Tk. 

See IDLE and tkinter with Tcl/Tk on macOS, which documents that python.org 
Python installers for versions 3.8.0+, 3.7.2+, 3.6.8 all ship with built-in 
Tcl/Tk 8.6.8. 

See Python bug tracker issue 35402 , 
which documents reverting the use of Tcl/Tk 8.6.9.1, and Python bug tracker 
issue 35485 , which documents specific 
problems and gives a reference to the Tcl/Tk ticket 
 that documents the 
problem.  The current release of Tcl/Tk is 8.6.10; that dates from November 
of 2019, and it hasn't been tried with Python as yet, but I see on the 
timeline for Tcl/Tk  that work 
on the macOS interface is under way as I type this in May of 2020, so the 
bundled Tcl/Tk 8.6.8 won't be upgraded immediately. The developers are 
working around macOS bugs, and Apple is changing the operating system 
significantly, so their work is not easy. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4dc190f4-6790-4085-8432-88ac87ee59a6%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[Thomas Passin]

On Thursday, May 7, 2020 at 11:49:31 AM UTC-4, tfer wrote:
>
> Thanks Matt and Thomas, I'll look into that.  It's not that I want to 
> avoid Zoom so much, I want to demonstrate some work flow stuff, (Windows 
> 10, some Powershell stuff, and It's virtual workspace), so that's why I 
> need to show what's on my screen.
> If anyone is interested, and it's okay with Edward more people could jump 
> on the call .
>

 I have a periodic Zoom meeting for my particular software project.  One of 
the people acts as the recorder/secretary.  He gets the screen control and 
pulls up the (Word) document that records progress and issues, scrolls 
through it, and we see him update it while we discuss the issues.  The only 
thing is that it's a bit slow compared with being at your own screen.  At 
the end of the meeting, his work is done and he emails us the revised doc.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4d4c5537-2557-4792-8284-5fab135911ac%40googlegroups.com.

Re: a portable Leo.exe, maybe

[Thomas Passin]

Yes, and I think you have to run it on a Mac to get a Mac version.  For 
linux, I don't know how version-specific you need to be.

On Thursday, May 7, 2020 at 11:26:46 AM UTC-4, Matt Wilkie wrote:
>
> This would have to be Windows only, wouldn't it?  All the packagers I 
>> looked at recently could make a self-contained package for just one kind  
>> of OS.  Of course, that's not a surprise!
>>
>
> It's being built with Pyinstaller, which has doc sections for Mac and 
> Linux. I haven't tried to go through those parts yet.
>
> -matt
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/83d0fb91-d157-4fb2-b3aa-7e99283a2f0a%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

[David Szent-Györgyi]

Edward writes: 

>
> Thanks for this update. Vitalije recently created a prototype in Tk, so 
> there is actually some code available.
>
> The great advantage Qt has (or had) over Tk was in the appearance of text. 
> Has Tk improved in that regard?
>

Answer for Windows: work has been done. See the Python bug tracker issue 
26698 , which states that a fix for 
IDLE on Windows made it into Python 3.6.6rc1 and Python 3.7.0rc1. That work 
was superseded by work documented by Python bug tracker issue 33656 
. 

Issue 33656 mentions the addition of a call to a Windows API to say that tk 
scales for DPI - the change is in Iines 15-20 of the source code 

. 

That change is documented in as new in Python 3.6.6 
 and new in Python 3.7 
. In each case, the text 
reads, 

On Windows, a new API call tells Windows that tk scales for DPI. On Windows 
> 8.1+ or 10, with DPI compatibility properties of the Python binary 
> unchanged, and a monitor resolution greater than 96 DPI, this should make 
> text and lines sharper. It should otherwise have no effect. (Contributed by 
> Terry Jan Reedy in bpo-33656 .) 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/dc51bb77-c4f1-47c3-b607-2a2bc5735b62%40googlegroups.com.

Re: ENB: rethinking Model/View/Controller split in Leo

['tfer' via leo-editor]

Thanks Matt and Thomas, I'll look into that.  It's not that I want to avoid 
Zoom so much, I want to demonstrate some work flow stuff, (Windows 10, some 
Powershell stuff, and It's virtual workspace), so that's why I need to show 
what's on my screen.
If anyone is interested, and it's okay with Edward more people could jump on 
the call .
 
>>> A 'live' reference to an object that will change in real-time...
  -- I like that a lot, I'll probably add it in my rework of the documentation, 
thanks Felix

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d9867f12-ef72-4487-8b9b-e4f507f220ab%40googlegroups.com.

Re: a portable Leo.exe, maybe

[Matt Wilkie]

>
> This would have to be Windows only, wouldn't it?  All the packagers I 
> looked at recently could make a self-contained package for just one kind  
> of OS.  Of course, that's not a surprise!
>

It's being built with Pyinstaller, which has doc sections for Mac and 
Linux. I haven't tried to go through those parts yet.

-matt

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0305b685-82d2-4a0d-9f31-cf38223eafa7%40googlegroups.com.

Re: a portable Leo.exe, maybe

[Thomas Passin]

This would have to be Windows only, wouldn't it?  All the packagers I 
looked at recently could make a self-contained package for just one kind  
of OS.  Of course, that's not a surprise!

On Thursday, May 7, 2020 at 2:33:45 AM UTC-4, Matt Wilkie wrote:
>
> Hi Folks,
>
> I'm taking a run at creating a single executable package of Leo that can 
> be unpacked on any machine and just run, no installing!
>
> Only Windows 64bit so far. Initial results are promising, but much testing 
> still needed. First working draft with commit 1579844 
> 
>  
> and resulting exe in a google drive folder: 
> https://drive.google.com/drive/folders/1eOekkp53j1dPb3ewDhW5TAuNgrAeKzWm
>
>1. Download leo-devel-2020-05-06-11-19.zip (140mb)
>2. unpack it somewhere, say C:\apps\Leo
>3. run c:\apps\leo\leo.exe
>
> Report any successes and failures (open new issues on github).
>
> cheers,
>
> -matt
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ec4878eb-9477-4cb8-8a32-3c52254d6ba0%40googlegroups.com.

Re: a portable Leo.exe, maybe

[lewis]

Hi Matt,

This worked fine for me with no errors or hiccups at all on a Windows 10 
machine.
In log pane it reported python 3.6.10

A fine success :)

Regards
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/679a6141-66e7-4775-bd0f-7b66374d7a86%40googlegroups.com.

Re: a portable Leo.exe, maybe

[Edward K. Ream]

On Thu, May 7, 2020 at 1:33 AM Matt Wilkie  wrote:

I'm taking a run at creating a single executable package of Leo that can be
> unpacked on any machine and just run, no installing!
>

Thanks for this. It might ease the clamor to do a Tk gui, hehe.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0bAiedH-gy2wbhA2mq50TH-HgHYe9BqNgRQ%3Dk-tRr92A%40mail.gmail.com.

Re: Problems with abbreviations with non-english keyboards

[Edward K. Ream]

On Wed, May 6, 2020 at 7:16 PM Mike Hodson  wrote:

> The usual way seems to be a shifted comma and period.
>

Thanks for this. Now I see the semicolon.

> To me this seems to me to be a somewhat mooted point?
>

No, the issue is real. With the German keyboard, when I type "alp;;", that
is, "alp I see "alp;;", not the expansion,
"@language python".

With a German keyboard in effect, I can now see why abbreviations
fail:--trace-keys shows: key-release: Shift ';'.

Presumably the shift modifier ruins the match. It's not clear what to do
about this, but now I have something to work with.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2KqWV-4B7MgnQQRsaONuvWSz%3DiSLPpNJoN0XeTCEXW1g%40mail.gmail.com.

a portable Leo.exe, maybe

[Matt Wilkie]

Hi Folks,

I'm taking a run at creating a single executable package of Leo that can be 
unpacked on any machine and just run, no installing!

Only Windows 64bit so far. Initial results are promising, but much testing 
still needed. First working draft with commit 1579844 

 
and resulting exe in a google drive folder: 
https://drive.google.com/drive/folders/1eOekkp53j1dPb3ewDhW5TAuNgrAeKzWm

   1. Download leo-devel-2020-05-06-11-19.zip (140mb)
   2. unpack it somewhere, say C:\apps\Leo
   3. run c:\apps\leo\leo.exe

Report any successes and failures (open new issues on github).

cheers,

-matt

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/635d37d5-1771-4fdc-84ba-70d2888340f7%40googlegroups.com.