date:20210411

My apologies. 
I did a full “clean” install from devel branch and can verify that the 
@path with @file sub-node using “../“ pattern does indeed work just fine on 
my OS X machine.


On Sunday, April 11, 2021 at 8:04:57 PM UTC-4 Edward K. Ream wrote:

> On Sun, Apr 11, 2021 at 4:17 PM TEK42  wrote:
>
>>
>> Unfortunately, there is a fly in the ointment.  I have an external file 
>>> at a location that uses "..", like this:
>>>
>>> - @path d:/Tom/devel/leo/plugins
>>> -@file ../plugins/viewrendered3.py
>>>
>>>
>> On my OS X machine the above pattern doesn’t work at all (unclear about 
>> the reasoning for the pattern too).
>> I must take out the “../plugins/“ part of the @file for it to be able 
>> write/read the file. 
>>
>
> My apologies. All the obvious things are supposed to work. Leo has several 
> wrappers around g.os.path.  Search for the node "g.os_path_ Wrappers" in 
> leoPy.leo (LeoPyRef.leo).
>
> g.os_path_finalize_join is the workhorse. It should handle just about 
> everything, but apparently it doesn't.
>
> It's surprisingly difficult to make everything work uniformly everywhere. 
> There are gazillions of related calls in Leo.
>
> 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/c81ea432-31fb-45dc-8327-55b89084ce6cn%40googlegroups.com.

Re: Recent changes to the ekr-qt branch

I just incorporated your qt6/qt5 changes into my newer version of VR3.  You 
have probably seen the PR by now.  In addition to your changes, I have 
added new functionality.  This was so I could compile/run Julia programs.  
My approach is to use an ini file to specify which external program to run 
for a specific language.  There is also a simplified  capability to specify 
command line parameters for that external processor.  You can only specify 
params that come before the name of your file on the command line, but that 
probably covers a lot of common cases.

Julia and sql are now allowed languages, and there is a new sql.py file in 
modes to do  the sql colorization. 

Of course, this version doesn't work in the devel branch yet, only the 
ekr-qt one.

On Sunday, April 11, 2021 at 7:54:42 PM UTC-4 Edward K. Ream wrote:

> On Sun, Apr 11, 2021 at 9:29 AM tbp1...@gmail.com  
> wrote:
>
>>
>>
>> On Sunday, April 11, 2021 at 5:31:59 AM UTC-4 Edward K. Ream wrote:
>>
>>>
>>> 4. I have just fixed some problems in the VR3 plugin. It now loads 
>>> properly, but I make no claim that it works in all respect. I don't 
>>> remember who wrote VR3, but we'll have to work out a way to support qt6.
>>>
>>
>> That's me.  I had hoped/intended to avoid qt6 until it had been out 
>> longer, but I suppose I'll have to bite the bullet pretty soon. 
>>
>
> Thanks for checking in, Thomas. I don't think there is much rush just yet.
>
> I'm hoping that the new philosophy of not trying to load optional modules 
> (in qt6) will simplify matters for those who want to do special things. Let 
> me know what you think.
>
> 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/16d5f7a1-05c2-4d7c-8859-1c24e97c7450n%40googlegroups.com.

Re: Recent changes to the ekr-qt branch

On Sun, Apr 11, 2021 at 9:19 PM tbp1...@gmail.com 
wrote:

> I think it's always good not to import things you don't need.  OTOH, if
> qt-ish things are going to need wrappers, then a plugin (say) that wants to
> use one of those optional modules will need to construct the wrapper as
> well.  I'm not very clear on how that should work, if the wrappers don't
> exist until wanted later.
>

I'm not clear either. The only thing I know is that being too clever with
wrappers (as in leoQt5.py) is asking for trouble.

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/CAMF8tS3UNqqvk5n0R3fZ2oRW50LKQmy9bkL9Qxyp9HmzSFpy%2Bw%40mail.gmail.com.

Re: Recent changes to the ekr-qt branch

