#@+leo-ver=5-thin
#@+node:ekr.20060207133601: * @file ../doc/leoToDoLater.txt
#@+all
#@+node:ekr.20060824110846: ** Colorizing
#@+node:ekr.20060813121814: *3* Add colorizer files for cweb, rapidq
#@+node:ekr.20060824103837: *4* Notes
@nocolor

Renamed pl-sql.* to plsql.* (This required rerunning jEdit2py.)

Forth is going to be a problem, because keywords can be extensible.
Perhaps the user should be responsible for updating forth.xml.
#@+node:ekr.20060227142119: ** Drawing, printing and rendering
#@+node:ekr.20060822162521: *3* Make headlines scroll
Limit the with of the headline to the width of the outline pane.
#@+node:ekr.20050512031131: *3* Use global_log_window_position to specify outline/log ratio?
#@+node:ekr.20060227123536: *3* Tiddlywiki and related comments about rendering body text
@nocolor
http://sourceforge.net/forum/message.php?msg_id=3578252
By: bwmulder

I have been thinking for a while that it ought to be possible to somehow  to
unite Leo with wiki features (my thinking is still vague at this point).

If you look at systems like Tiddlywiki (http://www.tiddlywiki.com/) you will
find that they already pretty much provide all the formatting features mentioned
in the article.

MoinMoin, another wiki (http://moinmoin.wikiwikiweb.de), has started to use
a graphical interface for editing in the latest version.

Maybe Leo can be split up into three components:

1. A storage component is responsible for storing nodes. Currently, this is
just memory, but databases like shelve, Zope or sqllite should also be possible.

2. The control component is responsible for converting from the internal format
to external files which can be processed by existing compilers, searching within
a document, and the like.

3. A display component is responsible for interfacing with the user. If can
be TK, but it can also be something like the Tiddlywiki interface, which immediately
shows the formatting applied to text.

I don't know much about javascript, so I would have to learn more about this
language before doing anything in this direction.

As an intermediate step, maybe we could allow mixing RST processing with regular
program text.  Leo would produce two documents out of a source file: a version
for the compiler in plain ascii, and an HTML file for reading the source.
#@+node:ekr.20050127110221: *3* Printing & flash
@killcolor
https://sourceforge.net/forum/message.php?msg_id=2962825
By: jasonic

-- pdf -- 
yes I know what you mean, PDF has it uses.  If nicely embedded into Leo via
'reportwriter'  and some export scripts {and clear useinterfance} would stillbe
a good thing.


As I start to think about how to print Leo, I become more aware of the differneces
between Leo structures and linear [print] layouts.

Different kinds of outlines obviously will need different kinds of printing.
I don't yet have enough experience or overview.

--xslt--
Seems a natural way to go for printing Leo, but yet another langauge and syntax
to wrassle with. Last time I looked I went from being horrified to very impressed
to be being exhausted.

--htmlize--
thanks I'll check into that

"print to web"  should definitely be on Leo's missing PRINT MENU.

--swf [flash]--
This printing topic pushes me harder to get FLC  [my FlashLeoClient project]
into the Leosphere.

Flash has*limited*  CSS handling, but enough to do some nice and useful typographic
formatting in a pretty clean object-oriented manner.

FLC parses .leo files into a Flash object. Flash Textformat instances are created
using CSS and can be applied then to rendering any parts of  the deserialized
Leo object.. The beauty is it can be very fast and ynamic so I can imagine a
real-time WYSIWYG laytou tool for printing Leo to web and at the same making
it suitable at the same time for print-to-paper.

Since FLC is in the very first instance a READ-ONLY client tool for Leo, it
makes it a natural Leo printing service.

To complete full service, it woudl be good if Leo could create SWF files directly
itself, just like using PDF reportwriter.
There are a couple of libraries to help this 
- Ming [with PHP, Perl, Python and Ruby wrappers]
http://ming.sourceforge.net/

- makeswf.r [interesting REBOL/Flash dialect by David Oldes]
http://sweb.cz/oliva.david/swf/

These could also be both configured as web-services.
So Leo print-to-web would include by default rendering a flash swf file versoin
of itself either using locally installed libraries or by passing a view of itself
to a chosen client or server-based tool.

But even without those extra 'services' and libraries a single flash file in
the form of FLC could become an effective Leo printing kit. Using a standalone
desktop  version [not embedded in the browser, out of the sandbox] much more
is possible - remote control, peer-peer editing, file writing etc.

-- flashpaper2--
btw, Lately I've been using Flashpaper2 a lot to print all kinds of stuff, Often
from web pages to my local adhoc home filebase. It's a very fast lighweight
alternative to PDF, saves paper, has excellent zooming and nice search features
built-in.
Flashpaper renders a very litteral snapshot, but as I am discovering that turns
out to be extremely useful.
For example you visit a page and click on some links. Flashpaper saves teh pages
exactly as it looks, viisted links disntinguished.  In the era of info-overload,
even that crude mnemonic is valuable.

Alas, Flashpaper2 is not free nor open in the way Leo is. But worth to play
with it if only for for the experience.
30 day trial downlaod from
http://www.macromedia.com/software/flashpaper/

And of course the flash _players_ is free, so can send people flashpaper documents
just like PDF.
Brilliant when you have a big Excel spreadsheet or CAD document which would
normally get all messy printing across pages, confusing people.
Instead adjust and print to a generous 'piece' of flashpaper - letting your
coleagues pan and zoom to their comfort.

I've not quite figured out the place where  Leo meets Flashpaper, because Leo
needs to preserve its full pane contents. Flashpaper works fine with long web
pages, automatically reading the full window contents and cutting into a paginated
sequence, ready for paper printing.
Leo's does not have aprint menu, so it's off the sytem's print-devices map,
which Flash paper appearing just  like any phtycial printer.

I imagine is possible to fix that in Leo, but I do not where to begin and woudl
not be surprised to learn its a major heachche to write adn debug for multiple
operating systems.

An immediate alternative are screencapture tools like vnc2swf or MDM Capture.

[vnc2swf uses Ming-0.2a]
http://www.unixuser.org/~euske/vnc2swf/

http://www.multidmedia.com/software/capture/index.php

But much is hidden or lost from view. 
Still very vauable for creating dynamic narrative tutorials [aka screencasting]

AS you know I am very excited about what flash can do for Leo, and vice versa.
But I am concerned that there is not yet a 100% Leo means which supports people's
standard print needs and habits.

-- PRINT MENU-- 
Leo deserves good friendly printing features which anyone can use. At the moment
we have a confusing patchwork of choices. Printing Leo seems to be both harder
and easier than  first meets the eye.

Having a little library of export scripts - well named, documented and intended
to aid printing woudl go a long way. Thesse scripts anyone coiuld be called
by onayone given a Leo Outline, accessing a navabr button. PRINT MENU or list.
Or they can just insert the appropriate script  into an outline giving finer
grained print control on the fly.
#@+node:EKR.20040512082621: *3* HTML widgets
#@+node:EKR.20040512082621.1: *4* htmllib.tcl
http://sourceforge.net/forum/message.php?msg_id=2565345
By: nobody

I just met a nice TCL-based html help viewer bundled with the evaluation version
of Fujitsu-Siemens OpenFT for Unix (see
fujitsu-siemens.com/products/software/openseas/openft.html)

It is based on a TCL library htmllib.tcl, written by Stephen Uhler in 1995 while
working in Sun's TCL group.Iit seemts that this lib is owned by Sun and i'm
not certain about license. It is freely downloadable, anyway.

The usage is really simple -- you have to create a text widget, a string variable
containing html text and a link callback, then feed all three to the library
routine. It should be not hard pythonize this process.

see http://www.usenix.org/publications/login/1999-8/features/tclsh.html,
ftp://ftp.scriptics.com/pub/tcl/misc/html_library-0.3.tar.gz
or just google for htmllib.tcl
#@+node:ekr.20031218072017.729: *4* HTML rendering in Leo's body pane
#@+node:ekr.20031218072017.731: *5* HTML plugin: opml
@nocolor
http://sourceforge.net/forum/message.php?msg_id=2283466
By: billp9619

FYI
I played around with opml a while back and it seemed very versatile.

It basically consists of an xml file of nested outline tags similiar to v-nodes
in leo xml. This then works with an xsl stylesheet that displays the outline
in a browser with scripted outline manipulation. (Uses div tags for this
display.)

What I discovered is that any html can make up the outline nodes , even forms,
etc. which collapse with the outline interaction. Just that the angle brackets
in the html must be escaped as is done within leo t nodes in .leo xml.

Actually, it would be interesting to see an addin that just passes leo nodes
to opml and then pops into the default browser. Also keep in mind that javascript
has an eval() statement that can be passed any script as a string. The leo text
box could be a form textarea box except that then there is no way to emulate
syntax coloring. Alternatively, this could be a floating window wrappiing node
text in html/body. (if nothing else, just destroy/close the window and reinitialize).
Maybe the images used in the opml could have javascript events like onclick()
to trigger refreshing leo text box from the t-nodes stored in an array or in
hidden form boxes.

Of course the effect of the stylesheet could be done via python script if no
xslt in the receiving browser. The minimal html and script might be just boilerplate
output.

regards,
bill p
#@+node:ekr.20041228092223: *3* Play with wiki markup
http://sourceforge.net/forum/message.php?msg_id=2205285
From: Rich

Color ''and'' italic/bold characters with @markup. One thing I'd like to
''not'' see are the markup characters in @file-nosent files.  "~~red:NOTE:~~"
does nothing for readability in plain text.
#@+node:ekr.20041201084142: *3* Add convenience methods to change individual headlines color directly
@killcolor

http://sourceforge.net/forum/message.php?msg_id=2877106

By: Paul Paterson - paulpaterson
RE: Can I color the headline text ?  
2004-12-01 08:01

The cleo plugin makes a permanent change to the headline appearance (using node attributes) while the footprints plugin makes a temporary change in the current session. Footprints was derived from cleo, although you might not be able to tell from looking at it! 

Cleo: http://sourceforge.net/forum/message.php?msg_id=2617221 

Footprints: http://sourceforge.net/forum/message.php?msg_id=2813450 

Between the two of them there should be enough information to help you achieve what you want. 

It is possible to do pretty much anything you want but you will have to provide the infrastructure yourself because Leo doesn't natively support it.  
#@+node:ekr.20041228091154: ** Commands
#@+node:ekr.20061021131443: *3* Emacs support
#@+node:ekr.20060628103226.3: *4* Make sure repeat counts work on basic editing commands
#@+node:ekr.20060628094329.2: *4* Test/Fix macros
#@+node:ekr.20060628103226.2: *4* Alt-x handlers should add to lossage
#@+node:ekr.20060123091352: *4* Incremental search in switch-to-buffer
#@+node:ekr.20060116090428: *4* Expand 'point' so it indicates node as well as text location
#@+node:ekr.20051021074728: *4* Space completion
#@+node:ekr.20051110155735.1: *3* Improve Spell tab
@nocolor

- Per-pane key bindings. (arrows, etc.)
- Try default fonts for spell buttons.
- Select the first entry.

@color
#@+node:ekr.20061006165447: *3* Let import commands decide what kind of import to do
@nocolor
http://sourceforge.net/forum/message.php?msg_id=3940843
By: ktenney

>the distiction between importing 'foreign' text files and importing derived
files created by Leo.

Couldn't Leo make this distinction by looking at
the file being imported? If so, I think it should.

This could eliminate a lot of confusion IMO, if
I want to bring a file into a node, just
'import' it, and the right thing happens.

An emergency measure could be available in a 
'File Special' menu.
#@+node:ekr.20041022083833.1: *3* Easy
#@+node:ekr.20040315060557: *4* Declone command
By: nobody ( Nobody/Anonymous ) 
 having a declone() method for vnodes?   
2004-03-15 04:36  

 hi,

Ive had a use for a declone() method in vnodes recently. Have you ever thought about adding a method that declones a clone? This would entail:

1. Making a clone node a normal node.

I can see this happening when cutting a node and pasting a node that is a clone. But there doesn't seem to be a dedicated function to do the operation. :)  
#@+node:ekr.20041219162724: *4* Add dialog to insert recent directories
http://sourceforge.net/forum/message.php?msg_id=2903742
By: nobody

In the multifile plugin there is an option to insert a directory string.  I
use it alot for the @path directive.  What happens is that when executed a FileDialog
opens up and the user selects the directory he wants to use as a directory string.
When chosen the directory string is inserted into the text editor.

The good of this:
1. It makes using path simpler, you dont have to type out the directory path
yourself, just use the tkFileDialog to select it and have Leo insert the string.
For long directories this saves a lot of typing.

simple, short and quite helpful.  Thoughts? :)

-----------

Time to create a directory class??

#@+node:ekr.20031218072017.800: *4* Improve extract section command
Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=1858824
By: gilshwartz
Open discusstion

Currently Extract Section is only available if the first line in a selection
is a section name <<x>>. I would like to propose a few enhancements I think
should be useful, while I believe most of the code is already implemented in
Leo.

1. If the first line in a selection is not <<x>>, than Extract Section WILL
make a section name from the first line (or a version of it, see below), leave
the section name in the body, create a new node with that section name, and
will copy the selection including the first line to the new node.

Rational: this is useful when selecting a function or a class. Thus the section
name becomes the function or the class definition. The section name can either
be the full first line, or, knowing the language, Leo can make a nice section
name like it does in import, e.g. "function foo", or "class bar", without the
parameters list.

2. Even better, when Extract Section is called WITHOUT a selection it will look
for the first function/class definition before the cursor's position and will
either use it as a selection and do 1 above, or just mark it as selection, which
will enable 1 above upon a second Extract Section.

Rational: Leo does it beautifully in import and when a node's code starts to
build it is most convenient. Also, I think a variation on this was recently
asked by another user.

3. Add an option Merge Section, which when called from a named section will
merge it back to all the sections containing it.

Rational: make it easy (together with 2) to create/delete sections until the
sections picture of a new code becomes clear.

Gil

--

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=1859516
By: nobody

Simpler & more intutive:
Mark text, select from menu - 'extract section', this presents a dialog box
in which you fill in the section name. It is too much work to type <<name>>
then select the whole thing...

As an enhancement, the dialog can show the first line of the selection as the
default section name, which obviously can be changed.

- Rajiv Bhagwat
#@+node:ekr.20041130123243: *4* Clear Undo command
@killcolor

http://sourceforge.net/forum/message.php?msg_id=2859273
e

theres a config option to clear undo on save.
can that be a menu choice as well? 
clear undo now.
enable clear undo on save.
moot as it will be with the new config options
and any undo changes on the table.
maybe there is a single point to involke clear 
undo that could be run from a button?

with py2.3 after allot of small edits on an open leo after a few hours gc can
hit unexpectedly and last several minutes
and return at any time lasting several more minutes.
I think its gc related because the memory use and disk grinding demanding I
free up memory or kill python.

I have no idea if undo is the cause,
 just guessing.
using cvs of last week. I just updated, 
will let you know if it happens again.
(new error reporting jump to error is great)

usually I don't edit in the same process that long.
I have run scripts from leo that run 6, 12 
or 24 hours no problem. 
maybe I can turn on some internals reporting and
get some feedback on whats going on from python if it happens again. 
or run the gc script before and after.

 win98 128meg w/maxmem memory defrager that works well.
but I go from 50% free to 10% when this starts happening.
I haven't noticed this problem yet in py2.4, and it is peppier,
but don't use py2.4 enough. it doesn't happen every day.
I reboot at least once a day for various reasons.
so it isn't that either. 
you do need to reboot and or exit python once it starts.
this was never an issue with py2.2 and Leo 4.1 or less with only 64 megs.
I don't really have any other long running python processes to compare to Leo. 
can't say what it is.
Aha, progress. 
this started sometime early in 4.2 or late 4.1
but I can still be persuaded something in my 
local system is to blame, some install or dll update. or script, psyco or plugin
related.

nonwithstanding, I should be taking better advantage Moore's law in my CPU and
memory.
I only notice this when I'm running the same leo over a few hours of constant
editing and running scrips.
and when I exit python and restart leo everything returns to normal.
more a supporting anomaly report 
than a bug report or feature request.
#@+node:ekr.20031218072017.790: *4* Import dialog improvements
@nocolor

Other options I though would be really handy:

1. Use an existing node as a source also

2. Use an node from another Leo file.. I am not sure what the syntax for that
would be exactly

3. From a URL.. this would be really cool. People could post outlines not only
as existing Leo xml files, but as text files or even dynamic scripts. The code
to handle these would presumably need to deal with http:// intelligently. But
that's easy in Python. Rebol is great at that too.

4. Other XML file with valid filepaths in them.
That's probably a much bigger project like Leo 3.10  

Jason
#@+node:ekr.20031218072017.807: *4* Put up file dialog on empty @url, etc.
@nocolor

Open Discussion
https://sourceforge.net/forum/message.php?msg_id=2003457
By: dsalomoni

Proposal: modify the code for @url so that if you type for example just "@url"
(no file specified) in a headline, a window pops up allowing you to browse the
local file system and select the file (similar to what browsers do when you
want to open a file).

This would be more convenient than manually writing @url
file://a/long/path/to/the/file. @read-only nodes already allow this, it would
perhaps be nice if all these types of plugins (@folder might be another one
for example) and directives (@file etc) had the same behavior (and this should
probably be specified in some guidelines for writing new plugins -see e.g. the
jedit plugin guidelines).

Davide
#@+node:ekr.20040217153407: *4* User customizeable tangling and untangling
@template plugin does some (most?) of this.
#@+node:ekr.20040329094003: *3* Apply patch command
#@+node:ekr.20031218072017.748: *3* Import/Export to yaml
Need a good yaml parser first: I don't want to write another parser by hand.
#@+node:ekr.20041016134312.2: *3* Standard Weave command
Use noweb and TeX, or maybe Pyx.
#@+node:ekr.20060227124411: *3* Import/export from wiki's
@nocolor
http://sourceforge.net/forum/message.php?msg_id=3583737
By: Offray

I was previously thinking in the relation between Leo and Wikis, and I think
that may be a thing that would help to make Leo more visible in Wiki space could
be if Leo can export/import to/from a Wiki (something limilar to th @file or
@url directives). Let me explain a little better the scenary where this idea
come.

We have a local wiki for colombian Free Software Community related issues, and
I have used Leo for writing the migration scripts from Mediawiki to MoinMoin
(wich I think is more flexible and extensible that the popular wiki behind
wikipedia). I was probing also the idea of a Wiki like environment for solving
colaborative problems, so I was posting the scripts I made on Leo in a Wiki
page, and republishing them in the moment they changed. This keeps me pasting
all the time the script and in some moments I was thinking what about if someone
make a change in the Wiki page. Would be nice then to have the same capability
to detect and sincronize that change as Leo make with the hard disk files.

But this doesnt end here. Another Wiki-Leo interaction is to use outlines as
a way to organice Wiki content. For example "= Title =" in a Wiki would be a
Outline Node in Leo and "== Subtitle ==" Would become a outline subnode all
arranged in the proper hierarchy.

Somekind of Wisiwyg display would be nice, but this must be a plugin or something
like that, so Leo could become a "Layered" front end to some kind of data.

About and article on Wikipedia. That would be nice, but I'm a little tired of
fighting with some wikipedians ignorance on certain matters combined with power
(a pretty bad combination). I think that a Wiki page is nice because its live
comes from the community knowledge, but I'm not interested in that fighting,
so I have made a Leo wiki page in our local Wiki:

http://www.el-directorio.org:8080/Leo

and when I have enough knowledge about Leo (and time) I hope to start making
contribs in the spanish documentation (for the moment I'm only workind in the
evangelism here).
#@+node:ekr.20060227131611: *3* Two ideas from Kent
@nocolor
http://sourceforge.net/forum/message.php?msg_id=3593116
By: ktenney

This work may or may not be related to a couple
things which have been on my mind lately.

When I have a traceback in the log pane, I'd love
to be able to select an item and cause the file
to appear in a node.
It would be cool to have 'Next' and 'Prev' 
capability while in this mode, effortlessly 
traversing views of the source of the stack items.

Also; 
Zope3, with it's component based architecture,
has machinery which hooks components together ..
Interfaces, Adapters and ZCML, the configuration
language.

It sounds like the autocompleter code is able
to build indexes of classes and methods. It would
be cool if that capability could be extensible,
allowing building indexes of the couplings between
components.

I think this might look like some kind of automatic
hyperlinking, providing access to related code,
as defined for that application.

I really don't know if this makes sense, but
I see you moving in the direction of making Leo
capable of doing some _explaining_ of the code 
being written.

I think this holds lots of promise.

Thanks,
Kent
#@+node:ekr.20061011111007: *3* @bool autoload_most_recent_leo_file
@nocolor

http://sourceforge.net/forum/message.php?msg_id=3957908

> Is there a setting for autmoatically loading most recent file or files.

@color
#@+node:ekr.20041022083226: ** Directives
#@+node:ekr.20031218072017.833: *3* Use @file extension by default if no @language
@nocolor

Open discussion
By: jasonic ( Jason Cunliffe ) 
 use of @language   
2003-07-16 03:40  

I am wondering why Leo does not default to just use the file suffix in @file nodes, instead of obliging @language line in in the body pane 

For example any @file ending with a suffix as defined in the language extensions could just default to use those. 

".py" for python 
".r" for rebol 
".as" for actionscript etc.. 

Should anyone need to over-ride those, they could use @language.
#@+node:ekr.20041016134312.1: *3* Allow multiple @language directives in a single node
@killcolor

Treat @language like @color: ambiguous nodes (nodes containing more than one
@language directive) should not affect descendent nodes.
#@+node:ekr.20031218072017.805: *3* Allow other section delims besides << and >>
Maybe the section operator could be customizable, 
I personally prefer the wiki way [[name of section]]. 

@setlink-tag [[ ]] 
#@+node:ekr.20031218072017.745: *3* @@first <n>
@nocolor

Hate to break into the grand design discussions, but here's a hopefully small thing. If you need to place a good sized copyright statement at the top of your files, LEO doesn't handle this case very cleanly. As I'm sure you're aware, you wind up with a matching number of @@first lines for each leading line in your source. 

As an example: 
# 1 
# 2 
# 3 
# 4 
# 5 
@verbatim
@verbatim
@verbatim
#@verbatim
#@+leo 
@verbatim
@verbatim
@verbatim
#@verbatim
#@+node:0::@file /tmp/firstcheck.py 
@verbatim
@verbatim
@verbatim
#@verbatim
#@+body 
@verbatim
@verbatim
@verbatim
#@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@verbatim
#@+doc 
# 
# How many firsts do I get? 

@verbatim
@verbatim
@verbatim
#@verbatim
#@-doc 
@verbatim
@verbatim
@verbatim
#@verbatim
#@@c 
Start code. 
@verbatim
@verbatim
@verbatim
#@verbatim
#@-body 
@verbatim
@verbatim
@verbatim
#@verbatim
#@-node:0::@file /tmp/firstcheck.py 
@verbatim
@verbatim
@verbatim
#@verbatim
#@-leo 

My fellow co-workers who don't use LEO, aren't exactly loving me here. 

Might we introduce an: 

@@first <num> 

Type tag instead? So one '@@first 5' could represent all 5 of the above @@first lines? It makes for a smaller, cleaner LEO footprint and will tick off non-LEO users much less. 

Thanks. 

- ordinarius 
#@+node:ekr.20031218072017.795: *3* Metatags
@nocolor

By: nobody ( Nobody/Anonymous ) 
 RE: 3.11 todo list & schedule   
2003-02-11 03:25  

Here are some features I'd like to see: 

3. Metatags. @sectionname or @savedate are expanded to the appropriate text when saved.

-marshall-  

There are quite a few of these now.  It would be good to generalize:
- Register @node type.
#@+node:ekr.20041130104552: *3* (Support bird-track programs/comments?)
@killcolor

By: Guenther Enthaler - genthaler
RE: Haskell support  
2004-11-18 22:55

There's a literate programming mode in Haskell (and in a number of other functional programming languages such as Clean & Curry), where the program is in a comment, usually where the line starts with ">" (bird track style, I think it's called), and the comments/documentation are freeform. It would be difficult but cool if Leo could support it, if only because the sentinels in the derived files wouldn't make whole file look so busy. 

