Incorrect text highlighted using Find commands

84 views
Skip to first unread message

lewis

unread,
Aug 29, 2014, 7:31:25 PM8/29/14
to leo-e...@googlegroups.com
Hi Edward,

Open LeoDocs.leo
search for 'sphinx'
 Find Next: F3
 it highlights sphinx correctly however when it reaches node
LeoDocs.leo#Web pages-->@edit html\conf.py
at line 5:
   # sphinx-quickstart on Mon Mar 30 16:39:02 2009.
find now highlights the 'inx-qu'
and at line 27:
   # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
find now highlights 'names ' '.*') o' and 'stom o'

Using mouse or keyboard for F3 or F2 the same result occurs.


Leo Log Window
Leo 4.11 final, build 20140829164717, Fri Aug 29 16:47:17 CDT 2014
Git repo info: branch = master, commit = 77a33f784fa6
Python 3.4.1, PyQt version 4.8.6
Windows 7 AMD64 (build 6.1.7601) SP1

    Please report *any* new behavior in Leo immediately.  It is especially important that you do so now.
I haven't confirmed if this problem occurs with previous rev 7151b2dd6469 but I'll check for you now.


Regards
Lewis

lewis

unread,
Aug 29, 2014, 7:54:44 PM8/29/14
to leo-e...@googlegroups.com
I confirmed the highlighting problem also happens with build 7151b2dd6469

I tried a different search term. Open LeoDocs.leo
search for 'matching'
 Find Next: F3
 it highlights matching and then at node
LeoDocs.leo#Leo's Documentation-->Release notes-->@file release_notes.txt-->Previous versions...-->4.1... gnx's-->4.1 rc4-->New features in 4.1 rc4-->Simplified operation of script-find/change & improved documentation--> Script Find and Script Change

this traceback occurs:
hook failed: select3, <bound method todoController.updateUI of <leo.plugins.todo.todoController object at 0x0000000008137358>>, leo.plugins.todoTraceback (most recent call last):


Traceback (most recent call last):  File "C:\Python34\Lib\site-packages\leo-editor\leo\core\leoPlugins.py", line 357, in callTagHandler
    result = handler(tag,keywords)


  File "C:\Python34\Lib\site-packages\leo-editor\leo\core\leoPlugins.py", line 357, in callTagHandler
    result = handler(tag,keywords)  File "C:\Python34\Lib\site-packages\leo-editor\leo\plugins\todo.py", line 1173, in updateUI
    self.ui.UI.createdTxt.setText(created.strftime("%d %b %y?"))


  File "C:\Python34\Lib\site-packages\leo-editor\leo\plugins\todo.py", line 1173, in updateUI
    self.ui.UI.createdTxt.setText(created.strftime("%d %b %y?"))ValueError: format %y requires year >= 1900 on Windows


ValueError: format %y requires year >= 1900 on Windows

Regards
Lewis

lewis

unread,
Aug 29, 2014, 9:29:47 PM8/29/14
to leo-e...@googlegroups.com
The same highlighting behaviour occurs if I use the Nav tab.
Maybe LeoDocs.leo is a strange document; it's @edit html\conf.py node doesn't like being interrogated :)

Lewis 

Fidel N

unread,
Aug 30, 2014, 3:03:35 AM8/30/14
to leo-e...@googlegroups.com
I found that to happen after you edited text in one node. Then,in its clones (or any other matches after that one), you will find the selection wrong, matching the "previous position" of the erased text.


--
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.

lewis

unread,
Aug 31, 2014, 7:33:35 AM8/31/14
to leo-e...@googlegroups.com
This issue may have been around for a while.
It also occurs with an older build:
 Leo Log Window
 Leo 4.11 final, build 4dddc3320dbb (branch: master), 2014-08-09 11:01:35
 Python 3.4.1, PyQt version 4.8.6
 Windows Vista x86 (build 6.0.6002) SP2

Lewis

Zoltan Benedek

unread,
Sep 1, 2014, 1:22:46 PM9/1/14
to leo-e...@googlegroups.com
Hi,

I went through the mentioned steps, it seems the problem depends on system-environment.
I cannot confirm the problem.
On my system 'find' works correctly.

My system: Kubuntu 14.04, Python 2.7.6, PyQt version 4.8.6
Leo commit = d5f6141efe89

Regards

lewis

unread,
Sep 2, 2014, 8:14:33 AM9/2/14
to leo-e...@googlegroups.com
I changed the python version to 2.7.8 on the x86 machine. 
Search for 'matching' gives a slightly different traceback

Leo Log Window
Leo 4.11 final, build 4dddc3320dbb (branch: master), 2014-08-09 11:01:35
Python 2.7.8, PyQt version 4.8.6
Windows Vista x86 (build 6.0.6002) SP2
reading: C:\Python27\Lib\site-packages\leo-editor\leo\doc\LeoDocs.leo
reading: @edit conf.py
reading: @edit leo_toc.html.txt
...
hook failed: select3, <bound method todoController.updateUI of <leo.plugins.todo.todoController instance at 0x05719F58>>, leo.plugins.todoTraceback (most recent call last):


Traceback (most recent call last):  File "C:\Python27\Lib\site-packages\leo-editor\leo\core\leoPlugins.py", line 357, in callTagHandler
    result = handler(tag,keywords)


  File "C:\Python27\Lib\site-packages\leo-editor\leo\core\leoPlugins.py", line 357, in callTagHandler
    result = handler(tag,keywords)  File "C:\Python27\Lib\site-packages\leo-editor\leo\plugins\todo.py", line 1173, in updateUI
    self.ui.UI.createdTxt.setText(created.strftime("%d %b %y?"))


  File "C:\Python27\Lib\site-packages\leo-editor\leo\plugins\todo.py", line 1173, in updateUI
    self.ui.UI.createdTxt.setText(created.strftime("%d %b %y?"))ValueError: year=1106 is before 1900; the datetime strftime() methods require year >= 1900