I think it's always good not to import things you don't need.  OTOH, if 
qt-ish things are going to need wrappers, then a plugin (say) that wants to 
use one of those optional modules will need to construct the wrapper as 
well.  I'm not very clear on how that should work, if the wrappers don't 
exist until wanted later.

On Sunday, April 11, 2021 at 7:54:42 PM UTC-4 Edward K. Ream wrote:

> On Sun, Apr 11, 2021 at 9:29 AM tbp1...@gmail.com  
> wrote:
>
>>
>>
>> On Sunday, April 11, 2021 at 5:31:59 AM UTC-4 Edward K. Ream wrote:
>>
>>>
>>> 4. I have just fixed some problems in the VR3 plugin. It now loads 
>>> properly, but I make no claim that it works in all respect. I don't 
>>> remember who wrote VR3, but we'll have to work out a way to support qt6.
>>>
>>
>> That's me.  I had hoped/intended to avoid qt6 until it had been out 
>> longer, but I suppose I'll have to bite the bullet pretty soon. 
>>
>
> Thanks for checking in, Thomas. I don't think there is much rush just yet.
>
> I'm hoping that the new philosophy of not trying to load optional modules 
> (in qt6) will simplify matters for those who want to do special things. Let 
> me know what you think.
>
> 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/0268bd0c-fa1c-4645-bd55-39e89f64e87an%40googlegroups.com.

Re: creating a new importer for parse-body use

On Sun, Apr 11, 2021 at 4:16 PM jkn  wrote:

> Hi (Edward, probably)

Yes. I wrote this mess :-)

> I am interested in writing an importer to allow me to use the parse-body
> command...
>
...

> I'm starting with a stripped-down file...leo/plugins/importers/tds.py
>

Yes, that sounds reasonable.

> I'm a little unclear as to whether just that file will be enough;
>

Yes, it should be enough, provided that '@language tds' is supported.

I intend to select this parser by means of '@language tds', but with just
> 'noddy' contents of the tds importer I am seeing an error like:
>
> {{{
>
> Traceback (most recent call last):
>
>   File "/home/jkn/leo-editor/leo/core/leoKeys.py", line 2466, in 
> callAltXFunction
> func(event)
>
>   File "/home/jkn/leo-editor/leo/core/leoImport.py", line 2738, in 
> parse_body_command
> c.importCommands.parse_body(c.p)
>
>   File "/home/jkn/leo-editor/leo/core/leoImport.py", line 1137, in parse_body
> ext = '.' + g.app.language_extension_dict.get(language)
> TypeError: can only concatenate str (not "NoneType") to str
> }}}
>
> I have tried creating a matching file colorizor leo/modes/tds.py, without
> success
>

Creating modes/tds.py only affects colorizing. It should have no effect on
importers.

Any thoughts? In any case, that error message might be improved IMO
>

Hehe. I agree the message leaves a bit to be desired.

However, the traceback is actually pretty informative. As usual, the last
two lines are the most informative. Clearly, g.app.language_extension_dict.get(
language) is returning None.

The "language" var comes from the line:

language = g.scanForAtLanguage(c, p), so yes, you must support your new
language by creating entries in three language dictionaries.  See the node
"app.__init__ (helpers contain language dicts)" in leoApp.py.

*Summary*

You have to make @language tds work by creating entries for tds in three
dictionaries in leoApp.py.
You have to create an importer for .tds files.
parse_body shouldn't crash if g.app.language_extension_dict.get( language)
is None.

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/CAMF8tS0JJdCvPbEFL9v5E9%2B7W9443m_Avg7o5_tkqdiY9LL%3DMQ%40mail.gmail.com.

Re: Leo n00b on Mac OS X

On Sun, Apr 11, 2021 at 4:17 PM TEK42  wrote:

>
> Unfortunately, there is a fly in the ointment.  I have an external file at
>> a location that uses "..", like this:
>>
>> - @path d:/Tom/devel/leo/plugins
>> -@file ../plugins/viewrendered3.py
>>
>>
> On my OS X machine the above pattern doesn’t work at all (unclear about
> the reasoning for the pattern too).
> I must take out the “../plugins/“ part of the @file for it to be able
> write/read the file.
>

