Line length in nested nodes

When writing Python code in the body pane, I see the cursor position
so I can watch the line length to not exceed a certain value. However,
when a line gets written into a derived file, its length may increase
(due to indentation) and pylint complains about long lines. This is a
situation I'd like to avoid. Any suggestions?

I must admit I lack knowledge to implement this (I've got no
experience with Python GUI programming at all). Would this feature
appear in the next leo release?

> p.fileLevel() is p.level() - root.level() ...

I am still returning from time to time to this subject and trying to
get a clear view. I understand p.fileLevel() as a getter for some
instance variable, let's call it p.fileLevel. The question that popped
up today after diving into the souces of leo is: why one shall
associate fileLevel with a position, not with a vnode directly (to be
more exact, with that v, that is passed to p.__init__() and becomes
p.v)?

I think I'm getting some progress with this.
Unfortunately my current bzr knowledge is restricted to retrieving a
certain leo branch from launchpad, so creating a launchpad account and
registering my own branch is out of question for the near future.
Would you guys mind if I post a small patch here so we could discuss
it?

Heh, no :-)

The body pane scrollbar issue was settled here.
http://groups.google.com/group/leo-editor/browse_thread/thread/aaa852a616c12569
It was the matter of a setting.

I've been trying to implement the feature discussed in the first two
posts of this thread.

I'd like to point from the start that thinking about fileLevel as
being a multiple of c.tab_width is wrong. Ok, it is true for derived
files that contain Python code, but that's because Python is very
strict about indentation. For other languages (like C), another
approach is needed.
I would like to think that my algorithm is good, because it walks the
outline branch only once, from c.currentPosition() up to min (root, a
derived file node). But feel free to criticize or improve it.
A special note: I do admit that some of the variable names are kinda
ugly and long. Feel free to refactor the code to make it "leo-style"
in terms of variable names.
I would also like to point that I've made modifications only to the
tkinter gui. If this will go into the trunk, please don't forget to
modify other GUI classes (GTK and Swing IIRC).

This patch was made against r664:

--- cut here ---
diff -Naur /tmp/5/leo-editor-r664/leo/core/leoNodes.py /tmp/leo/leo-
editor-r664-mod/leo/core/leoNodes.py
--- /tmp/5/leo-editor-r664/leo/core/leoNodes.py 2008-07-15
09:23:05.000000000 +0000
+++ /tmp/leo/leo-editor-r664-mod/leo/core/leoNodes.py 2008-07-15
09:51:34.000000000 +0000
@@ -1007,6 +1007,8 @@
g.app.positions += 1

# if g.app.tracePositions and trace: g.trace(g.callers())
+
+ self.flevel = None # see self.fileLevel()
#@-node:ekr.20080416161551.190: p.__init__
#@+node:ekr.20080416161551.186:p.__cmp__, equal and isEqual
def __cmp__(self,p2):
@@ -1391,6 +1393,46 @@