Günther 
#@+node:ekr.20031218072017.797: *3* Allow @file http & @file ftp
@nocolor

I'd like to see leo's @file can be extended to cover more protocols, like REBOL's "read" does. 

in short, it would be very sweet if the following work: 

@file http://www.somedomain.org/python/foo.py 

@file pass@ftp.sd.org/python/foo.py" target="_blank" target="_new">ftp://user:pass@ftp.sd.org/python/foo.py> 

while we are at it, what about xmlrpc/soap? 

should there be new directive, like @source ?

@color
#@+node:ekr.20031218072017.810: *4* Remote access Scott Powell
I will wait. Here's clarification, when you're ready for it:

All of my projects are stored on remote computers, and accessed via FTP. 
What I want is basically the ability to open up these projects directly 
through leo, instead of transferring the files manually between my computer 
and the computers that hold my projects, preferably through FTP.

My solution: A new menu item called 'FTP' or 'Remote'. Click on this, and an 
FTP dialog opens up, with an empty list of FTP sites, and the ability to add 
more. You select a site, and it brings up a list of files. You select a 
file, and it is added to your project. When you hit 'save', it automatically 
does an FTP send.

Python makes this a lot easier with the builtin module 'ftplib'. I'm sure 
there are similar things for C++. I hope you take this idea into 
consideration.

