Re: AHA: new Leo directive
For under-indented multi-line comments, I'm not sure I see much of a problem. The most common thing I've seen is an ambiguity as to whether later lines should indent to the opening (triple) quote or indent to the leading character after the opening quote. What's more important is that intentional indentation used for formatting within the multiline comment be preserved. The other usual possibility is that succeeding lines aren't indented at all. In that case, they wouldn't need to be changed anyway. Besides docstrings, I also use multiline quotes to define things like css stylesheets and HTML HEAD elements. In those cases the indentation is for readability, not functionality. Before jumping to add a new directive, I've like to see written down just what the requirements are for handling multistring quotes. Let's have it clearly spelled out, including interactions with *@others*. It's not altogether clear in my mind yet. On Sunday, December 12, 2021 at 2:24:02 PM UTC-5 vitalije wrote: > While thinking about the problem with new Python importer I've got an > idea. The problem with the importers in general is not to detect when we > have under indented lines, it is the question of what to do with them. > While in some cases like under indented comments, it is easy to just change > the indentation or to insert some sentinel line in order to represent them > in the derived file, when we have under indented lines in the python multi > line string constants, it isn't possible to insert any sentinel or it would > change the meaning of the program. > > The solution is to add a new Leo directive `at-indent `. This > directive would change the indentation of the following lines until the new > at-indent directive or until the end of the node. This directives can be > inserted automatically during the parsing of file and they're never written > in the external file. This way it would be possible to have Python multi > line strings defined in some indented outline node, which represent the > value without indentation. For example in many tests strings used in > test_leoImport and test_leoAtFile we have to use textwrap.dedent to remove > extra indentation from multi line strings. Using at-indent directive it > would be possible to define constants without any indentation added by Leo. > > Branch at-indent contains the code for this feature. > > With this, it would be trivial to resolve problematic files in python > importer. > > 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/d063a260-6086-49a6-a203-c873b10e861an%40googlegroups.com.
Re: AHA: new Leo directive
I've pushed my changes by error directly in the devel branch. I've reverted those changes to the previous commit. Now, the proposed new directive at-indent is in the new branch at-indent On Sunday, December 12, 2021 at 8:24:02 PM UTC+1 vitalije wrote: > While thinking about the problem with new Python importer I've got an > idea. The problem with the importers in general is not to detect when we > have under indented lines, it is the question of what to do with them. > While in some cases like under indented comments, it is easy to just change > the indentation or to insert some sentinel line in order to represent them > in the derived file, when we have under indented lines in the python multi > line string constants, it isn't possible to insert any sentinel or it would > change the meaning of the program. > > The solution is to add a new Leo directive `at-indent `. This > directive would change the indentation of the following lines until the new > at-indent directive or until the end of the node. This directives can be > inserted automatically during the parsing of file and they're never written > in the external file. This way it would be possible to have Python multi > line strings defined in some indented outline node, which represent the > value without indentation. For example in many tests strings used in > test_leoImport and test_leoAtFile we have to use textwrap.dedent to remove > extra indentation from multi line strings. Using at-indent directive it > would be possible to define constants without any indentation added by Leo. > > Branch at-indent contains the code for this feature. > > With this, it would be trivial to resolve problematic files in python > importer. > > 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/d0347ab9-88c8-4f90-945c-e96dffbf1990n%40googlegroups.com.
AHA: new Leo directive
While thinking about the problem with new Python importer I've got an idea. The problem with the importers in general is not to detect when we have under indented lines, it is the question of what to do with them. While in some cases like under indented comments, it is easy to just change the indentation or to insert some sentinel line in order to represent them in the derived file, when we have under indented lines in the python multi line string constants, it isn't possible to insert any sentinel or it would change the meaning of the program. The solution is to add a new Leo directive `at-indent `. This directive would change the indentation of the following lines until the new at-indent directive or until the end of the node. This directives can be inserted automatically during the parsing of file and they're never written in the external file. This way it would be possible to have Python multi line strings defined in some indented outline node, which represent the value without indentation. For example in many tests strings used in test_leoImport and test_leoAtFile we have to use textwrap.dedent to remove extra indentation from multi line strings. Using at-indent directive it would be possible to define constants without any indentation added by Leo. Branch at-indent contains the code for this feature. With this, it would be trivial to resolve problematic files in python importer. 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/022bc04e-dded-4b4f-a8f1-9b166c1f9cb3n%40googlegroups.com.
Re: Leo Install Problems on Linux (again)
I agree with you, but it will be hard for people to try Leo if the pip-install fails. I don't know the solution, though, except not to require pyqtwebengine for pip to suceed, and to have VR3 emit a message about installing it. The development of the WebEngine seems to be handled separately from the main part of Qt, on its own schedule. They planned to do some redesign. As of the latest version of PyQt6, there was still no WebEngine, and that's why VR3 doesn't work "completely". It falls back to using a QTextBrowser like VR does. On Sunday, December 12, 2021 at 7:51:26 AM UTC-5 Edward K. Ream wrote: > On Fri, Nov 19, 2021 at 5:56 PM tbp1...@gmail.com > wrote: > >> I thought that Leo install problems on Linux had been solved, but >> apparently not so. I tried to install Leo in Linux Mint to a new virtual >> environment. It failed to install because it wanted versions of PyQt and >> PyQtWebengine that don't seem to be available for Linux. >> >> In recent past, it had been found that one had to install older Leo Leo >> versions, 6.4, or even 6.1, before upgrading to later versions. Today I >> couldn't get 6.4 to install. The reason turned out to be that PyPi >> apparently doesn't have the right linux versions of PyQt5 and PyQtWebEngine. >> >> I was able to get Leo installed in two different virtual environments by >> first installing the PyQt packages. The only combination I was able to >> install successfully was: >> >> PyQt5 (5.14.0) >> PyQtWebEngine (5.12) >> >> All other versions failed for one or the other of PyQt5 or PyQtWebEngine. >> I had to pip-install these first. Then I pip-installed Leo with success, >> getting version 6.5. >> >> Apparently you can't get a list of what versions PiPi has available. The >> pip *search* function doesn't work anymore, and the old way of >> installing with a blank version (e.g., pip install PyQt5==) to get a >> list of available versions doesn't work either. If you search on the PyPi >> web site, it tells you there are versions which don't install and does not >> say that it has versions that actually do. >> >> I don't know what the solution is here, but it could be a nasty problem >> for new users on Linux. >> > > My apologies for the delay in responding. The problem with extra Qt > packages exists on Windows too, and very likely on MacOS, as I just > rediscovered yesterday. In particular, I have not been able to get the VR3 > plugin working completely with Qt6. > > Imo, these problems will not prevent people from trying Leo and I don't > think it should be Leo's responsibility to handle Qt madness. > > 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/c1c7ae0c-4b55-4a4c-a733-263f503af44an%40googlegroups.com.
Re: Leo Install Problems on Linux (again)
On Fri, Nov 19, 2021 at 5:56 PM tbp1...@gmail.com wrote: > I thought that Leo install problems on Linux had been solved, but > apparently not so. I tried to install Leo in Linux Mint to a new virtual > environment. It failed to install because it wanted versions of PyQt and > PyQtWebengine that don't seem to be available for Linux. > > In recent past, it had been found that one had to install older Leo Leo > versions, 6.4, or even 6.1, before upgrading to later versions. Today I > couldn't get 6.4 to install. The reason turned out to be that PyPi > apparently doesn't have the right linux versions of PyQt5 and PyQtWebEngine. > > I was able to get Leo installed in two different virtual environments by > first installing the PyQt packages. The only combination I was able to > install successfully was: > > PyQt5 (5.14.0) > PyQtWebEngine (5.12) > > All other versions failed for one or the other of PyQt5 or PyQtWebEngine. > I had to pip-install these first. Then I pip-installed Leo with success, > getting version 6.5. > > Apparently you can't get a list of what versions PiPi has available. The > pip *search* function doesn't work anymore, and the old way of installing > with a blank version (e.g., pip install PyQt5==) to get a list of > available versions doesn't work either. If you search on the PyPi web > site, it tells you there are versions which don't install and does not say > that it has versions that actually do. > > I don't know what the solution is here, but it could be a nasty problem > for new users on Linux. > My apologies for the delay in responding. The problem with extra Qt packages exists on Windows too, and very likely on MacOS, as I just rediscovered yesterday. In particular, I have not been able to get the VR3 plugin working completely with Qt6. Imo, these problems will not prevent people from trying Leo and I don't think it should be Leo's responsibility to handle Qt madness. 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/CAMF8tS13JYT-SEReBvBJV4H%2BdcYOSjgCP_%3DSf3JEZ0UYNH9crw%40mail.gmail.com.
Re: Year-end report
On Sat, Dec 11, 2021 at 7:36 AM Zoom.Quiet wrote: > I plan to release Leo 6.6b2 after I return, provided this suits Félix and > his plans for leoInteg. > > so glad know this, > means Leo never stop granding ;-) > and Leo is 26 years old, > so long so far away... > deep hoping 2042 is upgrading also. > Thanks for these comments. I don't expect to see 2042, but stranger things have happened :-) 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/CAMF8tS1%3Dc-FGZD-n%3DbPxZ7ej3ezYXt7E3u0PwgzNCOG4XccqYA%40mail.gmail.com.
Re: bugs/feature requests in the new python importer
On Sat, Dec 11, 2021 at 10:31 AM vitalije wrote: I was absent for the last few days. Regarding async def problem, I believe > that would be an easy fix/addition. I know that at-others some times can be > at the zero indentation and most of the children have extra indentation. > This is supposed to happen only if indenting at-others would lead to the > indentation of under-indented comments and therefore would cause the > difference between the source code and the code outline would produce. This > was intentional. > I see. My preference is to base the indentation of @others on the first *significant *line that follows the "class" line. In that case, the python importer may be forced to insert the underindented escape sequence. > I will check to see why those files have this problem, and if it is caused > by under indented comments I would rather let user manually fix this > indentation problem. The next time the file is imported it would have usual > form (indented at-others and not indented children). However, this might > also be a matter of setting/preference too. > I am happy to "promote" underindented comments as required. In my importer, this is (would be?) done by not adding the underindented escape sequence before comment lines. I'll investigate further and will report my findings later. > Thanks. I am enjoying this conversation. The python importer presents subtle problems, and it's good to see alternative solutions. 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/CAMF8tS1R%3D%3DRJcs4S%2BbRsav7k7FquiSn%2B3pSgQM-Dracnd71MRA%40mail.gmail.com.