simpleLevel = level
#@-node:ekr.20080416161551.197:p.level & simpleLevel
+ #@+node:shadow.20080715122537.2:p.fileLevel
+ def fileLevel(self):
+
+ '''
+ See http://tinyurl.com/5nescw for details
+ '''
+
+ p = self
+
+ if p.flevel is not None:
+ return p.flevel
+
+ p.flevel = 0
+ is_file = False
+ for cursor in p.self_and_parents_iter():
+ cursor_is_section = False
+ cursor_headString = cursor.headString()
+ if cursor_headString.startswith('<<'):
+ cursor_is_section = True # section node
+ parent = cursor.parent()
+ if parent == None:
+ break
+ parent_bodyString = parent.bodyString()
+ if parent_bodyString == '': # organizer node
+ continue
+ parent_lines = parent_bodyString.split('\n')
+ for line in parent_lines:
+ if cursor_is_section == True:
+ pos = line.find(cursor_headString)
+ else:
+ pos = line.find('@others')
+ if pos > 0:
+ break
+ if pos > 0:
+ p.flevel += pos
+ if parent.v.isAnyAtFileNode(): # do not scan upper
+ break
+
+ return p.flevel
+ #@-node:shadow.20080715122537.2:p.fileLevel
#@-node:ekr.20040306212636:p.Getters
#@+node:ekr.20040305222924:p.Setters
#@+node:ekr.20040306220634:p.Vnode proxies
diff -Naur /tmp/5/leo-editor-r664/leo/core/leoTkinterFrame.py /tmp/leo/
leo-editor-r664-mod/leo/core/leoTkinterFrame.py
--- /tmp/5/leo-editor-r664/leo/core/leoTkinterFrame.py 2008-07-15
09:23:06.000000000 +0000
+++ /tmp/leo/leo-editor-r664-mod/leo/core/leoTkinterFrame.py
2008-07-15 09:32:19.000000000 +0000
@@ -974,7 +974,7 @@
# self.log.colorTags.append("black")
self.parentFrame = parentFrame
self.statusFrame = Tk.Frame(parentFrame,bd=2)
- text = "line 0, col 0"
+ text = "line 0, col 0, fcol = 0"
width = len(text) + 4
self.labelWidget =
Tk.Label(self.statusFrame,text=text,width=width,anchor="w")
self.labelWidget.pack(side="left",padx=1)
@@ -1111,9 +1111,10 @@
s2 = s[index-col:index]
s2 = g.toUnicode(s2,g.app.tkEncoding)
col = g.computeWidth (s2,c.tab_width)
+ fcol = col + c.currentPosition().fileLevel()