Scott Powell
CEO, Dev Designs
#@+node:ekr.20060527184335: ** Gui
#@+node:ekr.20031218072017.793: *3* Keep right panes constant when tiling horizontally (Tix)
This is done automatically now!  I may have to use configure events.

> When I have the 'split mode' set to display tree and log on left, and viewpane
on right, I sometimes need to increase the width of the window.

When I do the resize, the tree/log panes grow in proportion. I don't know about
others, but I'd much prefer if the tree/log panes stayed at the same width,
and only the view pane grew.
#@+node:ekr.20060213151918: *3* Add baloons
#@+node:ekr.20060212125650: *4* createBalloon
def createBalloon (tab,sv):

    'Create a balloon for a widget.' ''

    balloon = Pmw.Balloon(tab,initwait=100)
    balloon.bind(tab,'')
    hull = balloon.component('hull')
    def blockExpose (event):
        if sv.get() == '':
             hull.withdraw()
    hull.bind('<Expose>',blockExpose,'+')
    balloon._label.configure(textvariable=sv)
#@+node:ekr.20060116083043.1: *3* Add context-menus on nodes or text
#@+node:ekr.20051207130144: *3* Investigate Tk DnD
@nocolor
https://sourceforge.net/forum/message.php?msg_id=3460955
By: nobody