ValueError: year=1106 is before 1900; the datetime strftime() methods require year >= 1900
[end]

The todo.py plugin appears to be the the problem. When I disable todo.py there is no traceback error.
 
Regards
Lewis

Edward K. Ream

unread,
Sep 2, 2014, 9:09:12 AM9/2/14
to leo-editor
On Tue, Sep 2, 2014 at 7:14 AM, lewis <lewi...@operamail.com> wrote:
> I changed the python version to 2.7.8 on the x86 machine.
> Search for 'matching' gives a slightly different traceback

Thanks for this report. Terry is on vacation this week. I'll see if
I can fix this problem asap.

Edward

lewis

unread,
Sep 11, 2014, 10:15:40 PM9/11/14
to leo-e...@googlegroups.com
Hi Edward,

Terry has fixed the todo.py issue..
The original query remains on the latest commit 3b3cc8bfc629.

Open LeoDocs.leo
search for 'sphinx'
 Find Next: F3
 it highlights sphinx correctly however when it reaches node
LeoDocs.leo#Web pages-->@edit html\conf.py
at line 5:
   # sphinx-quickstart on Mon Mar 30 16:39:02 2009.
find now highlights the 'inx-qu'
and at line 27:
   # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
find now highlights 'names ' '.*') o' and 'stom o'

Using mouse or keyboard for F3 or F2 the same result occurs.


The problem is particular to LeoDocs.leo >@edit html\conf.py node.

Regards
Lewis

Edward K. Ream

unread,
Sep 17, 2014, 11:51:53 AM9/17/14
to leo-e...@googlegroups.com
On Thursday, September 11, 2014 9:15:40 PM UTC-5, lewis wrote:

Open LeoDocs.leo
search for 'sphinx'
 Find Next: F3
 it highlights sphinx correctly however when it reaches node
LeoDocs.leo#Web pages-->@edit html\conf.py
at line 5:
   # sphinx-quickstart on Mon Mar 30 16:39:02 2009.
find now highlights the 'inx-qu'

Fixed (I think) at  d8bfd2c

This another example of the wretched newline problem. @edit nodes preserve '\r' characters, and that messes up the counts in the find command.

I don't *think* this will cause problems on the Mac, which uses (sheesh) '\r' characters instead of '\n'.  But no guarantees...

Edward

Edward K. Ream

unread,
Sep 17, 2014, 7:08:25 PM9/17/14
to leo-e...@googlegroups.com


On Thursday, September 11, 2014 9:15:40 PM UTC-5, lewis wrote:
Hi Edward,

Terry has fixed the todo.py issue..
The original query remains on the latest commit 3b3cc8bfc629.

Open LeoDocs.leo
search for 'sphinx'
 Find Next: F3
 it highlights sphinx correctly however when it reaches node
LeoDocs.leo#Web pages-->@edit html\conf.py
at line 5:
   # sphinx-quickstart on Mon Mar 30 16:39:02 2009.
find now highlights the 'inx-qu'

Are you running on Windows?  Stripping '\r' worries me greatly on the Mac.

Edward

lewis

unread,
Sep 18, 2014, 5:16:19 AM9/18/14
to leo-e...@googlegroups.com
OK search now correctly highlights the correct text in the @edit html\conf.py node.
I went F3 all the way to the end and then F2 back up the tree. When it reaches the node Web pages-->TOC-->@edit html\leo_toc.html.txt
  line 4: .. sphinx-quickstart on Mon Mar 30 16:39:02 2009.
it logs a message: backwardsHelper bad index: i = 0, j = 965
and the node Web pages-->@edit html\conf.py
  line 137: # The name for this set of Sphinx documents.  If None, it defaults to
it logs a message: backwardsHelper bad index: i = 0, j = 8762

Yes I am running windows
Leo Log Window
Leo 4.11 final, build 20140917180028, Wed Sep 17 18:00:28 CDT 2014
Git repo info: branch = master, commit = f541849d6c09

Python 3.4.1, PyQt version 4.8.6
Windows 7 AMD64 (build 6.1.7601) SP1


Regards
Lewis

Edward K. Ream

unread,
Sep 18, 2014, 11:04:17 AM9/18/14
to leo-editor
On Thu, Sep 18, 2014 at 4:16 AM, lewis <lewi...@operamail.com> wrote:
> OK search now correctly highlights the correct text in the @edit
> html\conf.py node.

Thanks for this confirmation.

> I went F3 all the way to the end and then F2 back up the tree. When it
> reaches the node Web pages-->TOC-->@edit html\leo_toc.html.txt
> line 4: .. sphinx-quickstart on Mon Mar 30 16:39:02 2009.
> it logs a message: backwardsHelper bad index: i = 0, j = 965
> and the node Web pages-->@edit html\conf.py
> line 137: # The name for this set of Sphinx documents. If None, it
> defaults to
> it logs a message: backwardsHelper bad index: i = 0, j = 8762

I'll look at this today.

> Yes I am running windows

Ok. I'll make the previous hack a windows-only affair.

Edward

Edward K. Ream

unread,
Sep 18, 2014, 11:29:09 AM9/18/14
to leo-editor
On Thu, Sep 18, 2014 at 10:04 AM, Edward K. Ream
> On Thu, Sep 18, 2014 at 4:16 AM, lewis <lewi...@operamail.com> wrote:

>> it logs a message: backwardsHelper bad index: i = 0, j = 8762

Fixed at rev 9a42be0, Leo build: 20140918102605

Keep those reports coming ;-) This is the time to fix as many
problems as we can.

Edward
Reply all
Reply to author
Forward
0 new messages