Re: [error] under m1 chip's macOS 12.3.1 with homebrew
BTW: install steps is: 0: base ARM version Homebrew install Python@3.10 1: usage it create venv ༄ python3.10 -m venv .py310leo 2: activate it ༄ source .py310leo/bin/activate 3: base pip install Leo ༄ pip install leo Zoom.Quiet 于2022年5月6日周五 20:01写道： > > in the old MBP i install Leo flow > Installing Leo — Leo 6.6.1 documentation > https://leoeditor.com/installing.html#installing-leo-with-pip > (in fact "Installing Leo on MacOs 10.7 (Lion) and later¶" chapter is my > logging) > > after upgrade into M1max MBP and macOS 12.3.1, some thing is change; > i tried: > - PyENV, can not complile python 3.10.* > - Anaconda, can create py3.10 env, but can usage pip install Leo > - ... > > so try install the lasted Leo with Homebrew Python > > ༄ abrew info python@3.10 > python@3.10: stable 3.10.4 (bottled) [keg-only] > Interpreted, interactive, object-oriented programming language > https://www.python.org/ > /opt/homebrew/Cellar/python@3.10/3.10.4 (3,165 files, 57.7MB) > Poured from bottle on 2022-05-06 at 12:16:44 > From: > https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/pyt...@3.10.rb > License: Python-2.0 > ==> Dependencies > Build: pkg-config ✔ > Required: gdbm ✔, mpdecimal ✔, openssl@1.1 ✔, readline ✔, sqlite ✔, xz ✔ > ==> Caveats > Python has been installed as > /opt/homebrew/opt/python@3.10/bin/python3 > > Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to > `python3`, `python3-config`, `pip3` etc., respectively, have been installed > into > /opt/homebrew/opt/python@3.10/libexec/bin > > You can install Python packages with > /opt/homebrew/opt/python@3.10/bin/pip3 install > They will install into the site-package directory > /opt/homebrew/lib/python3.10/site-packages > > tkinter is no longer included with this formula, but it is available > separately: > brew install python-tk@3.10 > > See: https://docs.brew.sh/Homebrew-and-Python > > python@3.10 is keg-only, which means it was not symlinked into /opt/homebrew, > because this is an alternate version of another formula. > > If you need to have python@3.10 first in your PATH, run: > echo 'export PATH="/opt/homebrew/opt/python@3.10/bin:$PATH"' >> > /Users/zoomq/.bash_profile > > For compilers to find python@3.10 you may need to set: > export LDFLAGS="-L/opt/homebrew/opt/python@3.10/lib" > > For pkg-config to find python@3.10 you may need to set: > export PKG_CONFIG_PATH="/opt/homebrew/opt/python@3.10/lib/pkgconfig" > > ==> Analytics > install: 327,625 (30 days), 1,043,942 (90 days), 2,203,047 (365 days) > install-on-request: 78,597 (30 days), 260,440 (90 days), 359,785 (365 days) > build-error: 328 (30 days) > > but when i try pip install leo: > > ༄ pip install leo > Looking in indexes: https://mirrors.aliyun.com/pypi/simple/ > Collecting leo > Downloading > https://mirrors.aliyun.com/pypi/packages/52/d5/3e0b42cd0a41046ba583ea9e04dcc0e4b7d6454d5d41ce9cf1350f360800/leo-6.6.1-py3-none-any.whl > (13.3 MB) > 13.3/13.3 MB 2.0 MB/s eta > 0:00:00 > Collecting PyQtWebEngine > Downloading > https://mirrors.aliyun.com/pypi/packages/60/66/56e118abb4cddd8e4bea6f89bdec834069b52479fb991748f1b21950811e/PyQtWebEngine-5.15.5.tar.gz > (48 kB) > 48.6/48.6 KB 1.7 MB/s eta > 0:00:00 > Installing build dependencies ... done > Getting requirements to build wheel ... done > Preparing metadata (pyproject.toml) ... error > error: subprocess-exited-with-error > > × Preparing metadata (pyproject.toml) did not run successfully. > │ exit code: 1 > ╰─> [8 lines of output] > Querying qmake about your Qt installation... > /opt/homebrew/bin/qmake -query > These bindings will be built: QtWebEngineCore, QtWebEngine, > QtWebEngineWidgets. > Generating the QtWebEngineCore bindings... > _in_process.py: > /private/var/folders/pl/8rsjzmjn2ybgd71lwqf3lxw8gp/T/pip-install-2ob2v5nn/pyqtwebengine_bbfdebdd8f894252872cafbbe5a825b3/sip/QtWebEngineCore/QtWebEngineCoremod.sip: > line 25 column 9: 'QtCore/QtCoremod.sip' could not be found > > /private/var/folders/pl/8rsjzmjn2ybgd71lwqf3lxw8gp/T/pip-install-2ob2v5nn/pyqtwebengine_bbfdebdd8f894252872cafbbe5a825b3/sip/QtWebEngineCore/QtWebEngineCoremod.sip: > line 26 column 9: 'QtGui/QtGuimod.sip' could not be found > > /private/var/folders/pl/8rsjzmjn2ybgd71lwqf3lxw8gp/T/pip-install-2ob2v5nn/pyqtwebengine_bbfdebdd8f894252872cafbbe5a825b3/sip/QtWebEngineCore/QtWebEngineCoremod.sip: > line 27 column 9: 'QtNetwork/QtNetworkmod.sip' could not be found > > /private/var/folders/pl/8rsjzmjn2ybgd71lwqf3lxw8gp/T/pip-install-2ob2v5nn/pyqtwebengine_bbfdebdd8f894252872cafbbe5a825b3/sip/QtWebEngineCore/qwebengineclientcertificatestore.sip: > line 24 column 6: 'PyQt_SSL' is not a known qualifier > [end of output] > > note: This error originates from a subprocess, and is likely not a > problem with pip. > error: metadata-generation-faile
Re: Should execute-general-script Run On A Thread?
On Wed, May 4, 2022 at 4:37 PM tbp1...@gmail.com wrote: here i want to open a discussion of whether the execute-general-script > should be made to be non-blocking. > Yes, that would be good. > if yes, there are some complications, such as where the output should go > when several instances of the command are running at the same time, and > whether several instances should even be allowed to run at the same time. > maybe. for example, the command should queue itself up with the background > process manager. > I agree. Use the BPM if possible. > i am inclined to think that such a command should open a new tab in the > log frame and write to it. > Imo (which can always change), using the log is simple and best (less confusing). It's almost never necessary to do several background tasks at once, and even if there is, the BPM is the best way to keep things straight. If you *really* want to do lots of things at once, you can do them outside of Leo. *Summary* Using the BPM to avoid confusion will be simplest and will be adequate virtually all the time. I look forward to your PR! 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/CAMF8tS3jBgCiPtLpYtAJt7ZC74B118r%3DA5n0PMVcJDi8Yw0Z4Q%40mail.gmail.com.
Re: [error] under m1 chip's macOS 12.3.1 with homebrew
On Fri, May 6, 2022 at 7:51 AM tbp1...@gmail.com wrote: > this looks like a problem with Qt or PyQt, not leo per se. possibilities: > > - try to install PyQt6 on its own (without the rest of leo); > - try to install an earlier version of PyQt6, if you can figure out which > ones are available; > - try installing PyQt5 instead of PyQt6 (Leo can use either one); > - install python 3.9 and see whether PyQt6 or PyQt5 will install without > errors. > Sounds like good advice. Thanks. 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/CAMF8tS31%2BTiJRNNZzxJk1EDQKeXEKfMMdXY2ssAGbnF1BNSqRA%40mail.gmail.com.
Re: Non-ASCII characters in a node body make edit operations produce unintended results
On Thu, May 5, 2022 at 9:27 AM Arjan wrote: > It's not a new problem: > https://github.com/leo-editor/leo-editor/issues/1368 Yes. I have no idea how it could be fixed. Anyone have any suggestions? 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/CAMF8tS2pSOzRPBZAB0xVHWGL%2BQ7B4v8f5kK4ce0wsCFWo21C1A%40mail.gmail.com.
Re: Specific command behavior : goto-first/last-visible-node
On Friday, May 6, 2022 at 12:03:55 AM UTC-5 Félix wrote:
To me it feels counter intuitive to have those two operations change the
> collapsed state of nodes using *expandOnlyAncestorsOfNode*(p), as i feel
> they should use *treeSelectHelper(p)* which doesn't change the collapsed
> states of nodes from what i understand (i may be wrong)
>
> And so basically I'm kind of wondering if those commands have a reason for
> contracting all the rest of the tree when going to the first/last visible
> node...?
Good questions :-) This is a surprisingly complicated topic. At least the
following settings (in the `Tree Operation` part of leoSettings.leo) relate
to this discussion:
@bool collapse-nodes-after-move = True
@bool collapse-nodes-during-finds = True
@bool collapse-on-lt-arrow = True
@bool sparse-move-outline-left = False
These defaults are my strong preferences. I almost never want to see
unnecessarily expanded nodes. Instead, I use clones to focus my attention
on *one thing at a time.* Other people have their own preferences, which is
why the above settings exist in the first place.
Your comment suggests that maybe a new preference would be useful. The code
involved is straightforward:
@g.commander_command('goto-first-visible-node')
def goToFirstVisibleNode(self, event=None):
"""Select the first visible node of the selected chapter or hoist."""
c = self
p = c.firstVisible()
if p:
c.expandOnlyAncestorsOfNode(p=p)
c.redraw()
The setting would determine whether c.expandOnlyAncestorsOfNode should be
called.
*Summary*
Contracting non-ancestor nodes when going to the first or last visible node
seems like a valid user preference. I'll be happy to consider a PR :-)
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/1bd4c696-b569-4583-a03e-fd64e1958da4n%40googlegroups.com.
Re: Non-ASCII characters in a node body make edit operations produce unintended results
I'm in the dark too, but when i encountered the same problem several leo versions ago, i raised the issue and then after a few more merges the problem was gone. actually, that time it was more serious because every use of the ctrl key (iirc) inserted those symbols. it's always been those exact strange symbols, so there must be some very specific thing going on. the symbols involved do not change with the font, so it's not a matter of missing or wrong glyphs getting drawn. it might be something like utf8 decoding getting shifted by a bit or a nibble, or getting an extra byte inserted spuriously into the decoded stream. if so, it would probably be an issue with the decoding library that qt uses. i never knew what had changed - i assumed that @edward had done something to fix it - but if someone can find my report - maybe 2 years ago by now? - and has some skill with tracking changes through git - something might come too light. sorry, i'm not in a position to do it myself right now. On Friday, May 6, 2022 at 10:15:40 AM UTC-4 Edward K. Ream wrote: > On Thu, May 5, 2022 at 9:27 AM Arjan wrote: > >> It's not a new problem: >> https://github.com/leo-editor/leo-editor/issues/1368 > > > Yes. I have no idea how it could be fixed. Anyone have any suggestions? > > 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/52951c93-76ef-4caf-a616-d662707c62bcn%40googlegroups.com.
Re: Non-ASCII characters in a node body make edit operations produce unintended results
On Fri, May 6, 2022 at 12:02 PM tbp1...@gmail.com wrote: the symbols involved do not change with the font, so it's not a matter of > missing or wrong glyphs getting drawn. it might be something like utf8 > decoding getting shifted by a bit or a nibble, or getting an extra byte > inserted spuriously into the decoded stream. if so, it would probably be > an issue with the decoding library that qt uses. I agree with this analysis. The only workaround I can think of is not to paste the offending glyphs/characters. 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/CAMF8tS3nz2ZYHB%3D6teQWhUTspb8Tb45qv808npgrO4ia4o%3DH9w%40mail.gmail.com.
Re: [error] under m1 chip's macOS 12.3.1 with homebrew
Edward K. Ream 于2022年5月6日周五 22:14写道： > > On Fri, May 6, 2022 at 7:51 AM tbp1...@gmail.com wrote: >> >> this looks like a problem with Qt or PyQt, not leo per se. possibilities: >> >> - try to install PyQt6 on its own (without the rest of leo); >> - try to install an earlier version of PyQt6, if you can figure out which >> ones are available; >> - try installing PyQt5 instead of PyQt6 (Leo can use either one); >> - install python 3.9 and see whether PyQt6 or PyQt5 will install without >> errors. > > > Sounds like good advice. Thanks. > sure, i will try them all. > 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/CAMF8tS31%2BTiJRNNZzxJk1EDQKeXEKfMMdXY2ssAGbnF1BNSqRA%40mail.gmail.com. -- life is pathetic, go Pythonic. 人生苦短, Python当歌 ;-) 课: https://py.101.camp/ 怼: https://du.101.camp/ 俺: http://zoomquiet.io 许: http://creativecommons.org/licenses/by-sa/2.5/cn/ 怒: 冗余不做,日子甭过!备份不做,十恶不赦. KM keep growing environment culture which promoting organization learning ;-) -- 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/CAAFijRfJrtC1Ap4bh%3Db%3DTHiuqSd72O7LusFmxyPWgTeD4w5k0w%40mail.gmail.com.
Re: Specific command behavior : goto-first/last-visible-node
Thanks for those clarifications Edward,
I totally see why, and agree, that the contraction performed is useful and
mostly desired, when going from a find-match to the next, etc. and the
other commands that are fine-tuned and handled by the boolean settings you
mentioned also make total sense for me.
On the other hand, the gotofirstvisible and gotolastvisible absolutely felt
unintuitive as navigation commands when I was using them. It felt as if the
simple up/down or page/up page down suddenly collapsed all nodes. ...It
felt as if i accidentally pressed [alt + - ] (contract all)... I would have
bet money that it was a bug if asked to!!
Anyways... I got tons more reasons to argue that for those 2 commands, the
tree state should not change... but lets not waste time: I'd be more than
happy to take a couple minutes to implement your change suggestion :)
I'll open the issue and branch off devel to make a pull request shortly.
Heh! It's nice to contribute something other than some server feature for
once!
--
Félix
On Friday, May 6, 2022 at 10:39:31 AM UTC-4 Edward K. Ream wrote:
> On Friday, May 6, 2022 at 12:03:55 AM UTC-5 Félix wrote:
>
> To me it feels counter intuitive to have those two operations change the
>> collapsed state of nodes using *expandOnlyAncestorsOfNode*(p), as i feel
>> they should use *treeSelectHelper(p)* which doesn't change the collapsed
>> states of nodes from what i understand (i may be wrong)
>
>
>> And so basically I'm kind of wondering if those commands have a reason
>> for contracting all the rest of the tree when going to the first/last
>> visible node...?
>
>
> Good questions :-) This is a surprisingly complicated topic. At least the
> following settings (in the `Tree Operation` part of leoSettings.leo) relate
> to this discussion:
>
> @bool collapse-nodes-after-move = True
> @bool collapse-nodes-during-finds = True
> @bool collapse-on-lt-arrow = True
> @bool sparse-move-outline-left = False
>
> These defaults are my strong preferences. I almost never want to see
> unnecessarily expanded nodes. Instead, I use clones to focus my attention
> on *one thing at a time.* Other people have their own preferences, which
> is why the above settings exist in the first place.
>
> Your comment suggests that maybe a new preference would be useful. The
> code involved is straightforward:
>
> @g.commander_command('goto-first-visible-node')
> def goToFirstVisibleNode(self, event=None):
> """Select the first visible node of the selected chapter or hoist."""
> c = self
> p = c.firstVisible()
> if p:
> c.expandOnlyAncestorsOfNode(p=p)
> c.redraw()
>
> The setting would determine whether c.expandOnlyAncestorsOfNode should be
> called.
>
> *Summary*
>
> Contracting non-ancestor nodes when going to the first or last visible
> node seems like a valid user preference. I'll be happy to consider a PR :-)
>
> 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/98129241-49ff-422c-936f-29c091513199n%40googlegroups.com.