My apologies. All the obvious things are supposed to work. Leo has several
wrappers around g.os.path.  Search for the node "g.os_path_ Wrappers" in
leoPy.leo (LeoPyRef.leo).

g.os_path_finalize_join is the workhorse. It should handle just about
everything, but apparently it doesn't.

It's surprisingly difficult to make everything work uniformly everywhere.
There are gazillions of related calls in Leo.

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/CAMF8tS1Sus7RY7QigUOi6ENwxwC-GvqL1qm8exT4D2jjKYWFRQ%40mail.gmail.com.

Re: Recent changes to the ekr-qt branch

On Sun, Apr 11, 2021 at 9:29 AM tbp1...@gmail.com 
wrote:

>
>
> On Sunday, April 11, 2021 at 5:31:59 AM UTC-4 Edward K. Ream wrote:
>
>>
>> 4. I have just fixed some problems in the VR3 plugin. It now loads
>> properly, but I make no claim that it works in all respect. I don't
>> remember who wrote VR3, but we'll have to work out a way to support qt6.
>>
>
> That's me.  I had hoped/intended to avoid qt6 until it had been out
> longer, but I suppose I'll have to bite the bullet pretty soon.
>

Thanks for checking in, Thomas. I don't think there is much rush just yet.

I'm hoping that the new philosophy of not trying to load optional modules
(in qt6) will simplify matters for those who want to do special things. Let
me know what you think.

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/CAMF8tS06q-JWswOqHR%2BTTii47jhvBskajYreik-nWnsC50q1fQ%40mail.gmail.com.

Re: Leo n00b on Mac OS X



> Unfortunately, there is a fly in the ointment.  I have an external file at 
> a location that uses "..", like this:
>
> - @path d:/Tom/devel/leo/plugins
> -@file ../plugins/viewrendered3.py
>
>
On my OS X machine the above pattern doesn’t work at all (unclear about the 
reasoning for the pattern too).
I must take out the “../plugins/“ part of the @file for it to be able 
write/read the file. 

And this is after a clean pull of devel branch.

-TK


 

>
> tbp1...@gmail.com
>
> On Friday, April 9, 2021 at 10:11:49 PM UTC-4 tbp1...@gmail.com 
>  wrote:
> It looks like there is a simple fix.  This hasn't had hardly any testing, 
> but on the surface it's doing the right thing.  The little example that 
> failed in an earlier post created the right directories.
>
> In *leoCommands.py*, in the method *expand_path_expression(self, s)*, add 
> the line marked below
>
> val = ''.join(aList)
> *val = os.path.expanduser(val)  # <= Add this line*
> if g.isWindows:
> val = val.replace('\\', '/')
> return val
>

-- 
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/852554d0-a782-4ed8-9f70-640f791d13c9n%40googlegroups.com.

creating a new importer for parse-body use

2021-04-11 Thread jkn


Hi (Edward, probably)

I am interested in writing an importer to allow me to use the parse-body 
command on a simple format I use for making notes (it's similar to the 
format used by the old Origami editor used for Transputer occam files in 
the TDS; Transputer development system)

I'm starting with a stripped-down file

leo/plugins/importers/tds.py

based on others in that directory.

I'm a little unclear as to whether just that file will be enough; I intend 
to select this parser by means of '@language tds', but with just 'noddy' 
contents of the tds importer I am seeing an error like:

{{{

Traceback (most recent call last):
  File "/home/jkn/leo-editor/leo/core/leoKeys.py", line 2466, in 
callAltXFunction
func(event)
  File "/home/jkn/leo-editor/leo/core/leoImport.py", line 2738, in 
parse_body_command
c.importCommands.parse_body(c.p)
  File "/home/jkn/leo-editor/leo/core/leoImport.py", line 1137, in parse_body
ext = '.' + g.app.language_extension_dict.get(language)
TypeError: can only concatenate str (not "NoneType") to str
}}}

I have tried creating a matching file colorizor leo/modes/tds.py, without 
success

Any thoughts? In any case, that error message might be improved IMO

