Issue: @path @auto - strange behaviour (newbie - long post)
PMario
I did test leo some time ago, and decided to wait until the "new
layout" mechanism is sattled down. Now I downloaded leo version
(Leo 4.9.1 devel, build 4867, 2011-12-05 06:57:18 -0500) to try again.
The layout handling is OK, but I did encounter some strange behaviour
with @path and @auto directives.
General Info
==========
- leoSettings.leo activated plugins:
# default
contextmenu.py
leo_to_html.py
mod_scripting.py
nav_qt.py
quicksearch.py
stickynotes.py
todo.py
viewrendered.py
# I activated
active_path.py
attrib_edit.py
xml_edit.py
all other settings are default. There is no myLeoSettings.leo
===
OS: ubuntu 11.10
TestCase
========
A simplified testcase outline looks like this:
+ @path ~/tmp/
|
+- /tstLeo/
*- test.js
test.js file contains:
/* some comment */
var = "<< some text >>";
=====
When I doubleClick the test.js _the first time_ it says:
@verbatim is not a Leo directive: test declarations
undefined section: << some text >>
referenced from: test declarations
error: @auto did not import test.js perfectly
first mismatched line: 4 (original) = 4 (imported)
hook failed: icondclick1, <function <lambda> at 0x3a23848>,
leo.plugins.active_path
Traceback (most recent call last):
File "/path/to/leo/core/leoPlugins.py", line 336, in callTagHandler
result = handler(tag,keywords)
File "/path/to/leo/plugins/active_path.py", line 124, in <lambda>
g.registerHandler(event, lambda t,k: onSelect(t,k))
File "/path/to/leo/plugins/active_path.py", line 229, in onSelect
if sync_node_to_folder(c,pos,path):
File "/path/to/leo/plugins/active_path.py", line 322, in
sync_node_to_folder
openFile(c,parent,d)
File "/path/to/leo/plugins/active_path.py", line 398, in openFile
c.importCommands.createOutline(d,parent=parent,atAuto=True)
File "/path/to/leo/core/leoImport.py", line 888, in createOutline
func(s,p,atAuto=atAuto)
File "/path/to/leo/core/leoImport.py", line 1531, in
scanJavaScriptText
scanner.run(s,parent)
File "/path/to/leo/core/leoImport.py", line 3327, in run
ok = self.errors == 0 and self.check(s,parent)
File "/path/to/leo/core/leoImport.py", line 1838, in check
return self.checkTrialWrite()
File "/path/to/leo/core/leoImport.py", line 1927, in checkTrialWrite
self.reportMismatch(lines1,lines2,bad_i1,bad_i2)
File "/path/to/leo/core/leoImport.py", line 2070, in reportMismatch
line = repr(lines2[i])
IndexError: list index out of range
======
I want to see, what's going on
I click the outline in no special order (see below)
* @path ~/tmp/
|
+- /tstLeo/ ... mouse click
+- test.js ... mouse click
it magically changes to this view:
* @path ~/tmp/
|
+- /tstLeo/
+- test.js
+- *test declarations*
test.js node contains:
@language javascript
@tabwidth -4
@others
-> OK
*test declarations* node contains:
/* comment */
@verbatim
var text1 = '<< some text >>';
which actually is the test.js file content. (except @verbatim) -> ???
=====
the log window doesn't show new information ...
=====
Save the file:
saved: workbook.leo
Closed the workbook.leo tab
=====
Open the file with: Menu: File: Recent: workbook.leo
I want to load test.js automatically, so I added @auto
* @path ~/tmp/
|
+- /tstLeo/
+- @auto test.js
+- *test declarations*
mouse right click: refresh from disk "@auto test.js"
log says:
@verbatim is not a Leo directive: test declarations
undefined section: << some text >>
referenced from: test declarations
error: @auto did not import @auto test.js perfectly
first mismatched line: 4 (original) = 4 (imported)
@verbatim is not a Leo directive: test declarations
undefined section: << some text >>
referenced from: test declarations
<Ctrl> Save
log says:
not written: /home/aaa/tmp/tstLeo/test.js
saved: workbook.leo
====
Added some comments "// test asdf" to node "test declarations"
content:
var text1 = '<< some text >>'; // test asdf
<Ctrl> Save -> OK
====
Close the workbook.leo tab
====
Having a look at the "real" directory structure it shows
/tstLeo
|
+- test.js
+- test.js.tmp
test.js content isn't changed -> OK
test.js.tmp contains no code just the comment -> ?????
====
Open file with: Menu: File: Recent: workbook.leo
outline says:
* @path ~/tmp/
|
+- /tstLeo/
+- @auto test.js
+- test declarations
+- test declarations
- the first "test declarations" contains the "leo node content"
- the second node contains the file test.js content.
- both are different. ?!?!
----
log says:
Leo Log Window
Leo 4.9.1 devel, build 4867, 2011-12-05 06:57:18 -0500
Python 2.7.2, qt version 4.7.3
linux2
reading: /home/aaaa/.leo/workbook.leo
reading: @auto test.js
@verbatim is not a Leo directive: test declarations
undefined section: << some text >>
referenced from: test declarations
@verbatim is not a Leo directive: test declarations
undefined section: << some text >>
referenced from: test declarations
error: @auto did not import @auto test.js perfectly
first mismatched line: 4 (original) = 4 (imported)
Original file...
2 u'*/\n'
3 u'\n'
4 u"var text1 = '<< some text >>';\n"
5 u'\n'
Imported file...
2 u'*/\n'
3 u'\n'
4 u'\n'
5 u'\n'
inserting @ignore
errors inhibited read @auto /home/aaa/tmp/tstLeo/test.js
=====
--- Test stopped ---
=====
As I wrote at the beginning, the above is a simplified testcase to
track down the "magic behaviour".
The first time I ran into this I did use a "real project" structure.
It took me hours to see the "inserting @ignore". message in the log
pane. I'm a _newbie_. I simply didn't see it ;) It took much time to
figure out, why I couldn't reproduce the strange behaviour again.
(Because @ignore, suppressed it)
It took me hours again (reading this group and the leo documentation)
to find out that:
var text1 = "<< some text >>";
can't be @auto imported/exported into a leo outline without troubles
or deep knowledge.
The point is:
- I can't beleve it. What am I missing?
help appreciated
-mario
Terry Brown
PMario <pmar...@gmail.com> wrote:
> The first time I ran into this I did use a "real project" structure.
> It took me hours to see the "inserting @ignore". message in the log
> pane. I'm a _newbie_. I simply didn't see it ;) It took much time to
> figure out, why I couldn't reproduce the strange behaviour again.
> (Because @ignore, suppressed it)
When you're more experienced with Leo you'll still be able to miss that
log message and spend a lot of time wondering what's going on :-}
This condition definitely needs more sirens and flashing lights.
Just to clarify - did you're original before Leo touched it .js file
include "<< something >>"?
<< sectioname >> has a special meaning in Leo, for which you might be
invoking unintentionally?
Cheers -Terry
PMario
> When you're more experienced with Leo you'll still be able to miss that
> log message and spend a lot of time wondering what's going on :-}
go".
> This condition definitely needs more sirens and flashing lights.
>
> Just to clarify - did you're original before Leo touched it .js file
> include "<< something >>"?
I'm not sure about this question?
my
var text1 = "<< some text >>"; is just a text1 variable that contains
the text "<< some text >>" that's it.
> << sectioname >> has a special meaning in Leo, for which you might be
> invoking unintentionally?
hmm .. unintentionally .. kind of.
Since someone else wrote the code, I just don't know, what comes up.
But I did know, what <<..>> means in leo. I just couldn't connect the
error messages, with the js code.
The "problem" here is, the project I want to work with, uses << ...>>
all over the places in js code, and even more in its documentation but
not for leo sections.
I did have a look at the leo source code and the "<<" ">>" parsers
seem to do the same :)) All hardcoded, which makes the dilemma
perfect.
The @verbatim would work as an escape mechanism, for may be 10 lines,
but not in every second line of documentation text.
thx for your attention.
-m
PMario
produce a valid (but ugly and errorprone) js file too.
+ @path ~/tmp/
+- /tstLeo/
+- @auto xx.js
+- xx declarations
+- << some text >>
====
a)
node: "@auto xx.js" contains:
@language javascript
@tabwidth -4
@others
====
b)
node "xx declarations" contains:
/* some comments */
var text1 = '<< some text >>';
====
c)
node "<< some text >>" contains:
<'+'< the text >>
===================================
The problem here is, that according to Murphy's law, case c) will
break.
So what if we use a @plain directive, that just inserts the node
header into the section.
eg:
+ @path ~/tmp/
+- /tstLeo/
+- @auto xx.js
+- xx declarations
+- @plain << some text >>
If the node "@plain << some text >>" body is empty,
- it inserts "<< some text >>"
If the node body is not empty, it inserts the plain node content,
without any further section replacement.
Would this be a doable escape mechanism?
What do you think?
I'm just brainstorming
- I didn't think about usability at the moment.
- I didn't think about a @shadow xx.js instead of @auto xx.js
- I didn't think about a "reload from file" for xx.js
have fun!
-mario
HansBKK
On Tuesday, December 13, 2011 2:57:04 AM UTC+7, PMario wrote:
The "problem" here is, the project I want to work with, uses << ...>>
all over the places in js code, and even more in its documentation but
not for leo sections.I did have a look at the leo source code and the "<<" ">>" parsers
seem to do the same :)) All hardcoded, which makes the dilemma
perfect.
http://webpages.charter.net/edreamleo/glossary.html#index-43
Important: Any line containing matched << and >> is a section reference, regardless of context. To use << and >> as ordinary characters, place them on separate lines.
PS are you TiddlyWiki PMario?
PMario
On Dec 13, 1:56 am, HansBKK <hans...@gmail.com> wrote:
> > *Important*: Any line containing matched << and >> is a section
> > reference, regardless of context. To use << and >> as ordinary characters,
> > place them on separate lines.
To document something, it would be sometimes possible to place open
and close section into different lines. But sometimes, it isn't.
> PS are you TiddlyWiki PMario?
yup
-m
Terry Brown
HansBKK <han...@gmail.com> wrote:
> > The "problem" here is, the project I want to work with, uses << ...>>
> > all over the places in js code, and even more in its documentation but
> > not for leo sections.
> >
> > I did have a look at the leo source code and the "<<" ">>" parsers
> > seem to do the same :)) All hardcoded, which makes the dilemma
> > perfect.
If there isn't already a way to disable any special treatment of << and
>> there should be, I wonder if Edward has this thread parked in his
to-read pile. Anyway, if it turns out there isn't, file a bug report
to make sure it gets added.
Also, "x = 2 << 16 / 2048 >> 2" is valid arithmetic in some languages.
Cheers -Terry
HansBKK
I realize this isn't helpful to those that require the normal ones within their content. . .
Nice to see you here PMario - one of my intended "target output formats" from Leo is TW, one reason for my ongoing advocacy for on-disk plaintext tiddlers. DokuWiki supports such an approach out of the box, and looks like a great way to enable community collaboration on creating/editing content. Anyway totally OT here, good to see "great minds think alike" <g>
PMario
> If there isn't already a way to disable any special treatment of
> << and>> there should be, I wonder if Edward has this thread parked in his
> to-read pile. Anyway, if it turns out there isn't, file a bug report
> to make sure it gets added.
>
> Also, "x = 2 << 16 / 2048 >> 2" is valid arithmetic in some languages.
I've seen a very clear statement [1] from Edward. It's from 2008 and
he says "more than 10 years ago (now 14) he decided not to deal with
escape mechanisms" ....
That's why I thought, "why not use the existing mechanisms" (see my
post about the @plain directive). I'm pretty sure all the "default"
stuff can handle it. May be a new plugin is needed but, that's it.
What do you think?
-m
[1] http://groups.google.com/group/leo-editor/msg/c3b96cbdf44d3ce6?hl=en
Edward K. Ream
> If there isn't already a way to disable any special treatment of << and
>>> there should be,
Use @asis or @nosent instead of @auto or @file.
> I wonder if Edward has this thread parked in his to-read pile.
Full bug-fixing mode means I save most discussions for later.
> Anyway, if it turns out there isn't, file a bug report to make sure it gets added.
I made a conscious decision, which I never regretted, not to support
any escape mechanism for << and >>. The problem is that escapes do
*not* appear explicitly in the external file. That's the whole
purpose of escapes! Thus, the read code must (somehow!) recreate
escapes in the *outline*.
But how to do this? We don't want to do AI in the read code.
Experience with earlier versions of Leo (15+ years ago) shows that
this greatly complicates the read code and makes it much more fragile.
So we want to represents escapes *explicitly* in the external file. Alas,
the only place for their representation would be in sentinels, but we
don't want to break lines for sentinels because that would cause other
problems.
In short, there is no good way to fix the problem directly.
It would be possible to use other delimiters for section references,
say <<< and >>>. This could be done by adding another argument field
to @+leo sentinel lines. A new directive would be required::
@ref-delims <<< >>>
This probably could work relatively cleanly, but it would be a
significant change to Leo.
Finally, a new setting would specify default section reference delims.
Edward
Edward K. Ream
> It would be possible to use other delimiters for section references,
say <<< and >>>.
On second thought, this look like an easily-fixed bug: Leo should
*not* honor section references when reading or writing @auto trees.
Thus, there should be no need for escapes or "overridden" delimiters
for section references.
I haven't verified that the bug exists, but if it does I'll mark it as
high priority and fix it along with the other high-priority bugs.
Edward
This could be done by adding another argument field
> to @+leo sentinel lines. A new directive would be required::
>
> @ref-delims <<< >>>
>
> This probably could work relatively cleanly, but it would be a
> significant change to Leo.
>
> Finally, a new setting would specify default section reference delims.
>
> Edward
--
------------------------------------------------------------------------------
Edward K. Ream email: edre...@gmail.com
Leo: http://webpages.charter.net/edreamleo/front.html
------------------------------------------------------------------------------
Edward K. Ream
> File "/path/to/leo/core/leoImport.py", line 2070, in reportMismatch
> line = repr(lines2[i])
> IndexError: list index out of range
I'll put this crash on the list to fix immediately.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> I haven't verified that the bug exists, but if it does I'll mark it as
> high priority and fix it along with the other high-priority bugs.
Just created https://bugs.launchpad.net/leo-editor/+bug/903818 on this.
Cheers -Terry
HansBKK
Use @asis or @nosent instead of @auto or @file.
It would be possible to use other delimiters for section references,
say <<< and >>>. This could be done by adding another argument field
to @+leo sentinel lines. A new directive would be required::
@ref-delims <<< >>>
This probably could work relatively cleanly, but it would be a
significant change to Leo.Finally, a new setting would specify default section reference delims.
These would be IMO most ideal - allow the user to choose delimiter characters either in mySettings or within the outlines
Given widespread support for extended character sets and unicode, it then becomes trivial (for the user) to select characters guaranteed not to conflict with the source content.
However if this will be a difficult to implement, and the issue hasn't been a significant problem for decades, then a quicker fix that handles most use cases would be worth further complicating the differences between the different @ <file> directives.
Terry Brown
HansBKK <han...@gmail.com> wrote:
> Given widespread support for extended character sets and unicode, it then
> becomes trivial (for the user) to select characters guaranteed not to
> conflict with the source content.
>
> However if this will be a difficult to implement, and the issue hasn't been
> a significant problem for decades, then a quicker fix that handles most use
> cases would be worth further complicating the differences between the
> different @ <file> directives.
The issue is not dynamically defining the delimiters, although that's
currently not supported. The issue is working out what the delimiters
in a derived file are, without embedding that information in the
derived file. Or breaking legacy derived files, which assume "<<",
">>".
So I think the simplest most bang for the buck solution now is to make
sure that Leo ignores the delimiters in @<file> types where they make
no sense. This is Edward's area of expertise:
Should ignore:
@auto
Can't ignore:
@file
@thin
I don't know:
@nosent
@shadow
@edit
@auto-rst
etc.
If most of the "I don't know" list ended up on the "Should ignore"
list, all would be well. Let's see where they go.
Cheers -Terry
PMario
I'd vote for this.
> So I think the simplest most bang for the buck solution now is to make
> sure that Leo ignores the delimiters in @<file> types where they make
> no sense. This is Edward's area of expertise:
>
> Should ignore:
> @auto
nope,
I didn't want to have leo ignore sections within @auto / @shadow
files, on it's own, without asking the user. I personally _do need_
sections in external files, that's why I'm evaluating leo. It's just a
problem, that sections markers interfere with the content.
I didn't test Edward's suggestions with @nosent and @asis yet. When I
did, I'll post again.
-m
Edward K. Ream
On Dec 13, 10:22 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 11:27 AM, PMario <pmari...@gmail.com> wrote:
> > File "/path/to/leo/core/leoImport.py", line 2070, in reportMismatch
> > line = repr(lines2[i])
> > IndexError: list index out of range
>
> I'll put this crash on the list to fix immediately.
Fixed on the trunk at rev 4873. All uni tests pass, including an
updated existing unit test.
Now *this* is the way unit testing is supposed to work. It was easy
to find the existing unit test, modify it slightly so it failed
initially. I then made a trivial change to the source code and
verified the change worked by running the updated unit test externally
without having to reload unitTest.leo. It took about a minute.
Edward
Edward K. Ream
> These would be IMO most ideal - allow the user to choose delimiter
> characters either in mySettings or within the outlines
>
> Given widespread support for extended character sets and unicode, it then
> becomes trivial (for the user) to select characters guaranteed not to
> conflict with the source content.
>
> However if this will be a difficult to implement, and the issue hasn't been
> a significant problem for decades, then a quicker fix that handles most use
> cases would be worth further complicating the differences between the
> different @ <file> directives.
When I awoke this morning I had ideas similar to yours.
A new directive, similar to @delims, and handled in about the same
way, will be easier to code and better for the user. There should be
no need for user settings: indeed: such settings could cause problems.
There *is* a place in the external file for the information, namely in
the sentinel line that represents the new directive, say::
@section-delims <<< >>>
The sentinel would be (for Python)::
#@@section-delims <<< >>>
To repeat, this will work like @delims, so that one could change
section delims many times in an external file. It's much safer than
@delims because the *comment* delims don't change, so no matter what
happens the result will always be a valid source file, in our example,
a valid Python file.
I plan to do this today. First, though, I'll disable section handling
entirely for @auto imports. It makes no sense to support section
references in @auto!
Edward
P.S. Leo used to support @noref, but here a new directive is better
than yet another @<file> type. So this is progress...
EKR
Terry Brown
Terry Brown <terry_...@yahoo.com> wrote:
> > The first time I ran into this I did use a "real project" structure.
> > It took me hours to see the "inserting @ignore". message in the log
> > pane. I'm a _newbie_. I simply didn't see it ;) It took much time to
> > figure out, why I couldn't reproduce the strange behaviour again.
> > (Because @ignore, suppressed it)
>
> When you're more experienced with Leo you'll still be able to miss that
> log message and spend a lot of time wondering what's going on :-}
This just got me again - in complex environments like web app. servers
it doesn't occur to you that the file isn't being saved, instead you
start looking to see if the javascript files are being grabbed from the
wrong place by the http server or something...
I think Leo needs to get seriously in your face every time you try to
save an outline with @ignore in and @<file>. Maybe we need an
@ignore-quietly for cases where it's intended.
Cheers -Terry
HansBKK
When I awoke this morning I had ideas similar to yours.
There *is* a place in the external file for the information, namely in
the sentinel line that represents the new directive, say:: @section-delims <<< >>>The sentinel would be (for Python)::
#@@section-delims <<< >>>
To repeat, this will work like @delims, so that one could change
section delims many times in an external file. It's much safer than
@delims because the *comment* delims don't change, so no matter what
happens the result will always be a valid source file, in our example,
a valid Python file.
8-)
Edward K. Ream
> This just got me again - in complex environments like web app. servers
> it doesn't occur to you that the file isn't being saved, instead you
> start looking to see if the javascript files are being grabbed from the
> wrong place by the http server or something...
>
> I think Leo needs to get seriously in your face every time you try to
> save an outline with @ignore in and @<file>. Maybe we need an
> @ignore-quietly for cases where it's intended.
You and Hans agree, and I am beginning to appreciate the problem more fully.
I don't like @ignore-quietly, but changing @<file> to @@<file> will do
the same thing, and moreover is visible just by looking at the
headline. And if you want to make it more visible, just use
@@@@<file> ;-)
In short, I am now willing, on an experimental basis, to have Leo put
up a dialog when inserting an @ignore, and also when writing an
@<file> node containing @ignore.
In the past, I have always found read/write dialogs to be a) intrusive
and b) panic-inducing, but this may be a tolerable exception. We
shall see.
Edward
Edward K. Ream
>> To repeat, this will work like @delims, so that one could change
>> section delims many times in an external file. It's much safer than
>> @delims because the *comment* delims don't change, so no matter what
>> happens the result will always be a valid source file, in our example,
>> a valid Python file.
>
> Of course that's the way to go - this is why you get paid the big bucks!
Right ;-) However, this doesn't have high priority now that @auto
ignores << and >>.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> In short, I am now willing, on an experimental basis, to have Leo put
> up a dialog when inserting an @ignore, and also when writing an
> @<file> node containing @ignore.
>
> In the past, I have always found read/write dialogs to be a) intrusive
> and b) panic-inducing, but this may be a tolerable exception. We
> shall see.
Excellent :-)