I found this link:
http://www.8ung.at/klappnase/TkinterDnD/TkinterDnD.html
TkinterDnD

so if Edward is interested in adding drag and drop support for regular leo,
this might be a path to do so.  It looks like an active project.

leouser
#@+node:ekr.20051207130144.1: *4* @url http://www.8ung.at/klappnase/TkinterDnD/TkinterDnD.html
#@+node:ekr.20050509085713: ** Installer
#@+node:ekr.20050328093147.1: *3* Report: improving installer
@killcolor
http://sourceforge.net/forum/message.php?msg_id=3064212
By: djsg

The following applies to Leo 4.3, which is in alpha as I write this. It describes
the LeoSetup routine that I submitted to Edward to solve the "can't find Python"
problem, and which Edward cleaned up for distribution.

I think a few further issues need attention. I noticed them while working on
the "can't find Python" problem, and deferred dealing with them. This appears
to me to be a good time to pick them up.

Before I start work on them, I would like to lay them out for your comment.
Are they pains in the first place? Are my proposals good enough, and do they
make sense?

Issue 1. LeoSetup still thinks Leo's user is an Administrator who owns the whole
machine.

For explanation, let's say that I log on as David to Windows 2000 or Windows
XP and install Leo 4.3. You then log out. You log in as Edward, and click Start,
pick Programs... you have no visible entry for Leo!

The current Setup routine allows no one but David to use Leo on this computer.
To make things worse, when I go to use Leo, I have to log in to Windows using
the account under which I installed it, which has Administrator rights to the
computer. In other words, I can't use Leo without operating the computer in
a mode that leaves it needlessly vulnerable to security violations.

Issue 2. LeoSetup allows only one copy of Leo on a given computer. 

LeoSetup assumes that you want Leo in C:\Program Files\Leo. The installer can
override that already. LeoSetup also goes to some trouble to set up the usual
click-to-open behavior for .leo files. That behavior is tied to the copy of
Python that was current when I ran LeoSetup, and tied to the copy of Leo that
was installed most recently.

Proposal: While LeoSetup should allow all accounts to share the Python code
for core Leo and its plug-ins, my guess is that we don't want to enforce that,
since Leo is a programmer's tool and the individual programmer will wish to
modify Leo and its pieces for the programmer's use.

Proposal Option 1. Setup should ask whether to install Leo for everyone or for
the installer's account only. If the answer to that question is "yes," Setup
should give the user a private copy of everything that comes with Leo -- the
only application shared should be the current Python, assuming that it is installed
for all users.

Python.org's installer for Python 2.4 allows the installed Python to work only
for the account that installed it. I found this in December and wrote code to
handle it, which I then commented out since the issue wasn't critical. I can
check a computer with a single-account installation of Python in order to figure
out how a single-account installation of Leo would have to handle the click-to-open
behavior.

Proposal Option 2. When LeoSetup finds Python installed for that single user,
it should ask whether to install Leo for the installer's account only. If the
answer to that question is "yes," Setup should give the user a private copy
of everything that comes with Leo and use the single-user installation of Python.
Why does this matter. If you need to test your plug-ins with different versions
of Python, this would make that easier.

Issue 3. LeoSetup always installs Python MegaWidgets ("Pmw"), even on computers
whose installed Python installation already includes it.

Proposal: put up a dialog box and ask whether Setup should install Pmw  I do
not know whether doing this is a good idea.

Issue 4. LeoSetup does not run without human intervention. This complicates
deploying Leo in multi-computer sites.

The message box that displays the path of the Python installation found is one
issue. I put it in to allow the installer to cross-check Setup's behavior. Since
nobody has complained about problems with the code I wrote to fix the problem
installing with Python 2.4 and Active Python, Setup need no longer force the
installer to review the message box's contents.

Proposal: The message box needs to time out after, say, 15 seconds. 

I last looked at the installer three months ago so I would have to look at the
rest of it for other barriers to automated installation.

Let me know what you think. I won't be able to start work for a week or so,
so there's no rush.

-- David
#@+node:ekr.20070929125944: *3* Emulate Orange's download philosophy
@nocolor

http://sourceforge.net/forum/message.php?msg_id=4543089
By: billp9619

from the download page:

If it's the first time you hear about Python, this is the installation for you.
The packages includes complete Orange, Python, Windows Extensions for Python
(PythonWin), Numeric Python, Qt 2.2 non-commercial, PyQt, PyQwt and GraphViz.

Leo should copy this download philosophy.



#@+node:ekr.20041228085245: ** Options & settings
#@+node:ekr.20031218072017.740: *3* Disallow writes outside a "top-level" folder
1. Warn when creating _any_ new file.

2. Warn when rewriting any file that was not read properly.

This prevents "hijacking" an already existing file.
#@+node:ekr.20040311022923: *3* Make sentinel name in @-node optional
#@+node:ekr.20080807111553.1: ** Scripting
#@+node:ekr.20031218072017.753: *3* Emacs comint-mode:  The improved Execute Script command does most of this
@nocolor

Michael Manti
mmanti@mac.com

P.S. I think a feature that could make Leo *the* IDE for developing in 
interpreted languages is something like the (X)Emacs comint-mode.el for 
interacting with the shell and interpreters.

comint-mode.el serves as the basis for interactive modes for a number of
languages--OCaml, Haskell, SML, among them. It allows for editing expressions in
one buffer and triggering their evaluation in another buffer that has an
interpreter running in it, along with entering commands in the interpreter
buffer and moving back and forth through the history of their evaluation.

Imagine being able to highlight a node in Leo, and have all the code in it and
its children evaluated in an interpreter running in a separate window or pane,
much as Leo can open a Python shell now. Users of those languages could build
plug-ins specific to their language atop that layer, and the @language directive
could activate that. I think that would be very cool.
#@+node:ekr.20070627151457: *3* --runCommand option
@

--runCommand "leo-command-name" runs the command at idle-time after loading the file.

I am not going to do this: this, in conjunction with @command nodes, is a big security hole, equivalent to @script.

The only safe thing would be to disallow user-defined commands from being executed by --runCommand, but then what is the point of --runCommand.
#@+node:ekr.20041228092223.4: ** Windows
#@+node:ekr.20050108051818: *3* Add hyperlinks for url's
@killcolor

http://sourceforge.net/forum/message.php?msg_id=2928436
By: jasonic

> I really do want and need to be able to embed basic links throughout out my Leo outlines in a natural 2005 fashion. 

This should be fairly easy to do.

At present, the use_hyperlinks configuration option controls whether Leo generates 'live' hyperlinks for section names.  I don't enable this be default because I dislike jumping around the outline.  Instead, I use clones.

The code to do these kinds of hyperlinks is pretty straightforward.  There is a little code in the colorizer and callbacks in the leoTkinterTree, iirc.

