Re: Implementing goto-next-N-visible
The todo.py slowdown was not the only slowdown. For syntax highlighted nodes, there remains a (less severe) lack of visual updating when holding down the Up/Down arrow in the tree and additionally a significant lack up visual updates when holding down Ctrl-Up/Down in the body to move lines around. On Monday, June 8, 2015 at 7:21:43 PM UTC-4, Edward K. Ream wrote: On Sat, Jun 6, 2015 at 10:08 AM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com javascript: wrote: On Fri, 5 Jun 2015 11:01:13 -0500 'Terry Brown' via leo-editor leo-e...@googlegroups.com javascript: wrote: Well, I'm definitely seeing Todo.py related slow down, and will attempt to investigate that. Just pushed a fix for this. w.setStyle(/* */) was being called on every node, and is just too slow for that :-/ Now it's called on idle, which was tricky [snip] Thanks for this. Here is what I think I know about loading large text. 1. Syntax coloring: At present, the Python colorizer is enabled in leoColorizer.py. That is, python_qsh = True. This switch enables idle-time colorizing of the text, so the length of text shouldn't matter. 2. Waiting for large text to load. Qt has major issues with large text. This should not cause problems if the user doesn't try to change the text. The setting, @int max-pre-loaded-body-chars = 3, controls whether Leo will insert so-call large-text buttons for body text greater than the given value. (The value of 0 disables the feature). I doubt whether much more can be done to speed loading of large text. The normal workaround is to split large nodes. HTH. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
On Tue, Jun 9, 2015 at 5:07 AM, john lunzer lun...@gmail.com wrote: The todo.py slowdown was not the only slowdown. For syntax highlighted nodes, there remains a (less severe) lack of visual updating when holding down the Up/Down arrow in the tree and additionally a significant lack up visual updates when holding down Ctrl-Up/Down in the body to move lines around. I doubt much more can be done about this, except to reduce the size of nodes' body text. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
Alright, I'll add it to my long list of things to look into that I'm never actually going to have time for :) On Tuesday, June 9, 2015 at 10:05:22 AM UTC-4, Edward K. Ream wrote: On Tue, Jun 9, 2015 at 5:07 AM, john lunzer lun...@gmail.com javascript: wrote: The todo.py slowdown was not the only slowdown. For syntax highlighted nodes, there remains a (less severe) lack of visual updating when holding down the Up/Down arrow in the tree and additionally a significant lack up visual updates when holding down Ctrl-Up/Down in the body to move lines around. I doubt much more can be done about this, except to reduce the size of nodes' body text. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
On Tue, 9 Jun 2015 03:07:06 -0700 (PDT) john lunzer lun...@gmail.com wrote: The todo.py slowdown was not the only slowdown. For syntax highlighted nodes, there remains a (less severe) lack of visual updating when holding down the Up/Down arrow in the tree and additionally a significant lack up visual updates when holding down Ctrl-Up/Down in the body to move lines around. On Monday, June 8, 2015 at 7:21:43 PM UTC-4, Edward K. Ream wrote: On Sat, Jun 6, 2015 at 10:08 AM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com javascript: wrote: On Fri, 5 Jun 2015 11:01:13 -0500 'Terry Brown' via leo-editor leo-e...@googlegroups.com javascript: wrote: Well, I'm definitely seeing Todo.py related slow down, and will attempt to investigate that. Just pushed a fix for this. w.setStyle(/* */) was being called on every node, and is just too slow for that :-/ Now it's called on idle, which was tricky [snip] Thanks for this. Here is what I think I know about loading large text. Just a hit and run comment - w.setStyle(/* */) not a text coloring issue in this case, it's being called on the Todo widget / tab / pane thing, to set displayed dates to red when they've past and a tasks not done. Cheers -Terry 1. Syntax coloring: At present, the Python colorizer is enabled in leoColorizer.py. That is, python_qsh = True. This switch enables idle-time colorizing of the text, so the length of text shouldn't matter. 2. Waiting for large text to load. Qt has major issues with large text. This should not cause problems if the user doesn't try to change the text. The setting, @int max-pre-loaded-body-chars = 3, controls whether Leo will insert so-call large-text buttons for body text greater than the given value. (The value of 0 disables the feature). I doubt whether much more can be done to speed loading of large text. The normal workaround is to split large nodes. HTH. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
On Sat, Jun 6, 2015 at 10:08 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: On Fri, 5 Jun 2015 11:01:13 -0500 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: Well, I'm definitely seeing Todo.py related slow down, and will attempt to investigate that. Just pushed a fix for this. w.setStyle(/* */) was being called on every node, and is just too slow for that :-/ Now it's called on idle, which was tricky [snip] Thanks for this. Here is what I think I know about loading large text. 1. Syntax coloring: At present, the Python colorizer is enabled in leoColorizer.py. That is, python_qsh = True. This switch enables idle-time colorizing of the text, so the length of text shouldn't matter. 2. Waiting for large text to load. Qt has major issues with large text. This should not cause problems if the user doesn't try to change the text. The setting, @int max-pre-loaded-body-chars = 3, controls whether Leo will insert so-call large-text buttons for body text greater than the given value. (The value of 0 disables the feature). I doubt whether much more can be done to speed loading of large text. The normal workaround is to split large nodes. HTH. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
Terry, thanks for getting to this so quickly. It will be good to have Todo back. I'm more organized than I've ever been thanks to Leo and Todo! . On Saturday, June 6, 2015 at 11:08:18 AM UTC-4, Terry Brown wrote: On Fri, 5 Jun 2015 11:01:13 -0500 'Terry Brown' via leo-editor leo-e...@googlegroups.com javascript: wrote: Well, I'm definitely seeing Todo.py related slow down, and will attempt to investigate that. Just pushed a fix for this. w.setStyle(/* */) was being called on every node, and is just too slow for that :-/ Now it's called on idle, which was tricky because it needs to be true idle, not just the 0.5 sec(?) interval the idle hooks fires on. So it's only called when the node was entered 0.2 seconds ago. It seems Qt styles are not really up to the heavy lifting you can do with HTML browser CSS just by changing class(es). Cheers -Terry -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
On Fri, 5 Jun 2015 11:01:13 -0500 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: Well, I'm definitely seeing Todo.py related slow down, and will attempt to investigate that. Just pushed a fix for this. w.setStyle(/* */) was being called on every node, and is just too slow for that :-/ Now it's called on idle, which was tricky because it needs to be true idle, not just the 0.5 sec(?) interval the idle hooks fires on. So it's only called when the node was entered 0.2 seconds ago. It seems Qt styles are not really up to the heavy lifting you can do with HTML browser CSS just by changing class(es). Cheers -Terry -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
I've experienced the same annoying slow, non-updating tree movement with the up/down key navigation. I didn't think to look into the plugins. Lo and behold, removing the todo plugin fixes that problem for me too! There is only a barely noticeable visual lag remaining now (which may well be due to syntax highlighting, but I thought highlighting was delayed so that it didn't interfere). Thanks for the tip! Good to get this verified! I didn't know this shortcut existed; it will probably get used a lot from now on. I can confirm that this slow visual updating behaviour remains for me, even after removing the todo plugin. Also good to get this verified. From my tests for this one it didn't make a difference if it the todo plugin was enabled. However it does make a difference if the node is syntax highlighted. Even @language rest creates this slowdown. With no syntax highlight what-so-ever then the visual updating is smooth sailing. I think both of these could be considered a bug related to syntax highlighting (ie these are not desired behaviors), I think my previous suggestion of not performing syntax highlighting if holding down Up/Down in the tree or not updating syntax highlighting if holding down Ctrl+Up/Down in the body and waiting for a key release event might solve both of these issues. If we can't find a quick solution and it's because the speed of syntax highlighting is negatively impacting other parts of Leo then I think the speed of syntax highlighting needs to at least be considered an issue that should to be on Leo's roadmap. I would like to get peoples' thoughts. On Thursday, June 4, 2015 at 9:29:16 PM UTC-4, Peter Mills wrote: On Friday, May 29, 2015 at 9:02:32 PM UTC+10, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. I've experienced the same annoying slow, non-updating tree movement with the up/down key navigation. I didn't think to look into the plugins. Lo and behold, removing the todo plugin fixes that problem for me too! There is only a barely noticeable visual lag remaining now (which may well be due to syntax highlighting, but I thought highlighting was delayed so that it didn't interfere). Thanks for the tip! Leo 5.1-final, build 20150421110203, Tue Apr 21 11:02:03 CDT 2015 Python 2.7.6, PyQt version 4.8.4 Windows 8 AMD64 (build 6.2.9200) That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? I didn't know this shortcut existed; it will probably get used a lot from now on. I can confirm that this slow visual updating behaviour remains for me, even after removing the todo plugin. On Thursday, June 4, 2015 at 9:29:16 PM UTC-4, Peter Mills wrote: On Friday, May 29, 2015 at 9:02:32 PM UTC+10, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. I've experienced the same annoying slow, non-updating tree movement with the up/down key navigation. I didn't think to look into the plugins. Lo and behold, removing the todo plugin fixes that problem for me too! There is only a barely noticeable visual lag remaining now (which may well be due to syntax highlighting, but I thought highlighting was delayed so that it didn't interfere). Thanks for the tip! Leo 5.1-final, build 20150421110203, Tue Apr 21 11:02:03 CDT 2015 Python 2.7.6, PyQt version 4.8.4 Windows 8 AMD64 (build 6.2.9200) That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? I didn't know this shortcut existed; it will probably get used a lot from now on. I can confirm that this slow visual updating behaviour remains for me, even after removing the todo plugin. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit
Re: Implementing goto-next-N-visible
On Fri, 5 Jun 2015 04:34:07 -0700 (PDT) john lunzer lun...@gmail.com wrote: I've experienced the same annoying slow, non-updating tree movement with the up/down key navigation. I didn't think to look into the plugins. Lo and behold, removing the todo plugin fixes that problem for me too! There is only a barely noticeable visual lag remaining now (which may well be due to syntax highlighting, but I thought highlighting was delayed so that it didn't interfere). Thanks for the tip! Good to get this verified! I didn't know this shortcut existed; it will probably get used a lot from now on. I can confirm that this slow visual updating behaviour remains for me, even after removing the todo plugin. Also good to get this verified. From my tests for this one it didn't make a difference if it the todo plugin was enabled. However it does Well, I'm definitely seeing Todo.py related slow down, and will attempt to investigate that. Cheers -Terry make a difference if the node is syntax highlighted. Even @language rest creates this slowdown. With no syntax highlight what-so-ever then the visual updating is smooth sailing. I think both of these could be considered a bug related to syntax highlighting (ie these are not desired behaviors), I think my previous suggestion of not performing syntax highlighting if holding down Up/Down in the tree or not updating syntax highlighting if holding down Ctrl+Up/Down in the body and waiting for a key release event might solve both of these issues. If we can't find a quick solution and it's because the speed of syntax highlighting is negatively impacting other parts of Leo then I think the speed of syntax highlighting needs to at least be considered an issue that should to be on Leo's roadmap. I would like to get peoples' thoughts. On Thursday, June 4, 2015 at 9:29:16 PM UTC-4, Peter Mills wrote: On Friday, May 29, 2015 at 9:02:32 PM UTC+10, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. I've experienced the same annoying slow, non-updating tree movement with the up/down key navigation. I didn't think to look into the plugins. Lo and behold, removing the todo plugin fixes that problem for me too! There is only a barely noticeable visual lag remaining now (which may well be due to syntax highlighting, but I thought highlighting was delayed so that it didn't interfere). Thanks for the tip! Leo 5.1-final, build 20150421110203, Tue Apr 21 11:02:03 CDT 2015 Python 2.7.6, PyQt version 4.8.4 Windows 8 AMD64 (build 6.2.9200) That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? I didn't know this shortcut existed; it will probably get used a lot from now on. I can confirm that this slow visual updating behaviour remains for me, even after removing the todo plugin. On Thursday, June 4, 2015 at 9:29:16 PM UTC-4, Peter Mills wrote: On Friday, May 29, 2015 at 9:02:32 PM UTC+10, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. I've experienced the same annoying slow, non-updating tree movement with the up/down key navigation. I didn't think to look into the plugins. Lo and behold, removing the todo plugin fixes that problem for me too! There is only a barely noticeable visual lag remaining now (which may well be due to syntax highlighting, but I thought highlighting was delayed so that it didn't interfere). Thanks for the tip! Leo 5.1-final, build 20150421110203, Tue Apr 21 11:02:03 CDT 2015 Python 2.7.6, PyQt version 4.8.4 Windows 8 AMD64 (build 6.2.9200) That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? I didn't know this shortcut existed; it will probably get used a lot from now on. I can confirm that this slow visual updating behaviour remains for me, even after removing the todo plugin. -- 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
Re: Implementing goto-next-N-visible
On Friday, May 29, 2015 at 9:02:32 PM UTC+10, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. I've experienced the same annoying slow, non-updating tree movement with the up/down key navigation. I didn't think to look into the plugins. Lo and behold, removing the todo plugin fixes that problem for me too! There is only a barely noticeable visual lag remaining now (which may well be due to syntax highlighting, but I thought highlighting was delayed so that it didn't interfere). Thanks for the tip! Leo 5.1-final, build 20150421110203, Tue Apr 21 11:02:03 CDT 2015 Python 2.7.6, PyQt version 4.8.4 Windows 8 AMD64 (build 6.2.9200) That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? I didn't know this shortcut existed; it will probably get used a lot from now on. I can confirm that this slow visual updating behaviour remains for me, even after removing the todo plugin. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
It may not be enough to say that Leo has no control over it. As you say this is probably mostly able PyQt and there may be a workaround to whatever is going on. Additionally if I create my own PyQt app and add a QTreeView I can easily traverse up and down the list without issue, here is an example https://wiki.python.org/moin/PyQt/Creating%20a%20context%20menu%20for%20a%20tree%20view that will create a stand alone tree view. Anyways since I'm not sure I gave my full setup here is what Leo reports: Leo 5.1-final, build 20150430065234, Thu Apr 30 06:52:34 CDT 2015 Git repo info: branch = master, commit = 6325d1c54d1b Python 2.7.8, PyQt version 4.8.6 Windows 7 AMD64 (build 6.1.7601) SP1 On Thursday, May 28, 2015 at 4:41:02 PM UTC-4, Chris George wrote: There are many versions of Windows, and many different possible combinations of Qt, Python, etc. etc. Leo has no control over any of that. Funny how business always feels that tighter control on process leads to better results. Chris On Thu, May 28, 2015 at 1:18 PM, john lunzer lun...@gmail.com javascript: wrote: Would if I could! At work they make me use Windows, otherwise I would definitely be using Linux. Also as Edward pointed out he uses Windows and is not experiencing the problem, which is extra confusing for me. On Thursday, May 28, 2015 at 4:14:14 PM UTC-4, Chris George wrote: Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. 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+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com javascript:. To post to this group, send email to leo-e...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? On Friday, May 29, 2015 at 6:22:30 AM UTC-4, john lunzer wrote: It may not be enough to say that Leo has no control over it. As you say this is probably mostly able PyQt and there may be a workaround to whatever is going on. Additionally if I create my own PyQt app and add a QTreeView I can easily traverse up and down the list without issue, here is an example https://wiki.python.org/moin/PyQt/Creating%20a%20context%20menu%20for%20a%20tree%20view that will create a stand alone tree view. Anyways since I'm not sure I gave my full setup here is what Leo reports: Leo 5.1-final, build 20150430065234, Thu Apr 30 06:52:34 CDT 2015 Git repo info: branch = master, commit = 6325d1c54d1b Python 2.7.8, PyQt version 4.8.6 Windows 7 AMD64 (build 6.1.7601) SP1 On Thursday, May 28, 2015 at 4:41:02 PM UTC-4, Chris George wrote: There are many versions of Windows, and many different possible combinations of Qt, Python, etc. etc. Leo has no control over any of that. Funny how business always feels that tighter control on process leads to better results. Chris On Thu, May 28, 2015 at 1:18 PM, john lunzer lun...@gmail.com wrote: Would if I could! At work they make me use Windows, otherwise I would definitely be using Linux. Also as Edward pointed out he uses Windows and is not experiencing the problem, which is extra confusing for me. On Thursday, May 28, 2015 at 4:14:14 PM UTC-4, Chris George wrote: Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. 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+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
I use todo.py and experience no slowdown in scrolling at all. Chris On Friday, May 29, 2015 at 4:02:32 AM UTC-7, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? On Friday, May 29, 2015 at 6:22:30 AM UTC-4, john lunzer wrote: It may not be enough to say that Leo has no control over it. As you say this is probably mostly able PyQt and there may be a workaround to whatever is going on. Additionally if I create my own PyQt app and add a QTreeView I can easily traverse up and down the list without issue, here is an example https://wiki.python.org/moin/PyQt/Creating%20a%20context%20menu%20for%20a%20tree%20view that will create a stand alone tree view. Anyways since I'm not sure I gave my full setup here is what Leo reports: Leo 5.1-final, build 20150430065234, Thu Apr 30 06:52:34 CDT 2015 Git repo info: branch = master, commit = 6325d1c54d1b Python 2.7.8, PyQt version 4.8.6 Windows 7 AMD64 (build 6.1.7601) SP1 On Thursday, May 28, 2015 at 4:41:02 PM UTC-4, Chris George wrote: There are many versions of Windows, and many different possible combinations of Qt, Python, etc. etc. Leo has no control over any of that. Funny how business always feels that tighter control on process leads to better results. Chris On Thu, May 28, 2015 at 1:18 PM, john lunzer lun...@gmail.com wrote: Would if I could! At work they make me use Windows, otherwise I would definitely be using Linux. Also as Edward pointed out he uses Windows and is not experiencing the problem, which is extra confusing for me. On Thursday, May 28, 2015 at 4:14:14 PM UTC-4, Chris George wrote: Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. 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+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
I'm not sure what John's original issue was - I see slow down scrolling through nodes which all get syntax highlighting, I assume that's the issue. Cheers -Terry On May 29, 2015 2:39:17 PM EDT, Chris George technat...@gmail.com wrote: I use todo.py and experience no slowdown in scrolling at all. Chris On Friday, May 29, 2015 at 4:02:32 AM UTC-7, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? On Friday, May 29, 2015 at 6:22:30 AM UTC-4, john lunzer wrote: It may not be enough to say that Leo has no control over it. As you say this is probably mostly able PyQt and there may be a workaround to whatever is going on. Additionally if I create my own PyQt app and add a QTreeView I can easily traverse up and down the list without issue, here is an example https://wiki.python.org/moin/PyQt/Creating%20a%20context%20menu%20for%20a%20tree%20view that will create a stand alone tree view. Anyways since I'm not sure I gave my full setup here is what Leo reports: Leo 5.1-final, build 20150430065234, Thu Apr 30 06:52:34 CDT 2015 Git repo info: branch = master, commit = 6325d1c54d1b Python 2.7.8, PyQt version 4.8.6 Windows 7 AMD64 (build 6.1.7601) SP1 On Thursday, May 28, 2015 at 4:41:02 PM UTC-4, Chris George wrote: There are many versions of Windows, and many different possible combinations of Qt, Python, etc. etc. Leo has no control over any of that. Funny how business always feels that tighter control on process leads to better results. Chris On Thu, May 28, 2015 at 1:18 PM, john lunzer lun...@gmail.com wrote: Would if I could! At work they make me use Windows, otherwise I would definitely be using Linux. Also as Edward pointed out he uses Windows and is not experiencing the problem, which is extra confusing for me. On Thursday, May 28, 2015 at 4:14:14 PM UTC-4, Chris George wrote: Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. 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+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: Implementing goto-next-N-visible
I only ever write plain text or rst, so that may be it. Chris On Friday, May 29, 2015 at 12:54:44 PM UTC-7, john lunzer wrote: This is a major factor! Thank you Terry for at least bringing some sanity to what I've been seeing, not sure if there is a solution. Maybe there needs to be a check on syntax highlighting if the arrow keys are being held down or not. Even when I'm in an outline where the nodes all have no syntax highlighting my goto-next-N-visible is still a much faster keyboard navigation method. If it was built in and didn't have to use the full c.redraw then I'm sure it would be even nicer. But I should say again this does not affect the lack of visual updates when holding down Ctrl-Up or Ctrl-Down to move a line around. And like I said, I sure that is a completely separate issue. On Friday, May 29, 2015 at 3:40:20 PM UTC-4, Terry Brown wrote: I'm not sure what John's original issue was - I see slow down scrolling through nodes which all get syntax highlighting, I assume that's the issue. Cheers -Terry On May 29, 2015 2:39:17 PM EDT, Chris George techn...@gmail.com wrote: I use todo.py and experience no slowdown in scrolling at all. Chris On Friday, May 29, 2015 at 4:02:32 AM UTC-7, john lunzer wrote: I had a suspicion that a plugin could be causing the problem. Sure enough the todo.py plugin causes the significant lack of visual updates. Even with all plugins disable traversing the list using Up/Down-arrow is still a little choppy but much much better. It is only the todo.py plugin which causes the significant lag in visual updating in the tree, however. That said, there is still visual lag when holding down Ctrl+Up or Ctrl+Down in the body which moves a line of text. That may be a whole other bug/issue. Can somebody confirm if they're seeing this behavior? On Friday, May 29, 2015 at 6:22:30 AM UTC-4, john lunzer wrote: It may not be enough to say that Leo has no control over it. As you say this is probably mostly able PyQt and there may be a workaround to whatever is going on. Additionally if I create my own PyQt app and add a QTreeView I can easily traverse up and down the list without issue, here is an example https://wiki.python.org/moin/PyQt/Creating%20a%20context%20menu%20for%20a%20tree%20view that will create a stand alone tree view. Anyways since I'm not sure I gave my full setup here is what Leo reports: Leo 5.1-final, build 20150430065234, Thu Apr 30 06:52:34 CDT 2015 Git repo info: branch = master, commit = 6325d1c54d1b Python 2.7.8, PyQt version 4.8.6 Windows 7 AMD64 (build 6.1.7601) SP1 On Thursday, May 28, 2015 at 4:41:02 PM UTC-4, Chris George wrote: There are many versions of Windows, and many different possible combinations of Qt, Python, etc. etc. Leo has no control over any of that. Funny how business always feels that tighter control on process leads to better results. Chris On Thu, May 28, 2015 at 1:18 PM, john lunzer lun...@gmail.com wrote: Would if I could! At work they make me use Windows, otherwise I would definitely be using Linux. Also as Edward pointed out he uses Windows and is not experiencing the problem, which is extra confusing for me. On Thursday, May 28, 2015 at 4:14:14 PM UTC-4, Chris George wrote: Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this
Re: Implementing goto-next-N-visible
Yes, holding up/down-arrow is to slow moving through the outline, plus the bug I mentioned makes it even less appealing to use the keyboard for navigating large expanded outlines. With this function (and its 'prev' counterpart) the speed is tolerable. On Thursday, May 28, 2015 at 3:35:21 PM UTC-4, Terry Brown wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com javascript: wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
Would if I could! At work they make me use Windows, otherwise I would definitely be using Linux. Also as Edward pointed out he uses Windows and is not experiencing the problem, which is extra confusing for me. On Thursday, May 28, 2015 at 4:14:14 PM UTC-4, Chris George wrote: Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com javascript: wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com javascript: wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. 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+...@googlegroups.com javascript:. To post to this group, send email to leo-e...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
There are many versions of Windows, and many different possible combinations of Qt, Python, etc. etc. Leo has no control over any of that. Funny how business always feels that tighter control on process leads to better results. Chris On Thu, May 28, 2015 at 1:18 PM, john lunzer lun...@gmail.com wrote: Would if I could! At work they make me use Windows, otherwise I would definitely be using Linux. Also as Edward pointed out he uses Windows and is not experiencing the problem, which is extra confusing for me. On Thursday, May 28, 2015 at 4:14:14 PM UTC-4, Chris George wrote: Why not just switch operating systems instead of making accommodations? :-) Chris On Thu, May 28, 2015 at 12:35 PM, 'Terry Brown' via leo-editor leo-e...@googlegroups.com wrote: On Thu, 28 May 2015 12:26:05 -0700 (PDT) john lunzer lun...@gmail.com wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: You want this because holding up/down-arrow to move through the outline is too slow? I've noticed that too. Would you want 'else: break' in the if, just to save those valuable microseconds? Cheers -Terry @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. 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+...@googlegroups.com. To post to this group, send email to leo-e...@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
Also if it helps with the bug I've been experiencing. I also see the same behavior (of the GUI not updating) when I using Ctrl+Up or Ctrl+Down (which is the swap line command) when in the body. If I hold down this command it will visually update the first two swaps/moves but then will stop updating until I've let go of the keys and when Leo finally visually updates the line has moved much further down the body. So it's not isolated to the outline. On Thursday, May 28, 2015 at 3:26:05 PM UTC-4, john lunzer wrote: Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
Not as if anyone is actually interested but I implemented goto-next-N-visible in a much faster way: @language python N=5 def getVisNextN(n): current = c.p for ind in range(n): forward = current.getVisNext(c) if forward != None: current = forward return current NAhead = getVisNextN(N) c.setCurrentPosition(NAhead) c.redraw() I find this extremely useful (when bound to a key shortcut) for quickly navigating an outline when lots of nodes are expanded. Can be easily modified for goto-prev-N-visible. On Thursday, May 21, 2015 at 6:22:35 AM UTC-4, Edward K. Ream wrote: On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com javascript: wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
On Wed, May 20, 2015 at 11:40 AM, john lunzer lun...@gmail.com wrote: Thanks for the report. Edward what is your setup? Are you on windows or linux? Both. I do most of my work on Windows because the fonts are clearer and sharper on that machine. Soon after a commit I'll rerun all unit tests on the Linux machine. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
I do not see this behaviour at all. Smooth scrolling, as expected. Leo 5.1-final, build 20150520101731, Wed May 20 10:17:31 CDT 2015 Git repo info: branch = master, commit = 234e39c3251b Python 2.7.6, PyQt version 4.8.6 linux2 On Tuesday, May 19, 2015 at 8:09:56 AM UTC-7, john lunzer wrote: It doesn't appear to be a performance issue. It looks like something is happening programmatically because the behavior is the exact same every time regardless of outline size. Collapsing nodes automatically wouldn't really be compatible with my work flow. Not sure how to address this issue on my setup. It seems like I've had several graphical outline issues that others aren't having. On Tuesday, May 19, 2015 at 9:13:42 AM UTC-4, Edward K. Ream wrote: On Mon, May 11, 2015 at 2:35 PM, john lunzer lun...@gmail.com wrote: I find it slow to traverse outlines via keyboard for a couple reasons: There seems to be a bug/issue where if you hold down up or down in the outline the outline stops visually updating after it moves two nodes and then jumps to the new highlighted node which is way down (however long you were holding down). I don't see this behavior on. Do you have a lot of expanded nodes showing? If so, a workaround would be to collapse nodes automatically with the following settings: @bool collapse_on_lt_arrow = True @bool sparse_move_outline_left = True EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
Thanks for the report. Edward what is your setup? Are you on windows or linux? On Wednesday, May 20, 2015 at 12:30:30 PM UTC-4, Chris George wrote: I do not see this behaviour at all. Smooth scrolling, as expected. Leo 5.1-final, build 20150520101731, Wed May 20 10:17:31 CDT 2015 Git repo info: branch = master, commit = 234e39c3251b Python 2.7.6, PyQt version 4.8.6 linux2 On Tuesday, May 19, 2015 at 8:09:56 AM UTC-7, john lunzer wrote: It doesn't appear to be a performance issue. It looks like something is happening programmatically because the behavior is the exact same every time regardless of outline size. Collapsing nodes automatically wouldn't really be compatible with my work flow. Not sure how to address this issue on my setup. It seems like I've had several graphical outline issues that others aren't having. On Tuesday, May 19, 2015 at 9:13:42 AM UTC-4, Edward K. Ream wrote: On Mon, May 11, 2015 at 2:35 PM, john lunzer lun...@gmail.com wrote: I find it slow to traverse outlines via keyboard for a couple reasons: There seems to be a bug/issue where if you hold down up or down in the outline the outline stops visually updating after it moves two nodes and then jumps to the new highlighted node which is way down (however long you were holding down). I don't see this behavior on. Do you have a lot of expanded nodes showing? If so, a workaround would be to collapse nodes automatically with the following settings: @bool collapse_on_lt_arrow = True @bool sparse_move_outline_left = True EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Implementing goto-next-N-visible
On Mon, May 11, 2015 at 2:35 PM, john lunzer lun...@gmail.com wrote: I find it slow to traverse outlines via keyboard for a couple reasons: There seems to be a bug/issue where if you hold down up or down in the outline the outline stops visually updating after it moves two nodes and then jumps to the new highlighted node which is way down (however long you were holding down). I don't see this behavior on. Do you have a lot of expanded nodes showing? If so, a workaround would be to collapse nodes automatically with the following settings: @bool collapse_on_lt_arrow = True @bool sparse_move_outline_left = True EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