Thanks, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d264f6a9-0288-464c-9646-9be33fb0fd9dn%40googlegroups.com.

Re: [ctlug] M$ Joy

The VR3 plugin for Leo can render Asciidoc to HTML using an Ascidoc command 
line processor, and then display it inside Leo in its display pane.  I have 
found that the conversion is slow for larger asciidoc trees, though (not 
because of Leo but because of the processor).  The flavor of HTML would 
depend on the external processor.

You write your document as a subtree in Leo.  You can render any node or 
subtree, or the entire subtree.  Node headlines become section titles in 
the rendered result.

On Sunday, April 11, 2021 at 3:11:10 PM UTC-4 David Szent-Györgyi wrote:

> On Sunday, April 11, 2021 at 4:14:30 AM UTC-4 Edward K. Ream wrote:
>
>>
>> 1. Those who are planning major writing projects would be well advised to 
>> make a serious study of the strengths and weakness of the major contenders, 
>> including Jupyter, LaTeX, reStructuredText, and Leo. And yes, it will take 
>> some study. wysiwyg editors and simplistic markup languages like markdown 
>> are too limiting. Better to invest in more powerful tools.
>>
>> 2. It is a great mistake to underestimate the capabilities of existing 
>> tools.
>>
>> I have made this mistake several times. 30 years ago, I despaired of 
>> using Emacs because I didn't understand that tab completion makes it 
>> unnecessary to remember full command names, or to type them. Had I 
>> understood this, I would likely have based Leo on Emacs. Leo's entire 
>> history would have changed, and I would not have spent much of the last 30 
>> years dealing with tangential editor-related issues.
>>
>> In short,* please* take the time to study what is already possible. 
>> Major tools typically have dozens or even hundreds of contributors. It 
>> would be impossible to do better on one's own.
>>
>
> Edward is absolutely right in recommending using existing tools when 
> possible. 
>
> I am looking for a markup language for plain-text files, some of which are 
> documentation meant for PDF or ODF, some of which are plain text meant for 
> conversion via templates to static HTML5 for a Web site. Has anyone else 
> worked with AsciiDoc format? 
>
> AsciiDoc is meant to be less ad-hoc than Markdown and the variants 
> thereof. It is meant to be semantically equivalent to DocBook XML, and its 
> creators are early in an effort to write a specification  complete with an 
> open Technology Compatibility Kit 
> .
>  
>
>
> The creators of AsciiDoc offer Asciidoctor , a "
> *fast*, open source 
>  text 
> processor and publishing toolchain for converting AsciiDoc 
>  content to HTML5, 
> DocBook, PDF, and other formats"; AsciiDoctor is cross-platform, written in 
> Ruby; AsciidoctorJ  runs on 
> a Java Virtual Machine, and Asciidoctor.js 
>  in JavaScript 
> environments, including Web browsers. The leaders of the Asciidoctor 
> project write that AsciidoctorJ and Asciidoctor.js need to develop 
> independently of Asciidoctor, which is one motivation for the creation of a 
> specification and TCK. 
>
> The Python implementation, AsciiDoc-py 
> , is limited to legacy syntax 
> for AsciiDoc. 
>
>  
>

-- 
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/a19dc21e-7c4e-4540-a0ce-1b44498e5b90n%40googlegroups.com.

Re: [ctlug] M$ Joy

2021-04-11 Thread David Szent-Györgyi

On Sunday, April 11, 2021 at 4:14:30 AM UTC-4 Edward K. Ream wrote:

>
> 1. Those who are planning major writing projects would be well advised to 
> make a serious study of the strengths and weakness of the major contenders, 
> including Jupyter, LaTeX, reStructuredText, and Leo. And yes, it will take 
> some study. wysiwyg editors and simplistic markup languages like markdown 
> are too limiting. Better to invest in more powerful tools.
>
> 2. It is a great mistake to underestimate the capabilities of existing 
> tools.
>
> I have made this mistake several times. 30 years ago, I despaired of using 
> Emacs because I didn't understand that tab completion makes it unnecessary 
> to remember full command names, or to type them. Had I understood this, I 
> would likely have based Leo on Emacs. Leo's entire history would have 
> changed, and I would not have spent much of the last 30 years dealing with 
> tangential editor-related issues.
>
> In short,* please* take the time to study what is already possible. Major 
> tools typically have dozens or even hundreds of contributors. It would be 
> impossible to do better on one's own.
>