Supporting hyperlinks to urls would be similar.  They could appear in the following situations:

- Anywhere where @language plain is in effect.
- In comments where @language (a programming language) is in effect.
- Anywhere (except in comments?) where @language html is in effect.

This would make a straightforward plugin.  Mind you, this should be in Leo's core, but a plugin would get my attention :-)  Perhaps the reason I haven't done this is that I keep thinking a generalized syntax colorer is near ;-)

Edward
#@+node:ekr.20041022083005.2: *3* add a Stop button for find/change
#@+node:ekr.20040908104644: *3* Leo splash screen
To create a splash screen:

- Draw the screen.
- Erase the screen with self.after(5000, self.destroy)
#@+node:ekr.20040908221501: *4* @url http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/120687
#@+node:ekr.20041228084143: ** Maybe never
#@+node:ekr.20070426092031: *3* Consider another way to compute home directory
@nocolor
http://sourceforge.net/forum/message.php?msg_id=4281562
By: ktenney

I don't know if this is a resolved issue, here's another approach,
looks like a good one.

email link
http://murl.se/24201

python.org os.path doc
http://murl.se/24202

>>> import os
>>> lin_key, win_key = "home", "Documents"
>>> homedir = os.path.expanduser('~')
>>> if os.name == 'nt': os_key = win_key
>>> if os.name == 'posix': os_key = lin_key
>>> print homedir.find(os_key) > -1
True

#@+node:ekr.20060930110925: *3* Fix arrow keys (if possible)
Up/down arrow keys should move straight up/down, but this is difficult with Tk.
Still the present way is very bad.
#@+node:ekr.20041022070154: *3* (options for setting working directory during startup)
#@+node:ekr.20041022070154.1: *4* Request & response
@killcolor

http://sourceforge.net/forum/message.php?msg_id=2815599
By: Antonio Pala

All plugins I have tried (notably @run and the @rst variants) have their working
directory set to my home directory, regardless of the position of the Leo file
and all @path directives. This renders most of them useless, since I would have
to use absolute pathnames. Is this the way they were meant to work, or is there
a bug somewhere? Or maybe I have missed some configuration parameter?

I am using Leo 4.2 with Python 2.3 on Linux.

> All plugins I have tried (notably @run and the @rst variants) have their working directory set to my home directory, regardless of the position of the Leo file and all @path directives.

Directory issues are different on different platforms.

I would welcome specific proposals for setting directories during startup.  Early in the startup process Leo sets g.app.loadDir to the directory from which Leo was loaded.  Plugins can use this directory to set the working directory as they choose.

@path directives will have no effect on plugins:  they are loaded before the outline.

> This renders most [plugins] useless, since I would have to use absolute pathnames.

No, it means you might have to add a few lines of code to your plugin to make it work just as you would like it to work.

> Is this the way they were meant to work?

I don't have much control over how plugins were "meant" to work.  However, an improved plugin manager might have facilities for setting the working directory.

This is a non-trivial issue;   Leo uses and sets paths in many places in the code.  It seems dubious to have plugins change the working directory at random times.  Perhaps an option that inits the working directory would be good.  The new config system will allow per-outline options as well as global option. I believe such options could be loaded before plugins.

Edward
#@+node:ekr.20051104051733: *3* Make Focus-in in minibuffer widget equivalent to Alt-x
FocusIn does nothing for Label widgets.

http://sourceforge.net/forum/message.php?msg_id=3412640
By: btheado

Currently clicking on the minibuffer and typing text has no effect.  Kinda confusing
until the Alt-x binding I discovered that Alt-x is the way to access the minibuffer
command mode.

It would be nice if the <FocusIn> binding on the minibuffer widget were equivilent
to Alt-x.
#@+node:ekr.20040123102724: ** Can't or won't
#@+node:ekr.20100128094926.6222: *3*  port pmw to py3k
Pmw should be deprecated.
#@+node:ekr.20080822065427.3: *3* Create desktop icon or start menu item
#@+node:ekr.20080815174457.5: *3* Consider deleting private shadow files
@nocolor

http://groups.google.com/group/leo-editor/browse_thread/thread/e86796831635311b

I was wondering whether it would be a good idea to have leo
automatically delete the corresponding shadow file when a @shadow node
is deleted? Ditto for deleting the .leo_shadow dir when it is empty.

Answer:

My second thought is that this is too dangerous--shadow files might
turn out to be useful emergency backups.  I would prefer to have Leo
mess with the file system as little as possible.
#@+node:ekr.20060329102951: *3* @ref
@nocolor

The graph world is a better solution.
#@+node:ekr.20060329102951.1: *4* My summary post
http://sourceforge.net/forum/message.php?msg_id=3598136

> It appears that @ref nodes introduce a flexibility that can not be simulated (at all?) with clones.  

Now that something like @ref appears necessary, it is so much easier to see how @ref is useful :-) 

1. @ref is an explicit link (arc) that creates the links of a general graph structure explictily. 

The simplest cycle is: 

- root 
..- a 
.... - @ref b 
..- b 
.... - @ref a 

This is not possible with clones! No more mumbling about being able to represent such links in uA's! 

2. @ref allows users to compose documents from 'atomic' pieces of text properly. That is, adding a 'virtual' child to a piece of text does not add it to all other uses of that text in (possibly unrelated) documents. This vastly increases the flexibility of rst3 plugin. 

I suspect other essential uses of @ref will appear. I am sure we can declare the 'post-leo LP tool' project a great success already :-) 

Edward 
#@+node:ekr.20060329102951.2: *4* Reply
@nocolor
http://sourceforge.net/forum/message.php?msg_id=3650005
By: itsme213

Imho ...

There will not be any "arbitrary graph" from @ref. Instead there is a forest
of trees, and across trees, some nodes are same_as some other nodes (caused
by @ref). same_as is transitive. Quite likely the roots of all trees are same_as.
There may need to be some rules to ensure things make structural sense. Children
of a node are just that -- children of that node.

There will be a totally separate Merge node whose children will be the union
of the children of all the nodes it merges. A Merge node is, itself, the ordinary child of some
node.

Tree traversals will be tree traversals.

Hope that did not muddy the waters even more ... 
#@+node:ekr.20040220110030: *3* Change cursor when caps lock is down
@nocolor

http://sourceforge.net/forum/message.php?msg_id=2431552
By: nobody

From: Rich

 I just got nipped twice by the following effect: the Caps-Lock key is ON, but
because the LED is on the Caps-Lock key, it is hidden behind my hand. I hit
Ctrl-x, expecting to cut my selection, but the entire node is cut.

   I know there's a problem with tk and the shift key status, so I'm wondering
if it would be possible to change the shape of the cursor when the Caps-Lock
is ON (preferrably a big red flashing blot 8-), or otherwise show that Caps-Lock
is active ( "CAPS" on a status line, for instance).

  Another way: I don't know if this goes against an "anti-modalism rule," but
only allowing Ctrl-Shift-x|c|v in the outline pane would also be acceptable
to me.
#@+node:ekr.20031218072017.743: *3* Note window for each node
http://sourceforge.net/forum/message.php?msg_id=2205285
From: Rich