# Important: this does not change the focus because
labels never get focus.
- self.labelWidget.configure(text="line %d, col %d" %
(row,col))
+ self.labelWidget.configure(text="line %d, col %d, fcol
%d" % (row,col,fcol))
self.lastRow = row
self.lastCol = col
#@-node:ekr.20031218072017.1733:update (statusLine)
--- cut here ---

Edward, in your initial reply you actually introduced fileLevel by
describing the algorithm of its computation. The implementation of
p.level() doesn't contain a docstring. The "and" between a class
instance and an integer is a bit confusing, but seeing len(p.stack)
there, I can conclude that p.level() shows how "deep" a node is placed
in the outline. And p.fileLevel() must show how "deep" a node is
placed in a derived file subtree. Could you please comment this before
we go further? If this is correct, then the problem with my method is
that it has a wrong name, because it calculates the offset of the text
contained in a node in the derived file this node belongs to.

This idea is absolutely different.
However, I think it is more exact to say not "I want to be able to
detect overly-long lines when a file subtree gets written into a
derived file", but "I want to be able to watch the line length
(interactively, as I type), and this line length shall be relative to
the derived file it gets written to, not to the node it belongs".
Speaking in terms of leo GUI, "col" is the cursor position in the body
panel (relative to the current node), we introduce "fcol" as in "file
col", that is relative to the flat derived file this node gets written
to.
So writing the whole file, even to a string, every time when the
cursor position in the body panel changes (please correct me if I'm
getting your idea wrong) is a waste of time.
To explain my approach, I will introduce a new definition. I would
call "text offset" the offset of p.v.bodyString() when it gets written
to the derived file. Of course this definition is valid only for nodes
from @file (and other) subtrees. This "text offset" will be calculated
by my method of the position class. Let's call it p.textOffset()

A couple of examples:

1. Suppose we have the following structure:

@file myfile.txt

the "text offset" of p.v.bodyString() is 0.

2. Suppose we have the following structure

- @file myfile.txt
- << mysection >>

the content of p.v.bodyString() for the root node is:

--- cut here ---

this is some text
<< mysection >>
--- cut here ---

The "<< mysection >>" string is preceded by 4 spaces. The "text
offset" of the << mysection >> node is 4. When typing text into the <<
mysection >> body, I will get:

line: 0, col: 0, fcol: 4 # initially
line: 0, col: 1, fcol: 5 # pressed a key, added a char, cursor has
moved one position
line: 0, col: 2, fcol: 6 # repeated previous step

This example illustrates an important fact: when a node gets focus,
p.textOffset() remains a constant for the period I type text in the
body panel and fcol = col + p.textOffset(). So, it is enough to
compute it only once, when the position is created.

Now, we have the following situation. We have a position. We want to
find out its "text offset". I will examminate only the trivial cases.

1.

- @file myfile

p.textOffset() is 0

2.

- @file myfile
- mynode

What is the offset of mynode if this is an organizer node (contains
some children, it's bodyString is empty)?
p.textOffset() is 0, just because the bodyString is empty.

3.

- @file myfile
- << mysection >>

the content of p.v.bodyString() for the root node is:

--- cut here ---

this is some text
<< mysection >>
--- cut here ---

The "<< mysection >>" string is preceded by 4 spaces. This example was
explained above.
p.textOffset() is 4 for the "<< mysection >>" node

4.

- @file myfile
- mynode

the content of p.v.bodyString() for the root node is:

--- cut here ---

this is some text
@others
--- cut here ---

The "@others" string is preceded by 8 spaces.
p.textOffset() is 8 for the "mynode node"

That's all. We notice that the "text offset" property is cumulative.
This means that if we have a 3-level hierarchy:

- @file myfile
- << mysection >>
- mynode

then we first treat "<< mysection >>" as root and find the "text
offset" of "mynode" that is relative to "<< mysection >>", then we
threat "@file myfile" as root and find the "text offset" of "<<
mysecton >>" that is relative to "@file myfile". Then the "text
offset" of "mynode" relative to "@file myfile" will be the sum of the
previous two.

This is a brief description of my algorithm, I will now copy/paste
just the method from the patch here. I will rename it to textOffset()
and I will comment it. I've also noticed that the line "is_file =
False" is not needed, I'm checking for a @file node directly. I've
also moved a couple of lines down in the main loop.

Note:

In p.__init__(), the line:
shall be read as:

self.textOffset = None # see self.textOffset()

+ def textOffset(self):
+ # caching of p.textOffset
+ # as discussed above, we need to calculate it only once
+ if p.textOffset is not None:
+ return p.textOffset
+
+ p.textOffset = 0
+ # walk back from the current position
+ # we also need the parent, the "text offset" is relative
to it
+ parent = cursor.parent()
+ # root reached
+ # check out if the cursor node is a section
+ # find out the section in the bodyString of the
parent
+ # otherwise find the "@others" directive in the
bodyString of the parent
+ # break the iteration over lines if something is
found
+ p.textOffset += pos
+ return p.textOffset

As you can see, c.tab_width wasn't mentioned even once.

I'm not sure what do you mean.

This would be good if you consider the discussed feature useful.

Then please tell me what are the requirements for this to happen.
Would you take care to add the code to trunk yourself or there's
something else I shall do first?

Then this will have to wait for a while.
I will proceed to study the docs to get a view about how leo's unit
tests are working in general before creating an account at launchpad.
I also need to play with bzr for a while to gain some experience with
this VCS.
Meanwhile everyone is welcome to make comments and suggestions here.

I've just pushed the feature into the trunk. Please tell me if I did
something wrong (like overwriting something for example). I had to do
two merges because the trunk was modified right before I was going to
commit into it.

Will run the tests again right now. I've run the tests only after my
own changes, not after each merge.

I have added the line

"otl" : "vimoutline", #zpcspm 8/25/08 Vim's outline plugin

to

self.extra_extension_dict

in

Code-->
Core classes-->
@thin leoApp.py-->
app.__init__-->
<< define global data structures >> app

This didn't fix the failing test. I'm not even sure I did the right
thing.
I'm confused because my own changes didn't involve leo/core/leoApp.py
at all.
The merges I did before the push didn't report any conflicts. So I
fail to see the reason why this test is failing at all.

This is the traceback I'm seeing:

======================================================================
FAIL: @test languageForExtension

----------------------------------------------------------------------
Traceback (most recent call last):
File "/tmp/leo-editor/leo/core/leoTest.py", line 184, in runTest
execfile(scriptFile,d)
File "/tmp/leo-editor/leo/test/scriptFile.py", line 20, in <module>
assert g.os_path_exists(path), 'for ext=%s does not exist: %s' %
(ext,path)
AssertionError: for ext=otl does not exist: /tmp/leo-editor/leo/
core/../modes/vimoutline.py

I don't have a vimoutline.py file in leo/modes.
What should I do?

The vimoutline file type does not have a "mode file".
I don't think that is the problem.

The problem may be that autohotkey file type does have an entry in the
"extra_extension_dict" structure without a "mode file". It's been
there for a long time. I'm surprised the test hasn't failed months
ago.

An updated leoApp.py file with the "ahk" entry removed has been
committed to the trunk.

TL

@test languageForExtension

is still failing for me

I've run just this test, not all the tests from leoTest.py

$ bzr log -r -1..
------------------------------------------------------------
revno: 905
committer: TL <T...@TLTooLs.net>
branch nick: leo-editor
timestamp: Mon 2008-08-25 12:11:22 -0500
message:
ahk entry removed from the self.extra_extension_dict structure in
leoApp.py

> I don't have avimoutline.py file in leo/modes.
> What should I do?

I fixed this on the trunk on rev 909. I thought I sent a message to
this group telling how to fix it, but I don't see it. Oh well...

Edward

It was here, I've just forgot to mention it, sorry.
The test was passing before I pushed.


t$ bzr log -r 907..908
------------------------------------------------------------
revno: 908
committer: Edward K. Ream <edre...@gmail.com>
branch nick: trunk
timestamp: Tue 2008-08-26 08:50:11 -0500
message:
fixed failing unit test for otl language
------------------------------------------------------------
revno: 907
committer: Edward K. Ream <edre...@gmail.com>
branch nick: trunk
timestamp: Tue 2008-08-26 07:47:25 -0500
message:
commit after merge
------------------------------------------------------------
revno: 905.1.2
committer: zpcspm zpc...@gmail.com
branch nick: leo-current
timestamp: Tue 2008-08-26 09:41:03 +0300
message:
Fixed failng test @test batch mode
------------------------------------------------------------
revno: 905.1.1
committer: zpcspm zpc...@gmail.com
branch nick: leo-current
timestamp: Tue 2008-08-26 09:03:06 +0300
message:
Fixed failing test @test languageForExtension

Anyway, since you've revised it, I don't fear anymore that I made
anything wrong related to this failing test :)

However, this thread got a bit messed. Let's go back to the original
topic. Please update the site docs. You shall see a new screenshot
after that (which shows 3 numbers in the status area) and a new FAQ
entry (I've considered this to be the best place) which describes the
feature. Feel free to modify the docs if you will consider that the
feature is not explained well enough.

The link should be http://webpages.charter.net/edreamleo/FAQ.html#how-can-i-avoid-getting-long-lines-in-derived-files

I was browsing the source code and I've incidentally found that the
tests for p.textOffset() are not in the trunk. Perhaps they were lost
during a merge.

Relevant pointers:

------------------------------------------------------------
revno: 903
timestamp: Mon 2008-08-25 11:14:15 -0500
revno: 899.1.3
committer: zpcspm zpc...@gmail.com
branch nick: leo-fcol
timestamp: Mon 2008-08-25 17:53:37 +0300
message:
commit after merge

The following command shows that the tests disappeared here.

$ bzr diff leo/test/unitTest.leo -r 899.1.3..903

Done in rev 1164 of the trunk.

Edward