Edward is absolutely right in recommending using existing tools when 
possible. 

I am looking for a markup language for plain-text files, some of which are 
documentation meant for PDF or ODF, some of which are plain text meant for 
conversion via templates to static HTML5 for a Web site. Has anyone else 
worked with AsciiDoc format? 

AsciiDoc is meant to be less ad-hoc than Markdown and the variants thereof. 
It is meant to be semantically equivalent to DocBook XML, and its creators 
are early in an effort to write a specification  complete with an open 
Technology Compatibility Kit 
.

The creators of AsciiDoc offer Asciidoctor , a "
*fast*, open source 
 text 
processor and publishing toolchain for converting AsciiDoc 
 content to HTML5, DocBook, 
PDF, and other formats"; AsciiDoctor is cross-platform, written in Ruby; 
AsciidoctorJ  runs on a Java 
Virtual Machine, and Asciidoctor.js 
 in JavaScript environments, 
including Web browsers. The leaders of the Asciidoctor project write that 
AsciidoctorJ and Asciidoctor.js need to develop independently of 
Asciidoctor, which is one motivation for the creation of a specification 
and TCK. 

The Python implementation, AsciiDoc-py 
, is limited to legacy syntax 
for AsciiDoc. 

-- 
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/215e211e-671b-4e52-a09f-cc67feb2d415n%40googlegroups.com.

Re: Leo n00b on Mac OS X

New issue # 1889 at

https://github.com/leo-editor/leo-editor/issues/1889

On Sunday, April 11, 2021 at 3:42:02 AM UTC-4 Edward K. Ream wrote:

> On Sat, Apr 10, 2021 at 10:46 PM tbp1...@gmail.com  
> wrote:
>
>> Unfortunately, there is a fly in the ointment.
>>
> ...
>
> I have come up with completely  different code...
>>
>
> Many thanks for all this work.
>
> Please create a Leo issue for this, summarizing the problem. A new issue 
> will ensure that I don't forget about this topic.
>
> 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/66aa1219-84b3-4283-b1d6-f97122bc5049n%40googlegroups.com.

Re: Leo n00b on Mac OS X

I instrumented *expand_path_expression**()* with print statements and found 
that it is being called all the time, apparently for every file that Leo 
knows about.  I'm thinking that it's Leo polling to see if each file has 
been changed outside of Leo.  Some of those call outputs were full paths, 
some of them were relative paths (possibly they were my "..\" paths, but 
too many were scrolling by for me to be sure).

The thing is that *expand_path_expression()* is used by a number of other 
routines, and some plugins.  All of those probably assume that they will 
receive a certain path format, and none of that seems to be documented, at 
least not in the methods themselves.  Any change would have to be checked 
to make sure that everything else keeps working.  And it seems that 
different parts of Leo's internals depend on the exact behavior of this 
method.

I know of at least three things Leo has to do with node paths: 

1. Load/save external files whose location does not depend on *@path* 
directives;
2. Load/save external files whose location uses *@path* directives;
3. Poll all external files and outlines for changes.