I envision a short window at the bottom of the edit window that could hold notes
and comments about the code, such as "Test this harder" or "Find a better way of
phrasing this". This is currently available in uSoft Office and the Eclipse IDE
(http://www.eclipse.org). Perhaps a numeric reference, such as "<<1>>" could be
used.
#@+node:ekr.20060610193837: *3* open python window does not appear to work on Solaris
@nocolor

http://sourceforge.net/forum/message.php?msg_id=3771068
By: leouser

The open python window does not appear to work on Solaris.

http://sourceforge.net/forum/message.php?msg_id=3771167
By: nobody

from what I could see it looked like it was trying to start the shell up with
a location that pointed to a nonexistent path.

@color
#@+node:ekr.20040216054459: *3* @h @f @endh and @endf directives
@nocolor

http://sourceforge.net/forum/message.php?msg_id=2424151
By: ksejlod ( Peter Barrel ) 
 I Have a (maybe) great idea!   
2004-02-15 04:29

I've been using LEO for a while and finding surprinsingly powerfull new uses now
and then, (hey, not a week passes that i dont think to myself : "why did'nt
anyone thought of that kind of tool that is LEO. It's so stupid to program such
a tool, yet no one thought of doing such a thing ! ")

I was wondering if there was a leo keyword (beginning with "@") that would do a
feature I thought would be great: something such as :
@h
@endh
and of course, similarily...
@f
@endf

Standing for "Header", "End Header", "Footer" and "End Footer". Let me please explain ...

When creating files with @file (or nosentinels) I use the keyword "@others" in
the starting node body of the file and place in the file, as it's decendants
(children, grand-children & so on) some clones of other stuff somewhere else
outside of this file (usualy, clones of parts of program regrouped as children
of a "components" node up in the leo outline. Typical Example:

-Introduction
-+components
-a
-b
-c
-+@file program.BAS
-b
-c
-a

a, b, and c are clones and the @file node contains @others.

As you see, I proceed that way because in older programming languages or in lower level languages, the order of components such as procs, declarations, etc as an importance. It also has the implication that << and >> brackets are irrelevant in my way of using leo.

Now, my feature that I looked for in the doc but could not find (so i suggest it here in case no one had any need of this before) is that when used in the BODY of a node part of an "@file" the @h and @endh would define a chunk of text in the body, you've guessed it, to be added before _each_ children node and ONLY children no grandchildren or any deeper. But It could also be used INSIDE the body of a children to define headers or footers for IT'S OWN direct children.

so, eehh, do you see the relevance of such a feature? Have i explained it clearly? maybe this would help:
CONST baba=2 AS INTEGER
CONST bebe=7 AS INTEGER
CONST zaza=5 AS INTEGER
CONST bobo=1 AS INTEGER
... the beginning and end of each of those "parts-of-a-program" is the same for a potential lot of lines... 

To Be Precise :
It's just really for adding something at end or beginning of a direct children of a node part of an @file in the tangling process. 

Is this feature already implemented but i have not found it? I'm pretty sure it easy to implement... what do you people think of this?
Thanks 
--
k

p.s. I'm the guy who proposed that in the untangling process, a clone would not be updated by it's _Last-Instance-Found_ in the @file beeing untangled, but instead updated by the _Last-Modified-One-Found_ in the @file... :)

(ooouuuuhh that would be slick...)  

By: ksejlod ( Peter Barrel ) 
 RE: I Have a (maybe) great idea!   
2004-02-15 04:35  

 The tree i tried to draw in ascii did not came out the way i did it,
sourceforge "eated" leading spaces sorry a, b and c are children of their "+"
node just above them . -- k
#@+node:ekr.20040329185649: *3* Known Bugs: can't be fixed or can wait
#@+node:ekr.20031218072017.663: *4* Bug: can't be fixed
#@+node:ekr.20031218072017.664: *5* Cut/paste bug on X windows (waiting for help)
@nocolor

Under X Window system, when text is selected, it is automatically entered into a buffer and can be pasted with the middle button of the mouse.

In Leo, when this is done, the text is rendered in right place, but it doesn't stick unless some key is pressed after pasting. That is, if I leave the node in question without pressing any key after pressing the middle button, the pasted text is gone when I come back to that node.

Doing copy and paste works normally when done through the edit menu.

@color
#@+node:ekr.20031218072017.665: *6* (Cut & Paste ) (Middle-button bug reported by Timo)
#@+node:ekr.20031218072017.666: *7*  Paste bug report
@nocolor

By: riotnrrrd ( Timo Honkasalo ) 
 Pasted text doesn't stick   
2002-11-01 13:38  
System: Linux 

Under X Window system, when text is selected, it is automatically entered into a buffer and can be pasted with the middle button of the mouse. 

In Leo, when this is done, the text is rendered in right place, but it doesn't stick unless some key is pressed after pasting. That is, if I leave the node in question without pressing any key after pressing the middle button, the pasted text is gone when I come back to that node. 

Doing copy and paste works normally when done through the edit menu. 

-------------------

I also found out that if you do an extra "click" on the control key, it will
stick from then on.

If your text should have color in it, you can see that right before you "click",
the text has no color and the color back on right after you click the control.

It maybe a clue to someone, but seems strange to me. 
#@+node:ekr.20031218072017.667: *7*  Test
abc bbb bbbxyz bbb
#@+node:ekr.20031218072017.668: *6* Automatic select & Paste bug (Linux?)
@nocolor

Bumping the thread because the bug still persists. 

I've also noticed that the automatic select'n'paste doesn't work between nodes. That is, I can select text and paste a copy of it in the same node with middle button, but if I change click to another node, the paste buffer is erased. The automatic pasting works between Leo and other applications, however, and I can paste between nodes if I copy the selection to buffer by CTR-C. 

Maybe this is related to the non-sticking bug?

----

This may be a Linux-only bug related to the control-v workaround.
#@+node:ekr.20050514171429: *5* Glitch pasting into headlines

@killcolor

http://sourceforge.net/forum/message.php?msg_id=3152036
By: ngirard

Hi again,

Leo has IMHO a slight inconsistency as when a new node is created and has to
be given a name.

When the new node is created, the string "NewHeadline" appears and is selected.
Then there are 2 ways of setting a new name:

1. by typing the new name character by character using the keyboard. This way,
"NewHeadline" disappears as the first character of the new name is typed. Here
the implicit idea is that "NewHeadline" is very unlikely to be the final node
name -- which makes sense to me ;-)

2. by pasting the contents of the clipboard, with Ctrl-v. This way, "NewHeadline"
*remains* and the contents of the clipboard is appended to it.


I find leo's behaviour in case #2 inconsistent with #1 and suggest that the
first approach should be preferred.

Cheers,
Nicolas


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=10226

#@+node:ekr.20031218072017.669: *5* Linux-only Bugs
These may indicate problems with Tk on Linux.  I can not reproduce them on XP.
#@+node:ekr.20031218072017.670: *6* Possible webbrowser bug
(In Linux) The home page and online tutorial options in the menu only work properly if Mozilla window is already open. If not, a Mozilla window opens, but with empty page and url field. 
#@+node:ekr.20031218072017.671: *6* Fix horiz scrollbar bug when tiling horizontally
When in 'vertical split' mode (with viewpane on right, and tree pane over log pane on left), the horixontal scrollbar at bottom of screen is at full width, despite the fact that not all of the tree pane area is displayed. 

Another way of saying this - I narrow the tree and log panes, to the extent that the display of tree node headings is truncated. But the horizontal scrollbar at the bottom doesn't contract, and doesn't allow me to horizontally scroll the tree pane to expose the rest of the node headings. 
#@+node:ekr.20031218072017.672: *6* Control-V doesn't work on Linux
This has been and continues to be a known issue with Tk. Has been logged as a bug; no response from the Tk folks. 

Here is a link to the Tk bug report: 

http://sourceforge.net/tracker/?func=detail&aid=605277&group_id=12997&atid=112997 

Note the work-around/patch in the followup post at the bottom of that page. Commenting out some statements in text.tcl removes the problem. 
#@+node:ekr.20050202073944: *5* Mac bugs
#@+node:ekr.20050201175325.2: *6* Can't delete script buttons
#@+node:ekr.20050201175325.1: *6* Icon buttons are not colored, nor do they have square borders, etc.
#@+node:ekr.20050202052911.1: *6* Find Text in Find Panel gets focus only if it contains text
#@+node:ekr.20031218072017.673: *5* Tk bugs
The following bugs can not be fixed because they are Tk bugs.
#@+node:ekr.20041201071145: *6* Tk Freezes on debean when libtk is compiled with thread support
http://sourceforge.net/forum/message.php?msg_id=2876797
By: skal

By: Grossé Pascal - skal
RE: Leo freezing up  
2004-12-01 06:15

The freezing problem on debian sid (which is also my current OS) is caused by a bug in Tkinter: Tkinter does not work when libtk is compiled with thread support, which is the case on debian sid for tk8.4 
I compiled my own non-threaded libtk with the corresponding python/tkinter, and the freeze magically vanished.  

This is a known bug in debian bugtrack: 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171353 

Skal
#@+node:EKR.20040523192553: *6* (Crash when pasting large text into headlines)
#@+node:EKR.20040606104355: *7* Report
@nocolor

From: <eltronic@juno.com>
To: <edreamleo@charter.net>
Sent: Sunday, May 23, 2004 9:36 AM
Subject: fatal bug in Leo headline handling


> found a fatal bug in Leo headline handling.
> not sure if anyone reported before,
> an oversize string can crash python 2.3.3
> 
> 
> the text was about 4500 bytes. nothing but text.
> opened the  leo again, copy a large page of text,
> insert headline, paste, fatal error in python.
> 
> I have by mistake pasted whatever node xml was in 
> the copy buffer into a headline w/o problem.
> but that was just dumb luck. just verified,
> had the node been large enough it crashes.
> 
> Leo 4.1 final, py2.3.3 win98
> PYTHON caused an invalid page fault in
> module TK84.DLL at 0167:1022b74f.
> 
> Leo 4.1 final, py2.2 win98
> paste a 15k node copy into headline. no problem.
> 
> this is the first repeatable hard crash I've stumbled on
> and thought it best to report it privately.
> I can think of no advantage to allowing a headline 
> of this size anyway. think of the tooltip that would create!
> 
> there are latent bugs in the selectall and delete from 
> the edit menu related to headline as well on the todo list.
> reported many times. 
> covert destruction of the selected body text.
> use of virtual events, with out proper focus to headline.
> 
> without myself being able to supply a patch, I'll guess,
> the virtual event paste called can as well point 
> to a function that checks the size before pasting.
> or simply sets the headline directly with 
> g.app.gui.getTextFromClipboard()[:1024]
> 
> 
> e
#@+node:ekr.20031218072017.674: *6* Caps lock affects keyboard shortcuts on Windows
Using leo under Windows, the keyboard shortcuts seem to use the "Caps Lock" state in determining the shift state when executing a shortcut.   For example, if the caps-lock key is on, then Ctrl-X is interpreted as Shift-Ctrl-X and cuts a node rather than selected text, and Shift-Ctrl-X is interpreted as Ctrl-X and cuts text.
#@+node:ekr.20031218072017.675: *6* Tree problems
1. The border of the tree control is gray, and it is overwritten with large headlines.  This may be a Tk or Tkinter bug.

2. Adding trailing whitespace to a line in body text does not set the file-dirty mark.  This can never cause a derived file to become "out-of-synch" because the read code does not compare body text.

Apparently there is no way to fix this glitch because of holes in Tk's event mechanism.  Specifically, tree.idle_body_key has no way to tell directly what keystroke caused it to be entered.
#@+node:ekr.20031218072017.676: *6* Control-T can't be overridden in canvas text.
#@+node:ekr.20031218072017.677: *6* (Alt-ctrl = Alt)
@nocolor

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=1765069
By: dalcolmo

I use the bindings that come with Leo:

[keyboard shortcuts]
pastenode = Shift+Ctrl+V
gonextvisible = Alt+DnArrow
importtofile = Shift+Ctrl+F
writefilenodes = Shift+Ctrl+W
editheadline = Ctrl+H
markchangeditems = Alt+C
replace = Ctrl+=
goprevvisible = Alt+UpArrow
gotonextmarked = Alt+M
readoutlineonly = Shift+Ctrl+R
extractnames = Shift+Ctrl+N
gonext = Alt+Shift+DnArrow
findpanel = Ctrl+F
close = Ctrl+W
demote = Ctrl+}
tangle = Shift+Ctrl+T
extract = Shift+Ctrl+D
openpythonwindow = Alt+P
marksubheads = Alt+S
saveas = Shift+Ctrl+S
cut = Ctrl+X
preferences = Ctrl+Y
equalsizedpanes = Ctrl+E
cantundo = Ctrl+Z
open = Ctrl+O
promote = Ctrl+{
sortsiblings = Alt-A
unmarkall = Alt+U
mark = Ctrl+M
showinvisibles = Alt+V
exit = Ctrl-Q
insertnode = Ctrl+I
findprevious = F4
converttabs = Shift+Ctrl+J
save = Ctrl+S
tanglemarked = Shift+Ctrl+M
moveup = Ctrl+U
copynode = Shift+Ctrl+C
contractparent = Alt+0
selectall = Ctrl+A
setfont = Alt+Shift+T
aborteditheadline = Shift+Esc
goback = Alt+Shift+UpArrow
toggleactivepane = Ctrl+T
findnext = F3
tangleall = Shift+Ctrl+A
endeditheadline = Esc
deletenode = Shift+Ctrl+BkSp
cantredo = Shift+Ctrl+Z
new = Ctrl+N
contractall = Alt+1
moveleft = Ctrl+L
copy = Ctrl+C
paste = Ctrl+V
convertblanks = Shift+Ctrl+B
expandall = Alt+9
markchangedroots = Alt+R
cutnode = Shift+Ctrl+X
indent = Ctrl+]
gotonextchanged = Alt+D
expandnextlevel = Alt+=
setcolors = Alt+Shift+S
matchbrackets = Ctrl+K
movedown = Ctrl+D
clonenode = Ctrl+`
untangle = Shift+Ctrl+U
expandtolevel7 = Alt+7
expandtolevel6 = Alt+6
expandtolevel5 = Alt+5
expandtolevel4 = Alt+4
expandtolevel3 = Alt+3
expandtolevel2 = Alt+2
moveright = Ctrl+R
unindent = Ctrl+[
replacethenfind = Ctrl+-
extractsection = Shift+Ctrl+E
expandtolevel8 = Alt+8


However, I use a utility called AllChars (Free as in beer :-(  ) to be able
to type all kinds of chars on my US keyboard, and "Handything" to place the
windows on the screen (Win2000). Perhaps this makes a difference, although disabling
them did not seem to make it go away. Still, on pressing alt+ctrl+uparrow I
end up at the next upper node etc...

- Josef

#@+node:ekr.20031218072017.718: *6* (tab bug)
#@+node:ekr.20040117092727: *7* This is definitely a Tk bug
By: dthein ( Dave Hein ) 
 RE: BUG: Non-leading tabs not working properl   
2004-01-17 14:40  

 This seems to be a TK bug. I've reproduced the problem directly in Tk.

It's been around for a long time :-(

More details on this page, along with a patch for an earlier version.

http://www.qs.co.nz/Tcl/TkTabs.html

The Tk folks fixed a bug I reported with Ctrl-V behavior, but it took about a year for them to get to it. I don't have high expectations with this problem either, but I'll probably put together a patch for some of the recent version of Tk and submit the patches and bug report.  
#@+node:ekr.20040118090055: *7* Patch and bug report
https://sourceforge.net/forum/message.php?msg_id=2380238
By: dthein

I've submitted a patch and bug report to the Tk project.

The patch, #879073, for those that want to fix this problem on their systems,
is at:

http://sourceforge.net/tracker/?func=detail&aid=879073&group_id=12997&atid=31299
7

And the bug report, #879077, is at:

http://sourceforge.net/tracker/?func=detail&aid=879077&group_id=12997&atid=11299
7

The patch is for 8.4.2.  If you have a different version, you can probably figure
out the changes needed by looking at the patch file.  If not, let me know your
version and I may be able to produce a patch for it.

Note: If you use tabs for anything other than leading whitespace, you will find
this patch really helpful.  I make lots of little tables when I'm documenting
or note-taking ... this fix really helped my sanity when making those tables
inside Leo.

Dave Hein
#@+node:ekr.20031218072017.719: *7* Report
@nocolor

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=1906790
By: dspeed
Open Discussion

-- Tabs are not expanded correctly in .c files, when language in preferences is set to c, and when the tabs occur in the middle of a line. The tabs are expanded as spaces until the next tab location is reached, then the tabs are expanded correctly. 
#@+node:ekr.20040105070023.5: *7* Report 2
Leo 4.1 rc3, build 1.62 , December 19, 2003
Python 2.3.0, Tk 8.4.2
Linux 2.4.22-21mdkenterprise

1. Any tab typed before the first tab stop behaves correctly (the cursor is moved to the tab stop). Good.

2. Any tab typed after a non-tab character (even a space) _and_ after the first tab stop position doesn't behave like a tab and doesn't move the cursor to the next tab stop. Bad.

3. Any tab typed after a tab character will behave properly no matter what position on the line. Okay.

To reproduce this, set your global tab prefernence to 4. Show invisibles. And then create a node containing:

[BEGIN BODY TEXT]
@language plain
@tabwidth 8
[END BODY TEXT]

Create a child node to that one, containing:

[BEGIN BODY TEXT]
@root-code somefilename
\t\tThis works
bbb\tAnd This works
So\tdoes this

But, this \tdoes not.
Here is the two-tab \t\t behavior.
[END BODY TEXT]

I hope this is a Leo bug and not a Tk bug. 

Dave Hein 
#@+node:ekr.20031218072017.720: *7* Minimal test
This is a test line.
#@+node:ekr.20031218072017.721: *7* Test File for Non Expanding Tabs
This is a test line.
put the text insertion point in the space between 'a' and 'test' above. Enter 3 tabs in a row and watch it not work.

If your expansion works correctly, then maybe something with leoconfig?  But wait, Im using the leoconfig from the beta download.

The contents of my Log Windows when opening this file:

Leo Log Window...
Pyton 2.2.2, Tk 8.3.2
reading d:\test.leo


#@+node:ekr.20040129133809.8: *5* top node not saved
@nocolor

When opening a .leo file Leo selects the correct node but it is no longer the top most node in the window.

What I did:

- Eliminated entries like a="":  This happened because Leo no longer writes clone bits.

- Made sure Leo writes a="T" entries.  However, Leo really can't use this easily.

Another possibility would be to save the scrolling state, but that is very gui-dependent.
#@+node:ekr.20040105064959: *4* Bugs: can wait
@nocolor
#@+node:ekr.20040115165036: *5* bug in xml doc parts (hard to fix?)
@language html
@ignore
@color
#@+node:ekr.20040115165036.1: *6* Demo XML comment bug
@ 
This document demonstrates what appears to be a bug in Leo 4.1 rc3, build 1.62 of December 19, 2003.

It has manifested when Leo is executed under Python 2.3.3, Tk 8.4.3 under Windows 2000.

In brief, derived XML files are not well-formed with respect to comments under some conditions.  Comments can wind up nested, which looks okay to humans but not to XML parsers.
@c
#@+node:ekr.20040115165036.3: *6* @file xmlcommentbug.xml
@first
@language HTML
<HiMom>
@
This will produce, in the derived file, an XML comment with another XML comment
embedded. Or, if you prefer, it will produce an unclosed XML comment followed by
a well-formed one, followed by a string of text containing a comment-close
marker.

This text is sitting in the inner comment, according to the first view.
@c


@
This comment is well-formed, seemingly because its content does not begin on the
same line as the at-sign.
@c
</HiMom>
#@+node:ekr.20040115165036.4: *6* xmlcommentbug.xml
<?xml version='1.0'?>
<!--@+leo-ver=4-->
<!--@+node:@file xmlcommentbug.xml-->
<!--@@first-->
<!--@@language HTML-->
<HiMom>
<!--@+at -->
<!--
<!--@nonl-->
This will produce, in the derived file, an XML comment with another XML 
comment embedded.  Or, if you prefer, it will produce an unclosed XML comment 
followed by a well-formed one, followed by a string of text containing a 
comment-close marker.

This text is sitting in the inner comment, according to the first view.
-->
<!--@-at-->
<!--@@c-->


<!--@+at-->
<!--
This comment is well-formed, seemingly because its content does not begin on 
the same line as the at-sign.
-->
<!--@-at-->
<!--@@c-->
</HiMom>
<!--@nonl-->
<!--@-node:@file xmlcommentbug.xml-->
<!--@-leo-->
#@+node:ekr.20040125114453: *5* Import bug?control-alt-f of python code misalloctes code (waiting for answer)
@nocolor
http://sourceforge.net/forum/message.php?msg_id=2391076
By: thyrsus

There is a lot of correct intepretation going on, but there are some errors.
As an example, the anaconda code, in text.py, contains the following lines.
I'll use periods for leading whitespace, the two characters ^I for leading tabs,
and a $ to indicate a newline:

class WaitWindow:
def pop(self):
    self.screen.popWindow()
    self.screen.refresh()

def __init__(self, screen, title, text):
    self.screen = screen
    width = 40
    if (len(text) < width): width = len(text)

    t = TextboxReflowed(width, text)

    g = GridForm(self.screen, title, 1, 1)
    g.add(t, 0, 0)
    g.draw()
    self.screen.refresh()


After importing file text.py, I get three associated nodes like so:

[class WaitWindow]
.|
.+-[pop]
.|
.+-[__init__]

However, the contents of the nodes are off.  In node [class WaitWindow] the
text is

class WaitWindow:
@others
    self.screen = screen
    width = 40
    if (len(text) < width): width = len(text)

    t = TextboxReflowed(width, text)
    g = GridForm(self.screen, title, 1, 1)
    g.add(t, 0, 0)
    g.draw()
    self.screen.refresh()

Node [pop] contains the text

def pop(self):

Node [__init__] contains the text

self.screen.popWindow()
self.screen.refresh()

def __init__(self, screen, title, text):

This anaconda code is being correctly interpreted by the python 1.5 interpreter.
I'm too green with python to pronounce on whether the formatting is conventional.
I don't consider this a bug a major problem, but it should probably be addressed
before we start touting Leo for large collections of existing code.

This is my first experience importing python; in the past I've imported perl
code, and Leo gave me just one big @file node, and I was on my own to better
structure it.  Given the perversity of perl syntax ("Nothing but perl can parse
Perl." - Tom Christiansen), that's probably the right thing to do.  It's a judgement
call for whomever wants to take responsibility for the python importer as to
whether that may be the right thing to do for python.
#@+node:ekr.20040129133809.5: *5* Expand/contract may not work after drag (works for me)
sometimes after a drag of a node, 
then the expand/contract doesnt work.
click or menu has no effect.
in an open leo
maybe it is ok after you save the file
other times only fix is to exit & restart.
#@+node:ekr.20040217153407.1: *3* Unify @root and @file
@nocolor

- There is no way to unify the syntax: a different syntax is needed to specify sections that may appear in pieces.

- I have little interest in this project, even if a better read logic for @root derived files might make automatic untangling possible.
#@+node:ekr.20060228072202: *3* New undoer
#@+node:ekr.20060201161901.2: *4* @url http://sourceforge.net/forum/message.php?msg_id=3332355
@nocolor

By: Edward K. Ream - edream RE: Dividing The Undo: doing w/o v.uA 2005-09-09
   14:17 > If we can open up how [Leo] reads xml, it may make it simpler to
   start developing a stash scheme.

I agree that reading xml more properly would be A Good Thing (tm). As we shall
see, however, it is not the main issue.

> DOM seems like a good path to start out on.

This is not the path I would have chosen. The new colorizer at in leoPlugins.leo
at:

Plugins-->Experimental/unfinished-->New colorizer-->@thin __jEdit_colorizer__.py

uses sax. I like the light-weight approach. I would rather do a bit more work in
the initial parsing and create the data structures myself then relying on DOM.

But parsing is irrelevant. The problem is the design of *thin* derived files and
the code that reads such files. Let us consider how we can "do without"
v.unknownAttributes in thin derived files. I **shall not** change the format of
thin derived files, so some trickery is required. The first step is read this
section of Leo's new docs:

http://webpages.charter.net/edreamleo/customizing.html#adding-extensible-attributes-to-nodes-and-leo-files
/> The key here is the so-called 'hidden machinery'. This is an essential
feature of the code that reads and writes thin derived files and it **will not**
change. **Note**: Leo has two sets of read code: the code that reads .leo files
has no trouble whatever recreating vnodes. It is only vnodes in thin derived
files that may not have attributes.

**Important**: for @thin trees (in the outline) Leo saves *only* the <v> element
corresponding to the @thin node itself. It is this <v> element that contains the
'hidden machinery'. Don't even think about having Leo write the whole tree of
<v> elements: the 4.0 read code is made possible because these <v> elements do
*not* exist. This eliminates all the error 'recovery' schemes that can not, if
fact, be robust enough.

So the only real alternative is to add uA's sufficient to recreate elements in
the *reconstituted* vnodes that Leo creates in the leoAtFile read logic.
Happily, we can do this as follows. When writing, a plugin (or an extended Leo)
would 'piggyback' the vnode attributes in the corresponding
**t**.unknownAttributes field. When reading, the plugin (or Leo) would put the
vnode attributes "where they belong" in the appropriate vnode. We associate a
'vnode traversal index' with each vnode. This is simply how many previous "same"
vnodes appeared in the traversal before getting to the desired vnode. Something
like this::

vx = {} # traversal indices for vnodes. for p in c.all_positions(): ....n =
vx.get(p.v.t,0) # n is the traversal index for vnode p.v. ....vx[p.v.t] = n+1 #
bump the index for the next v such that v.t == p.v.t

We store attributes for vnode v in v.t.unknownAttributes, along with the
traversal index. The read code uses the traversal index to copy vnode attributes
from t.unknownAttributes to v.unknownAttrutes. Rather than forcing each plugin
to do this, Leo should probably have support for this in the leoFileCommands
read/write code. In short, the t.unknownAttributes machinery suffices in theory,
and in practice a bit of support code would be good.

Glad you asked :-) . I have been willing to live without v.uA's in thin derived
files. I never thought much about this until you asked, but necessity is the
mother... So this is good. A way exists to treat all vnodes as first-class
citizens.

Edward
#@-all
#@-leo