There may easily be more.  The trick will be to get them all to work 
correctly if any changes are made.  And then existing external files might 
become inaccessible.  Consider a case where you specified *@path 
~/my-special-dir*/*test.txt*.  We know that this will create a 
directory/file structure in the wrong - that is, not intended - place.  Now 
say we fix the code so that in the future it creates our file in the 
correct location.  Trouble is, Leo now won't be able to find the existing 
external file that it had created earlier in the wrong place.

This might be all right for you and your new outline that only has one or 
two such files.  You can fix that by hand.  But there may be large outlines 
out there that have dozens or hundreds of files created with the wrong 
paths.  For example, in LeoPy.leo, all the plugins have paths starting with 
"../" .  They *have to* keep working.  Fixing that up is a much larger 
task.  Not everyone has the script knowhow and desire to work up a script 
that reliably fixes this kind of problem.

On Sunday, April 11, 2021 at 9:10:45 AM UTC-4 TEK42 wrote:

> That is all curios. I am unclear the expanduser() call would affect things 
> that way. Then again I understand <1% of Leo code at this point.
> What *is *clear is that I will need to get Leo setup on Windows and Linux 
> as well.
>
>

-- 
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/8273a450-0ef6-4f8b-affc-c83ece3db682n%40googlegroups.com.

Re: Recent changes to the ekr-qt branch



On Sunday, April 11, 2021 at 5:31:59 AM UTC-4 Edward K. Ream wrote:

>
> 4. I have just fixed some problems in the VR3 plugin. It now loads 
> properly, but I make no claim that it works in all respect. I don't 
> remember who wrote VR3, but we'll have to work out a way to support qt6.
>

That's me.  I had hoped/intended to avoid qt6 until it had been out longer, 
but I suppose I'll have to bite the bullet pretty soon. 

-- 
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/b6159b65-90b9-4fc7-b7c8-45f99a2a93ban%40googlegroups.com.

Re: Leo n00b on Mac OS X

That is all curios. I am unclear the expanduser() call would affect things 
that way. Then again I understand <1% of Leo code at this point.
What *is *clear is that I will need to get Leo setup on Windows and Linux 
as well.

On Saturday, April 10, 2021 at 11:46:28 PM UTC-4 tbp1...@gmail.com wrote:

> Unfortunately, there is a fly in the ointment.  I have an external file at 
> a location that uses "..", like this:
>
> - @path d:/Tom/devel/leo/plugins
> -@file ../plugins/viewrendered3.py
>
> Leo wants this @file path to contain the *../plugins* path step.  With 
> the *expanduser()* line, my file doesn't save.  I tried adding an 
> *os.path.abspath()* operation, but then a lot of other files don't load 
> and Leo operation are quite messed up.  Apparently certain calls expect 
> relative paths to be returned.  So it's a mess, so far as creating correct 
> directory @paths that contain "~" is concerned.
>
> And without adding the *os.path.expanduser()* call, Leo doesn't make the 
> correct directories when the *@path* subtree starts with "~".  So this is 
> not such an easy thing to fix properly.
>
> I have come up with completely  different code for opening a directory 
> that properly expands "~".  Of course, it won't cause the correct 
> directories to be made, but it does return the correct directory path, 
> including "~",  and does not rely on ".".  It won't work right if an 
> *@path* directory contains ".." but it does work right if the *@file* 
> headline contains ".." as in my example above.
>
> """Return the full path on disk to an external file or directory.  
>
> Honor all @path directives. Expand "~" in path to be the user's 
> home directory. If get_file is False, return only the directory's 
> path (less any filename).
> """
> import os
>
> steps = [d.get('path') for d in g.get_directives_dict_list(p) if 'path' in 
> d]
> steps.reverse()
>
> # Comment in these four lines if you also want to include the file itself 
> in the path.
> #pth = g.fullPath(c, p)
> #fn = os.path.basename(pth) #file name if there is a file here. 
> #if fn:  
> #steps.append(fn)
>
> if len(steps) > 1:
> pth = os.path.join(steps[0], *steps[1:])
> elif len(steps) == 1:
> pth = steps[0]
> else:
> pth = os.getcwd()
>
> pth = os.path.expanduser(pth)
> if g.isWindows:
> pth = pth.replace('/', '\\')
> else:
> pth = pth.replace('\\', '/')
>
>
> tbp1...@gmail.com
>
> On Friday, April 9, 2021 at 10:11:49 PM UTC-4 tbp1...@gmail.com 
>  wrote:
> It looks like there is a simple fix.  This hasn't had hardly any testing, 
> but on the surface it's doing the right thing.  The little example that 
> failed in an earlier post created the right directories.
>
> In *leoCommands.py*, in the method *expand_path_expression(self, s)*, add 
> the line marked below
>
> val = ''.join(aList)
> *val = os.path.expanduser(val)  # <= Add this line*
> if g.isWindows:
> val = val.replace('\\', '/')
> return val
>

-- 
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/7f996527-a849-417d-a77c-8c7f9cd747b4n%40googlegroups.com.

Re: Leo n00b on Mac OS X


You could do all your work in a virtual environment, but I like to set 
PYTHONPATH to point to the top of the repo instead.  Then Python will find 
Leo in the repo but all other python packages from their usual places.  On 
my Windows machine:

>
> set PYTHONPATH=d:\tom\git\leo-editor
> python3 -m leo.core.runLeo
>
> One advantage of doing it this way is that you can run the ordinary Leo 
> release simply by unsetting PYTHONPATH.  You don't have to try to remember 
> which venv has got which configuration, or how to get the venv to use the 
> repo.  
>
> I've learned that it's best to make a new branch for each of your change 
> projects, no matter how small.  Once the PR is closed, you can update from 
> Leo's *devel* and again branch off it for your next effort, or merge your 
> branch back into your clone of *devel*.  
>
> Of course, you may be way more experienced at doing the PR dance and if so 
> just keep doing whatever you have been doing!
>

Thanks for the python path tips - it’s been about 15 years since developed 
with python professionally.

As far as the PR dance goes, that is pretty much my everyday dance at work 
;)


-- 
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/6f18d6ae-1ae9-4dd2-b8d1-03209428e0bbn%40googlegroups.com.

Recent changes to the ekr-qt branch

The following changes should have zero impact on qt4 and qt5 users. They 
may have impact on qt6 users and devs:

1. leoQt6.py no longer imports any optional Qt modules. This means that 
plugins won't have to deal with the "import munging" that happened when Leo 
imported PyQt5.

2. Leo now detects if the printsupport module doesn't exist. The Qt docs 
imply that this is a required module, but it doesn't seem to exist on my 
PyQt6 6.0.2 build on Windows. This is a mystery that googling has not 
resolved.

3. I have just fixed #1886 
, a crasher in the 
stickynotes plugin.

4. I have just fixed some problems in the VR3 plugin. It now loads 
properly, but I make no claim that it works in all respect. I don't 
remember who wrote VR3, but we'll have to work out a way to support qt6.

That's all for now. Keep those bug reports coming.

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/63baf4f1-5a99-429d-b01e-ead4f8243a9bn%40googlegroups.com.

Re: [ctlug] M$ Joy

On Friday, April 9, 2021 at 12:41:41 PM UTC-5 Edward K. Ream wrote:

>> I feel everybody's pain. As far as I know, there's not a single piece of
software out there that authors quickly and yet does consistent,
styles-based formatting and outputs to both PDF and HTML. But I'll keep
searching.

> 1. You're screwed if you insist on wysiwyg.
...
> 2. Some people spend their whole life complaining about missing tools,
without any clear idea of what they want.

I apologize for the insulting tone. A more helpful response would be
something like this:

1. Those who are planning major writing projects would be well advised to
make a serious study of the strengths and weakness of the major contenders,
including Jupyter, LaTeX, reStructuredText, and Leo. And yes, it will take
some study. wysiwyg editors and simplistic markup languages like markdown
are too limiting. Better to invest in more powerful tools.

2. It is a great mistake to underestimate the capabilities of existing
tools.

I have made this mistake several times. 30 years ago, I despaired of using
Emacs because I didn't understand that tab completion makes it unnecessary
to remember full command names, or to type them. Had I understood this, I
would likely have based Leo on Emacs. Leo's entire history would have
changed, and I would not have spent much of the last 30 years dealing with
tangential editor-related issues.

In short,* please* take the time to study what is already possible. Major
tools typically have dozens or even hundreds of contributors. It would be
impossible to do better on one's own.

HTH.

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/dccc1911-96d5-4453-a376-fdabfb69fd5fn%40googlegroups.com.

Re: Leo n00b on Mac OS X