.. @+leo-ver=5-thin
.. @+node:ekr.20100119205347.6015: * @file ../doc/leoToDo.txt
.. @@language rest
.. @@wrap
.. @+all
.. @+node:ekr.20170308150422.1: ** To do: Leo 5.6
.. @+node:ekr.20170320052551.1: *3* First
Fix javascript importer bugs
- Make sure whitespace stripping doesn't put @language at end of line.

Fix @auto bugs:
- Cancelling @auto write creates orphan nodes.
- Cloned @auto nodes duplicates section references.

Improve Ctrl-up/down:
- Ctrl-Down should insert a blank line if at the bottom.
- Ctrl-Up should insert a blank line if at the top.

Add commands to show color wheel and font picker.
- Similar to @button nodes in leoSettings.leo.

- check pid logic in BPM.
- p.b & p.h setters should check that s is a string.
- Create leoFind wrappers:
    - c.findCommands.setFindText -> c.findCommands.ftm.setFindText
    - c.findCommands.setReplaceText -> c.findCommands.ftm.setReplaceText

.. @+node:ekr.20170211190548.1: *3* Add org-mode features
@language rest
@wrap

Better support for org-mode:
- p.drawer and p.results properties.
- If no text selection, only execute between @language directives.
- Add arguments to @language directive.
- Rendering of Latex, and *images* in Leo's body pane.
- Better support for shell console & scripts.
- Better support for make, C, C++, Java, etc.
- Support .org files and .org.leo files.

Maybe:
- Agenda: an agenda plugin.
- Tables: a tables plugin.

Use client/server architecture?
- Emulate/ use pyzo server?
- A short prototype of @jupyter?
  https://groups.google.com/d/msg/leo-editor/wRQfJ5UdsFU/yPEZheV8EwAJ
  Appears to work only with Python 2.

.. @+node:ekr.20160318113006.1: *3* API's for icons, attributes & windows
Must be easy to use.

- Add p/v.temp_u properties. Revise docs.

- Use Terry's window code to create all panes:
    - New console window plugin.
.. @+node:ekr.20160305033136.1: *4* Found:['"]icons[i"]
.. @+node:ekr.20160129081036.1: *4* simplifying uA access
d = p.u.get(plugin_name, {})
d['duration'] = 5
p.u[plugin_name] = d
.. @+node:ekr.20080802070659.11: *4* Make node attributes visible, and supported by Leo's core
.. @+node:ekr.20170315071752.1: *3* New docs
- Leo scripting for scientists.

- (Maybe) execute-script-in-common-namespace command. It's needed to simulate pyzo/jupyter/org mode calculations.

- show-drawer command. It will pop up a window showing a special 'core-drawer' uA. Saving the popup will update the uA.  No need for changes to Leo's body pane.

The easy way to simulate org-mode's window, and improve upon it, will be to allow Leo's body pane to contain multiple, vertically aligned panes.  Like this:

    Overall body pane:
    
    pane 1
    ----- (separator)
    pane 2
    ----- (separator)
    pane 3
    ...

Users will be able to see the various panes without intervening headlines, although separators may show headlines.  Only one of the panes will be active.  It is the "real" body pane.  This can be done in a plugin.
.. @+node:ekr.20170315081957.2: *4* Consider using Leo if...
Feature table

- Want Python and its libs.

- You develop software, including scientific software and scripts:
    Org-mode's script delims make it impossible to develop large software.
    
- You want to treat an outline as a programmable database.
    - Leo *is* a db. Outlines can represent db queries.

- You have hundreds of files to manage.
    - Leo has a fast caching scheme.
    
- You want clone-find commands

.. @+node:ekr.20170315081957.3: *4* Leo as a compendium

"A research project typically relies upon components such as:

    The data being studied;
    Details of calculations and code used in data analysis;
    Methodological conventions and assumptions;
    Decisions among alternate analytic paths.

However, the documents produced by a research project typically stand apart from the things they describe and rely upon, which makes it difficult for other researchers to reproduce the results and to understand fully the conclusions of the research project. This situation is problematic because reproducibility of results and accurate communication are both central to notions of good science.

A software solution to this problem was proposed by \citet{compendium}, who “introduce the concept of a compendium as both a container for the different elements that make up the document and its computations (i.e., text, code, data, …), and as a means for distributing, managing and updating the collection.”"
.. @+node:ekr.20170315081957.4: *4* Reproducible research
They summarize the uses and implications of a compendium as follows:

    It encapsulates the actual work of the author, not just an abridged version suitable for publication;
    It can display different levels of detail in derived documents;
    The computations included in it can be re-run by an interested reader, potentially with different inputs;
    It contains explicit computational details that make it easier for an interested reader to adapt and extend the methods;
    It enables programmatic construction of plots and tables;
    Its components can be treated as data or inputs to software and manipulated programmatically in ways perhaps not envisioned by the author.

Reproducible research thus approaches mixed natural and computational language documents from a different direction than literate programming. Rather than adding prose to computational projects, reproducible research seeks to augment publications of scientific research with the computer code used to carry out the research. Whereas literate programming extracts embedded code into an external file used as input to a compiler or an interpreter, code embedded in a reproducible research document is intended to be executed as part of the document generation process. In this way the data, analysis, and figures supporting a publication can be generated from the publication itself.
.. @+node:ekr.20170315081957.5: *4* Scripting for scientists
Show how scripts can invoke other scripts.

Show how to compose results:
    - With pickle?
.. @+node:ekr.20170315081957.6: *4* Plans for 2017
- Support for .org.leo files.

- p.drawer property.

- What to do about org-mode code blocks.

- How good is the org-mode import/export code?

- agenda.py plugin (improve existing todo.py plugin.)
- tables.py plugin
.. @+node:ekr.20170315081957.7: *4* Underlying technologies
@language rest
@wrap





.. @+node:ekr.20170315081957.8: *5* LP and RR
Leo easily supports `Literate programming`_ (LP) and  `Reproducible Research`_ (RR) with unique, powerful underlying technology, not a mishmash of features.

**LP**: Leo redefines LP, showing that many kinds of comments are unnecessary in an outline environment. In LP terms, Leo supports *automatic* `tangling`_ and `weaving`_, but those terms are not used in Leo because they happen automatically.  More importantly, Leo supports `untangling`_, something entirely missing in org mode. Leo can update outlines corresponding to external files when those files change outside of Leo, preserving and updating outline structure as it does so. Untangling requires the `Mulder-Ream update algorithm`_, something entirely missing in org mode.
.. @+node:ekr.20170315081957.9: *5* Scripting
@language rest
@wrap

Leo is fundamentally more powerful than org mode scripting:

1. Unlike org mode, Leo's outline nodes are true Python objects, *easily* accessible via Leo's Python `API`_. Furthermore, Leo scripting is based on Python and Python's standard library, not elisp and Emacs-specific code. Leo scripts can be run outside of Leo.

2. Leo can `compose`_ both external files and scripts using the same `markup`_. Unlike org mode, Leo's markup applies *everywhere* and is fully integrated with Leo's outline structure. As a result, it is complete natural to compose external files or scripts (experiments) from a suboutline. For example: this defines an external file::

    @first # -*- coding: utf-8 -*-
    '''whatever.py'''
    << imports >>
    @others
    # That's all, folks
    @language python
    @tabwidth
    
And this this defines the top-level part of a script::

@language python

    @langauge python
    '''My script'''
    << imports >>
    class Controller:
        # Child nodes define the methods of this class.
        @others
    Controller(c).run # Yes, c *is* defined.

@language rest
    
There is no need to put this inside wonky org-mode markup. The @language python directive tells Leo how to execute the script. More importantly, the `@others`_ directive includes *properly indented* code from descendant nodes. At the moment, I can't tell from the org mode docs whether anything like Leo's ``@others`` directive exists.
.. @+node:ekr.20170315081957.10: *5* Data model
Leo's underlying database is a `directed acyclic graph`_, (DAG) not a `tree`_ or, as in org-mode plain text with a collection of hacks that make that text look like a tree. The technology behind Leo's `clones`_ is based on the underlying DAG. It has been optimized over several decades. Org mode will likely never have clones.

Leo has a full-featured `Document Object Model`_ (DOM) consisting, among other things, of a collection of Python generators that traverse trees, subtrees or ancestor, visiting clones multiple times. Leo distinguishes between `positions`_ in a traversal and `vnodes`_, containing the actual data in each node.
.. @+node:ekr.20170125104430.1: *3* Minor issues (Jon N)
@language rest
@wrap

I do not think the 'use lossage()' key functions should be in the core, unless you know better...

A few things:

- depending on the actual size of the Body pane, there can be a small amount of 'micro-scrolling' as you move the cursor to the top/bottom of the pane. I think my other editor resizes the pane so as not to have partial text lines. The current behaviour seems liveable with, although I might be interested in learning how to 'fix' this.

- I don't currently deal with any existing selected region. If this were to go into the core this would probably all be refactored, maybe using some of the existing helper functions

- the doKey() function has to know about the key(s) that are calling it, "Home" or "End" in the lossage() list. How might I improve this?

- I had some trouble calling the pre-existing editor commands, like c.editCommand.beginningOfBuffer() etc. Not 100% sure I am doing this correctly.

- as per the comments I am currently assuming that lossage() has at least three entries. I'll fix this shortly.
       
Anyway, here's what I have. I am currently using two @command nodes
    @command myCtrlHome @key=Ctrl+Home
    @command myCtrlEnd @key=Ctrl+End
with content like below (merged a bit from two nodes for 'clarity')
.. @+node:ekr.20170125104502.1: *4* Declarations
​
from leo.core.leoQt import QtCore

.. @+node:ekr.20170125104502.2: *4* cursorToEndOfPane
def cursorToEndOfPane():
    """ move the text cursor to the last character visible in the body pane
    """
    w = c.frame.body.widget
    # get viewport of the body widget
    vp = w.viewport()
   
    # get the coordinates of the bottom of the visible area
    vWidth = vp.width() -1
    vHeight = vp.height() -1
    # g.es("width", vWidth, "height", vHeight)
   
    # create a QPoint from this
    bottom_right = QtCore.QPoint(vWidth, vHeight)
   
    # get the (text)'position' within the widget of the bottom right QPoint
    end_pos = w.cursorForPosition(bottom_right).position()
   
    # create a cursor and set it to this position
    cursor = w.textCursor()
    cursor.setPosition(end_pos)
    # set the Leo cursor from this
    w.setTextCursor(cursor)
   
    c.bodyWantsFocusNow()
   
.. @+node:ekr.20170125104502.3: *4* cursorToTopOfPane
def cursorToTopOfPane():
    """ move the text cursor to the first character visible in the body pane
    """
    w = c.frame.body.widget

    # create a QPoint of the top of the widget (client area)
    top_left = QtCore.QPoint(0, 0)
   
    # get the (text)'position' within the widget of the top left QPoint
    start_pos = w.cursorForPosition(top_left).position()
   
    # create a cursor and set it to this position
    cursor = w.textCursor()
    cursor.setPosition(start_pos)
    # set the Leo cursor from this
    w.setTextCursor(cursor)
   
    c.bodyWantsFocusNow()

# arrive here with 'Ctrl-Home' the first entry in lossage
# XXX for now, assume we have pressed more than three keys...
.. @+node:ekr.20170125104502.4: *4* doMyCtrlHomeKey
def doMyCtrlHomeKey():
    if g.app.lossage[1][1] == "Ctrl+Home":
        if g.app.lossage[2][1] == "Ctrl+Home":
            g.es("would move to top of buffer")
            c.editCommands.beginningOfBuffer(None)
        else:
            g.es("would move to top of body")
            cursorToTopOfPane()
    else:
        g.es("would move to beginning of line")
        c.editCommands.beginningOfLine(None)

doMyCtrlHomeKey()

# arrive here with 'Ctrl-End' the first entry in lossage
# XXX for now, assume we have pressed more than three keys...
.. @+node:ekr.20170125104502.5: *4* doCtrlEndKey
def doCtrlEndKey():
    showLossage()
    if g.app.lossage[1][1] == "Ctrl+End":
        if g.app.lossage[2][1] == "Ctrl+End":
            g.es("would move to end of buffer")
            c.editCommands.endOfBuffer(None)
        else:
            g.es("would move to end of body pane")
            cursorToEndOfPane()
    else:
        g.es("would move to end of line")
        c.editCommands.endOfLine(None)


doCtrlEndKey()
.. @+node:ekr.20170122010350.1: *3* Fossil videos & ideas
​Richard Hipp, Fossil and SQLite author, makes that distinction and about
the "pile of files" database (like the .git folder) instead of the single
file approach[2]. There is a lot of querying capabilities of the last one,
as you can see on [4]

[2] https://www.youtube.com/watch?v=8y_ABXwYtuc
[3] https://www.youtube.com/watch?v=ghtpJnrdgbo
[4] http://fossil-scm.org/index.html/doc/trunk/www/webpage-ex.md


If the emphasis is on node versioning, there's this:

https://groups.google.com/d/msg/leo-editor/LIUGtgP8T_s/oSQD4RQGeogJ

===== Offray

Some years ago I proposed something for Leo, combining two technologies: fossil and Yaml[1], for the same reasons exposed here: fossil a as easier, self contained technology for working with files and Yaml as a diff friendly format to express graphs (trees with clones). At that time the idea didn't advance, but I explored it in Grafoscopio using STON[2] instead of Yaml. Now I have a diff and human friendly format for Grafoscopio notebooks, that can express graphs. For example, the interactive notebook about Panama Papers at [3] is shown in a fossil repository at [4] and a diff with a previous version is on [5].

[1] http://markmail.org/search/?q=leo-editor%20offray%20yaml%20fossil#query:leo-editor%20offray%20yaml%20fossil+page:1+mid:t7xlg7mt5hqnldkn+state:results
[2] https://github.com/svenvc/ston/blob/master/ston-paper.md
[3] http://mutabit.com/offray/blog/en/entry/panama-papers-1
[4] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212
[5] http://mutabit.com/repos.fossil/panama-papers/fdiff?sbs=1&v1=255e79b046584a36&v2=cbfe8929edf64212

Some notes about my thesis that are in Leo have conflicts created by xml +
dropbox, that made the XML unreadable from Leo again, as you can see in
this fossil repo at [6]. I will try to fix the file to make it loadable
again in Leo.

[6] http://mutabit.com/repos.fossil/doctorado-offray/dir?ci=ab8052282f0847de&name=Tesis

This shows how XML is really a big weakness for Leo and other programs and
that other simpler approaches for a diff/human friendly format and
technologies for storing complex documents and enabling collaborative
projects are available, as the Grafoscopio prototypes shown, but,
unfortunately, XML and git have monopolized the developer's imagination.
But maybe now we can rethink some core assumptions about technologies and
formats behind Leo.

I would try something like this:

- Storing a simple Leo tree as a Yaml tree, including clones and see how
  far can we push the format, for example, when interaction with external
  files is represented in that tree (@file, @clean @auto).
  
- Storing Leo and these external files in a single .fossil repository and
  explore if having this technology as a simple backed for storing files
  and their history makes easier to work with the changes in such external
  files. At least in my preliminary explorations, having fossil compiled
  with JSON support[7][8] has enabled to query, from Grafoscopio, the
  fossil repository with a simple interface (I have not made any POST
  experiment yet). Anyway, I could imagine a single .fossil file that makes
  Leo store a tree and related files, so if any of them changes, the
  changes are compared against the repository to ease collaboration.

[7] http://fossil.wanderinghorse.net/repos/fwiki/index.cgi/wiki/README
[8] https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view
.. @+node:ekr.20161231072528.1: ** Maybe
- reload-abbreviations command.

* Allow key unbinding.

- Unit tests should preserve find state.
  The find command doesn't seem to work after unit tests.
.. @+node:ekr.20160318113505.1: *3* Avoid mouse in nodetags & other plugins
We want the alternatives to clones to be mouse free.
.. @+node:ekr.20160315141751.1: *3* Code Academy: possible topics
@language rest
@wrap

- Redraw mode that hides siblings.

- Clones: making and deleting them.
  Clones are cheap to create!

- How to create new panes anywhere,
  and how to put cool stuff in them.

- How to hoist outlines programmatically.

- How to write a plugin so it can respond to events.

- Using g.trace and g.pdb: example: splitter.open_window
- Find all nodes with a given uA.
- Create log pane.
    - Put Qt stuff in it.
- Key bindings.
- Create new panes.
- Scripts can handle events.


.. @+node:ekr.20160309105419.1: *4* Chapters & hoists
How to change what is shown in the outline pane.  Chapters and hoists exploit existing capabilities.  If need be, more could be added with just a few lines of code in Leo's main outline redrawing code.
.. @+node:ekr.20160309105156.1: *4* uA's & views
Quick additions to Leo's core:
- Define the p.u property, so code can do p.u instead of p.v.u.
- Possibly make the api for uA's more convenient.

A better attribute gui would help *everyone*.
- We need to be *associate icons with attributes*.
- This can be used for chapters, bookmarks, my-view-a/b/c, etc.

An **attribute calculus** would form union & intersections of attributes.

We would like searches to add/clear attributes. The Nav or nodetags plugins could do this. We might also want interactive add/remove attribute commands. These plugins could also hoist the nodes they show, similar to create-chapter-from-nodes command.

clone-mark-all could also set define attribues.

A more ambitious addition: Define a gui interface for uA's.

Being able to make uA's visible somehow would give Leo many of the cool features of the ECCO outliner. We envisage a uA tab in the outline pane that would allow the user to:

- See all and only nodes with given attributes.  This is similar to Leo's clone-find-all (or clone-find-all-flattened) commands, combined with something like a hoist.

- List all such nodes in the uA pane, similar to the Nav Pane (Quicksearch plugin), so that clicking on a node would select the node in the entire outline, with only ancestors of the selected node expanded.  Pretty easy to do.  Alternatively, perhaps some  tag (uA) oriented features can be added to existing plugins.
.. @+node:ekr.20160309105326.1: *4* API for windows
The so-called Easter-Egg interface creates new panes from the gui.

A summary of how to do this programmatically is needed.

Note: it's possible to save the layout so that Leo will restore it when Leo starts up the next time.
.. @+node:ekr.20161019020710.1: *3* Improve pylint command
- enable more pylint checks
- pylint command should ensure that the leo directory is on the path.
  At present, Leo seems to need sitecustomize.py.
- Pylint --recent option.  Last hour? Last day?
.. @+node:ekr.20160310055038.1: *3* Improve quicksearch (Nav pane)
- Key bindings in the nav pane.
    - Arrow keys.
    - Enter shift to outline pane.
    - Some key to shift back to the nav pane.
- Focus to Nav pane should select search area.
    - Something like ctrl-Enter shouild go back to Nav pane.
.. @+node:ekr.20161205102034.1: *3* Maybe: Temp vim modes
The idea is to be able to define the dot easily.

- Allow Leo to enter vim-mode temporarily.
- Define the dot.
- Leave vim-mode.
- Use the dot.
.. @+node:ekr.20161207052323.1: *3* Maybe: use x.reload
Important core classes, including importer classes, could support a reload method, that would reload the file containing the class, and return a new instance of the class, ready to be used by unit tests. Something like this::

    if 0: # Preamble...
        g.cls()
        if c.isChanged(): c.save()
        ic = c.importCommands.reload()
    else:
        ic = c.importCommands

The call to c.importCommands.reload() could return a new GeneralTestCase instance and this instance could set a reload flag.  The later call to ic.markdownUnitTest(p...) would then reload markdown and linescanner when the reload flag is set.

But... leoTest.leo defines several other subclasses of unittest.TestCase besides GeneralTestCase.  So maybe we need variants of c.importCommands.reload to handle the other kinds of TestCase.

I'm not in a hurry to do any of this, since the present importer cases work.  Still it's a good idea to keep these ideas in the back of our minds. This kind of simplification could be useful when creating other kinds of unit tests.
.. @+node:ekr.20161106074940.1: *3* Maybe: Visualize massive git changes
This is likely impossible, but git contains all history...
.. @+node:ekr.20160327111800.1: *3* Support jedi auto-completion (& valuespace)
https://github.com/davidhalter/jedi

Terry: valuespace remarks
https://groups.google.com/d/msg/leo-editor/u5fToKw2wEU/Cl1Wy3whAgAJ

Terry: autocomplete code looks at objects in c.vs namespace
https://groups.google.com/d/msg/leo-editor/u5fToKw2wEU/2ag8PH3oAAAJ
.. @+node:ekr.20120516140545.9987: ** Wishlist: no due date
@language rest
@wrap
.. @+node:ekr.20131101080215.16488: *3* * Outreach to magazine editors: create videos
@language rest
@wrap

Steve Litt

EKR summary: Videos will encourage magazine editors to write about Leo.

**Get more fans who can write and who are listened to**

To do that, you'd need to give them enough of a burning desire to spend a few days learning the ins and outs of Leo.

**Leo has an image problem**

Mention Leo, and most people say "it's an outliner." If that's all Leo was, VimOutliner would have eaten Leo's lunch years ago. VimOutliner is faster and has the 90% of outlining features that people use 90% of the time.

95% of the population will never believe they need an outliner or that an outliner would do them any good, or that outlining is a skill they need to bother to acquire.

**Make a 3 minute video**

Leo is a mechanism by which you can specify a computer program as an outline-like thing in an outliner-like setting, flip a switch, and bang, there's your program. THAT'S what's going to hook people.

**Video 1**: will show how to compose an application outline and turn it into a program.

The program can be trivially simple, but make the program as 2014 relevant as possible: A web app would be nice. At the end of the video explain that although this video's program was simple, Leo can be used to make arbitrarily complex apps, and make them well.

**Video 2**: will show hhow to make a GUI app.

**Video 3**: will show how to write a book in Leo.

Flip a switch, and have it be a book, flip it back, and see your book as an outline again, ready for changes, either minor, or structurally major.

**Publicize these videos**

You're going to get some journalists excited, and those are your reviews.

**Start publicizing different ways people use Leo.**

Encourage them to write in with their unique uses, and publicize them. I bet people are doing things with Leo you never dreamed of, and some of those things might be the itch some journalist wants to scratch.
.. @+node:ekr.20150412034943.1: *4* Show what rST & css can do in Leo
.. @+node:ekr.20131121211048.16378: *3* * More screenshots!
Different font sizes, coloring schemes, plugins, etc.
.. @+node:ekr.20140704052551.17951: *3* Code
.. @+node:ekr.20130806072439.21341: *4* * Node pipes
From: Kent Tenney <ktenney@gmail.com>

The editor envy resulting from the Light Table demo has me revisiting a feature that's been percolating.

Sending output to the log pane is very useful, it's how Leo talks back.

Executing from the command line means one space for input and output.

Executing in a Leo node and writing to the log improves on this by providing different spaces for input and output.

Could Leo generalize this concept such that any node could be designated as a destination for output?

Given multiple visible nodes, akin to Terry's stickynotes, or Ville's recent grid suggestion, Leo could duplicate the power of simultaneous feedback shown by Light Table.

I guess 'rendering' addresses this to some degree.

Reminds me of the power graph database folks talk about, where you can define nodes and edges to be whatever you want.

The nodes could be sources or sinks. Sources: code or commands ... Sinks: standard out, tail -f logfile, network traffic, introspection ...

The edges would define handlers for the content of the sources, format the results and send to the sinks.

So, as I write code in one node, I can see a node displaying stdout, another watching a log file, another showing docstrings, another showing test results ...

===== Ville

The 'ileo workbook' concept is relevant; it allowed you to easily reference other nodes in your scripts (wb.foo meant node with headline 'foo').

It's nice in theory, but the rigid ui model where we show only one node at a time made it hard to visualize. Tabula or grid would make it more concrete and intuitive - you could show input, output and the manipulator script at the same time. Or make small nodes with intermedote results etc.

How this would relate to 'pipeline' - you would have explicit way to say what nodes are input, whan nodes are output and what are the scripts that transform input to output. Editing inputs or scriyts would ping you somehow that outputs are out of date, allowing you to easily press button to recalculate outputs.
.. @+node:ekr.20130806072439.21342: *5* Re: Node pipes
From: "Edward K. Ream" <edreamleo@gmail.com>

On Wed, Apr 18, 2012 at 9:48 AM, Kent Tenney <ktenney@gmail.com> wrote:

> Could...any node...be designated as a destination for output?

Certainly.  Just assign to v.b in the appropriate place.

> could [Leo] duplicate the power of simultaneous feedback shown by Light Table.

Yes, provided somebody understands what the simultaneous feedback is ;-)

Tabula might be natural for that, perhaps enhanced via free_layout.

> I guess 'rendering' addresses this to some degree.

Interesting connection.  We might want to render to tabula nodes.

> Reminds me of the power graph database folks talk about, where you can
> define nodes and edges to be whatever you want.

This is coming.  Redefining edges would be easy provided that they had
different colors from the "main" edges.

> The nodes could be sources or sinks.
> Sources: code or commands ...
> Sinks: standard out, tail -f logfile, network traffic, introspection ...

Yes.  This is a straightforward generalization of your first question.

> The edges would define handlers for the content of the sources, format the results and send to the sinks.

A new idea!  This could be revolutionary!

> So, as I write code in one node, I can see a node displaying stdout, another watching a log file, another showing docstrings, another showing test results ...

To paraphrase: nodes and links are not simply ways to represent structure.  They may have independent identity and function.  A brilliant idea.

Edward
.. @+node:ekr.20130806072439.21344: *5* Re: Node pipes
From: "Edward K. Ream" <edreamleo@gmail.com>

On Wed, Apr 18, 2012 at 11:47 AM, Kent Tenney <ktenney@gmail.com> wrote:

>> Certainly. Just assign to v.b in the appropriate place.
>
> Right. Leo can be considered a programming language, it is able
> to do most anything one dreams up. Here we are discussing what
> features are appropriate to add to the 'standard library' IE: put the
> effort into making the capability an API call instead of a bunch of code.

In fact, the inadequacy of my remark that assigning to v.b was all that was needed lead me to consider the broadcaster/listener framework.

The idea is that the v.b setter property would broadcast the fact that v.b has changed to all the listeners connected to v.  Presumably, those listeners will be UI elements that will update their text from v.b and recolor as appropriate.

We might generalize this concept to update outline structure in those UI elements that show outlines.

> My impression of the Light Table demo is that the right side of the screen was reporting interesting information about what was being typed on the left side. Seems like it could be called "simultaneous feedback"

An excellent generalization.  We can use this without knowing exactly what the feedback is, or where it comes from.

> I'm unable to keep up, unaware of the capability of free_layout,
> tabula, rendering, but I expect most if not all of the tools are availabl=
e.

Keeping up with ourselves these days seems like a full-time job.

I believe a broadcaster/listener event framework is an essential ingredient.  It shouldn't be too hard to do, it will simplify existing code, and it will be an enabling technology that will stimulate further development.
.. @+node:ekr.20130807203905.16681: *4* * travis-ci "continuous integration" for Leo
From: "Ville M. Vainio" <vivainio@gmail.com>

Someone may be interested in investigating a free CI system for Leo:

https://travis-ci.org/

This could e.g. create debian packages for daily builds, run unit tests, check stuff with lint, try compiling with python3 so we (*cough*) wouldn't have accidental print statements in the source...
.. @+node:ekr.20140115052524.16699: *4* Allow clones *anywhere* in @file nodes
​https://groups.google.com/d/msg/leo-editor/YjJdWjNSM9o/SDL7Nb__OUcJ

There is a way to allow clones *anywhere* in @file nodes and simplify Leo's read code in the process!

The idea is for the read code to treat *all* nodes exactly the same initially, regardless of whether they should actually be clones of each other. A post-pass would then "unify" all vnodes having the same gnx.

Why, oh, why, did I never think of doing this? It will be *so* much simpler than the present code!​ And it will be just as fast, maybe even faster. Another example of generality arising from simplicity...

I can tell you why I *did* think of doing this now: the new @auto read logic uses a new p._relinkAsCloneOf method, exactly what the @file read post pass will use!
.. @+node:ekr.20100219083854.5615: *4* Improve caching
.. @+node:ekr.20100209160132.5770: *5* cache notes
Top-level folder are direct subfolders of .leo/db.

Top-level folders represent file *locations* not file contents.

Exception: the top-level "globals" folder represents minor data.

Only two files are ever needed in a top-level folder:

contents_<key>: the contents of the file.
data_<key>: a dict representing the "minor data" of the file:
    <globals> element stuff, expansion bits, etc.

We write contents_<key> only once.
By definition, its contents never changes, since the contents generates the key.
We can write data_<key> as many times as we like.

To do:
- Simplify or even eliminate the path-manipulation code in PickleShareDB.
- Use g.makeAllNonExistentDirectories to make top-level directories.
- Clear cache should clear all top-level directories.
.. @+node:ekr.20100209114432.5751: *6* Cache expansion bits
# Simplify the structure of the cache: put more into the "minor" files.
.. @+node:ekr.20100211095442.6201: *5* cache notes 2
1. Memory does leak, and that's not ok with me.  And I want just two files per top-level directory.

2. Strange things can happen with caching, as just happened to me when I restored qtui_generate.py mistakenly deleted from leo/test.  There is an @auto node for this file in qtGui.py, and I got improper 'can not open' messages for this file.

3. It is troubling that the present caching scheme does not use the full path to a file, only the basename.  This means that two identical files in two different places will use the same cache entries.  I've been wondering for the last several days about whether this could cause problems.  I don't know for sure, but I am uncomfortable.

4. I want the clear-cache and clear-all-caches commands to do what they say: get rid of everything.  Among other things, this is good for debugging and recovering from cache problems.
.. @+node:ekr.20100210163813.5748: *5* Caching buglets?
This is a recent bug, but imo it has uncovered some other caching buglets. These buglets are not big enough to delay Leo 4.7, but the new caching scheme would ensure they never bite.

1. The code that computes what I have been calling the top-level directory is dubious::

    dbdirname = join(g.app.homeLeoDir,'db',
            '%s_%s' % (bname,hashlib.md5(fn).hexdigest()))

The problem is that bname is only the base name of the cached file, not a name (or key) that depends on the full path. Thus, two copies of the same file in the same place will be cached in the same directory. Is this ominous?

2. It's not clear what caching to do with the save-to command.
.. @+node:ekr.20100225102636.5627: *5* Use the string returned by cacher
It should be possible to avoid duplicate reads.
.. @+node:ekr.20080628095358.1: *4* Make each Leo command a class
http://groups.google.com/group/leo-editor/browse_thread/thread/5688ed9aaa39be2e#
.. @+node:ekr.20111101050427.16716: *4* Make g.openWithFileName "reentrant"
That is, make sure it works when called from within itself.
.. @+node:ekr.20111021035504.9467: *4* Play with PyQt Qtest framework
http://groups.google.com/group/leo-editor/browse_thread/thread/b851e7d9855a57c2

http://www.voom.net/pyqt-qtest-example
.. @+node:ekr.20111125072438.10216: *4* Regularize slashes and back-slashes
http://groups.google.com/group/leo-editor/browse_thread/thread/0d48b507bc8ffc05

If I 'Open' a file, I get the following node header:

@edit E:/Documents/index.html

If I 'Import' the same file, I get the following:

@file E:\Documents\index.html

Just wondering why the difference between

E:/ and E:\

This is probably trivial and of no consequence, but I thought it curious.

Create unit tests illustrating path ops
.. @+node:ekr.20130503061707.10515: *5* @@test path computations
@language python
fj = g.os_path_finalize_join
f = g.os_path_finalize
eu = g.os_path_expanduser
if g.app.isExternalUnitTest:
    loadDir = fj(g.app.loadDir, '..', 'test')
else:
    loadDir = g.app.loadDir
table = (
    (fj, '@@file fj-test-1', fj(loadDir, 'rel-path')),
)
for func, h, expected in table:
    p = g.findNodeAnywhere(c, h)
    assert p, 'not found: "%s"' % (h)
    assert p.h.startswith('@@')
    p.h = p.h[1:] # Remove the first @ sign.
    try:
        d = c.scanAllDirectives(p)
        result = d.get('path')
        assert result == expected, 'expected "%s", got "%s"' % (
            expected, result)
    finally:
        p.h = '@' + p.h
        c.redraw()
.. @+node:ekr.20130503061707.10516: *6* @path rel-path
.. @+node:ekr.20130503061707.10517: *7* @@file fj-test-1
.. @+node:ekr.20111003232155.6988: *4* Use c.db for marks & expansion bits
This would allow us to eliminate @bool put_expansion_bits_in_leo_files.
.. @+node:ekr.20140704052551.17957: *3* Coloring
.. @+node:ekr.20060824110846: *4* Add colorizing for cweb, rapidq
.. @+node:ekr.20110614123640.6587: *4* Add headline/color functions to Leo's core
http://groups.google.com/group/leo-editor/browse_thread/thread/7e279fe3dedf42be/f00fde4df5b39ded

What uA should be used to specify node colors?

if the foreground / background color API uses uAs,
would/should the uAs use the reserved "leo_&lt;something&gt;"
namespace?

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

Terry Brown

Sounds like something I may have brought up, long ago.

I was thinking that setting the fore/background color of nodes in the tree should be a "gui core" function, and that the info should be stored in uA, and so wanted to know what key should be used in uA for that.  I think the docs say top level keys starting with "leo_" are reserved, and probably wanted a ruling on

v.u['leo_fg'] = 'red'

vs

v.u['leo_tree_style']['fg'] = 'red'

etc.

I think the question may be more complicated than just what to call the key, so you can probably retire the todo item.
.. @+node:ekr.20111028195854.16607: *4* Allow ruleset-specific colors
Like @color html::tags_markup_color = blue
.. @+node:ekr.20111019104425.15863: *4* Won't do: use pygments for syntax coloring
This has little chance of improving Leo
.. @+node:ekr.20120229094652.15178: *3* Commands
.. @+node:ekr.20041130123243: *4* Clear Undo command
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.20130806072439.21225: *4* Distributed collaboration tool
===== Miles Fidelman <mfidelman@meetinghouse.net>

A big Leo fan pointed me at Leo, and this group - indicated that sharing Leo documents has been talked about over the years, but not really implemented, and suggested that I post some details about a project that I've been working on.  So....

Basic model is synchronized copies of documents, linked by an asynchronous pub-sub channel.  Think of a personal Wiki (like TiddlyWiki) - linked to copies of itself, that's the general idea.  Compose a document, email copies to collaborators, everyone saves a local copy - those copies link to each other via a pub-sub protocol to distribute updates.  All in JavaScript, embedded in the "smart documents" - nothing special to install.

If you're interested, details are at:
http://www.kickstarter.com/projects/1947703258/smart-notebooks-keeping-on-the-same-page-across-th

Andy Oram wrote a background piece for O'Reilly Radar:
http://radar.oreilly.com/2012/08/smart-notebooks-for-linking-virtual-teams-across-the-net.html

.. @+node:ekr.20120515193246.10083: *4* Find & spell
.. @+node:ekr.20111014134653.15672: *5* Search across multiple Leo files
http://groups.google.com/group/leo-editor/browse_thread/thread/cf5ab54f29a6c128
.. @+node:ekr.20110520051220.18203: *5* Cross-tab search
This would be a substitute for cross-file clones.
.. @+node:ekr.20041022083005.2: *5* add a Stop button for find/change
.. @+node:ekr.20041219162724: *5* Add dialog to insert recent directories
http://sourceforge.net/forum/message.php?msg_id=2903742

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:

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.

.. @+node:ekr.20050127110221: *4* jsonic about output
@language rest
@wrap

By: jasonic

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

**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.
.. @+node:ekr.20060227131611: *4* Kent: extensible auto-completion-like capabilities
http://sourceforge.net/forum/message.php?msg_id=3593116
By: ktenney

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.
.. @+node:ekr.20111010122531.15569: *4* print-bindings/commands/settings create nodes??
http://groups.google.com/group/leo-editor/browse_thread/thread/d302b2715b3ace96

A reminder, the opposite of "light" is "heavy", not "dark" :-)

Leo's print-settings, print-commands and print-bindings commands
create too much text.

Suppose they created outline nodes instead, replacing existing nodes
if they exist.  Something like this:

- Reference (Anywhere you like)
 - @print-settings
    etc.
 - @print-bindings
   etc
 - @print commands
   etc

Doh!  This uses Leo's power.  The subnodes can be as voluminous as desired, and there can be organizer nodes in each case.  The actual tree could be specified as in @menus.

Etc., etc.  This could moot the need for separate apropos commands. Conversely, apropos commands could create their own trees, or subtrees.

This could be the tip of an iceberg.

The more I think about the light/heavy distinction, the more I think it is getting close to what makes Leo special.  For example, clones (and nodes, for that matter) drastically lighten the apparent complexity of programs or data.
.. @+node:ekr.20031218072017.807: *4* Put up file dialog on empty @url, etc.
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.20110929074744.15449: *4* generalize show/hide/select gui elements commands
tab-cycle-next makes the following not so important

There is a relationship here with mouseless programming.  It would seem that all visual elements, especially those that may exist in multiple versions, must have a name or other description suitable for generalized commands.

The user might want multiple rendering panes, especially if one or more are locked.  Without a description, there is no way to specify exactly what show/hide-rendering pane does.

I haven't forgotten the autocompleter docs.  I'll get to them next. It looks like autocompletion would be the way to generalize the not- very-effect commands that switch focus from one ui element to another.  A related benefit is one generalized command might be more convenient to use than the present flavors of (buggy) cycle-focus commands.

In short, contemplating generalized windows leads us to generalized select/delete/show/hide commands, based on autocompletion, that work on various ui elements.
.. @+node:ekr.20140921072018.17937: *4* separate-process commands
run-script-from-bridge
run-script-externally
    * Specify which version of python to use.
    
*** The at_produce plugin now has technology for reporting progress using
the IdleTime class.

This technology should become part of g.execute_shell_commands. New
settings will control whether, and how often, to report progress.

*** There will soon be two new functions for running both Leo and non-Leo
scripts externally.

- g.run_python_script_externally would simply create an external file
  containing the script and then run python on that file.

- g.run_leo_script_externally would do something similar using the Leo
  bridge.

Both functions would be controlled by new settings, including (Kent will be
glad) what version of Python.

*** Revise http://leoeditor.com/leoBridge.html

There are several ways to run code externally:

- Using leo.core.leoBridgeTest.
- (When ready) using g.run_leo_script_externally.
- Using the full-blown method that Terry discusses in that chapter.
.. @+node:ekr.20140921072018.17938: *5* Settings for at-produce plugin?
* Why not just improve g.execute_shell_commands ?
    - It could report too.
    - And it could use settings too.

- time-between-notifications: 0 means disable notifications.
- Decrease time between calls to idle-time handler.
.. @+node:ekr.20160405063258.1: *4* Unlikely
.. @+node:ekr.20150215102218.4: *5* Unlikely: @ns-rst/vo/otl commands
@language rest

===== @ns-* write logic

In his initial post, Rob said, "when I change my @auto-rst files to @nosent
files, the resulting files do not contain the RST section headers that were
automatically added by @auto-rst."

This proves that @ns-rst must have special logic that writes the proper
section headers. Happily, this can be done easily with special cases in
at.putOpenNodeSentinel. Ditto for @ns-md, @ns-vimoutline and @ns-otl.

From https://groups.google.com/d/msg/leo-editor/QxK2V62ESLw/vCSolavmw4YJ

===== @ns-* read logic

No change is actually *required* for @ns-rst and @ns-md. When reading an
@ns-rst or @ns-md file, added sections could be slurped into the outline as
under/overlining text. The user could leave the changed node as it is. Or
the user could create a new node with the indicated headline. Either way,
the @ns-rst write logic would recreate the changed file.

However, a simple, fast post-pass in the @ns-rst/md read logic could create
the new nodes automagically. The post-pass would traverse the tree created
by the @nosent logic looking for under/overlined lines (or # lines for md),
creating new nodes as needed. The actual code would be similar to the
@auto-rst logic,but it exists in a far simpler context than @auto-rst.

Post passes are probably *required* for @ns-vimoutline and @ns-otl. Indeed,
vimoutline or otl sentinels should *never* be left as plain text in an
existing node. The "raw" sentinels would corrupt the vim or Emacs outline
if the node were later moved. An unpleasant time bomb.
.. @+node:ekr.20130806072439.21337: *5* Unlikely: better C importer
From: ne1uno <eltronis@gmail.com>

wouldn't it be great to have a first class c importer?

hiding the complexity of platform & compiler/option #defines. invisible (TM) nodes would be fruitful here. switched on by @#define. with an @#define=3D collection node or using a bunch of headlines. and an rclick flipper for true/false, defined/not defined declarations.

meanwhile I wait for the inspiration or someone else to nail down a regular expression c language parser. maybe a tokenizer is enough. I did run c code through AStyle then through your old c2py via buttons. for code that would remain in c, in SciTE through google CPPlint program to point up flaws, and to get the context sensitive help from various CHM. running flawfinder good to do now and then old or new code. post processing and displaying the report in a browser. but it doesn't go far enough & too many false positives.

there is splint, maybe the only free lint left. the need to inject "hints" all over the code make it less than ideal for perusing unknown source and generally a deal breaker for project code. sometimes all you need is a function/var list to get by. deeper static analysis is quite the serious business. so, it's not a surprise those programs are not easily found, or used. there are a few code flow programs that could be harnessed to colorize headlines indicating relations. taking all this in, marking nodes that need work with a popup or tooltip action event when you view that node with the details of one or another parser to annotate what needs work.

we have had a few plugins/buttons/attempts at designing an interface to get a program node compiled. this is also a decent way to get info on the quality of code by turning all warnings on. fails for snippits. never quite simple to hookup or modify painless. perhaps the biggest problem is knowing what is available and where. more toolbars, no reason they can't dock. drag & dropping buttons. one of the huge advantages of Qt over Tk so far barely tapped. you begin to accept the fact that you need to create a temp file instead of real process control. managing program quirks & options becomes more trouble than it's worth just to protect the purity of the operation sans temp files. QTprocess has more options than the process in pythons libs. if it ever works as well as it should. but, a little hard to wrap. not going to venture a guess if pyqt gets it right or not. not to mention how bungled up OS process control still is. process control will be essential to any inter-process operations. that is, unless you backslide into wanting to build everything "in" and invent everything new again. re: blender, I haven't looked at blender code in a while, but I would be shocked if there weren't some well established way to hook into a script. sounds like noone has found them yet.

not sure how to grab a window handle on other OS but for windows it's fairly straight forward. blender or GTK could setup blocks. another great Qt based project is universal indenter, a front end

for many indenters for many languages. this would be a good place to look for how to manage inter-process communication in Qt. a first class editor will have to include first class importer for javascript at the least and probably lua and one or two others. one could imagine niceties like clickable links on #include files. right clickable options on them such as import, simple view, htmlize.

also about styles, astyle has the options on the commandline, the builtin/compiled in defaults and an ~/.astyle.rc for personal style. some will find an indenter that has no options useless. I know the indenter created is purely for internal use, as it were, at this point. adding selectable options later will complicate the program and for most use will have little payback. you may as well expect to have some want a plugable option for style. exposing a general use tokenizer could have many callers.
.. @+node:ekr.20110529115328.18238: *5* Unlikely: Emacs related
I'll do these if and and only if somebody asks for them.
.. @+node:ekr.20110529104352.18248: *6* Complete k.universalDispatcher
.. @+node:ekr.20110529104352.18249: *6* Complete number-to-register command
.. @+node:ekr.20031218072017.753: *6* Emacs comint-mode
Summary: The improved Execute Script command does most of this

Michael Manti
mmanti@mac.com

The 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.20060116090428: *6* Expand 'point' so it indicates node as well as text location
.. @+node:ekr.20071004120359.2: *6* expand-region-abbrev
See: regionalExpandAbbrev.

You may wish to expand an abbrev with a prefix attached; for example, if `cnst' expands into `construction', you might want to use it to enter `reconstruction`. It does not work to type recnst, because that is not necessarily a defined abbrev. What you can do is use the command M-' (abbrev-prefix-mark) in between the prefix `re' and the abbrev `cnst`. First, insert `re`. Then type M-'; this inserts a hyphen in the buffer to indicate that it has done its work. Then insert the abbrev `cnst'; the buffer now contains `re-cnst'. Now insert a non-word character to expand the abbrev `cnst' into `construction'. This expansion step also deletes the hyphen that indicated M-' had been used. The result is the desired `reconstruction'.

If you actually want the text of the abbrev in the buffer, rather than its expansion, you can accomplish this by inserting the following punctuation with C-q. Thus, foo C-q , leaves `foo,' in the buffer.
.. @+node:ekr.20060123091352: *6* Incremental search in switch-to-buffer
.. @+node:ekr.20060628103226.3: *6* Make sure repeat counts work on basic editing commands
.. @+node:ekr.20051021074728: *6* Space completion
.. @+node:ekr.20100830120622.5829: *5* Unlikely: Improve python import
> > Hmm, I guess that would be more clear, although I think I'd like an option
to include it in the following def to avoid

> > Decoration
> > index
> > Decoration
> > add_user
>
> Sure.  Decorations must always be part of a definition.

Well, personally I'd like to have them included in the definition, but I think Kent's preference for a separate node is reasonable to. If your function and hence definition node is called "pluralize", and it's decorated with something like "@authenticate_user", you may never check the innocent looking pluralize definition to find out what on earth's triggering the mysterious network database call. And this isn't a completely specious example, authentication may have been added to stop pluralize being used in a user existence detection exploit or something. OTOH in well behaved code like CherryPy apps you don't want a separate node for every @cherrypy.expose.

Bottom line is I think we're asking for a set of @settings to fine tune python import behavior::

    @python_import_interdef = previous | next | own_node | ai
    @python_import_decoration = next | own_node

I'm not sure I believe the AI option is possible / practical, and am not asking for it, just listing it :-)

I'd also like::

    @python_import_init_in_class_node = true | false

as often there's more docs on a class in the __init__ than the class docstring.

I think that's really all we're talking about, some @settings to test during import.
.. @+node:ekr.20150408193842.1: *5* Unlikely: Limit searches so clones are found at most once
This doesn't seem very important in practice.

An easy workaround is to start the search from a place where clones are likely to be found just a few times.
.. @+node:ekr.20041016134312.2: *5* Unlikely: Standard Weave command
Use noweb and TeX, or maybe Pyx.
.. @+node:ekr.20160405063304.1: *4* Won't do
.. @+node:ekr.20131121050226.16327: *5* Won't do: reload command
- Don't reload any files!
- Only reprocess leoSettings.leo or myLeoSettings.leo if they are actually open.
- Change LoadManager to handle a reload flag.
.. @+node:ekr.20130806072439.21443: *5* Won't do: threaded saveAll()
From: Terry Brown <terry_n_brown@yahoo.com>

I often need to save 4, 6, even more open changed Leo files at once.  Mainly when I'm filing / adjusting todo items, although at the end of a session having 4 changed files open can't be that unlikely.

So it would be really nice if c.saveAll() could be threaded.  Even as I write this, it gets more complicated...

  - each thread should do no user interface calls, or at least no calls
    that aren't deferred to the main thread

    - that's ok, would take quite a bit of tracing to catch them all,
      but doable - except - plugins called from save hooks might break
      the rule

  - updating recent files list would have to be done properly, not a
    big deal

  - multiple threads saving to the same external files would be a
    problem, that's the complication that only just occurred to me

I don't typically have the same external file referenced from multiple Leo files, why would you do that... so the last problem, although potentially major, might be theoretical more than practical.

Hmm, well it's a thought.  First thing to check, is saving IO bound or CPU bound...
.. @+node:ekr.20130806072439.21444: *6* Re: threaded saveAll()
From: "Ville M. Vainio" <vivainio@gmail.com>

Since the flat document is a sort of "rambling" blue sky topic, I added some more thought on G+ leo community instead of increasing mailing list noise:

https://plus.google.com/103097156557482112329/posts/Vp5ansTdLwq
.. @+node:ekr.20130806072439.21445: *6* Re: threaded saveAll()
From: "Ville M. Vainio" <vivainio@gmail.com>

I'm pretty sure saving is cpu bound; for "normal" size documents, flushing that kind of stuff to disk (or memory buffers that are to be written to disk) shouldn't take significant amount of time.

.. @+node:ekr.20130806072439.21446: *6* Re: threaded saveAll()
From: Terry Brown <terry_n_brown@yahoo.com>

On Sat, 9 Mar 2013 14:46:09 -0600
Terry Brown <terry_n_brown@yahoo.com> wrote:

> I guess this is a wishlist item - I suspect it's a result of my
> workflow that might be quite different from other peoples, but I often
> need to save 4, 6, even more open changed Leo files at once.  Mainly
> when I'm filing / adjusting todo items, although at the end of a
> session having 4 changed files open can't be that unlikely.

I've just found that, because these todo items are always in the outline itself and not external files, I can just do 'write outline only' on all the open outlines, and this is much faster and smooths out the bump in my workflow that got me started thinking about this.
.. @+node:ekr.20130806072439.21447: *6* Re: threaded saveAll()
From: Terry Brown <terry_n_brown@yahoo.com>

On Sun, 10 Mar 2013 08:13:41 +0200
"Ville M. Vainio" <vivainio@gmail.com> wrote:

> I'm pretty sure saving is cpu bound; for "normal" size documents, flushing
> that kind of stuff to disk (or memory buffers that are to be written to
> disk) shouldn't take significant amount of time.

Probably right, so could you use `multiprocessing` instead of `threading`?  More challenging implementation wise, but I'm wondering if it's even possible, in terms of handing over the in-memory data structure?
.. @+node:ekr.20130806072439.21448: *6* Re: threaded saveAll()
From: "Ville M. Vainio" <vivainio@gmail.com>

Multiprocessing based implementation will likely be quite hard, and once you walk the trees anyway and copy the data over the process boundary, it could cause bad pauses in execution.

I have often thought how nice it would be to have "flat" storage for the leo document, so that you could just copy over a flat chunk of memory and let other processes traverse that. Doing that is a somewhat nontrivial undertaking, to say the least :).

I'd just start with threads, despite the GIL problems.
.. @+node:ekr.20111017132257.15883: *5* Won't do: Use IPython completion
http://groups.google.com/group/leo-editor/browse_thread/thread/014fe61ff9480b2b

I don't know if this is relevant or not, but the IPython autocompletion
capability is awesome.

If I'm investigating code I tend to do the following.

list the modules in a package:
In [1]: from fs import <tab>

this lists the modules, in a package so I pick one
In [1]: from fs import osfs
<the osfs entry is tab-completable>

now I can check the usage of fs.osfs
In [2]: osfs? <enter>

or the source:
In [2]: osfs?? <enter>

or the contents of the module
In [2]: osfs. <tab>

I can instantiate a class:
In [3]: myfs = osfs.OSFS('/')

and examine the ivars and methods:
In [4]: myfs. <tab>

It is such an efficient way to learn and remember the details of code.

I know a bunch of work was done on Leo/IPython integration, don't
know the current status, my wish of synchronized IPython and Leo
may well be one of the many granted wishes I have forgotten about.

I certainly think IPython autocompletion is the gold standard.

===== EKR:

This can't be done because IPython has access to live objects.  Leo does not.
.. @+node:ekr.20150420100543.1: *3* Config
.. @+node:ekr.20111026075003.16481: *4* Unlikely: Support ~/.leo_config.py
Supposedly would make Leo more professional/standard. However, Leo has plenty of ways to execute code or set settings at startup. Nobody is asking for it.
.. @+node:ekr.20081119132758.2: *4* Won't do: @ifgui in settings trees
@language rest

This could be done now that gui's are created on the command line.
However, it's not useful because the only gui is Qt.

Note: @ifplatform does work: 

​​Also, @if-os and @if-env aVar == aValue

@language python

.. @+node:ekr.20150412054121.1: *3* Directives
.. @+node:ekr.20130806072439.20369: *4* @paragraph(s)
From: <offray@riseup.net>

I have been using txt2tags + Nested Editor to produce structured docs in 
a light markup and exporting them to HTML and LaTeX > pdf. The fine 
tunning on the pdf output is done by editing the LaTeX source in Leo. I 
like the aesthetic of the source code and the outputs and I have 
contacted the Nested author in order to get some cross-pollination 
between it and Leo [1].

[1] 
https://groups.google.com/group/nestededitor/browse_thread/thread/7068e3cd229d4614 

Now I think that is time to start hacking Leo for a better support of my 
work flow and the first thing I would like to have is a "@paragraph" 
directive that works the same as @rst-no-head but can be used in any 
part of a (sub)tree, even if is not @rst (sub)tree. This would come 
handy in chunking and reassembling LaTeX docs without marking up the 
parts with "<<chunk>>" tags.

===== EKR

Interesting idea. Please file a wishlist bug at https://bugs.launchpad.net/leo-editor.

===== offray As I have say repeatedly I'm an "end user" 
of Leo and I have browse the doc about developing in Leo in [2] and I 
plan to follow it as a tutorial, but any pointer to a more detailed 
section to pay attention or to the Leo trees to start hacking is welcomed

[2] http://webpages.charter.net/edreamleo/scripting.html

.. @+node:ekr.20031218072017.797: *4* Won't do: @file http & @file ftp
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 ?
.. @+node:ekr.20031218072017.810: *5* 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.20031218072017.745: *4* Won't do: @first <n>
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
#@+leo 
@verbatim
@verbatim
@verbatim
#@+node:0::@file /tmp/firstcheck.py 
@verbatim
@verbatim
@verbatim
#@+body 
@verbatim
@verbatim
@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@@first 
@verbatim
@verbatim
@verbatim
#@+doc 
# 
# How many firsts do I get? 

@verbatim
@verbatim
@verbatim
#@-doc 
@verbatim
@verbatim
@verbatim
#@@c 
Start code. 
@verbatim
@verbatim
@verbatim
#@-body 
@verbatim
@verbatim
@verbatim
#@-node:0::@file /tmp/firstcheck.py 
@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.20040216054459: *4* Won't do: @h @f @endh and @endf directives
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.20041130104552: *4* Won't do: bird-track programs
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 

===== EKR: @clean eliminates this problem.
.. @+node:ekr.20031218072017.805: *4* Won't do: 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.20141103113220.10: *4* Won't do: parameterized template nodes
From: Alexandre_Toledo <jalexandretoledo@gmail.com>

As I use Leo to write PL/SQL code, I need to write similar text several times, changing only small parts of it. It would be great if I could create a node with the "template" and then clone it everywhere it should be written, and then providing the parameters to be used in this writing.

Let me try to clarify it. I'd like to create a tree like this:

    +- @file something.sql
       +- Section 1
          + << Clone >> with Parameters A, B
       +- Section 2
          + << Clone >> with Parameters C, D

In this tree, both "Clone" nodes would be generated from a template specified somewhere in the tree, and would have parts of its text replaced with values "A" and "B" in Section 1, and "C" and "D" in Section 2.

I've searched but couldn't find anything like this, then I've thought of trying to write a hook to intercept the "save" command, but couldn't think of a way to pass the parameters; I think the obvious way would be to put the parameters after the "<< >>", but then all cloned nodes are changed, so it wouldn't work.

Another alternative would be creating some kind of directive @something, but I have no idea of how to do that.

Any ideas?

===== EKR: This is not likely ever to happen.
.. @+node:ekr.20141103113220.11: *5* OP: Re: Parameterized template nodes
I've tried it and it's great, I think it will be useful, but it's not what I was thinking of...

Let me try to explain what I had thought about.  What I would like to do is:

 1. create a new .leo file
 2. add a "template" node (eventually with sub nodes) with some ${schema}
    and ${table} macro place holders in its contents
 3. add a @file node to the .leo file
 4. add to this @file node a new one with definitions such as
    schema=3DSCHEMA_NAME and table=3DTABLE_NAME
 5. add as a sub node to this last one a clone from the "template" node;
 6. then, when I save everything, the @file would have "SCHEMA_NAME" and
    "TABLE_NAME" everywhere a "${schema}" or a "${table}" were in the original
    template node.

It would be important that, when I reopen the .leo file later, the macros in the @file node where shown as ${schema} and ${table}, and not as it's substituted text.

Now that I've described it, I can't see how it would be done... The ${macro} place holders should be on the contents of the @file node, so after substitution, how could we recover it?

That's also why the code from Jacob is not what I need (but I'm already thinking of other uses for it :) ): it will create a text when the button is pressed, but the generated nodes will be just static text.
.. @+node:ekr.20140824043305.18292: *3* Docs
.. @+node:ekr.20130909111702.13058: *4* Allow paypal donations to Leo
.. @+node:ekr.20130503155210.24814: *4* Tutorials/Screencasts (revise)
Rewrite in screencast-script style:
- Docstrings for the most important plugins.
- All help-for-<topic> text.
- Leo's tutorials.

** Screencast style for plugins docstrings.
* Screencast style for help messages.
* Screencast style for tutorials.
* Create YouTube channel for Leo screencasts.

Topics:
- Minibuffer: alt-x, tab-completion.
- @button.
- @rclick
- Find/Change (done)
- execute-script.
- bookmarks.py.

.. @+node:ekr.20160318134258.1: *4* Wiki stuff
.. @+node:ekr.20130806072439.21301: *5* LeoWiki using GitIt and Pandocs
From: HansBKK <hansbkk@gmail.com>

This is highly off-topic for most on the list, so feel free to ignore, but anyone using Leo for single-source documentation generation/conversion, including future googlers, please reply with comments or notes on your experiences.

I have been advocating the idea of pushing Leo-derived content to DokuWiki as a platform for "wiki-publishing" to enable collaborative/community editing of content (1 <../d/msg/leo-editor/fSzVi1Rh5Tg/uu85satgb9YJ>, 2<../d/msg/leo-editor/xf6_HBxlV_c/4RgGYdDh8ywJ>). I've also talked about the markup syntax/doc generation tool Txt2tags (1<https://groups.google.com/d/msg/leo-editor/nNEnxoohFBM/XkMPQhqhDRsJ>, 2 <https://groups.google.com/d/msg/leo-editor/HBhBnAyVG3E/UXHC1jq50iYJ> ).

However, I have recently learned of the wiki platform Gitit <https://github.com/jgm/gitit#readme>, which apparently, like DW, also uses plain-text files rather than a database back-end, and integrates not only with git but mercurial (and darcs).

Gitit also incorporates the Pandoc <http://johnmacfarlane.net/pandoc/>project for its markup syntax, therefore enabling not only markdown but reST as a master source input format, while DokuWiki has its own (yet another unique) markup syntax 8-(

With the increasing likelihood that I'll be using Leo as the centerpiece of my toolchain, plus the fact that Pandoc is much more actively maintained, it's starting to look worth my while to consider switching my "master source" content syntax over from Txt2tags to reST. The only downsides are that Gitit is a Haskell project rather than Python, and one thing I like about Txt2tags is its support for conversion to AsciiDoc, rather than Pandoc's direct output to full-blown DocBook XML - but apparently even that's in the works in Pandoc's dev version.

Anyone in the Leo community using Gitit, especially for use beyond simple code documentation?
.. @+node:ekr.20130806072439.21302: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: "Edward K. Ream" <edreamleo@gmail.com>

On Thu, Jan 19, 2012 at 8:09 PM, HansBKK <hansbkk@gmail.com> wrote:
> This is highly off-topic for most on the list, so feel free to ignore, but
> anyone using Leo for single-source documentation generation/conversion,
> including future googlers, please reply with comments or notes on your
> experiences.

No experience myself, but thanks for these interesting links.

EKR
.. @+node:ekr.20130806072439.21303: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: =?UTF-8?B?T2ZmcmF5IFZsYWRpbWlyIEx1bmEgQ8OhcmRlbmFz?= <offray@riseup.net>

Hi,

I made some errors.

In this part:

El lun 23 ene 2012 07:22:21 COT, Offray Vladimir Luna C=E1rdenas escribi=F3=
:
>
> but at the end we could not intervene MoinMoin as much as we would=20
> like because of the server permissions, that why I started to look=20
> more integrated solutions of the development and deployment=20
> environment as web2py or seaside, but they're not wiki engines=20
> properly but web application frameworks (where you could build a=20
> wiki-engine if needed). But surely
>

"But surely" was not intended.

Cheers,

Offray

.. @+node:ekr.20130806072439.21304: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: <offray@riseup.net>

El jue 19 ene 2012 21:09:26 COT, HansBKK escribi=F3:
> This is highly off-topic for most on the list, so feel free to ignore, bu=
t
> anyone using Leo for single-source documentation generation/conversion,
> including future googlers, please reply with comments or notes on your ex=
periences.

I'm using Leo in that scenario (for writing my Thesis and I hope my=20
students will use it in a similar fashion), so is not off-topic for me=20
and not for people who is using Leo primary for documentation.

> I have been advocating the idea of pushing Leo-derived content to DokuWik=
i as a
> platform for "wiki-publishing" to enable collaborative/community editing =
of
> content (1<../d/msg/leo-editor/fSzVi1Rh5Tg/uu85satgb9YJ>, 2
> <../d/msg/leo-editor/xf6_HBxlV_c/4RgGYdDh8ywJ>). I've also talked about t=
he
> markup syntax/doc generation tool Txt2tags (1
> <https://groups.google.com/d/msg/leo-editor/nNEnxoohFBM/XkMPQhqhDRsJ>, 2
> <https://groups.google.com/d/msg/leo-editor/HBhBnAyVG3E/UXHC1jq50iYJ>  ).


When you suggested DocuWiki I thought of MoinMoin which has also=20
support of plain files as storage mechanism but is also scalable to=20
databases if this is needed and it supports reStructuredText and is=20
made in python, a language that "leonizens" are familiar with.

> However, I have recently learned of the wiki platform Gitit
> <https://github.com/jgm/gitit#readme>, which apparently, like DW, also us=
es
> plain-text files rather than a database back-end, and integrates not only=
 with
> git but mercurial (and darcs).
>
> Gitit also incorporates the Pandoc<http://johnmacfarlane.net/pandoc/>  pr=
oject
> for its markup syntax, therefore enabling not only markdown but reST as a=
 master
> source input format, while DokuWiki has its own (yet another unique) mark=
up
> syntax 8-(
>
> With the increasing likelihood that I'll be using Leo as the centerpiece =
of my
> toolchain, plus the fact that Pandoc is much more actively maintained, it=
's
> starting to look worth my while to consider switching my "master source" =
content
> syntax over from Txt2tags to reST. The only downsides are that Gitit is a
> Haskell project rather than Python, and one thing I like about Txt2tags i=
s its
> support for conversion to AsciiDoc, rather than Pandoc's direct output to
> full-blown DocBook XML - but apparently even that's in the works in Pando=
c's dev
> version.
>
> Anyone in the Leo community using Gitit, especially for use beyond simple=
 code
> documentation?

Now that I'm using Leo + Fossil for my documentation related matters=20
and distributed work I certainly think that a distributed off-line=20
collaboration system for documentation is needed and, if MoinMoin can't=20
support the use of distributed wikis (and seems is not planned or in=20
development [1][2]) Gitit would be a nice place to start with this idea=20
and would offer advantages over the non-distributed and outdated Zope's=20
actual implementation, so, interested ones in the community could offer=20
an implementation of Gitit. On a related matter one of the problems I=20
see with actual server technology is its gigantism which concentrates=20
power in the people who has the resources, knowledge and time to=20
possess, understand and administer/intervene this technology so a=20
Global South Test for me about which server technology to choose is:=20
"it runs from a USB thumb drive?". This, for example, favors=20
Web2py/Smalltalk instead of Zope and Fossil instead of GitHub. May be=20
you should put this in the panorama when you judge GitIt or=20
Haskell/Pandoc. Pandoc, by the way, was for me a compelling reason to=20
learn Haskell[3] (but I thought that I would learn Smalltalk before)=20
because it deals elegantly with a problem in the diversity of markup=20
languages (txt2tags makes something similar but only in one way=20
translation) and for me the point of using Leo is having a tool to deal=20
consistently with diversity in the "sub-optimal distopic world of=20
everything is a file".

[1] http://moinmo.in/PawelPacana/MercurialBackend
[2] http://moinmo.in/MoinMoin2.0
[3] http://learnyouahaskell.com/

We could get philosophical here, and think about different programming=20
paradigms and languages that implement them with elegant syntaxes, like=20
Smalltalk, Haskell and Python versus the non elegant ones of .java, php=20
or ... (put your hated language here) and how this elegant syntaxes,=20
languages and computer using experience could cross-pollinate. If that=20
is the case, may be reading some about Combined Object Lambda=20
Architecture[4] and the comprehensive "Concepts, Techniques, and Models=20
of Computer Programming" by Van Roy and Haridi would be a nice reading.=20
Some times I dream of a world connected diversity where all the=20
problems of computer interaction can be solved by expressing that=20
diversity in fundamental constructs that respect it at the same time=20
that bring consistency and interface solving the apparent chaos and=20
noise.

[4] https://en.wikipedia.org/wiki/COLA_%28software_architecture%29

Cheers,

Offray

.. @+node:ekr.20130806072439.21305: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: Matt Wilkie <maphew@gmail.com>

> Wow I think that this is the first time I have the opportunity to
> write (curiously in English instead of my native tongue) about
> that dystopy, because most of the time I just talk about this
> with my students or friends but not as detailed and contextually,
> so thanks for bring this up Hans, and thanks everyone else
> here who is still reading :-)

I am reading, and enjoying. The clouds you've placed in my mind are
making interesting shapes and I am intrigued. ;-)
.. @+node:ekr.20130806072439.21306: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: =?UTF-8?B?T2ZmcmF5IFZsYWRpbWlyIEx1bmEgQ8OhcmRlbmFz?= <offray@riseup.net>

Hi,

El lun 23 ene 2012 01:18:48 COT, HansBKK escribi=F3:
> Thanks Offray for your detailed and informative response.

Well I'm enjoying also these talks with you. I think that putting=20
documentation also in the center is required if we want to break the=20
Leo's self-fulfilled prophesy about being a "ghetto tool" for=20
programmers only and I want this in the best way.

[..]
>
> I for some reason missed the MoinMoin's "simple page storage" option - th=
anks so
> much for pointing that out. For all the reasons you cite, and most import=
antly
> is much more mainstream, more actively developed and well-supported than =
Gitit,
> I'll definitely give it a higher priority in my testing.
[...]

I enjoyed using MoinMoin for this project:

http://el-directorio.org/

but at the end we could not intervene MoinMoin as much as we would like=20
because of the server permissions, that why I started to look more=20
integrated solutions of the development and deployment environment as=20
web2py or seaside, but they're not wiki engines properly but web=20
application frameworks (where you could build a wiki-engine if needed).=20
But surely

>      the "sub-optimal distopic world of everything is a file".
>
>
> I personally disagree with your dislike for "everything is a file" - I se=
e that
> principle as a fundamental part of the *nix tool philosophy, and IMO this=
 is a
> perfect example:
>
>      I certainly think that a distributed off-line collaboration system f=
or
>      documentation is needed and, if MoinMoin can't
>
>      support the use of distributed wikis (and seems is not planned or in=
 development
>
> To my mind, any wiki platform that can store the page data as plain text =
(as
> opposed to binary/database), in a format suitable for diff tools ("light"=
 markup
> as opposed to html/xml) can make use of whatever VCS for distribution/rep=
lication.

You're right and I like the idea of "everything is a something" when=20
that something is powerful unifying idea. That's the case with Unix's=20
"everything is a file" or Smalltalk's "everything is an object" (in=20
Unix you have also every tool makes one thing and makes it right,=20
combined with pipes). For me these two paradigm's were the ones that,=20
in 70's, were fighting for the mind share  about computer experience of=20
today and both of them won in a dystopic way, but for me "taking genius=20
to understand Unix simplicity"[0], was even more dystopic. When you're=20
trying to empower users the impedance between development and=20
deployment shows the dystopia, at least compared with the original=20
visions, so most of the "end users" cant change the tool that changes=20
them, so, someone else is making decisions about that changes and that=20
users.

[0] https://en.wikipedia.org/wiki/Unix_philosophy#Quotes

I like the simplicity of light markups and I try myself of not using=20
explicitly nothing as xml and I like also the idea of the light markup=20
being used by VCS tools. That's not where dystopia lies. The problem is=20
not about files or structure but about "meta-structure" (structure=20
talking about structure, as in meta-languages), specially=20
self-referential meta-structure, because self-referential=20
meta-structures are the key for self-directed change, as opposed with=20
change directed by others. When you see how the "world of everything is=20
a file" talks about itself, there is a lot of impedance and=20
discontinuity between source code, binary, apps and docs and there is a=20
long path for the user who is confined to using apps to create docs,=20
but never change the apps that could let she/he to change his/her=20
writing and that's why I want to use Leo this semester with=20
non-technical writers to explore the way that writing change the tool=20
that writes and not only the human who does.

For me a unified emergent meta-structure in the world of "everything is=20
a file" is where lies the power of Leo. You can use an outline to=20
change the way that Leo behaves and that's why having the Leo's=20
self-referential meta-structure is more powerful that the "dystopic=20
world of everything is a file" (in that world you don't have=20
meta-structure, only structure, mostly for storage purposes and the=20
intelligence to read/process it is mostly outside the file, in the=20
human reader, the compiler or the binary). What Leo does is to create=20
self-referentiality in the world of everything is a file by introducing=20
outlines that can talk/structure the files and that can talk about=20
outlines, i.e outlines that can talk about files and about themselves=20
and can reprogram the way Leo itself works, and so Leo is bridging the=20
gap between objects and files in a valuable and unique way.  But we=20
need still to improve, specifically we need a more elegant way to talk=20
about that files, specially about their changes in time, because is in=20
that change where talking with the distopic world has more problems and=20
possibilities, and that way I'm making the Fossil/VCS experiment and=20
also.

Wow I think that this is the first time I have the opportunity to write=20
(curiously in English instead of my native tongue) about that dystopy,=20
because most of the time I just talk about this with my students or=20
friends but not as detailed and contextually, so thanks for bring this=20
up Hans, and thanks everyone else here who is still reading :-)

>      On a related matter one of the problems I see with actual server tec=
hnology
>      is its gigantism which concentrates
>      power in the people who has the resources, knowledge and time to pos=
sess,
>      understand and administer/intervene this technology so a Global Sout=
h Test
>      for me about which server technology to choose is: "it runs from a U=
SB thumb
>      drive?".
>
> IMO "server" is a function, not a question of scale or complexity - the b=
etter
> question for my workflow is "does the app run portably?". I personally fi=
nd
> actually running stuff from flash drives too slow and data-dangerous.

I'm agree with you. Server and gigantism have not to be equal, but=20
unfortunately in the "dystopic informatic world" (where the previous=20
dystopia is just a part) they're most of the time. Portability is the=20
key, not flash drives. In my context they're just a medium to ask the=20
same as you, but also a way to let people take the technology with=20
them, no matter if they have access to a "classical" server.

>
> So far I've found that anything that runs under Linux is inherently porta=
ble in
> that sense.

Agreed. Having Leo + Fossil + Laptop ( ;-P ) gives me some kind of=20
portability, but we need more. That's why I think that we need a self=20
contained version of Leo with a default discourse about file flat world=20
change in time (at least for Windows), but ideally would be nice to=20
have something like the self-contained multiplatform Pharo's One Click=20
Experience[1]

[1] http://www.pharo-project.org/pharo-download

>      This, for example, favors Web2py/Smalltalk instead of Zope and Fossi=
l
>      instead of GitHub.
>
> I haven't any experience with these others, but note that Git does not =
=3D GitHub.
> I share your dislike for server/storage platforms out of my direct contro=
l, not
> least for privacy/security issues for many use cases. If I used Git for d=
ata
> distribution I wouldn't use GitHub, and my understanding is that even "Gi=
t for
> Windows" is already fully portable.

Oohh I don't make myself clear, sorry. Fossil compared with GitHub was=20
not because of the equivalence of Git and GitHub, but because of the=20
integration of web characteristics of GitHub in Fossil (wiki, tickets,=20
web interface and so on).

> For myself, I think mercurial would be a good fit, but my main point is t=
hat any
> moves toward a "distributed Leo" should IMO be VCS-agnostic, just as my p=
lans
> for enabling community editing of Leo-managed content will be wiki-platfo=
rm
> agnostic.

I fully share your opinion on that subjects, but in this case I want to=20
start by some specific implementation from which one start to abstract=20
that to think abstractly without any particular implementation in the=20
road, which is not your case, I just point to different implementation=20
strategies based on the same agnosticism/diversity as a valuable thing=20
to preserve.

> To me, the key enabler for that is "everything as a file". . .

For me the enabler is self-referential meta-structure

Thanks,

Offray

.. @+node:ekr.20130806072439.21307: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: HansBKK <hansbkk@gmail.com>



Content-Transfer-Encoding: quoted-printable

On Monday, January 23, 2012 7:22:21 PM UTC+7, Offray Vladimir Luna C=E1rden=
as=20
wrote:
>
>
> documentation also in the center is required if we want to break the Leo'=
s=20
> self-fulfilled prophesy about being a "ghetto tool" for programmers only


Usability for clueless noobs is a lot of work, probably harder than the=20
complex whiz-bang functionality part.

And to take something as powerful and flexible as Leo and make it=20
accessible for noobs would require "lobotomizing" it to some extent, at=20
least hiding those features that weren't relevant to the intended=20
more-mainstream task at hand.

I imagine something like "application mode" flag at launch time=20
  - Leo as a journaling tool (like Rednotebook on steroids)
  - Leo as an Evernote-style note-taking brain extension
    - with user-accessible tagging, perhaps multiple headings per node?
  - Leo as a delicous-replacement (import/export/backup) bookmarks=20
management tool
  - Leo as a single-source multiple-output documentation management=20
meta-organizer and conversion-supporting tool

etc - very different UX - pane layouts, menu structures etc - for each=20
mode, but the same underlying code and data structures

but at the end we could not intervene MoinMoin as much as we would like=20
> because of the server permissions


ACLs is one of DokuWiki's strengths, as they target the corporate world (as=
=20
much as a FOSS tool can 8-)

> So far I've found that anything that runs under Linux is inherently=20
> portable in
>
> > that sense.
>
> Agreed. Having Leo + Fossil + Laptop ( ;-P ) gives me some kind of=20
> portability, but we need more.
>
Pocket-size portable HDD with USB2 / SATA2  (will soon start converting to=
=20
v3 of both, used to use Firewire), booted up using any arbitrary internet=
=20
cafe / friend / customer desktop.

ideally would be nice to have something like the self-contained=20
> multiplatform Pharo's One Click=20
> Experience[1]
>
> [1] http://www.pharo-project.org/pharo-download
>
Most of the mainstream distros now have easy-to-customize=20
create-your-own-distro LiveCD/USB+persistent storage projects. I've got a=
=20
portable drive that launches a GRUB2 boot menu letting me choose between=20
various configs of Fedora, Red Hat, Debian, Ubuntu and Slax, all of which=
=20
access shared /home and server-data partitions (which gets sync'd with my=
=20
central filer). Check out Sardu <http://www.sarducd.it/>, which also=20
handles all the mainstream recovery/rescue/sysadmin tools like grml,=20
pmagic, sysresccd - even BartPE, Win7 repair etc all on the same pocket=20
drive. . .
=20

> integration of web characteristics of GitHub in Fossil (wiki, tickets, we=
b=20
> interface and so on).
>
=20

> agnosticism/diversity as a valuable thing to preserve.

=20
Personally I prefer using CLI batch/scripts and/or TortoiseXX rather than a=
=20
web interface for my VCS usage, and my ticket/project management/GTD system=
=20
of choice is Redmine (likely Chili soon).=20

Both of these integrate well with the important VCSs, so when I finally get=
=20
away from SVN and get familiar with the distributed new kids, I can keep my=
=20
other tools - Redmine/Chili now has such a custom-infrastructure encrusted=
=20
around it sync'ing with gcal, printing pocketmods for my calendar and=20
@context to-do's that have become indispensable to my day-to-day life=20
management.

=20

> "dystopic world of everything is a file" (in that world you don't have=20
> meta-structure, only structure, mostly for storage purposes and the=20
> intelligence to read/process it is mostly outside the file, in the human=
=20
> reader, the compiler or the binary). What Leo does is to create=20
> self-referentiality in the world of everything is a file by introducing=
=20
> outlines that can talk/structure the files and that can talk about=20
> outlines, i.e outlines that can talk about files and about themselves=20
> and can reprogram the way Leo itself works, and so Leo is bridging the ga=
p=20
> between objects and files in a valuable and unique way.  But we need stil=
l=20
> to improve, specifically we need a more elegant way to talk about that=20
> files, specially about their changes in time, because is in that change=
=20
> where talking with the distopic world has more problems and=20
> possibilities, and that way I'm making the Fossil/VCS experiment and also=
.
>

> To me, the key enabler for that is "everything as a file". . .
>
> For me the enabler is self-referential meta-structure
>
=20
I don't see any conflict between the two, IOW no inherent limitations to=20
"everything is a file" other than (to me, at least within the personal-use=
=20
prototyping context) unimportant factors like relative speed/scaleability -=
=20
it's "just" an implementation detail.=20

The various levels of structural overlays as presented within Leo as=20
"uber-manager of the metadata" can be as flexible and complex as can be,=20
and still be stored/distributed as diffed/versionable/convertable files at=
=20
whatever appropriate level of granularity to support integration with=20
outside toolchains. To the extent design choices are made that "lock in" to=
=20
a particular "higher level" technology bet, e.g. a specific database engine=
=20
or DVCS, then much higher-level programming/sysadmin skills are required in=
=20
order to integrate Leo into the thousands of mainstream tools that have=20
evolved over time to support structured-plain-text.

Look at source code - after all these decades, it's still stored as plain=
=20
text in a filesystem. There's a reason for that - any language that=20
required its modules/functions/objects whatever to be stored in a=20
"proprietary" database engine for example would have very limited uptake,=
=20
because coders would have to put so much effort into infrastructure=20
overhead work to be able to keep working with their preferred toolset.=20
Anyway 'nuff said on that.

.. @+node:ekr.20130806072439.21308: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: Largo84 <Largo84@gmail.com>

This topic is of much interest to me as I use Leo primarily for writing 
documentation (mostly LaTex, some html and some rST). I haven't worked w/ 
Pandoc yet but am interested in some of the possibilities. Thanks for the 
links, I'll check them out.
.. @+node:ekr.20130806072439.21309: *6* Re: Leo doc-generation and Wiki integration - GitIt and Pandocs
From: HansBKK <hansbkk@gmail.com>



Content-Transfer-Encoding: quoted-printable

Thanks Offray for your detailed and informative response.

On Friday, January 20, 2012 5:34:21 PM UTC+7, Offray Vladimir Luna C=E1rden=
as=20
wrote:
>
> When you suggested DocuWiki I thought of MoinMoin which has also support=
=20
> of plain files as storage mechanism but is also scalable to databases if=
=20
> this is needed and it supports reStructuredText and is made in python, a=
=20
> language that "leonizens" are familiar with.
>
 I for some reason missed the MoinMoin's "simple page storage" option -=20
thanks so much for pointing that out. For all the reasons you cite, and=20
most importantly is much more mainstream, more actively developed and=20
well-supported than Gitit, I'll definitely give it a higher priority in my=
=20
testing.

=20

> the "sub-optimal distopic world of everything is a file".
>
 =20
I personally disagree with your dislike for "everything is a file" - I see=
=20
that principle as a fundamental part of the *nix tool philosophy, and IMO=
=20
this is a perfect example:

 I certainly think that a distributed off-line collaboration system for=20
> documentation is needed and, if MoinMoin can't=20
>
> support the use of distributed wikis (and seems is not planned or in=20
> development
>
To my mind, any wiki platform that can store the page data as plain text=20
(as opposed to binary/database), in a format suitable for diff tools=20
("light" markup as opposed to html/xml) can make use of whatever VCS for=20
distribution/replication.

=20

> On a related matter one of the problems I see with actual server=20
> technology is its gigantism which concentrates=20
> power in the people who has the resources, knowledge and time to possess,=
=20
> understand and administer/intervene this technology so a Global South Tes=
t=20
> for me about which server technology to choose is: "it runs from a USB=20
> thumb drive?".
>
IMO "server" is a function, not a question of scale or complexity - the=20
better question for my workflow is "does the app run portably?". I=20
personally find actually running stuff from flash drives too slow and=20
data-dangerous.

In my workflow, at the beginning of a session I first sync the relevant=20
data and "portable apps" filesystem branches, then run everything off the=
=20
local HD. At the end of a session I sync it all back - most of the time=20
these days this is to/from a central filer, but I do have portable drives I=
=20
use for this when that's required or more convenient, which then get sync'd=
=20
to the filer next chance I get.

So far I've found that anything that runs under Linux is inherently=20
portable in that sense.
=20

> This, for example, favors Web2py/Smalltalk instead of Zope and Fossil=20
> instead of GitHub.
>
I haven't any experience with these others, but note that Git does not =3D=
=20
GitHub. I share your dislike for server/storage platforms out of my direct=
=20
control, not least for privacy/security issues for many use cases. If I=20
used Git for data distribution I wouldn't use GitHub, and my understanding=
=20
is that even "Git for Windows" is already fully portable.

For myself, I think mercurial would be a good fit, but my main point is=20
that any moves toward a "distributed Leo" should IMO be VCS-agnostic, just=
=20
as my plans for enabling community editing of Leo-managed content will be=
=20
wiki-platform agnostic.

To me, the key enabler for that is "everything as a file". . .
.. @+node:ekr.20060227123536: *5* Mulder: Tiddlywiki and related comments about rendering body text
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.20131213072223.16397: *4* Video tutorials (revise)
Are any more needed?

When ready to release:

- Note to Dave Winer.
- Announce to comp.lang.python & SourceForge.
.. @+node:ekr.20131221065129.16519: *5* - Basic: Basic operations

.. @+node:ekr.20131221065129.16522: *6* Basic focus operations
The presently selected pane has a blue border.
We say that the selected pane **has focus**.

Regardless of what pane has focus:

- Alt-T puts selects the outline pane.
- Alt-D puts selects the body pane.
- Alt-Arrow key select another outline node
  and put focus in the outline pane.

A handy shortcut:

- When the outline pane has focus,
  the Return puts focus in the body pane.
.. @+node:ekr.20131221065129.16524: *6* Basic outline operations
Ctrl-N creates a new file.
Ctrl-S saves the file.

When focus is in the outline pane:

- The Insert key inserts a new node.
  Type the headline text followed by Return.
- The Delete key or the BackSpace key deletes a node.
- Plain Arrow keys select nodes.
- Shift-Arrow keys move nodes.

The following commands work regardless of focus.


- Ctrl-I inserts a new node.
- Ctrl-H edits the headline of the selected node.
- Ctrl-Shift-X deletes (cuts) the node.
  (Ctrl-Shift-C copies the selected node)
- Ctrl-Shift-V copies a previously copied or cut node.
- Alt-Arrow keys select nodes, as in Windows explorer.
- Alt-Shift-Arrow keys move nodes.
- Ctrl-U, Ctrl-D, Ctrl-L and Ctrl-R move nodes up, down, left and right.
- Ctrl-Z undoes the last operation. 
  Ctrl-Shift-Z redoes the last operation.
.. @+node:ekr.20131221065129.16520: *6* Basic text operations
- Return inserts a newline.
- Arrow keys move the cursor by characters.
- Ctrl-Arrow keys move the cursor by words.
- Home and End move the cursor to the start/end of a line.
- PageUp and Page-Down move the cursor by pages.
- Ctrl-Home and Ctrl-End move the cursor to the start/end of the body text.

- Adding the Shift modifier to any of these keys extends the selection:

- Shift Arrow keys.
- Shift-Ctrl-Arrow keys.
- Shift-PageUp and Shift-PageDown.
- Shift-Home and Shift-End.
- Shift-Ctrl-Home and Shift-Ctrl-End.
.. @+node:ekr.20131211054925.16380: *5* - Basic: Creating external files
Using Leo *is* easy.

The rule (of thumb) that helper methods should be children of the method
that calls them instantly reveals that programs are outlines in disguise.
Once you have a way of seeing that fact *at all times*, one can never go
back to the flat, myopic way of seeing. It's really that simple.

And finally, there is @others. I created it within the first hour of
prototyping Leo in the MORE outliner. It has remained unchanged all these
years because it is, fundamentally, a very simple idea.

.. @+node:ekr.20131208103040.16343: *5* - Basic: Getting help
.. @+node:ekr.20131208103040.16342: *5* - Basic: Settings
- focus on visual settings.
@menu
leo-x-pt.leo files.
- Small test .leo files: useful for settings.
.. @+node:ekr.20131121050226.16328: *6* settings vid
open leoSettings.leo.
open myLeoSettings.leo.

Concentrate on:
    - visual settings.
    - keyboard shortcuts.

print-settings, print-bindings, print-commands.

Trick: use small, easily/quickly started, file to test settings.
    Demo: put console *behind* window.
.. @+node:ekr.20131208103040.16350: *5* - Find command (needed?)
- Ctrl-G hides the Find pane.

- Show how to use the minibuffer to discover the toggle commands:
    <Alt-X>tog<tab>f<tab>   or
    <Alt-X>set<tab>f<tab>
.. @+node:ekr.20131116123026.16661: *6* Example
# For the Find screencast.  It could be improved so the differences between nodes is more apparent.
.. @+node:ekr.20131116123026.16662: *7* spam
DEF spam():
    pass
.. @+node:ekr.20131116123026.16663: *7* eggs
def eggs():
    pass
.. @+node:ekr.20131208103040.16344: *5* - Intermediate: Auto-completion
.. @+node:ekr.20131208103040.16349: *5* - Intermediate: Importing files
recursive import.  Where is it?
active-path plugin, 
.. @+node:ekr.20131116212505.16666: *5* - Intermediate: More about scripting
c, g, p: commanders, generators, p.b, p.h etc.

@button (already covered)
@test (already covered)
.. @+node:ekr.20131116212505.16668: *6* Ctrl-B (execute-script)
Ctrl-B executes the Python code in the presently-selected body pane. g.es('hello world')

.. @+node:ekr.20131116212505.16669: *6* Ctrl-B on selected text
print('hi')
print('there')
.. @+node:ekr.20131116212505.16667: *6* g
# g is a Python module containing global utility functions and classes.
# g.es prints its arguments to Leo's log pane.
g.es(g.es)
# g is a large module:
g.es(len(list(dir(g))))
.. @+node:ekr.20120515193246.10087: *3* DOM
.. @+node:ekr.20071001052501: *4* Versioning for nodes
One feature I have not seen in SCS system is something which might be called "history compression": I might be interested in having both version 5 and 6 in my source tree, when the current version is 7, but I am not really interested in the 2000 steps which transformed 5 into 6 (just suggested this feature to the bazaar people). This happens actually quite often to me, since I use the SCS as a back-up system, saving many (uninteresting) intermediate steps while implementing a new feature.
.. @+node:ekr.20111019104425.15896: *4* Enhanced node attributes: ctime, atime, mtime (Kent)
.. @+node:ekr.20160319151013.1: *4* not likely: Multi-threaded trees
https://groups.google.com/d/msg/leo-editor/E0HtQiBRfOg/IOcZMv9vAgAJ

I don't think this feature is worth doing.

It is astoundingly easy to create this multi-dag in Leo.

Each vnode has a parents list and a children list.  All we have to do is replace these two lists by dictionaries whose keys are attributes and whose values are the parents or children lists for those attributes.  Finally, we add Python properties shield the dictionary lookup from the rest of Leo.  We are talking about maybe 50 lines of code!

As far as the rest of Leo is concerned, vnodes still have parents and children lists.  The switcheroo happens totally invisibly, when the user wants to see another view.  The attribute changes and that changes what the vnode dictionary/properties "deliver" to the rest of Leo.
.. @+node:ekr.20160405061740.1: *3* Features
.. @+node:ekr.20150602122614.1: *4* Beautifier warns about long lines
compute_line_length helper: just scans backward.
.. @+node:ekr.20130806072439.21204: *4* Comparison leo outline type with other outliner's types?
From: Todd Mars <tamnt54@gmail.com>

I remember reading -somewhere- about comparing various multi-parent or multi-copy of node outline types (clones vs. backlinks or whatever) but I can't find where I read that. Where is it? Desire to read analysis, isn't that in the leo docs somewhere?

Terry

Personally I think Leo could navigate cyclic graphs, see http://leo.zwiki.org/GraphsInTrees particularly the 'Older notes' section towards the end. But it's a major issue with regard to all the algorithms which don't expect to run in to loops. And the extra layer of connections from the backlinks plugin allows the same functionality, so it may be that it's more an interface issue than a data model issue.

I'd like Leo to be able to behave like CmapTools, http://cmap.ihmc.us/ but maybe it can, essentially, and it's really a matter of defining some new interface bells and whistles.
.. @+node:ekr.20150516123559.1: *4* Doc parts should colorize like rst/md by default
This seems more difficult than I thought.
.. @+node:ekr.20160503093454.2: *4* Ignore URL's in scripts?
@language rest
@wrap

From: HaveF <iamaplayer@gmail.com>

I write a script (say, @button button-1) in leo-file-A.leo, and reuse it by copy(ctrl+shift+c) the button to leo-file-B.leo.

When I'm working on leo-file-B.leo, I may have ideas to improve the @button button-1, but at that time(working on leo-file-B.leo), I may forget where the original place of @button button-1 is. Even I store the original scripts in the default workbook.leo is a tedious work to deal with(open it, locate where the original script is, update it...)

After I add the @url at the first line of @button button-1, I can decide if the improvements what I made on leo-file-B.leo's @button button-1 should or shouldn't be merged to the original and upstream @button button-1(in leo-file-A.leo) easily by just a click.

And if I work on leo-file-C.leo, I want to use the same script, but I just only remember I use the script in the leo-file-B.leo instead of original place. With @url I can easily jump to original place, and copy it to leo-file-C.leo.

Using @url in the leo script, I can make the scripts consistency and
diversity at same time.

===== Feature request

At present, you can use this idea by comment the @url line after jump. If @url isn't comment, the leo-editor will say... SyntaxError: invalid syntax at the @url line.

Maybe it is a good idea to omit the @url line in the script when executing script?

===== EKR

Yes.  I think this is a good idea.  A similar idea occurred to me when looking at @rclick nodes.  

At present, the context_menu plugin contains an ugly hack:  it allows an @rclick node to *follow* an @button node.  This is needed at present when the @button node contains @others: the @rclick node can't be part of the script "pulled in" by @others.

It would be much more elegant to ignore @rclick nodes when computing the script.  This would require a change to the @others logic, but I think it is worthwhile.

===== Terry Brown <terry_n_brown@yahoo.com>

I do this kind of thing by keeping buttons in @files...

@file ~/.leo/gen  # general utility buttons
@file ~/.leo/dml  # tools for editing an XML dialect I use
@file ~/.leo/sql  # tools for editing SQL / interacting with server

so changes made in one outline are automatically propagated to other
outlines next time they're reloaded.  You just reference the files
in each outline where you want those buttons.
.. @+node:ekr.20150311051910.4: *4* Improve recovered nodes operation
- Detect changes in root node, if possible.
- Detect changes in headlines, if possible.
.. @+node:ekr.20031218072017.795: *4* 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.20150413163840.1: *4* Migrate wiki to github
https://github.com/leo-editor/leo-editor/wiki
.. @+node:ekr.20141108064630.19: *4* Resolve clone wars based on modification dates
From: Joon Ro <joonpyro@gmail.com>

I think it would make more sense if leo checks the file modification time when it makes decision which node is new, instead of just depending on the order of files in the outline.
.. @+node:ekr.20130806211959.17373: *4* Support meld
From: Haroldo Stenger <haroldo.stenger@gmail.com>

I'm slowly trying to grok leo. I love meld, it's simply the best text
comparison I've ever seen. I wonder if a greater bit of integration between
meld and leo is possible, and in which ways. Undoubtedly calling it as an
external process is better than anything.
.. @+node:ekr.20141210123805.9: *4* Support rope
.. @+node:ekr.20150616085806.1: *4* Support solorized selected text
I don't believe this can be done just using stylesheets.
Probably will need custom painters.
.. @+node:ekr.20090131200406.15: *3* File & file format
.. @+node:ekr.20061002093442: *4* Add opml support to new, open, save commands
.. @+node:ekr.20111019104425.15895: *4* LeoFS (Kent)
- create a Leo implementation of pyfilesystem
http://packages.python.org/fs/implementersguide.html

.. @+node:ekr.20110527084258.18378: *4* New file format
** remove window state, expansion status etc.
   stuff from .leo file, and move that over to c.db

- <attr> solves pickle problem.

* Treat gnx's as strings: don't parse them.
  http://mail.google.com/mail/#inbox/12f3d4950fbabeea
  
* Don't save expansion bits in uA if not saving expansion bits. It's illogical
  to save bits in uA's if they aren't save in in the <v> elements.
  
    @bool put_expansion_bits_in_leo_files = False

- Use uuid's?

- Remove spaces from user names.

.. @+node:ekr.20080311135649.2: *5* Allow different .leo formats
On Tue, Mar 11, 2008 at 7:03 AM, Kent Tenney <kten...@gmail.com> wrote:

> On 3/11/08, derwisch <johannes.hues...@med.uni-heidelberg.de> wrote:

> >  On 11 Mrz., 08:03, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> >  > It could also be argued that

> >  > - Referring to previous cloned vnodes explicitly in XML does not
> >  > necessarily obscure DAG - it follows the "do not repeat yourself"
> rule
> >  > - It will speed up reading
> >  > - Wouldn't it be better for preserving the integrity of the XML file?

> > I would lean towards this line of argumentation. A couple of days I
> >  had my Leo extension destroy the Leo ODM file (which was still valid
> >  according to Leo, but unreadable wrt the extension and broken uAs). I
> >  resorted to editing the Leo file with Emacs, and was quite surprised
> >  to see that the headStrings were attributes of vnodes.

> I'll chime in with my pet peeve re: .leo file structure::

> I think that putting the headstrings on vnodes and body strings on tnodes
> obscures the informational content of the .leo file, and makes the .leo
> file
> format less attractive as a generalized solution to the problem of how to
> manage head/body pairs which live in a hierarchal structure.

> Thanks,
> Kent

> >  I think that
> >  editing the file might have been a bit easier if there had been no
> >  such redundancy. But this is more a feeling rather than a qualified
> >  opinion.

Thanks for all these comments.  I'll respond to them all here.

Clearly, we should be using a standard xml parser to read .leo files.

My present thoughts:

- I personally like human-readable headlines in <v> elements.

- I am open to putting headlines in <t> elements, as an indication that
tnodes do indeed contain headlines and body text.

- I am willing to consider only writing shared subtrees once.

Oh! (An Aha)  All these are preferences.  We can allow any combination of
these provided that headlines appear somewhere.

So that's clean.  This will happen in Leo 4.5. 
.. @+node:ekr.20110421132230.6107: *5* File format, v3 draft 4
Leo's file format: version 3, draft 4

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

Here is the latest version, with the graphml stuff removed.

This draft is intended to reflect our recent discussions, with no new invention from me. All comments and corrections welcome.

This draft covers only Leo's xml format, but it may be adapted for use as a json file format.

Recent changes
==============

- Removed graphml stuff, including leo: prefixes.

- Used "key" in <attr> elements (and "type" in <edge> elements.)

First lines
===========

Leo file will start with the following::

    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet my_stylesheet?>
    <!-- Created by Leo (http://webpages.charter.net/edreamleo/front.html) -->
    <leo_file file_format="3"
        xmlns:leo="http://www.leo-editor.org/2011/leo"/>
        

No session data
===============

There will be no <globals>, <preferences> or <find_panel_settings> elements. All such "session data" will be restored from the cache, or from defaults if caching is disabled.

**Important**: there is no representation of expansion state or the currently selected node anywhere in the .leo file. Eliminating these data is contingent on having Leo work well with caching disabled.

Note: marks are more than session data. They must appear somewhere within <node> elements.


Summary of format
=================

.leo files will have the following form, with similar indentation::

    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet my_stylesheet?>
    <!-- Created by Leo (http://webpages.charter.net/edreamleo/front.html) -->
    <leo_file file_format="3" xmlns:leo="http://www.leo-editor.org/2011/leo"/>
    <graph>
    <nodes>
        <!-- marked attribute appears only if the vnode is marked -->
        <node id="gnx"> 
            <head>headline text</head>
            <attr key="marked">1</attr>
            <!-- uA's... -->
            <!-- format="string" is the default -->
            <attr key="a">a string</attr>
            <attr key="b" format="json">a json string</attr>
            <attr key="c" format="pickle">a pickled string</attr>
            <attr key="d" format="binhex">a binhexed string</attr>
            ...
            <body>body text</body>
        </node>
        ...
        <!-- @file nodes contain a <data> package -->
        <node id="gnx">
            <head>@file x.py</head>
            ...
            <at-file-attributes>
                <attr>key="ua-name"
                    format="(empty)/json/pickle/binhex"
                    gnx="gnx">value
                </attr>
                ...
            </at-file-attributes>
        </node>
        ...
    </nodes>
    <edges>
        <edge type="child" from="gnx" to="gnx"</edge>
        ...
    </edges>
    </graph>
    </leo_file>

<attr> elements
===============

<attr> elements will one of the following forms::

    <attr key="a">a unicode string</attr>
    <attr key="b" format="json">a json string</attr>
    <attr key="c" format="pickle">a json string</attr>
    <attr key="d" format="binhex">a binhexed string</attr>
    
That is, the value will be a string by default.

uA's that start with "binhex_" will use the binhex format. This prefix must be retained in the type field, so the read code can restore them.

If the value is not a string, and there is no "binhex_" prefix, the write code will use format="json" if json.dumps succeeds, and will use format="pickle" otherwise.

No <attr> element will be written if both json.dumps and pickle.dumps fail. Attribute failures will create a warning for the plugin developer.

<edge> elements
===============

<edge> elements will have the form::

    <edge type="child" from="gnx" to="gnx"/>
    
Leo will use type="child" to represent Leo's official edges.
Plugins are free to define any type except "child". Examples::

    <edge type="undirected" from="gnx" to="gnx"/>
    <edge type="bidirectional" from="gnx" to="gnx"/>
    <edge type="backlink" from="gnx" to="gnx"/>
    <edge type="myPlugin" from="gnx" to="gnx"/>
    
Descendant attributes in @file trees
====================================

Descendants of @file nodes do not appear in .leo files. Thus, important data must be stored in the so-called hidden machinery: attributes of the @file node.

The <at-file-attributes> element may be contained in the <node> element for @file nodes::

    <at-file-attributes>
        <attr>key="ua-name"
            format="(empty)/json/pickle/binhex"
            gnx="gnx">value
        </attr>
        ...
    </at-file-attributes>
    
In other words, we use the graphml <attr> element, extended with the gnx attribute, to represent all the uA's in the descendants of @file nodes.
.. @+node:ekr.20110609042343.16548: *5* File format, v3 draft 5
http://groups.google.com/group/leo-editor/browse_thread/thread/2ddb57c62e67825c

Leo's file format: version 3, draft 5

This draft is intended to reflect minimal changes from Leo's present file format, but with improvements mentioned at the Ashland sprint and developed afterward.

This draft covers only Leo's xml format, but it may be adapted for use as a json file format.

This draft contains significant invention by EKR. See the next section. Don't panic: it can be changed :-)

Summary of changes from draft 4
===============================

- Elements will be renamed as follows::

    old         new
    ====        ====
    <vnodes>    <directed-acyclic-graph>
    <tnodes>    <data-list>
    <v>         <node>
    <t>         <data>

- Nesting of <node> elements represents the structure of the DAG,
  just as nesting of <v> elements does at present.
  
- Thus, there will be no <edge> elements.

- Headlines will move from <v> elements to <data> elements.
  This "normalizes" the data: headlines will appear only once.
  
- <attr> elements will represent uA's.  A full discussion below.

  Ideally, I would like to support only string and json formats
  for <attr> elements.  This is open to discussion. 

- Only <node> elements will contain <attr> elements.

- <node> elements for @file nodes will contain
  <at-file-attributes> elements, representing Leo's "hidden
  machinery" attributes.  <at-file-attributes> will contain
  <attr> elements. 

First lines
===========

Leo file will start with the following::

    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet my_stylesheet?>
    <!-- Created by Leo (http://webpages.charter.net/edreamleo/front.html) -->
    <leo_file file_format="3"
        xmlns:leo="http://www.leo-editor.org/2011/leo"/>
        
No session data
===============

There will be no <globals>, <preferences> or <find_panel_settings> elements. All such "session data" will be restored from the cache, or from defaults if caching is disabled.

**Important**: there is no representation of expansion state or the currently selected node anywhere in the .leo file. Eliminating these data is contingent on having Leo work well with caching disabled.

Note: marks are more than session data. They must appear within <node> elements.


Summary of format
=================

.leo files will have the following form, with similar indentation::

    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet my_stylesheet?>
    <!-- Created by Leo (http://webpages.charter.net/edreamleo/front.html) -->
    <leo_file file_format="3" xmlns:leo="http://www.leo-editor.org/2011/leo"/>
    <directed-acyclic-graph>
        <node id="gnx">
            <!-- contained node elements, if any.
        </node>
        <node id="gnx">
            <!-- contained v elements, if any.
        </node>
        ...
    </directed-acyclic-graph>
    <data-list>
        <data id="gnx">
            <!-- marked attribute appears only if the tnode/vnode is marked -->
            <head>headline text</head>
            <attr key="marked">1</attr>
            <!-- uA's... -->
            <!-- format="string" is the default -->
            <attr key="a">a string</attr>
            <attr key="b" format="json">a json string</attr>
            <attr key="c" format="pickle">a pickled string</attr>
            <attr key="d" format="binhex">a binhexed string</attr>
            ...
            <body>body text</body>
        </data>
        ...
    </data-list>
    </leo_file>

<attr> elements
===============

<attr> elements will one of the following forms::

    <attr key="a">a unicode string</attr>
    <attr key="b" format="json">a json string</attr>
    <attr key="c" format="pickle">a json string</attr>
    <attr key="d" format="binhex">a binhexed string</attr>
    
The value will be a string by default.

If possible, I would like to support only the string and json
formats. This would make the data as transparent as possible.
Please mentally amend the following discussion...

uA's that start with "binhex_" will use the binhex format. This
prefix must be retained in the type field, so the read code can
restore them.

If the value is not a string, and there is no "binhex_" prefix,
the write code will use format="json" if json.dumps succeeds, and
will use format="pickle" otherwise.

No <attr> element will be written if both json.dumps and
pickle.dumps fail. Attribute failures will create a warning for
the plugin developer.
    
Descendant attributes in @file trees
====================================

Descendants of @file nodes do not appear in .leo files. Thus, important data must be stored in the so-called hidden machinery: attributes of the @file node.

The <at-file-attributes> element may optionally be contained in the <node> element for @file nodes::

    <at-file-attributes>
        <attr>key="ua-name"
            format="(empty)/json/pickle/binhex"
            gnx="gnx">value
        </attr>
        ...
    </at-file-attributes>
.. @+node:ekr.20110419083918.6104: *5* File format, v3 graphml
This draft is intended to reflect our recent discussions, with no new invention from me. All comments and corrections welcome.

The draft is also intended to be compatible with graphml.

This draft covers only Leo's xml format, but it may be adapted for use as a json file format.

I am willing to change "type" to "key" in <edge> elements if that would be preferable.

Recent changes
==============

- Added <graphml> element defining the default namespace.

- Defined the leo namespace for leo-only elements.
    - Renamed <leo_file> to <leo:outline>
    - Renamed <descendant-attributes> to <leo:at-file-attributes>

- Used <leo:at-file-attributes> for marks, removing the special case.

- Enclosed <leo:descendant-attributes> in a (graphml) <data> element.

- Changed the format of the "marked" attribute to be a string-valued attribute.

First lines
===========

Leo file will start with the following::

    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet my_stylesheet?>
    <!-- Created by Leo (http://webpages.charter.net/edreamleo/front.html) -->
    <leo:file file_format="3"
        xmlns:leo="http://www.leo-editor.org/2011/leo"/>
    <graphml xmlns="http://graphml.graphdrawing.org/xmlns"/>
        

No session data
===============

There will be no <globals>, <preferences> or <find_panel_settings> elements. All such "session data" will be restored from the cache, or from defaults if caching is disabled.

**Important**: there is no representation of expansion state or the currently selected node anywhere in the .leo file. Eliminating these data is contingent on having Leo work well with caching disabled.

Note: marks are more than session data. They must appear somewhere within <node> elements.


Summary of format
=================

.leo files will have the following form, with similar indentation::

    <?xml version="1.0" encoding="utf-8"?>
    <?xml-stylesheet my_stylesheet?>
    <!-- Created by Leo (http://webpages.charter.net/edreamleo/front.html) -->
    <leo:outline file_format="3" xmlns:leo="http://www.leo-editor.org/2011/leo"/>
    <graphml xmlns="http://graphml.graphdrawing.org/xmlns"/>
    <graph>
    <nodes>
        <!-- marked attribute appears only if the vnode is marked -->
        <node id="gnx"> 
            <head>headline text</head>
            <attr key="marked">1</attr>
            <!-- uA's... -->
            <!-- format="string" is the default -->
            <attr key="a">a string</attr>
            <attr key="b" format="json">a json string</attr>
            <attr key="c" format="pickle">a pickled string</attr>
            <attr key="d" format="binhex">a binhexed string</attr>
            ...
            <body>body text</body>
        </node>
        ...
        <!-- @file nodes contain a <data> package -->
        <node id="gnx">
            <head>@file x.py</head>
            ...
            <data>
                <leo:at-file-attributes>
                    <attr>key="ua-name"
                        format="(empty)/json/pickle/binhex"
                        gnx="gnx">value
                    </attr>
                    ...
                </leo:at-file-attributes>
            </data>
        </node>
        ...
    </nodes>
    <edges>
        <edge type="child" from="gnx" to="gnx"</edge>
        ...
    </edges>
    </graph>
    </graphml>
    </leo:outline>

<attr> elements
===============

<attr> elements will one of the following forms::

    <attr key="a">a unicode string</attr>
    <attr key="b" format="json">a json string</attr>
    <attr key="c" format="pickle">a json string</attr>
    <attr key="d" format="binhex">a binhexed string</attr>
    
That is, the value will be a string by default.

uA's that start with "binhex_" will use the binhex format. This prefix must be retained in the type field, so the read code can restore them.

If the value is not a string, and there is no "binhex_" prefix, the write code will use format="json" if json.dumps succeeds, and will use format="pickle" otherwise.

No <attr> element will be written if both json.dumps and pickle.dumps fail. Attribute failures will create a warning for the plugin developer.

<edge> elements
===============

<edge> elements will have the form::

    <edge type="child" from="gnx" to="gnx"/>
    
Leo will use type="child" to represent Leo's official edges.
Plugins are free to define any type except "child". Examples::

    <edge type="undirected" from="gnx" to="gnx"/>
    <edge type="bidirectional" from="gnx" to="gnx"/>
    <edge type="backlink" from="gnx" to="gnx"/>
    <edge type="myPlugin" from="gnx" to="gnx"/>
    
Descendant attributes in @file trees
====================================

Descendants of @file nodes do not appear in .leo files. Thus, important data must be stored in the so-called hidden machinery: attributes of the @file node.

The <leo:at-file-attributes> element may be contained in the <node> element for @file nodes. For compatibility with graphml, it will enclosed in a data element::
    
    <data>
        <leo:at-file-attributes>
            <attr>key="ua-name"
                format="(empty)/json/pickle/binhex"
                gnx="gnx">value
            </attr>
            ...
        </leo:at-file-attributes>
    </data>
    
In other words, we use the graphml <attr> element, extended with the gnx attribute, to represent all the uA's in the descendants of @file nodes.
.. @+node:ekr.20090218115025.3: *5* Why are attributes pickled by default?
http://groups.google.com/group/leo-editor/browse_thread/thread/326a221f4c698f7a

> On Wed, Feb 18, 2009 at 12:12 PM, Kent Tenney <ktenney@gmail.com> wrote:
>>
>> Currently, Leo pickles the value of unknown attributes unless
>> the name starts with 'str_'
>>
>> Running the following code in node 'UA'
>>
>> p = c.currentPosition()
>> p.v.u = {'hello':'world', 'str_hello':'world'}
>>
>> results in the following in the .leo file:
>>
>> <v t="ktenney.20090218114928.367" str_hello="world"
>> hello="5505776f726c6471002e"><vh>UA</vh></v>
>>
>> I think this is surprising, Python-centric and contrary to the
>> spirit of Leo as a flexible data management platform.
>
> I suppose your point is that you can't create an arbitrarily named attribute
> with a string value. Does that create a real problem?

It requires a translation layer, either to (un)munge the name or
(un)pickle. Real problem?

Let's say each time I think 'I can use UAs to store that' I change
my mind when I realize my values will be in a pickle. (I really don't
want to name all my attributes str_xxx)

> As far as being Python-centric, can you suggest any other way of converting
> arbitrary data to a text string?

How is it done in any other XML file? I've not used XML for arbitrary data, but it probably can be done.

> Why would that way be better than pickle?

My suspicion is that UAs would be used more for storing text and numbers (as seems common for XML files) than Python data objects.

Does Leo use UAs to store pickles?

I'm sure pickling capability is great, but I'm not convinced it should be the _default._

No big deal.
.. @+node:ekr.20130806072439.21349: *4* Should @nosent put headlines as comments?
From: "Edward K. Ream" <edreamleo@gmail.com>

I've been blind all these years!  @nosent should put headlines as nodes a comments.  They would be very useful and I can see no reason not to put such comments.  If, for some reason, they are not desired, you could use
@asis.

===== Ville

I use @nosent for non-code text mostly, and it's not clear what "comment" should mean in that context.

I for sure would like this kind of feature, but sometimes I'd like to have the headlines written as reST style headlines (underlines), etc.

So this is not a complete no-brainer modification.

===== EKR

I agree.  Some more thought is needed.

===== Ville

Instead of changing how Leo fundamentally behaves (@nosent is part of that), how about adding a new @directive that allows things like this? E.g. "@write a.txt" would be nice & "obvious".

===== EKR

In this case, adding support for a new directive might be more complicated than changing @nosent :-)
.. @+node:ekr.20080626081829.2: *5* Allow headline comments for @nosent files
http://groups.google.com/group/leo-editor/browse_thread/thread/eb718b4c6d478ac0

I'm just getting started learning how to use Leo. Now, I'd like to use it for some of my projects, but there's no chance that I can convert everyone at work to using it, so putting sentinel-filled files in our repository is out of the question. At the same time, my code looks awfully bare without sentinels because the documentation ends up in the section names, not the comments!

So, I was wondering if there's a convenient way to pull the section names into a comment at the start of each section?

===============

Interesting question.  Am I correct in assuming you are using @nosent trees to generate your files?  If so, it would be easy to add support for the following options:

@bool write_section_comments_in_at_nosent_trees
@bool write_node_name_comments_in_at_nosent_trees

The first would write a sentinel consisting of only the section name;
the second would write a sentinel consisting only of the node's headline
(for nodes whose headline is not a section name).

These seem like they would be useful additions.  One can even imagine
corresponding Leo directives so that the comments could be turned on or off
within an @nosent tree.

What do you think?

=====================

> Interesting question.  Am I correct in assuming you are using @nosent trees
> to generate your files?  If so, it would be easy to add support for the
> following options:

> @bool write_section_comments_in_at_nosent_trees
> @bool write_node_name_comments_in_at_nosent_trees

> The first would write a sentinel consisting of only the section name;
> the second would write a sentinel consisting only of the node's headline
> (for nodes whose headline is not a section name).

> These seem like they would be useful additions.  One can even imagine
> corresponding Leo directives so that the comments could be turned on or off
> within an @nosent tree.

That sounds like an excellent solution. Particularly the last bit -- if you could turn section-comments on and off as required, it would become very convenient to use Leo to produce source that is intended to also be read by non Leo users.
.. @+node:ekr.20080919085541.3: *4* Use sqlite data base as an alternative representation for .leo files
http://groups.google.com/group/leo-editor/browse_thread/thread/dff0c165e2211691
.. @+node:ekr.20130806072439.21298: *4* Treat leo tree as a flat memory structure
Ville
https://plus.google.com/_/notifications/emlink?emr=02870587547267324596&emid=CLiiydTt8rUCFaY6MQodYAsAAA&path=%2F103097156557482112329%2Fposts%2FVp5ansTdLwq&dt=1362942818945&ub=63

How could we  treat leo tree as flat, contiguous memory structure (something that's easy to memcpy, pass as shared memory or flush to disk in one write)?

Some ideas could be: 

- Use Redis to store tree
- Keep the "clean" body texts in contiguous block (most bodies will always be clean), append dirty (modified) body texts after it
- Keeping the outline structure in memory block is quite easy, since there is not a lot of data. You could have just a list of [parent, child] id's or whatever
.. @+node:ekr.20141017110114.18265: *4* Won't do: Use uuid's in gnx's
https://groups.google.com/d/msg/leo-editor/p_b2LLBAqps/aTQoyGBec68J

This post discusses a new command line argument for Leo: --uuid

I have no plans to implement --uuid now, but it may have to be done in future.

===== Rationale

Terry has convinced me that collisions between both user ids and timestamps will become more frequent as Leo becomes more popular. Such collisions are not a serious problem at present: the odds of two different people with the same user id sharing .leo files is small.

Nevertheless, a serious problem lurks, one that can not, even in principle, be solved with Leo's present gnx's.

Suppose two people have the same id. Then Leo *must* assume that those people are actually the same person! As I have explained in other post, this can lead to data loss if the two people create two *distinct* nodes with the same gnx, and then try to merge those nodes into the same .leo file. The odds of this happening are small, but increasing.

A good way to solve this problem is to use uuids, http://en.wikipedia.org/wiki/Universally_unique_identifier and python's uuid module: https://docs.python.org/2/library/uuid.html

===== Operation

The --uuid should cause Leo to use uuid's for all *new* gnx's. The uuid option should not convert *existing* gnx's to uuid-based gnx's.

A new Leo command would convert all existing gnx's to uuid-based gnxs. Such mass conversions should *never* be done automatically.

===== Format of uuid-based gnxs

I would like the uuid-based gnx's to use uuid's in *addition* to the id and timestamp fields. Something like::

    id.timestamp..uuid

Alas, that does not seem possible, unless this kind of gnx is written to external files (in node sentinels). But many users would complain that such very-long gnx's clutters external files too much.

So it seems that new-style gnxs would have something like this form::

    ..uuid

The leading dots allow Leo to distinguish this kind of gnx from the old
forms::

    id.timestamp.n
    id.timestamp

provided that dots are not allowed in ids.

===== Summary

Recent work shows that this is not necessary or desirable.
https://github.com/leo-editor/leo-editor/issues/130

Leo's uuid-based gnxs can contain neither user ids nor timestamps.

We must ensure we stick with whatever new-style gnx format we choose initially: we don't want to burden Leo with distinguishing between several different forms of uuid-based gnxs.
.. @+node:ekr.20120515193246.10085: *3* Gui
.. @+node:ekr.20160318113605.1: *4* * Rethink windows
- Decouple commander from outline?
- Notifications might simplify multiple body panes.
- A good platform for web development and anything
  needing multiple consoles.
- Add status line showing type of window. Like Emacs.
.. @+node:ekr.20130806072439.21241: *5* Free range body editors
From: Terry Brown <terry_n_brown@yahoo.com>

I suspect that if body editors could be made just slightly more flexible it would open up whole new ways of using Leo.  It seems they just need two or three things to make them really flexible.

- a flag to indicate whether the tree pane should select the body editor's node when the body editor is focused.  To see an example of editing bodies without the tree selecting the node you're editing, see the stickynotes plugin

- a flag to indicate whether the body editor should track the node currently selected in the tree

- it needs to not care about what it's contained in, GUI wise.  I don't know how much work's involved in this.

I'll try and contribute to things moving in this direction when I have time, just throwing it out there for others to think on.

If you could have a body editor edit the node indicated by an UNL, it would basically be a clone...
.. @+node:ekr.20110929074744.15499: *5* Allow more panes to be part of the free_layout "action" buttons
.. @+node:ekr.20160405063110.1: *4* Maybe
.. @+node:ekr.20120604071051.10187: *5* Add multiple body editors to session machinery
Terry will do this, or help with it.
.. @+node:ekr.20111019104425.15892: *5* Buttons (Kent)
Enhance the button machinery to allow mixed case, spaces, colors.

Provide cascading rclick capability: rclick on an rclick list ...
.. @+node:ekr.20130806072439.21380: *5* QML - new window / gui / coding for Leo?
From: Terry Brown <terry_n_brown@yahoo.com>

This thread will need Ville to set it on the right track, I barely know the names of the technologies, but Qt has been advancing with, quoting from their site:

Qt Quick

The Qt UI Creation Kit lets you create rich, touch-enabled UIs and
apps...quickly.

  * QML - CSS & JavaScript like language, same code base for UI
    designers & developers

  * Supported by Qt Creator IDE for rapid prototyping and development

  * Qt Quick UI runtime - Direct access to native APIs, performance
    boost with C++

I think the first bullet is most relevant to Leo.  Could we embed this kind of environment in Leo?  Can it be integrated effectively with the current GUI?

That route might make adding task specific GUIs in Leo quick and easy.

Not for the touch part (although Leo on a tablet would be fun), but as a way of quickly creating task specific GUIs, "forms" if you like, for accessing / interacting with the data in a Leo outline.  I'm assuming that QML is higher level / less coding the regular PyQt programming, but I don't know that, not having tried it.

===== Ville

QML is actually lower level than QWidgets / "regular" PyQt programming. Key selling point of QML is that the UI's are more free form, "custom" and much faster than QWidget UI's (in Qt5, QML maps quite naturally to OpenGL, making it fly on mobile phone/tablet hardware).

QML would be natural for graphcanvas / tabula / other "custom" ui plugins, but it doesn't yet have text editor as powerful as QTextEdit, not tree widget as powerful as QTreeWidget / QTreeView.

I expect QML to be first used in mobile version of Leo (I have one actually, that I will publish "at later date" ;-). For desktop, QML is not yet as attractive as the "old stuff".
.. @+node:ekr.20130806072439.21464: *5* UI idea: body editors in a grid
From: "Ville M. Vainio" <vivainio@gmail.com>

Hey,

No time to mock this up right now, just throwing it out there.

"tabula" plugin allowed you to edit many nodes simultaneously in an MDI canvas - i.e. you could move the body editors around freely.

How about taking this idea further and locking the body editors in a grid, or column?

One fun idea would by layout like this

            | Child 1
Outline  | Child 2
            | Child3

That is, you would edit and view all the children of the currently focused node all at once. We can already do two body editors at once, so this would seem like natural extension.

Of course you could only see a small amount of text per body, but for a "workbook" / sheet like use cases it would be fine.
.. @+node:ekr.20130806072439.21465: *6* Re: UI idea: body editors in a grid
From: "Edward K. Ream" <edreamleo@gmail.com>

On Apr 18, 10:53=A0am, Terry Brown <terry_n_br...@yahoo.com> wrote:

> When the body editor is a well behaved widget it should be straight
> forward to place them where ever you want in using the free-layout
> mechanism.

Yes.  This might the key.

As I was thinking about doing body editors with free_layout (and by
extension, the tabula editors) I had another new thought: it's time to
replace the present difficult selection code with a broadcaster/
listener framework.

In particular, the multiple body editor code is on the verge of
collapse because it tries to figure out too much in a spaghetti-like
mass of logic.  This doesn't generalize, and Leo is becoming so
"exuberant" in its IDE that a simpler, more general mechanism is
becoming essential.

Edward

.. @+node:ekr.20130806072439.21466: *6* Re: UI idea: body editors in a grid
From: "Edward K. Ream" <edreamleo@gmail.com>

On Wed, Apr 18, 2012 at 4:37 AM, Ville M. Vainio <vivainio@gmail.com> wrote:

> "tabula" plugin allowed you to edit many nodes simultaneously in an
> MDI canvas - i.e. you could move the body editors around freely.

Tabula is part of the stickynotes plugin.  It creates the following commands:

         tabula
         tabula-marked
         tabula-show
         tabula-subtree

The "windowlets" show the node's headline. So this is the "sea of nodes" view!

The tabula nodes are "live": changes made in the tabula window
instantly affect the corresponding nodes in the regular outline.

An easter egg: double-clicking the title of a windowlet fills the
tabula window with the windowlet.  Another double-click undoes the
expansion.

> How about taking this idea further and locking the body editors in a
> grid, or column?

Good idea.  The tabula window is a great playground for invention.

In the "multi-colored link" world (coming soon, I hope), we could
imagine commands that create "tabula-colored" links, so that the
tabula window would work like a chapter.  (And each chapter would have
its own links).

The Light Table video suggested something else that I never considered
before.  Suppose each node "carries" its own mini-context outline,
showing just the parents of the node.  The tabula window might be
natural for that.

The idea is that each windowlet would have two parts:  the top would
show the parents, the bottom would show the body pane.  This allows
context to be visible without actually having to show the outline
pane.

Edward
.. @+node:ekr.20130806072439.21467: *6* Re: UI idea: body editors in a grid
From: "Edward K. Ream" <edreamleo@gmail.com>

On Wed, Apr 18, 2012 at 10:53 AM, Terry Brown <terry_n_brown@yahoo.com> wrote:
> On Wed, 18 Apr 2012 12:37:22 +0300

> When the body editor is a well behaved widget it should be straight
> forward to place them where ever you want in using the free-layout
> mechanism.

Are you suggesting doing free-layout in tabula?

EKR
.. @+node:ekr.20130806072439.21468: *6* Re: UI idea: body editors in a grid
From: "Ville M. Vainio" <vivainio@gmail.com>

--20cf3005df0ef84cc304be0227bb


If you fill the cells with stickynotes (as in tabula), the editors would at
least stick to the nodes.

Otoh, if more felxible body editors are just around the corner, it may not
be worth the hassle.

.. @+node:ekr.20130806072439.21469: *6* Re: UI idea: body editors in a grid
From: Kent Tenney <ktenney@gmail.com>

On Wed, Apr 18, 2012 at 2:57 PM, Edward K. Ream <edreamleo@gmail.com> wrote=
:
> On Apr 18, 10:53=A0am, Terry Brown <terry_n_br...@yahoo.com> wrote:
>
>> When the body editor is a well behaved widget it should be straight
>> forward to place them where ever you want in using the free-layout
>> mechanism.
>
> Yes. =A0This might the key.
>
> As I was thinking about doing body editors with free_layout (and by
> extension, the tabula editors) I had another new thought: it's time to
> replace the present difficult selection code with a broadcaster/
> listener framework.

'publish / subscribe' has buzzword cred these days, there are several
protocols out there, reportedly fairly simple to implement, don't know
if any are a fit here.
.. @+node:ekr.20130806072439.21470: *6* Re: UI idea: body editors in a grid
From: Terry Brown <terry_n_brown@yahoo.com>

--MP_/YLiyZOi3S=ZU5mZC9llHxW5

Content-Disposition: inline

On Wed, 18 Apr 2012 12:48:42 -0700
Ville Vainio <vivainio@gmail.com> wrote:

> > Expanding the scope to a grid, we could have a grid-lock-column that would
> > freeze the current column, allowing you to move the selected position in
> > the tree to another node, and locking the nodes for column 2 etc etc  

Attached screen-shot shows the potential for free-layout with the new
Open Window command to open a separate window as a 'grid' editor.  Here
instead of body editors I just have 5 view-rendered panes open, and
they're all looking at the same node because there's no mechanism for
locking them to separate nodes presently(*).  Free layout could handle
body editors in the same way, if they were more agnostic about their
containers.

Cheers -Terry

(*) I think there's a way to lock/unlock a special case singleton
view-rendered pane, but not a flock of them like this.
.. @+node:ekr.20130806072439.21471: *6* RE: UI idea: body editors in a grid
From: Ville Vainio <vivainio@gmail.com>

You are probably right. We Could also adjust the sizes dynamically
based on the amount of text in the nodes

Sent from my Windows Phone
From: Terry Brown
Sent: 4/18/2012 10:31 PM
To: leo-editor@googlegroups.com
Re: UI idea: body editors in a grid
On Wed, 18 Apr 2012 21:42:21 +0300
"Ville M. Vainio" <vivainio@gmail.com> wrote:

> I am bringing another angle into play here - systematic selection of what
> nodes are shown in the editors, in the proposed scheme we would have a
> single column of editors, each displaying every child of currently selected
> node.
>
> Expanding the scope to a grid, we could have a grid-lock-column that would
> freeze the current column, allowing you to move the selected position in
> the tree to another node, and locking the nodes for column 2 etc etc

Ok, but I still think it makes sense to implement this with the
free-layout system, so that your grid could be a separate window, or
not, as desired.  free-layout is basically nested QSplitters, so it can
represent a grid, but with more flexibility (cell 1,0 doesn't have to
be the same height as cell 0,0, etc.)
.. @+node:ekr.20130806072439.21472: *6* Re: UI idea: body editors in a grid
From: Matt Wilkie <maphew@gmail.com>

> That is, you would edit and view all the children of the currently
> focused node all at once.

I often use "Edit in notepad" (or more likely pyscripter) for this
purpose. It would be nice to stay inside Leo; I sometimes lose data by
forgetting which editor has the most current version.
.. @+node:ekr.20130806072439.21473: *6* Re: UI idea: body editors in a grid
From: Terry Brown <terry_n_brown@yahoo.com>

On Wed, 18 Apr 2012 21:42:21 +0300
"Ville M. Vainio" <vivainio@gmail.com> wrote:

> I am bringing another angle into play here - systematic selection of what
> nodes are shown in the editors, in the proposed scheme we would have a
> single column of editors, each displaying every child of currently selected
> node.
> 
> Expanding the scope to a grid, we could have a grid-lock-column that would
> freeze the current column, allowing you to move the selected position in
> the tree to another node, and locking the nodes for column 2 etc etc

Ok, but I still think it makes sense to implement this with the
free-layout system, so that your grid could be a separate window, or
not, as desired.  free-layout is basically nested QSplitters, so it can
represent a grid, but with more flexibility (cell 1,0 doesn't have to
be the same height as cell 0,0, etc.)
.. @+node:ekr.20130806072439.21474: *6* Re: UI idea: body editors in a grid
From: Kent Tenney <ktenney@gmail.com>

On Wed, Apr 18, 2012 at 10:53 AM, Terry Brown <terry_n_brown@yahoo.com> wro=
te:
> On Wed, 18 Apr 2012 12:37:22 +0300
> "Ville M. Vainio" <vivainio@gmail.com> wrote:
>
>> How about taking this idea further and locking the body editors in a
>> grid, or column?
>
> When the body editor is a well behaved widget it should be straight
> forward to place them where ever you want in using the free-layout
> mechanism.

Plus, free-layout provides persistence: it's worth putting effort into
configuring pane configuration because it will be available next time.

(I guess I'm persistent about wanting persistence)
.. @+node:ekr.20130806072439.21475: *6* Re: UI idea: body editors in a grid
From: Terry Brown <terry_n_brown@yahoo.com>

On Wed, 18 Apr 2012 12:57:03 -0700 (PDT)
"Edward K. Ream" <edreamleo@gmail.com> wrote:

> As I was thinking about doing body editors with free_layout (and by
> extension, the tabula editors) I had another new thought: it's time to
> replace the present difficult selection code with a broadcaster/
> listener framework.

Although such a framework might be quite useful, I can't help thinking
it would insert a big delay between now and getting flexible body
editors implemented.

> In particular, the multiple body editor code is on the verge of
> collapse because it tries to figure out too much in a spaghetti-like
> mass of logic.  This doesn't generalize, and Leo is becoming so
> "exuberant" in its IDE that a simpler, more general mechanism is
> becoming essential.

I think that getting body editors working as described in my recently
bumped "Free range body editors" post would not be that hard, certainly
simpler and faster than a broadcaster / listener framework.  And the
current multiple body editors code could just be dropped completely, so
while I suspect you're right about it being on the edge of implosion, I
don't think that's a problem :-)
.. @+node:ekr.20130806072439.21476: *6* Re: UI idea: body editors in a grid
From: "Ville M. Vainio" <vivainio@gmail.com>

--20cf305b11c06d69c404bdf86a61


I am bringing another angle into play here - systematic selection of what
nodes are shown in the editors, in the proposed scheme we would have a
single column of editors, each displaying every child of currently selected
node.

Expanding the scope to a grid, we could have a grid-lock-column that would
freeze the current column, allowing you to move the selected position in
the tree to another node, and locking the nodes for column 2 etc etc

.. @+node:ekr.20130806072439.21477: *6* Re: UI idea: body editors in a grid
From: "Ville M. Vainio" <vivainio@gmail.com>

Have you tried alt-x stickynote from stickynotes plugin?

.. @+node:ekr.20130806072439.21478: *6* Re: UI idea: body editors in a grid
From: Terry Brown <terry_n_brown@yahoo.com>

On Wed, 18 Apr 2012 11:45:25 -0500
Terry Brown <terry_n_brown@yahoo.com> wrote:

> Another feature I've wanted to add to free_layout is popping out any
> element into its own window (replacing sticky-notes).  You could go one
> better and pop-out free-layout frames which could contain multiple
> widgets, like tabula currently does.
> 
> I'll try and get those features into free-layout.

Woohoo - done and pushed.  Went for the second option, instead of
pop-out windows holding a single widget, they hold a whole new
free-layout hierarchy, which of course can be a single widget, or much
more, if you want.  See the 'Open Window' command on the free-layout
splitter handle context menu.

Even made a screencast to demonstrate, but unfortunately the sound was
useless, despite being ok in trials before hand.  Might try again later.
.. @+node:ekr.20130806072439.21479: *6* Re: UI idea: body editors in a grid
From: Terry Brown <terry_n_brown@yahoo.com>

On Wed, 18 Apr 2012 12:37:22 +0300
"Ville M. Vainio" <vivainio@gmail.com> wrote:

> How about taking this idea further and locking the body editors in a
> grid, or column?

When the body editor is a well behaved widget it should be straight
forward to place them where ever you want in using the free-layout
mechanism.  I think that's a better goal, it allows you more
flexibility in terms of maybe one small (both dimensions) and one large
editor, for example.
.. @+node:ekr.20130806072439.21480: *6* Re: UI idea: body editors in a grid
From: "Edward K. Ream" <edreamleo@gmail.com>

On Apr 18, 1:42=A0pm, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> I am bringing another angle into play here - systematic selection of what
> nodes are shown in the editors, in the proposed scheme we would have a
> single column of editors, each displaying every child of currently select=
ed
> node.

The new broadcaster/listener framework should probably be designed to
handle this.  That is, in the new framework it should explicitly be
possible to select multiple nodes.


> Expanding the scope to a grid, we could have a grid-lock-column that woul=
d
> freeze the current column, allowing you to move the selected position in
> the tree to another node, and locking the nodes for column 2 etc etc
> On Apr 18, 2012 6:53 PM, "Terry Brown" <terry_n_br...@yahoo.com> wrote:

Interesting.  For some purposes the column would be like a "super
node", that is, an explicit collection of nodes.

EKR

.. @+node:ekr.20130806072439.21481: *6* Re: UI idea: body editors in a grid
From: Terry Brown <terry_n_brown@yahoo.com>

On Wed, 18 Apr 2012 11:12:45 -0500
"Edward K. Ream" <edreamleo@gmail.com> wrote:

> > When the body editor is a well behaved widget it should be straight
> > forward to place them where ever you want in using the free-layout
> > mechanism.  
> 
> Are you suggesting doing free-layout in tabula?

No, although that gives me another idea...

Another feature I've wanted to add to free_layout is popping out any
element into its own window (replacing sticky-notes).  You could go one
better and pop-out free-layout frames which could contain multiple
widgets, like tabula currently does.

I'll try and get those features into free-layout.  Note that a couple
of widgets already have their own pop-out capability, the body editor
and view-rendered.

Also some frame manipulation tools in free-layout would be good.  To
maximize / restore one frame, and layout frames in a grid, if there was
an intent to replace tabula.

Not that tabular needs replacing, but I think it's benefits can be
generalized.
.. @+node:ekr.20130806072439.21482: *5* xiki window for leo
From: wgw <wgwinder@gmail.com>

Xiki.org gives a demo of a "wiki" shell for command execution. Leo should be able to do the same thing (and more!), in the sense that leoscreen, for example, has two way communication with the command line. I suppose a "Lxiki" is really just a question of setting up the right shortcuts (like a shift-ctrl-b that would run highlighted python code from the command line... with a tmp file?).

.. @+node:ekr.20130806072439.21483: *6* Re: Wish list: xiki window for leo
From: wgw <wgwinder@gmail.com>

Thanks for the tip -- it will take me a while to get my head around vspace (will keep an eye on Ville's blog post).

I'm just beginning to appreciate (or imagine) what Ipython, sublime text editor, leo, xiki, etc could mean for some kind of intelligent document workbench. Of course the big hurdle is not so much the string processing (sublime is a good example of how that can be done), but rather the syntax processing -- i.e. the docbench  (to coin a phrase) should understand the syntax of whatever is being input and then offer syntax-aware functions.... Sorry, getting a little obscure: all I mean by syntax-aware is the ability to propose text completions (Leo's autocompletion is a good example -- everything should work like autocomplete!) and allow for intelligent text changes depending on a database of information (for example, a search and replace that would  know how to search on "caterpillar" and turn it into "butterfly" but would not touch "caterpillar truck").

Seems like Leo is not far from doing that synthesis, but it would require more database integration. So for example, even the python help system does not have autocomplete. (No criticism there! The great thing about Leo is that if you want something, you just have to dive in and build it. My day job might just let me do that!)
.. @+node:ekr.20130806072439.21484: *6* Re: Wish list: xiki window for leo
From: Terry Brown <terry_n_brown@yahoo.com>

> Thanks for the tip -- it will take me a while to get my head around vspace
> (will keep an eye on Ville's blog post).

Just to clarify, vs-eval, vs-last, vs-last-pretty are quite straight forward, as I described them below, and do not require comprehension of the esoterica of value-space :-) I just put them in that plugin (a) to avoid creating yet another plugin, and (b) because it seemed sensible to have them use the value-space namespace c.vs, but all that means for vs-eval, vs-last, vs-last-pretty is that

  a =3D 7

executed by vs-eval assigns a value to a which can be used by subsequent vs-eval calls (persistent for the lifetime of the session).

For example, make a body with this text

a =3D 7
b =3D 3
a + b

and place the cursor in front of the first 'a'

execute (Alt-x or key binding) vs-eval 4 times

 - first time executes the empty selection and selects the next line
 - second time assigns 7 to a and report 7 in the log
 - third time assigns 3 to b and report 3 in the log
 - forth time calculates a + b and report 10 in the log

executing vs-last(-pretty) would insert the last result (None, 7, 3,
10) in the body.
.. @+node:ekr.20130806072439.21485: *6* Re: Wish list: xiki window for leo
From: wgw <wgwinder@gmail.com>

Got it! The value of valuespace (!) is that that you can make a pythonesque session persist. I did not realize that there was no direct two-way bridge to the python window that leo launches. Even if there were, we would want to make the session persist by logging it into the outline, as valuespace (vs-create-tree) does.
.. @+node:ekr.20130806072439.21487: *6* Re: Wish list: xiki window for leo
From: Terry Brown <terry_n_brown@yahoo.com>

In addition to the outline as a active data document functions of Ville's value-space plugin, I recently added some simple ;-) commands::

    Alt+A vs-eval
    Alt+S vs-last
    Alt+D vs-last-pretty
    (my key bindings)

vs-eval evaluates the selected python in the c.vs namespace.  It makes an effort to workout what the output should be, and puts it in the log.  It captures print output to the log too.  It selects the next line, ready for execution.

vs-last inserts the last result into the body, and vs-last-pretty does the same, but using pprint formatting.

Ctrl-B also runs the script in the body, but not in a persistent namespace, running only the selected text doesn't seem to be working, and it doesn't work so hard to work out the output.

I guess leoscreen would do the same things as the vs-* commands if you used it against a python shell.  The inspiration for the vs-* commands was wanting Leo to tell you what 3.57 * 365 / 12 was without a lot of effort, but of course you can define functions etc. etc.
.. @+node:ekr.20160405063138.1: *4* Won't do
.. @+node:ekr.20120516140545.9992: *5* Won't do: Different settings interface
Matt Wilkie

As for user interface, I'd love to see myLeoSettings with a checkbox interface and filter bar at the top, and a feature to "merge or reset from LeoSettings".

Or maybe something like Firefox's "about:config" would be better suited (and probably faster to build).
.. @+node:ekr.20111011062533.15693: *5* Won't do: Make headline widgets scrollable
It doesn't seem easy.
.. @+node:ekr.20130919120947.12506: *5* Won't do: Why Leo will never be a web app
There are two reasons why Leo is unlikely ever to be a web app.

1. There are somewhere around a million lines of Python code in Leo's core and plugins. Thus, a *solid* python in javascript system is required. This isn't likely to happen.

2. Creating a Leo outline widget is extremely complex. Even starting with a working javascript outliner, one has to deal with events (commands) coming from Leo scripts rather than from the user.

These seem like the most important obstacles. There may be others, but these
suffice.
.. @+node:ekr.20160405063125.1: *4* Unlikely
.. @+node:ekr.20111019104425.15887: *5* Unlikely: Host the PyQt demo inside Leo
.. @+node:ekr.20111019104425.15894: *5* Unlikely: Use templates to create Wizards (Kent)
Leverage the template capability to offer form-based content creation:
- create a plugin
- generate a test node
- generate a wizard :-]
.. @+node:ekr.20120515193246.10084: *3* Importers
.. @+node:ekr.20101004092958.5914: *4* Add treepad scanner (contains code!)
treepad.py is from the treepad website
.. @+node:ekr.20101004092958.5939: *5* treepad.py
@first #! /usr/local/bin/python
# treepad.py
@others
if __name__ == '__main__':
    Main().Run()
@language python
@tabwidth -4
.. @+node:ekr.20101004092958.5940: *6* treepad declarations
import sys, os, re, string
# constants
VERSION = "<Treepad version 2.7>"
# regexes
END_RE = re.compile(r'^<end node> ([^ ]+)$')
.. @+node:ekr.20101004092958.5941: *6* class Node
class Node:
    @others
.. @+node:ekr.20101004092958.5942: *7* __init__ (Node/treepad)
def __init__(self):
    self.title = ""
    self.level = 0
    self.article = []
    self.children = []
    self.parent = None
    self.end = ""
.. @+node:ekr.20101004092958.5943: *7* __str__
def __str__(self):
    return "%s/%d" % (self.title, self.level)
.. @+node:ekr.20101004092958.5944: *7* addchild
def addchild(self, node):
    assert self.level == node.level - 1 and node.parent is None
    node.parent = self
    self.children.append(node)
.. @+node:ekr.20101004092958.5945: *7* findparent
def findparent(self, node):
    if self.level == (node.level - 1): return self
    return self.parent.findparent(node)
.. @+node:ekr.20101004092958.5946: *7* writenode
def writenode(self, fp):
    fp.write("dt=Text\n")
    fp.write("<node>\n")
    fp.write("%s\n" % self.title)
    fp.write("%s\n" % self.level)
    for line in self.article:
        fp.write("%s\n" % line)
    fp.write("<end node> %s\n" % self.end)
.. @+node:ekr.20101004092958.5947: *7* writetree
def writetree(self, fp):
    self.writenode(fp)
    for node in self.children:
        node.writetree(fp)
.. @+node:ekr.20101004092958.5948: *6* class NodeReader
class NodeReader:
    @others
.. @+node:ekr.20101004092958.5949: *7* __init__ (NodeReader)
def __init__(self, fname, fp):
    self.fname = fname
    self.fp = fp
.. @+node:ekr.20101004092958.5950: *7* expect
def expect(self, text, line=None):
    if line is None:
        line = self.fp.readline().strip()
    assert line == text, "expected " + line + " == " + text
.. @+node:ekr.20101004092958.5951: *7* readstart
def readstart(self):
    self.expect(VERSION)
.. @+node:ekr.20101004092958.5952: *7* readnode
def readnode(self):
    line = self.fp.readline()
    if line is None:
        return None
    line = line.strip()
    if len(line) < 1:
        return None
    self.expect("dt=Text", line)
    self.expect("<node>")
    node = Node()
    node.title = self.fp.readline().strip()
    node.level = int(self.fp.readline().strip())
    while 1:
        line = self.fp.readline()
        m = re.match(END_RE, line)
        if m:
            node.end = m.group(1).strip()
            break
        node.article.append(line.strip())
    return node
.. @+node:ekr.20101004092958.5953: *6* class TreeReader
class TreeReader:
    @others
.. @+node:ekr.20101004092958.5954: *7* __init__(TreeReader)
def __init__(self, fname, fp=None):
    if fp is None: fp = open(fname, 'r')
    self.nodereader = NodeReader(fname, fp)
    self.root = None
    self.prev = None
.. @+node:ekr.20101004092958.5955: *7* add
def add(self, node):
    if self.prev is None:
        assert node.level == 0
        self.root = node
    else:
        assert node.level > 0
        parent = self.prev.findparent(node)
        parent.addchild(node)
    self.prev = node
.. @+node:ekr.20101004092958.5956: *7* read
def read(self):
    self.nodereader.readstart()
    prev = None
    while 1:
        node = self.nodereader.readnode()
        if node is None: break
        self.add(node)
.. @+node:ekr.20101004092958.5957: *6* class TreeWriter
class TreeWriter:
    @others
.. @+node:ekr.20101004092958.5958: *7* __init__ (TreeWriter)
def __init__(self, fname, fp=None):
    if fp is None: fp = open(fname, 'w')
    self.fname = fname
    self.fp = fp
.. @+node:ekr.20101004092958.5959: *7* write
def write(self, root):
    self.fp.write("%s\n" % VERSION)
    root.writetree(self.fp)
.. @+node:ekr.20101004092958.5960: *6* class Main
class Main:
    @others
.. @+node:ekr.20101004092958.5961: *7* __init__ (Main)
def __init__(self):
    self.infile = sys.argv[1]
    self.outfile = sys.argv[2]
    self.reader = TreeReader(self.infile)
    self.writer = TreeWriter(self.outfile)
.. @+node:ekr.20101004092958.5962: *7* Run
def Run(self):
    self.reader.read()
    self.writer.write(self.reader.root)
.. @+node:ekr.20130806211959.17365: *4* Docear, Latex, PDF enhancements
https://groups.google.com/d/msg/leo-editor/QbQHzlRtioc/uviFCvR9DeMJ
Leo as PIM and authoring tool

Josef <joe_da@gmx.net> 7/30/12
		
Recently I evaluated docear - a mind-mapping tool for collecting reference data (written in Java). It automatically extracts bookmarks and annotations from PDF files, and more, but it's support for authoring is still not up to the task. I think it would be great if Leo could do some of the tasks docear is doing.

Dragging a PDF into Leo currently just creates an url to the PDF. This could be expanded to also extract data (bookmarks, notes) from the PDF and to sync this data between Leo and the PDF. This info could be placed in child nodes: bookmarks and notes could even jump directly to the page in the PDF (although each PDF viewer seems to have a different syntax for doing that). This would be a great way to organize data sheets and specifications stemming from external sources.

Combining the above with an improved LaTeX support, one would get a very powerful research and authoring tool - in my opinion with a much more convenient interface than docear.

Perhaps it is too much work to duplicate all the work docear is doing. An alternative may be to sync data somehow between docear and Leo. Docear stores the data in a freeplane mind-map. Has anyone else thoughts about this? Offray Vladimir Luna Cárdenas offray@riseup.net via googlegroups.com
	
7/30/12
		
I have been using Leo to write my thesis. I didn't know about Docear, but my use was in some sense similar. I have a lot of @url links pointint to the pdfs files and in a subtree I cut and paste the text of the pdf I want to comment and made the comments inside the tree. These pdf were part of my bibliographic entries and I'm now writing a .bib file for these, so I can have in only one Leo tree all my thesis, with all the references to external files and the annotations and bibtex entries for them. For me the key point of Leo in academic writing is the tree view plus the clones and ignore nodes. My thesis can have several layers, the external ones being the actual writing and the deeper ones the references, texts, images, tools that enable me to do that writing. Using clones and @rst-no-head directives I can have the level of granularity of a paragraph, something that is not possible on traditional word processor which are the writing tool of tools like docear. This approach have some glitches:

* I still need to do some fine tunning to the LaTeX export for writing the pdf as I want. I imagine that putting sphinx in the tool chain could change that.

* I can not get much people of my companions using this advangages, besides of myself, because of the difficult installation process of Leo in Windows/Mac and the not so friendly interface for non-programmers. Other light markup structured text writing programs like Nested[1] are more easily used and understood despite of not having all the advantages and flexibility of Leo.

So, in resume, may be the better approach is connecting Leo to Docear, so you can have the advantages of both in terms of easy multiplataform installation and friendly interface of the later and programmability, flexibility and deeper organic structure of the former.

Offray

===== Terry Brown <terry_n_brown@yahoo.com>

> Dragging a PDF into Leo currently just
> creates an url to the PDF. This could be expanded to also extract data
> (bookmarks, notes) from the PDF and to sync this data between Leo and the
> PDF. This info could be placed in child nodes: bookmarks and notes could
> even jump directly to the page in the PDF (although each PDF viewer seems
> to have a different syntax for doing that). This would be a great way to
> organize data sheets and specifications stemming from external sources.

I'm not really sure how notes get embedded in PDFs.  As an aside, there is also capability for using Leo to manage bookmarks to web pages, with notes, tags, and snippets.  Look at the mod_http plugin.  It uses a javascript bookmark button in your browser to communicate with Leo.

> Combining the above with an improved LaTeX support, one would get a very
> powerful research and authoring tool - in my opinion with a much more
> convenient interface than docear.
>
> Perhaps it is too much work to duplicate all the work docear is doing. An
> alternative may be to sync data somehow between docear and Leo. Docear
> stores the data in a freeplane mind-map. Has anyone else thoughts about
> this?

Syncing between the two sounds a little cumbersome to me.  I wonder if the PDF stuff could be integrated with some sort of BibTeX .bib file management?

Do you really need the mindmap UI of docear?  I used to use Freemind which has a very similar interface, but switched to Leo.  I like what http://cmap.ihmc.us/ does, but it only does idea organization, no authoring etc.  To me cmaptools is better at idea organizing than mindmaps.

There is also the backlinks plugin for Leo, which allows arbitrary networks of links instead of just the directed tree, and graphcanvas, which allows graph layout of nodes.  There aren't comparable with the mindmap layouts, but they head in that direction.  Also note Leo's hidden UI flexibility in the context menus on the pane dividers, you can open a new window for the graphcanvas plugin, which gives it much needed screen real estate.

Cheers -Terry

===== Josef <joe_da@gmx.net>
		
no, I do not need the mindmap stuff at all. I had a look at short look at cmaptools, and I agree the generalized graph approach seems better than a standard mindmap. But I am quite happy with the tree view in Leo and as you already mentioned, this can be extended with backlinks etc. I have used Leo already to organize reference documents and write documentation (using Latex).

What I do want is links to a particular page of a PDF - links to just a file are not enough when you refer to documents with 100+ pages. Unfortunately this seems to be difficult to achieve in a cross-platform way, particular when trying to support different PDF viewers. Docear is solving this (and other compatibility problems) by developing its own integrated viewer (I do not suggest to do this for Leo).

On second thought, I don't think that extracting the bookmark and annotation info is really important to me - I would keep that info in the PDF, anyhow. I would write inside Leo addional notes, and the output text (in Latex).

Some integration of Bibtex may be a good thing and needs to be thought out. perhaps by using JabRef for this, or by recycling some pyBibliographer code, but this is also low on my priority list.

Offray seems to have a very similar use case as I - although I do not write a thesis, but specifications for scientific instruments. The point about cross-platform installation ease is also well taken, so I will look into some inter-operability here (either with docear or cmaptools). I see Leo mainly as a personal project / information manager: the leo tree is not easily shared with others, while the files Leo points to with @url, @auto,
@file etc can be shared quite easily. In this I use Leo as *my personal*
view on the project.

Ville Vainio <vivainio@gmail.com>
7/30/12
		
It seems that e.g. w/ foxit reader, you can open selected page from command line (-n 123). Abstracting this for other pdf readers that support such a thing should be no problem.
 
On Monday, July 30, 2012 8:08:23 PM UTC+2, Ville M. Vainio wrote:
     
    It seems that e.g. w/ foxit reader, you can open selected page from
    command line (-n 123). Abstracting this for other pdf readers that
    support such a thing should be no problem.
    
Yes, I suppose one could translate from a canonical representation inside Leo to whatever the tool needs (using @setting). Ideally, one would even have a choice between opening the new page in a different or in the same PDF viewer instance as the last page, but few viewers support that (Okular does - but I don't know any cross-platform solution).
.. @+node:ekr.20031218072017.790: *4* Import dialog improvements
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.20060227124411: *4* Import/export from wiki's
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.20031218072017.748: *4* Import/Export to yaml
Need a good yaml parser first: I don't want to write another parser by hand.
.. @+node:ekr.20150120155724.4: *4* Improve python importer
- Handle properties.
- Show base classes in headlines.
- Put @language and @tabwidth directives at end of body.
- Translate::

    #-----------------------------------------------------------------------------
    # Imports
    #-----------------------------------------------------------------------------

to organizer node whose headline is Imports.
.. @+node:ekr.20050509085713: *3* Install/installers
.. @+node:ekr.20160305055206.1: *4* Davy Cottet: apt-get install leo
apt-get install leo
https://groups.google.com/forum/#!searchin/leo-editor/apt-get$20install$20leo/leo-editor/AwYeds6PSn4/OtqtDYfktKAJ
.. @+node:ekr.20130807203905.16773: *4* Leo for portableapps?
.. @+node:ekr.20130807203905.16596: *4* PortableFileAssociator
From the thread: Cannot open Leo files by double-click in Windows Explorer?
https://groups.google.com/d/msg/leo-editor/KwrqYGMH20Q/z1uc-99vsnsJ

From: HansBKK <hansbkk@gmail.com>

For those like me who work in "portable" mode, there's a very cool tool
called "PortableFileAssociator" that allows you to create a set of windows
file associations, icons etc and enable/disable the whole profile at one
time, without messing with the local system's registry.

Also handy for those not in portable mode, but working on different windows
boxes and bored with having to tweak each one separately.
.. @+node:ekr.20130806072439.20732: *4* Runnable Leo in one .zip file w/ virtual machine
From: Terry Brown <terry_n_brown@yahoo.com>

Summary - it's easy to make a .zip file containing Leo and all it's
dependencies.

Inspired by Matt's recipe, using VirtualBox throw away 1GB Windows XP
32 bit machines, I tried the following.

Install Python (installer from python.org) 2.7.2 to 

  C:\Docouments and Settings\someuser\Desktop\leo\python27

Install PyQt (installer from Riverbank) 4.9 into the same folder (it
goes there by default)

Unzip http://www.greygreen.org/leo/leo-editor-latest.zip into

  C:\Docouments and Settings\someuser\Desktop\leo\leo-editor-latest

Make leo.zip from C:\Docouments and Settings\someuser\Desktop\leo

Delete the virtual machine, purging any registry entries etc. created
by the two installers.

On a fresh machine, searched the registry for 'python' just to be sure,
found nothing.

Unzip the .zip file, then

  cd C:\Docouments and Settings\someuser\Desktop\leo
  python27\python.exe leo-editor-latest\launchLeo.py

And Leo opens a blank outline, after asking for an ID, as it's supposed
to.  Didn't test it beyond that.

So, the .zip file contains all Leo needs to run, and obviously
runLeo.bat could be added in the top level to actually launch it.

Of course this is for Windows, so I think it's an improvement over
asking people to install Python and PyQt first, but neither of those
steps was that hard in Windows anyway.

===== EKR

Is this a technique that we could use for official Windows releases?
If so, what exactly would we do?

===== Terry

I guess, perhaps as an all-in-one option with a system integrated
option for those who want to use system python/qt.  Don't know if it
violates and licensing on Python / Qt, everything's being distributed
unaltered, so I wouldn't think so.

So basically you'd give people a large .zip file and tell them to
extract it to a folder and run the batchfile at the top level.  If they
can't do that, they might not be ready for Leo :-)  I guess you could
make it a self-extracting .zip, for that matter.

Also, the daily snapshot could be made this way, seeing once Python and
Qt are installed in the folder the Leo version can just be copied in.

It's not uncommon for FLOSS to be distributed this way, both Blender
and Inkscape use this approach, particularly for recent builds.

===== From: HansBKK <hansbkk@gmail.com>

If something like this **is** done, it should IMO be packaged as an
alternative to the normal installation procedure.

You would definitely get marketing exposure by getting the specs from
PortableApps.com and let them host it there as  "Portable Leo", tracking
the "official" Portable Python (currently 2.7.2) as a dependency, obviously
including QT etc as well. But it would need to be kept up to date. . .

Most Windows users would be better served by following the normal
installation procedure and ending up with a
registry-and-environment-variables-complete install of Python et al which
they can use for other things beyond Leo. Ending up with multiple instances
of Python to maintain is likely to cause more problems.

And the normal Windows install just isn't that hard, really! Improving the
current instructions, by providing a step-by-step "cookbook" with direct
links to the download packages etc might make it a **little** easier (IMO
only for the clueless), but then of course that would be a doc that would
need pretty frequent updates, which if I may be so bold doesn't seem to
happen too quickly on the doc side.
.. @+node:ekr.20130806072439.20736: *5* Re: Runnable Leo in one .zip file.
From: Matt Wilkie <maphew@gmail.com>

Since this topical today, almost a year later, I thought I'd take a run at 
repeating this using Portable Python (http://www.portablepython.com) as a 
base. It didn't work, but I think it should. Maybe someone else knows why. 

I ran the installer for 2.7.3 since 3.2 doesn't include PyQt4. At install 
time I selected only the Python and PyQt4 packages. Then from a fresh 
command shell:

{{{
path=c:\windows;c:\windows\system32
pushd x:\portapy27\App
path=%cd%;%cd%\Scripts;%cd%\Lib\site-packages\PyQt4;%path%
set pythonhome=%cd%
set pythonpath=%cd%\Lib

popd

python --version
Python 2.7.3

python -c "import PyQt4"
:: no error returned, we're good.

python c:\apps\leo-editor-latest\launchLeo.py
Leo requires Qt to be installed.
}}}

oh well.
.. @+node:ekr.20130806072439.20744: *5* Re: Runnable Leo in one .zip file.
From: HansBKK <hansbkk@gmail.com>

> PortableApps version would be FANTASTIC!!

A couple of versions have been posted here already, including Terry's very
simple sequence in the first message of this thread. Of course, we're only
talking about Windows, but note that it works equally well either syncing
with whatever tool (I favor Unison over SSH) or carrying around on an
arbitrary-path'd external device, including flash drives (but they can be
slow).

Here's my more robust (hence more complex) version, xx indicating your 
python version (mine is 27):

Use the normal .MSI, setup.exe etc processes to Install a clean "canonical" 
version of your "python dev stack" to say C:\PythonXX, reboot if needed, 
test thoroughly. Note any new environment variables pointing to your new 
binary locations.

Now create a corresponding PythonXX folder in your "PortableApps" location 
(I put it under "CommonFiles" along with GTK and Java) and copy everything 
from your installed location to the portable one.

You can then use the project-provided tools on the "master" computer to 
keep your binaries updated, and they will see any local Registry entries 
and the environment variables they created and operate normally wrt your 
installed location (e.g. C:\PythonXX).

If you have a local folder sync tool (I use Unison and WinMerge) you can 
add to/remove from/configure your Python environment from either location, 
otherwise just keep your installed location as the "master" and just copy 
the whole stack over each time you do so.

The whole PortableApps tree can then be sync'd/copied to any other 
desktop(s) you like, either over the wire or via an external device, and 
the latter can be carried for use in say an Internet cafe or client-site 
situation.

====================

For use on those other computers, for running in portable mode, I use a
"portable start menu" (PStart) which allows for its own "autolaunch" batch
files, where I set some global environment variables to be used by
app-specific launch batch files, including :

%Path% (I add my batch folder and a general utility/tools folder)
%HOME% (usually "E:\aasync\Data\H_HOME"
and a custom one called %h_pa%, which points to the root of my PortableApps 
parent (usually "D:\aasync\PortableApps")

Then for each environment that requires its own custom settings, I create a 
launch batch file that builds on that base. In the case of Python apps, 
here's an example that opens a CMD console window:

@ECHO OFF
set 
PATH=%PATH%;%h_pa%\CommonFiles\Python27;%h_pa%\CommonFiles\Python27\Lib\site-packages\PyQt4;%h_pa%\CommonFiles\Python27\Lib\idlelib;%h_pa%\CommonFiles\Python27\Scripts;
set PROMPT=$p_python$g
E:
cd \aasync
CMD.exe

I'm not sure which if any of the environment stuff Leo requires, but I 
figure it might as well have the same environment as my Python CLI, since 
I'll be testing shell integration, including iPython. In my leo-win.bat, 
the last three lines above are replaced with:

D:
cd \aasync\PortableApps\leo-editor
start "" "..\CommonFiles\Python27\pythonw.exe" 
"..\CommonFiles\Python27\Lib\site-packages\leo-editor4\launchLeo.py" %*

====================

Note this is more than the minimum you need to just run Leo - you could of 
course simplify it; for example, only set the environment variables Leo 
requires, or you could just set the master computer' installation routines 
to use a single location under PortableApps, but I prefer to keep them 
separate for testing purposes.

I hope you (and others googling this later) find this useful.
.. @+node:ekr.20150505084549.1: *3* Plugins
.. @+node:ekr.20150503061351.1: *4* Won't do: Enable plugins separately from loading plugins?
@language rest
@wrap

https://groups.google.com/forum/#!topic/leo-editor/K4rzqDE8emA

The consensus is that this is a bad idea.


Original post:

Leo's plugins manager can and imo should dispatch events registered to a plugin only to commanders for which the plugin is enabled in an @enabled-plugins node.

This would make @enabled-plugins nodes work like all other settings.  Not enabling a plugin in a local (per .leo file) @enabled-plugin node would disable that plugin for that outline even if the plugin is enabled in myLeoSettings.leo or leoSettings.leo.

In practice, the plugins manager would dispatch an event registered by a plugin to a commander only if the plugin is actually enabled in the commander.  Events would be dispatched as always.  For example:

    def onCreate (tag, keys):
        c = keys.get('c')
        if c: << do something >>

The only difference is that this event handler would be called only for outlines in which the plugin was enabled.

.. @+node:ekr.20160405062908.1: *3* Scripts
.. @+node:ekr.20160320072517.1: *4* javascript-to-coffeescript command
Use external code.
.. @+node:ekr.20150707052758.1: *4* py2cython: Like make_stub_files
Generate type declarations from a given set of naming conventions.
.. @+node:ekr.20140730175636.17982: *3* Vim emulation (completed)
No further work is planned.

- N ; repeat the last t,T,f,F command.
  N , repeat the last t,T,f,F command in opposite direction.

- Support z commands:
    z-          or zb   redraw, current line at bottom of window
    z.          or zz   redraw, current line at center of window
    z<Return>   or zt   redraw, current line at top of window

- Finish g command
    ge should go to end of n'th word: at present it goes to end of line.
    gv start visual mode at previous visual area
    gV start visual-line mode at previous visual area.
    
- Possible extensions:
    gft  focus-to-tree
    gfb  focus-to-body
    gfl  focus-to-log
    gfs  focus-to-spell-tab
.. @+node:ekr.20140808182202.18183: *4* Maybe
http://blog.carbonfive.com/2011/10/17/vim-text-objects-the-definitive-guide/

- ctrl-v : visual select column

- Write extend_vim_mode plugin

- Extend Leo's undo to show the vim characters for the commands.

- tab & shift-tab in normal mode might indent text.
  They do nothing in the real vim.  Sheesh.

- Ctrl-C works like escape (Conflicts with copy-text)

:1,$ s/^/  /g

    From line 1 to EOF ($), replace the beginning of the line (^) with two
    spaces ( ), globally (keep applying as many times as possible)
    
    A quick vim-like way to do indents on a range of characters. I also use
    this one frequently...

EKR: Can't Leo's find command do this?
.. @+node:ekr.20140822072856.18255: *4* Substitution notes
@language rest

The :substitute command searches for a text pattern, and replaces it with a text string. There are many options, but these are what you probably want:

:%s/foo/bar
:%s/foo/bar/
    Replace first occurrence of 'foo' with 'bar' in all lines.

:%s/foo/bar/g
     Replace all occurrences of 'foo' with 'bar' in all lines.
   
:s/foo/bar/
    Replace first occurrence of 'foo' (on the current line) with 'bar'

:s/foo/bar/g
    Replace all occurrence of 'foo' (on the current line ), with 'bar'.
    
Flags:
/gi case insensitive
/gI case sensitive
/gw word insensitive
/gW word sensitive
    
===== It's pointless to ask for confirmation: in that case, use Leo's search commands.

:%s/foo/bar/gc
    Change each 'foo' to 'bar', but ask for confirmation first. 

:%s/\<foo\>/bar/gc
    Change only whole words exactly matching 'foo' to 'bar'; ask for confirmation. 

:%s/foo/bar/gci
    Change each 'foo' (case insensitive) to 'bar'; ask for confirmation. 
    This may be wanted after using :set noignorecase to make searches case sensitive (the default). 

:%s/foo/bar/gcI
    Change each 'foo' (case sensitive) to 'bar'; ask for confirmation. 
    This may be wanted after using :set ignorecase to make searches case insensitive. 
.. @+node:ekr.20140822160427.19046: *4* Unfinished operations
N   CTRL-R          redo last N undone changes
    Ctrl-Shift-Z    redo last change
    
N   +               (motion) down N lines, on the first non-blank character (also: CTRL-M and <CR>)
N   -               (motion) up N lines, on the first non-blank character
N   (               (motion) N sentences backward
N   )               (motion) N sentences forward
N   {               (motion) N paragraphs backward
N   }               (motion) N paragraphs forward
N   |               (motion) to column N (default: 1)
    `<              (motion) go to the start of the (previous) Visual area
    `>              (motion) go to the end of the (previous) Visual area
    
N   [(              (motion) N times back to unclosed '('
N   [*              (motion) N times back to start of comment "/*"
N   [{              (motion) N times back to unclosed '{'
N   ])              (motion) N times forward to unclosed ')'
N   ]*              (motion) N times forward to end of comment "*/"
N   ]}              (motion) N times forward to unclosed '}'

N   C               change to end-of-line (and N-1 more lines)
N   D               delete to end-of-line (and N-1 more lines)
N   G               (motion) goto line N (default: last line), on the first non-blank character
N   I               insert text before the first non-blank in the line (N times)
N   J               (motion?) join N-1 lines (delete newlines)
VIS J               (motion?) join the highlighted lines
N   N               (motion) repeat last search, in opposite direction
N   R               enter Replace mode (repeat the entered text N times)
N   S               change N lines
N   X               delete N characters before the cursor
N   Y               yank N lines
    ZQ              Same as ":q!".
    ZZ              Same as ":x".
    
N   cc              change N lines
N   c{motion}       change the text that is moved over with {motion}
VIS c               change the highlighted text
    m<a-zA-Z>       mark current position with mark <a-zA-Z>
N   p               put a register after the cursor position (N times)
    q               stop recording
    q<A-Z>          record typed characters, appended to register <a-z>
    q<a-z>          record typed characters into register <a-z>
N   r<char>         replace N characters with <char>
N   s               change N characters

Searches:

N   /<CR>                       (motion) repeat last search, in the forward direction
N   /{pattern}[/[offset]]<CR>   (motion) search forward for the Nth occurrence of {pattern}
N   ?<CR>                       (motion) repeat last search, in the backward direction
N   ?{pattern}[?[offset]]<CR>   (motion) search backward for the Nth occurrence of {pattern}
.. @+node:ekr.20100113075303.6270: *4* vim problems (from Tom L)
None of these is easily solvable in Leo's present environment.
.. @+node:ekr.20140822160427.19049: *5* Can not be solved using @mode
Most, if not all of these things *can* be solved in Leo's new vim mode.
.. @+node:ekr.20100112051224.6239: *6* Displaying mode help
The "--> mode-help" command has the following issues related to the
display of the "Help" tab:

1. Key label always capitalized.

Vim commands are mapped to both lower-case and upper-case keys but always appear
mapped to upper-case keys within the "Help" tab.

2. Layout of tab's contents.

To improve readability and better support narrow tab cards, display the mode's
label without the "enter-" and "-mode" text and place the key label before the
mode label.

For example, the following entries would change from::
    enter-vi-delete-line-mode d
    enter-vi-delete-to-begin-of-word-mode b
to::
    d : vi-delete-line
    b : vi-delete-to-begin-of-word
.. @+node:ekr.20100113075303.6271: *6* Need mode-oriented bindings
Mapping a number to a command or an @mode node works but can not be used as it
prevents the number from being entered as text while in Vi's insert state.

Binding 'bksp' key to back-char to move back a character in command mode
prevents 'bksp' from deleting characters in text edit mode.
.. @+node:ekr.20100112051224.6238: *6* Some commands do not work in headline
Leo functions exist which unconditionally set focus to the body pane
regardless of the active pane.

For example, bracket matching commands ("%" key) do not work within
a node's headline text.  Instead, the command is performed on the
node's body text.

Using the "undo" command (key 'u') to undo a change to a node's headline text
only works correctly after another node has been selected. It appears that
changes made to a node's headline text are not recorded in Leo's change history
until the edited node has lost focus.
.. @+node:ekr.20100112051224.6222: *6* Commands requesting user input
Commands requesting user input must be the last command executed within an @mode
node. This prevents the implementation of commands such as "yank to <character>"
that requires a "copy to clipboard" operation after the "find-character"
command.

======

Maybe we just need more commands...
.. @+node:ekr.20100112051224.6223: *6* Editing node headlines using @mode nodes
Commands modifying or selecting headline text do not work correctly within a
@mode node.

This eliminates accurate implementation of vi's delete/change/substitute/yank
object commands. As a workaround, the commands are currently written to only
select the text. The user must perform the subsequent delete, change,
substitute, and yank.
.. @+node:ekr.20110529115328.18247: *6* Block cursor
Having worked with Tk text canvases more that Qt, there still seem to
be things that it had that have to be worked around as the Qt people
just haven't seen the need for.

One is the block cursor, I giving Leo Vim like functionality, it would
be nice if one where supported, theses new kids just don't understand
something so primitive I guess.
.. @+node:ekr.20090629183608.8446: *6* Copy/paste/yank/delete
Yank vs. Yank:
Vi's "yank" commands copy the selected text TO the clipboard.
Leo's "yank" commands insert text FROM the clipboard.

copy-text in modes:
Leo's copy-text command does not work within a mode.  As a result,
all "copy to clipboard" capability is being implemented using the
kill-<object> command followed by Leo's "yank" command to put the
text back.

paste-text in modes:
The paste-text command does not work within an @mode node.  Leo's
"yank" command is used instead.

delete-node does not copy node to clipboard:
A copy-node command is issued to copy the node to the clipboard
followed by the delete-node command.
.. @+node:ekr.20100112051224.6226: *6* Range prefix to commands/objects (k.getArgs)
The ability to specify a numeric range prefix is not supported. For example,
entering "3dd" will not delete the next three lines and "20G" will not move the
cursor to the 20th line in the file.

The ability to specify a numeric range prefix to an object is not supported. For
example, the "d2fx" command should Delete up to and including the 2nd Found "x"
character.
.. @+node:ekr.20140822160427.19047: *5* To be solved in new vim mode
Support the ';' key: repeat the last "To character" or "Find character" command.
.. @+node:ekr.20080616110054.2: *6* Support vim dot command
The ability to repeat the last editing related command by pressing the period
key is not supported and there is no workaround in place.

Binding keys within nodes:

Some commands can be "easily" repeated by having the command's mode
bind itself to the period key.  This is not currently working.  

Support commands requesting input:

Add companion commands that reuse input.  For example, a zap-to-
character-again command could exist which will reuse the key entered
in the last zap-to-character command.  With this support, the mode
that performs the initial command would assign the period key to a
companion mode that is identical to the initial mode but with the zap-
to-character command replaced by the zap-to-character-again command.

Commands requiring companion commands are:
  zap-to-character
  find-character
  backward-find-character
  (Any others?)

Notes:

- The copy of the character should be saved somewhere that does NOT affect the
  contents of the clipboard.

- The same or a separate storage location can be used for all commands to retain
  a copy of the character entered by the user. It doesn't matter since only the
  last command is assigned to the period key to be re-executed.
.. @+node:ekr.20100112051224.6234: *6* Move current line (to screen position)
Vi has a collection of "z<movement>" commands that will move the
current line to the top, middle, and bottom of the screen.  They are
not supported in Leo.
.. @+node:ekr.20100112051224.6235: *6* Move body text up/down
Vi maps keys to scroll the text up/down one line and by half the
number of visible lines.  Leo does not support this.

.. @+node:ekr.20110202094848.12568: *6* Named marks
Another is named marks, in Vim you can store a number of cursor
locations, and recall them to jump around in your code.  This was also
useful in filling out templates as each stop could be given a name
mark.  This helped make filling out a template easier as you weren't
stuck in a linear filling in the blanks in a set order, template stops
where linked in rings, you could jump from the last stop back to the
first and make and changes you wanted on a second go round.  Gravity
of marks made things easier to inspect to determine what stops where
used and which ones were being bypassed.

As these things had an actual presence in the text buffer, it going to
be a little harder to come up with a reasonable work around.
.. @+node:ekr.20100112051224.6236: *6* Two kinds of words
Vi supports two types of words in its commands:

1. Words that consist of only a subset of the character set and
2. words that consist of all characters except the space and tab characters.

Leo's always considers a word to consist of a subset of characters
although some word related commands include different characters
than others.
.. @+node:ekr.20100521090440.5887: *5* Generalize minibuffer code
From Tom L

This is hardwired for the first parameter.  Things I need to expand
this:

1. put in a variable that cycles through the tabStops

2. In this mock up, you are entering the parameters in the minibuffer,
a more advanced version would collect each keypress and put it in the
body at the current tabStop, a tab would finalize the entry and
advance to the next stop, no text other than the 'help', ends up in
the minibuffer.

Sinc I'm only modifying existing code without real understanding of
what Leo is doing, any guidance would be appreciated.

===== EKR: I think this has been solved.
.. @+node:ekr.20131105122124.16479: *4* vim reference card (do not delete)
@killcolor # Needed in children

https://groups.google.com/forum/#!topic/leo-editor/OSe0_D5tmJQ

http://stackoverflow.com/questions/7325052/can-someone-explain-to-me-why-the-dot-command-is-so-useful-in-vim
.. @+node:ekr.20131105122124.16482: *5*  keys (do not sort!!)
N   <Del>       delete N characters under and after the cursor
    <Del>       delete the character under the cursor
    <Del>       while entering a count: delete last character
    
    <Left>      (motion) cursor left
    <Right>     (motion) cursor right
    <C-Left>    (motion) cursor one word left
    <C-Right>   (motion) cursor one word right
    
    <Down>      recall newer command-line that starts with current command
    <S-Down>    recall newer command-line from history
    <S-Up>      recall older command-line from history
    <Up>        recall older command-line that starts with current command
    <Esc>       abandon command-line (if 'wildchar' is <Esc>, type it twice)

N   CTRL-^                  Edit alternate file N (equivalent to ":e #N").
N   CTRL-A                  add N to the number at or after the cursor
N   CTRL-B                  window N pages Backwards (upwards)
    CTRL-B                  (motion?) cursor to beginning of command-line
    CTRL-BREAK              MS-DOS: during searches: interrupt the search
    CTRL-C                  during searches: interrupt the search
N   CTRL-D                  window N lines Downwards (default: 1/2 window)
N   CTRL-E                  window N lines downwards (default: 1)
    CTRL-E                  (motion?) cursor to end of command-line
N   CTRL-F                  (motion) window N pages Forwards (downwards)
    CTRL-G                  show current file name (with path) and cursor position
N   CTRL-I                  (motion) go to Nth newer position in jump list
    CTRL-K {char1} {char2}  enter digraph
    CTRL-L                  Clear and redraw the screen.
N   CTRL-O                  (motion) go to Nth older position in jump list
N   CTRL-R                  redo last N undone changes
    CTRL-R <0-9a-z"%:->     insert contents of register <0-9a-z"%:->
N   CTRL-T                  (motion) Jump back from Nth older tag in tag list
N   CTRL-U                  window N lines Upwards (default: 1/2 window)
    CTRL-U                  remove all characters
    CTRL-V                  highlight blockwise or stop highlighting
    CTRL-V                  start highlighting blockwise   }  highlighted text
    CTRL-V {char}           insert {char} literally
    CTRL-V {number}         enter decimal value of character (up to three digits)
    CTRL-W                  delete the word in front of the cursor
    CTRL-W +                Increase current window height
    CTRL-W -                Decrease current window height
    CTRL-W =                Make all windows equal height
    CTRL-W CTRL-W           Move cursor to window below (wrap)
    CTRL-W CTRL-^           Split window and edit alternate file
    CTRL-W R                Rotate windows upwards
    CTRL-W W                Move cursor to window above (wrap)
    CTRL-W ]                Split window and jump to tag under cursor
    CTRL-W _                Set current window height (default: very high)
    CTRL-W b                Move cursor to bottom window
    CTRL-W c  or :cl[ose]   Make buffer hidden and close window
    CTRL-W f                Split window and edit file name under the cursor
    CTRL-W j                Move cursor to window below
    CTRL-W k                Move cursor to window above
    CTRL-W n  or :new       Create new empty window
    CTRL-W o  or :on[ly]    Make current window only one on the screen
    CTRL-W p                Move cursor to previous active window
    CTRL-W q  or :q[uit]    Quit editing and close window
    CTRL-W r                Rotate windows downwards
    CTRL-W s                Split window into two parts
    CTRL-W t                Move cursor to top window
    CTRL-W x                Exchange current window with next one
N   CTRL-X                  subtract N from the number at or after the cursor
N   CTRL-Y                  window N lines upwards (default: 1)
    CTRL-Z                  Same as ":stop!"
    CTRL-]                  Jump to the tag under cursor, unless changes have been made
    
    0               (motion) to first character in the line (also: <Home> key)
VIS ~               switch case for highlighted text
N   ~               switch case for N characters and advance cursor
N   +               (motion) down N lines, on the first non-blank character (also: CTRL-M and <CR>)
N   _               (motion) down N-1 lines, on the first non-blank character
N   -               (motion) up N lines, on the first non-blank character
N   ,               (motion) repeat the last "f", "F", "t", or "T" N times in opposite direction
N   .               (motion?) repeat last change (with count replaced with N)
N   ;               (motion) repeat the last "f", "F", "t", or "T" N times
N   (               (motion) N sentences backward
N   )               (motion) N sentences forward
N   {               (motion) N paragraphs backward
N   }               (motion) N paragraphs forward
N   |               (motion) to column N (default: 1)
    `"              (motion) go to the position when last editing this file
    '<a-zA-Z0-9[]'"<>>  (motion) same as `, but on the first non-blank in the line
    `<              (motion) go to the start of the (previous) Visual area
    `<0-9>          (motion) go to the position where Vim was last exited
    `<A-Z>          (motion) go to mark <A-Z> in any file
    `<a-z>          (motion) go to mark <a-z> within current file
    `>              (motion) go to the end of the (previous) Visual area
    `[              (motion) go to the start of the previously operated or put text
    `]              (motion) go to the end of the previously operated or put text
    ``              (motion) go to the position before the last jump
N   $               (motion) go to the last character in the line (N-1 lines lower) (also: <End> key)
    ^               (motion) go to first non-blank character in the line
N   %               (motion) goto line N percentage down in the file.  N must be given, otherwise it is the % command.
    %               (motion) find the next brace, bracket, comment, or "#if"/ "#else"/"#endif" in this line and go to its match
    
N   <{motion}       move the lines that are moved over with {motion} one shiftwidth left
N   >{motion}       move the lines that are moved over with {motion} one shiftwidth right
N   <<              move N lines one shiftwidth left
N   >>              move N lines one shiftwidth right

N   #                           (motion) search backward for the identifier under the cursor
N   *                           (motion) search forward for the identifier under the cursor
N   /<CR>                       (motion) repeat last search, in the forward direction
N   /{pattern}[/[offset]]<CR>   (motion) search forward for the Nth occurrence of {pattern}
N   ?<CR>                       (motion) repeat last search, in the backward direction
N   ?{pattern}[?[offset]]<CR>   (motion) search backward for the Nth occurrence of {pattern}

N   @<a-z>          execute the contents of register <a-z> (N times)
N   @@              (motion?) repeat previous @<a-z> (N times)

    "<char>         use register <char> for the next delete, yank, or put

N   [#              (motion) N times back to unclosed "#if" or "#else"
N   [(              (motion) N times back to unclosed '('
N   [*              (motion) N times back to start of comment "/*"
N   [[              (motion) N sections backward, at start of section
N   []              (motion) N sections backward, at end of section
N   [p              (motion?) like P, but adjust indent to current line
N   [{              (motion) N times back to unclosed '{'
N   ]#              (motion) N times forward to unclosed "#else" or "#endif"
N   ])              (motion) N times forward to unclosed ')'
N   ]*              (motion) N times forward to end of comment "*/"
N   ][              (motion) N sections forward, at end of section
N   ]]              (motion) N sections forward, at start of section
N   ]p              (motion?) like p, but adjust indent to current line
N   ]}              (motion) N times forward to unclosed '}'

N   A               append text at the end of the line (N times)
N   B               (motion) N blank-separated WORDS backward
N   C               change to end-of-line (and N-1 more lines)
N   D               delete to end-of-line (and N-1 more lines)
N   E               (motion) forward to the end of the Nth blank-separated WORD
N   F<char>         (motion) to the Nth occurrence of <char> to the left
N   G               (motion) goto line N (default: last line), on the first non-blank character
N   H               (motion?) go to the Nth line in the window, on the first non-blank
N   I               insert text before the first non-blank in the line (N times)
N   J               (motion?) join N-1 lines (delete newlines)
VIS J               (motion?) join the highlighted lines
    K               lookup keyword under the cursor with 'keywordprg' program (default: "man")
    M               (motion?) go to the middle line in the window, on the first non-blank
N   L               (motion?) go to the Nth line from the bottom, on the first non-blank
N   N               (motion) repeat last search, in opposite direction
N   O               open a new line above the current line, append text (N times)
N   P               put a register before the cursor position (N times)
N   R               enter Replace mode (repeat the entered text N times)
N   S               change N lines
N   T<char>         (motion) till before the Nth occurrence of <char> to the left
    U               restore last changed line
VIS U               make highlighted text uppercase
    V               highlight linewise or stop highlighting
    V               start highlighting linewise    }  operator to affect
N   W               (motion) N blank-separated WORDS forward
N   X               delete N characters before the cursor
N   Y               yank N lines
    ZQ              Same as ":q!".
    ZZ              Same as ":x".
N   a               append text after the cursor (N times)
N   b               (motion) N words backward
N   cc              change N lines
N   c{motion}       change the text that is moved over with {motion}
VIS c               change the highlighted text
VIS d               delete the highlighted text
N   dd              delete N lines
N   d{motion}       delete the text that is moved over with {motion}
N   e               (motion) forward to the end of the Nth word
N   f<char>         (motion) to the Nth occurrence of <char> to the right
    g CTRL-G        show cursor column, line, and character position
N   g^              (motion) to first non-blank character in screen line (differs from "^" when lines wrap)
    g~{motion}      switch case for the text that is moved over with {motion}
N   g#              (motion) like "#", but also find partial matches
N   g$              (motion) to last character in screen line (differs from "$" when lines wrap)
N   g*              (motion) like "*", but also find partial matches
N   g0              (motion) to first character in screen line (differs from "0" when lines wrap)
    gD              (motion) goto global declaration of identifier under the cursor
N   gE              (motion) backward to the end of the Nth blank-separated WORD
N   gI              insert text in column 1 (N times)
    gU{motion}      make the text that is moved over with {motion} uppercase
    ga              show ascii value of character under cursor in decimal, hex, and octal
    gd              (motion) goto local declaration of identifier under the cursor
    gf  or ]f       Edit the file whose name is under the cursor
N   ge              (motion) backward to the end of the Nth word
N   gg              (motion) goto line N (default: first line), on the first non-blank character
N   gj              (motion) down N screen lines (differs from "j" when line wraps)
N   gk              (motion) up N screen lines (differs from "k" when line wraps)
N   gq{motion}      format the lines that are moved over with {motion} to 'textwidth' length
N   gs              Goto Sleep for N seconds
    gu{motion}      make the text that is moved over with {motion} lowercase
    gv              start highlighting on previous visual area
N   h               (motion) left (also: CTRL-H, <BS>, or <Left> key)
N   i               insert text before the cursor (N times) (also: <Insert>)
N   j               (motion) down N lines (also: CTRL-J, CTRL-N, <NL>, and <Down>)
N   k               (motion) up N lines (also: CTRL-P and <Up>)
N   l               (motion) right (also: <Space> or <Right> key)
N   n               (motion?) repeat last search
    m<a-zA-Z>       mark current position with mark <a-zA-Z>
N   o               open a new line below the current line, append text (N times)
    o               (motion?) exchange cursor position with start of highlighting
N   p               put a register after the cursor position (N times)
    q               stop recording
    q<A-Z>          record typed characters, appended to register <a-z>
    q<a-z>          record typed characters into register <a-z>
N   r<char>         replace N characters with <char>
N   s               change N characters
N   t<char>         (motion) till before the Nth occurrence of <char> to the right
N   u               undo last N changes
VIS u               make highlighted text lowercase
    v               highlight characters or stop highlighting
    v               start highlighting characters  }  move cursor and use
N   w               (motion) N words forward
N   x               delete N characters under and after the cursor
N   yy              yank N lines 
N   y{motion}       yank the text moved over with {motion} 
VIS y               yank the highlighted text 
    z- or zb        redraw, current line at bottom of window
    z. or zz        redraw, current line at center of window
    z<CR> or zt     redraw, current line at top of window
N   zh              scroll screen N characters to the right
N   zl              scroll screen N characters to the left
.. @+node:ekr.20131108082341.18235: *5* motion keys
    CTRL-B  (motion?) cursor to beginning of command-line
    CTRL-E  (motion?) cursor to end of command-line
    N   .   (motion?) repeat last change (with count replaced with N)
N   [p      (motion?) like P, but adjust indent to current line
N   ]p      (motion?) like p, but adjust indent to current line
    
    <Left>  (motion) cursor left
    <Right> (motion) cursor right
    <S-Left>/<S-Right>  (motion) cursor one word left/right
    
N   CTRL-F  (motion) window N pages Forwards (downwards)
N   CTRL-I  (motion) go to Nth newer position in jump list
N   CTRL-O  (motion) go to Nth older position in jump list
N   CTRL-T  (motion) Jump back from Nth older tag in tag list
    0       (motion) to first character in the line (also: <Home> key)
N   +       (motion) down N lines, on the first non-blank character (also: CTRL-M and <CR>)
N   _       (motion) down N-1 lines, on the first non-blank character
N   -       (motion) up N lines, on the first non-blank character
N   ,       (motion) repeat the last "f", "F", "t", or "T" N times in opposite direction
N   ;       (motion) repeat the last "f", "F", "t", or "T" N times
N   (       (motion) N sentences backward
N   )       (motion) N sentences forward
N   {       (motion) N paragraphs backward
N   }       (motion) N paragraphs forward
N   |       (motion) to column N (default: 1)

    `"                  (motion) go to the position when last editing this file
    '<a-zA-Z0-9[]'"<>>  (motion) same as `, but on the first non-blank in the line
    `<                  (motion?) go to the start of the (previous) Visual area
    `<0-9>              (motion) go to the position where Vim was last exited
    `<A-Z>              (motion) go to mark <A-Z> in any file
    `<a-z>              (motion) go to mark <a-z> within current file
    `>                  (motion) go to the end of the (previous) Visual area
    `[                  (motion) go to the start of the previously operated or put text
    `]                  (motion) go to the end of the previously operated or put text
    ``                  (motion) go to the position before the last jump

N   $       (motion) go to the last character in the line (N-1 lines lower) (also: <End> key)
    ^       (motion) go to first non-blank character in the line
N   %       (motion) goto line N percentage down in the file.  N must be given, otherwise it is the % command.
    %       (motion) find the next brace, bracket, comment, or "#if"/ "#else"/"#endif" in this line and go to its match
    
N   #       (motion) search backward for the identifier under the cursor
N   *       (motion) search forward for the identifier under the cursor
N   /<CR>   (motion) repeat last search, in the forward direction

N   /{pattern}[/[offset]]<CR>   (motion) search forward for the Nth occurrence of {pattern}
N   ?<CR>                       (motion) repeat last search, in the backward direction
N   ?{pattern}[?[offset]]<CR>   (motion) search backward for the Nth occurrence of {pattern}

N   [#      (motion) N times back to unclosed "#if" or "#else"
N   [(      (motion) N times back to unclosed '('
N   [*      (motion) N times back to start of comment "/*"
N   [[      (motion) N sections backward, at start of section
N   []      (motion) N sections backward, at end of section
N   [{      (motion) N times back to unclosed '{'

N   ]#      (motion) N times forward to unclosed "#else" or "#endif"
N   ])      (motion) N times forward to unclosed ')'
N   ]*      (motion) N times forward to end of comment "*/"
N   ][      (motion) N sections forward, at end of section
N   ]]      (motion) N sections forward, at start of section
N   ]}      (motion) N times forward to unclosed '}'

N   B       (motion) N blank-separated WORDS backward
N   E       (motion) forward to the end of the Nth blank-separated WORD
N   F<char> (motion) to the Nth occurrence of <char> to the left
N   G       (motion) goto line N (default: last line), on the first non-blank character
N   H       (motion?) go to the Nth line in the window, on the first non-blank
N   J       (motion?) join N-1 lines (delete newlines)
VIS J       (motion?) join the highlighted lines
    M       (motion?) go to the middle line in the window, on the first non-blank
N   L       (motion?) go to the Nth line from the bottom, on the first non-blank
N   N       (motion) repeat last search, in opposite direction
N   T<char> (motion) till before the Nth occurrence of <char> to the left
N   W       (motion) N blank-separated WORDS forward

N   b       (motion) N words backward
N   e       (motion) forward to the end of the Nth word
N   f<char> (motion) to the Nth occurrence of <char> to the right
N   g^      (motion) to first non-blank character in screen line (differs from "^" when lines wrap)
N   g#      (motion) like "#", but also find partial matches
N   g$      (motion) to last character in screen line (differs from "$" when lines wrap)
N   g*      (motion) like "*", but also find partial matches
N   g0      (motion) to first character in screen line (differs from "0" when lines wrap)
    gD      (motion) goto global declaration of identifier under the cursor
N   gE      (motion) backward to the end of the Nth blank-separated WORD
    gd      (motion) goto local declaration of identifier under the cursor
N   ge      (motion) backward to the end of the Nth word
N   gg      (motion) goto line N (default: first line), on the first non-blank character
N   gj      (motion) down N screen lines (differs from "j" when line wraps)
N   gk      (motion) up N screen lines (differs from "k" when line wraps)
N   h       (motion) left (also: CTRL-H, <BS>, or <Left> key)
N   j       (motion) down N lines (also: CTRL-J, CTRL-N, <NL>, and <Down>)
N   k       (motion) up N lines (also: CTRL-P and <Up>)
N   l       (motion) right (also: <Space> or <Right> key)
N   n       (motion?) repeat last search
    o       (motion?) exchange cursor position with start of highlighting
N   t<char> (motion) till before the Nth occurrence of <char> to the right
N   w       (motion) N words forward
.. @+node:ekr.20131108082341.18226: *5* motions
@color

w   to start of next word, excluding it's first character.
e   to end of next word, including it's last character.
$   to end of line, including the last character.
0   to start of line

Motions may include repeat count:

d2w
2dd
d2d

From: http://bullium.com/support/vim.html#motion

Basic motion commands:

N h
N j or Ctrl-N
N k or Ctrl-P
0 or <Home>
^ 
$ or <End>
g0 or
g<Home> 	
g^
g$ or g<End>
f{char}
F{char}
t{char}
T{char}
; 	Repeat latest f, t, F or T [count] times.
, 	Repeat latest f, t, F or T in opposite direction [count] times.
-
N + or CTRL-M or <CR>
N _
<C-End> or G
N <C-Home> or gg
N <S-Right> or w
N <C-Right> or W
N e 	Forward to the end of word [count]
E 	Forward to the end of WORD [count]
<S-Left> or
b 	[count] words backward
<C-Left> or
B 	[count] WORDS backward
ge 	Backward to the end of word [count]
gE 	Backward to the end of WORD [count]

These commands move over words or WORDS.

A word consists of a sequence of letters, digits and underscores, or a
sequence of other non-blank characters, separated with white space (spaces,
tabs, ). This can be changed with the 'iskeyword' option.

A WORD consists of a sequence of non-blank characters, separated with white
space. An empty line is also considered to be a word and a WORD.

N ( 	    
N ) 	    
N { 	    
N } 	
N ]] 	    
N ][ 	    
N [[ 	    
N [] 	
.. @+node:ekr.20131105122124.16483: *5* vim regex
                                           Value of magic option
                                           ---------------------
                        meaning            magic       nomagic

           matches any single character      .            \.
                  matches start of line      ^            ^
                    matches end of line      $            $
                  matches start of word      \<           \<
                    matches end of word      \>           \>
   matches a single char from the range      [a-z]        \[a-z]
 matches a single char not in the range      [^a-z]       \[^a-z]
             matches an identifier char      \i           \i
              idem but excluding digits      \I           \I
            matches a keyword character      \k           \k
              idem but excluding digits      \K           \K
           matches a filename character      \f           \f
              idem but excluding digits      \F           \F
          matches a printable character      \p           \p
              idem but excluding digits      \P           \P

                          matches <Esc>      \e           \e
                          matches <Tab>      \t           \t
                           matches <CR>      \r           \r
                           matches <BS>      \b           \b

matches 0 or more of the preceding atom      *            \*
matches 1 or more of the preceding atom      \+           \+
   matches 0 or 1 of the preceding atom      \=           \=
                 separates two branches      \|           \|
           group a pattern into an atom      \(\)         \(\)
.. @+node:ekr.20131105122124.16484: *5* keys in insert mode
    char                action in Insert mode
    ----                --------------------- 
 
    <Esc>               end Insert mode, back to Normal mode
    <BS> or CTRL-H      delete the character before the cursor
    {char1} <BS> {char2}    enter digraph if 'digraph' option set
    <Del>               delete the character under the cursor
    <End>               cursor after last character in the line
    <Home>              cursor to first character in the line
    <NL> or <CR>        begin new line
    
    cursor keys         move cursor left/right/up/down
    shift-left/right    one word left/right
    shift-up/down       one screenful backward/forward

    CTRL-@              insert previously inserted text and stop insert
    CTRL-A              insert previously inserted text
    CTRL-B              toggle 'revins' (reverse insert) option
    CTRL-C              like <Esc>, but do not do an abbreviation
    CTRL-D              delete one shiftwidth of indent in front of the current line
0   CTRL-D              delete all indent in the current line
^   CTRL-D              delete all indent in the current line, restore indent in next line
    CTRL-E              insert the character from below the cursor
    CTRL-K {char1} {char2}  enter digraph
    CTRL-M or CTRL-J    begin new line
    CTRL-N              insert next match of identifier before the cursor
    CTRL-O {command}    execute {command}
    CTRL-P              insert previous match of identifier before the cursor
    CTRL-R <0-9a-z%:.-"> insert contents of register <0-9a-z%:.-">
    CTRL-T              insert one shiftwidth of indent in front of the current line
    CTRL-U              delete all entered characters in the current line
    CTRL-V <char>..     insert character literally, or enter decimal byte value
    CTRL-W              delete word before the cursor
    CTRL-X ...          complete the word before the cursor in various ways
    CTRL-Y              insert the character from above the cursor
.. @+node:ekr.20131105122124.16485: *5* complex
N  !{motion}{command}<CR>  filter the lines that are moved over through {command}
N  !!{command}<CR>         filter N lines through {command}
   {visual}!{command}<CR>  filter the highlighted lines through {command}
   :[range]! {command}<CR> filter [range] lines through {command}
N  ={motion}               filter the lines that are moved over through "indent"
N  ==                      filter N lines through "indent"
   {visual}=               filter the highlighted lines through "indent"
   
:[range]s[ubstitute]/{pattern}/{string}/[g][c]
:[range]s[ubstitute] [g][c]
   &         Repeat previous ":s" on current line without options
:[range]ret[ab][!] [tabstop]
.. @+node:ekr.20131105122124.16486: *5* text object
Used only in Visual mode or after an operator

a   Select current word
A   Select current WORD
s   Select current sentence
p   Select current paragraph
S   Select current block (from "[(" to "])")
P   Select current block (from "[{" to "]}")
.. @+node:ekr.20131105122124.16487: *5* offsets after search command
[num]       [num] lines downwards, in column 1
+[num]      [num] lines downwards, in column 1
-[num]      [num] lines upwards, in column 1
e[+num]     [num] characters to the right of the end of the match
e[-num]     [num] characters to the left of the end of the match
s[+num]     [num] characters to the right of the start of the match
s[-num]     [num] characters to the left of the start of the match
b[+num]     [num] characters to the right of the start (begin) of the match
b[-num]     [num] characters to the left of the start (begin) of the match
;{search command}   execute {search command} next

Examples

/test/+1		one line below "test", in column 1
/test/e		on the last t of "test"
/test/s+2		on the 's' of "test"
/test/b-3		three characters before "test"
.. @+node:ekr.20131105122124.16488: *5* Examples
:%g/^a/-1join     join lines starting with character 'a' to previous line
:%g/^ *$/d        delete empty lines
:%v/vim/m 1       move lines not matching the word 'vim' to line 1
:%g/^a/+1d        delete lines after the ones starting with character 'a'

:so[urce] {file}    Read Ex commands from {file}.
:so[urce]! {file}   Read Vim commands from {file}.
:sl[eep] [N]        don't do anything for N seconds
.. @+node:ekr.20131105122124.16489: *5* Options overview
name       short name   explanation
----       ----------   -----------
aleph          al       ASCII code of the letter Aleph (RIGHTLEFT)
autoindent     ai       take indent for new line from previous line
autowrite      aw       automatically write file if changed
backspace      bs       how backspace works at start of line
backup         bk       keep backup file after overwriting a file
backupdir      bdir     list of directories for the backup file
backupext      bex      extension used for the backup file
binary         bin      edit binary file mode
bioskey        biosk    MS-DOS: use bios calls for input characters
breakat        brk      characters that may cause a line break
cindent        cin      do C program indenting
cinkeys        cink     keys that trigger indent when 'cindent' is set
cinoptions     cino     how to do indenting when 'cindent' is set
cinwords       cinw     words where 'si' and 'cin' add an indent
cmdheight      ch       number of lines to use for the command-line
columns        co       number of columns in the display
comments       com      patterns that can start a comment line
compatible     cp       behave Vi-compatibly as much as possible
cpoptions      cpo      flags for Vi-compatible behaviour
define         def      pattern to be used to find a macro definition
dictionary     dict     list of filenames used for keyword completion
digraph        dg       enable the entering of digraphs in Insert mode
directory      dir      list of directory names for the swapfile
edcompatible   ed       toggle flags of ":substitute" command
endofline      eol      write end-of-line for last line in file
equalalways    ea       windows are automatically made the same size
equalprg       ep       external program to use for "=" command
errorbells     eb       ring the bell for error messages
errorfile      ef       name of the error file for the QuickFix mode
errorformat    efm      description of the lines in the error file
esckeys        ek       recognize function keys in Insert mode
expandtab      et       use spaces when <Tab> is inserted
exrc                    read .vimrc and .exrc in the current directory
formatoptions  fo       how automatic formatting is to be done
formatprg      fp       name of external program used with "gq" command
gdefault       gd       the ":substitute" flag 'g' is default on
guifont        gfn      GUI: Name(s) of font(s) to be used
guioptions     go       GUI: Which components and options are used
guipty                  GUI: try to use a pseudo-tty for ":!" commands
helpfile       hf       name of this help file
helpheight     hh       minimum height of a new help window
hidden         hid      don't unload buffer when it is abandoned
highlight      hl       sets highlighting mode for various occasions
history        hi       number of command-lines that are remembered
hkmap          hk       Hebrew keyboard mapping (RIGHTLEFT)
icon                    set icon of the window to the name of the file
ignorecase     ic       ignore case in search patterns
include        inc      pattern to be used to find an include file
incsearch      is       highlight match while typing search pattern
infercase      inf      adjust case of match for keyword completion
insertmode     im       start the edit of a file in Insert mode
isfname        isf      characters included in filenames and pathnames
isident        isi      characters included in identifiers
isprint        isp      printable characters
iskeyword      isk      characters included in keywords
joinspaces     js       two spaces after a period with a join command
keywordprg     kp       program to use for the "K" command
langmap        lmap     alphabetic characters for other language mode
laststatus     ls       tells when last window has status lines
linebreak      lbr      wrap long lines at a blank
lines                   number of lines in the display
lisp                    automatic indenting for Lisp
list                    show <Tab> and end-of-line
magic                   changes special characters in search patterns
makeprg        mp       program to use for the ":make" command
maxmapdepth    mmd      maximum recursive depth for mapping
maxmem         mm       maximum memory (in Kbyte) used for one buffer
maxmemtot      mmt      maximum memory (in Kbyte) used for all buffers
modeline       ml       recognize modelines at start or end of file
modelines      mls      number of lines checked for modelines
modified       mod      buffer has been modified
more                    pause listings when the whole screen is filled
mouse                   enable the use of mouse clicks
mousetime      mouset   max time between mouse double-click
number         nu       print the line number in front of each line
paragraphs     para     nroff macros that separate paragraphs
paste                   allow pasting text
patchmode      pm       keep the oldest version of a file
path           pa       list of directories searched with "gf" et.al.
readonly       ro       disallow writing the buffer
remap                   allow mappings to work recursively
report                  threshold for reporting nr. of lines changed
restorescreen  rs       Win32: restore screen when exiting
revins         ri       inserting characters will work backwards
rightleft      rl       window is right-to-left oriented (RIGHTLEFT)
ruler          ru       show cursor line and column in the status line
scroll         scr      lines to scroll with CTRL-U and CTRL-D
scrolljump     sj       minimum number of lines to scroll
scrolloff      so       minimum nr. of lines above and below cursor
sections       sect     nroff macros that separate sections
secure                  secure mode for reading .vimrc in current dir
shell          sh       name of shell to use for external commands
shellcmdflag   shcf     flag to shell to execute one command
shellpipe      sp       string to put output of ":make" in error file
shellquote     shq      quote character(s) for around shell command
shellredir     srr      string to put output of filter in a temp file
shelltype      st       Amiga: influences how to use a shell
shiftround     sr       round indent to multiple of shiftwidth
shiftwidth     sw       number of spaces to use for (auto)indent step
shortmess      shm      list of flags, reduce length of messages
shortname      sn       non-MS-DOS: File names assumed to be 8.3 chars
showbreak      sbr      string to use at the start of wrapped lines
showcmd        sc       show (partial) command in status line
showmatch      sm       briefly jump to matching bracket if insert one
showmode       smd      message on status line to show current mode
sidescroll     ss       minimum number of columns to scroll horizontal
smartcase      scs      no ignore case when pattern has uppercase
smartindent    si       smart autoindenting for C programs. For perl
                        script editing set this option and the following
                        key mapping: inoremap # x<BS># 
smarttab       sta      use 'shiftwidth' when inserting <Tab>
splitbelow     sb       new window from split is below the current one
startofline    sol      commands move cursor to first blank in line
suffixes       su       suffixes that are ignored with multiple match
swapsync       sws      how to sync swapfile
tabstop        ts       number of spaces that <Tab> in file uses
taglength      tl       number of significant characters for a tag
tagrelative    tr       filenames in tag file are relative
tags           tag      list of filenames used by the tag command
term                    name of the terminal
terse                   shorten some messages
textauto       ta       set 'textmode' automatically when reading file
textmode       tx       lines are separated by <CR><NL>
textwidth      tw       maximum width of text that is being inserted
tildeop        top      tilde command "~" behaves like an operator
timeout        to       time out on mappings and key codes
ttimeout                time out on mappings
timeoutlen     tm       time out time in milliseconds
ttimeoutlen    ttm      time out time for key codes in milliseconds
title                   set title of window to the name of the file
ttybuiltin     tbi      use built-in termcap before external termcap
ttyfast        tf       indicates a fast terminal connection
ttyscroll      tsl      maximum number of lines for a scroll
ttytype        tty      alias for 'term'
undolevels     ul       maximum number of changes that can be undone
updatecount    uc       after this many characters flush swapfile
updatetime     ut       after this many milliseconds flush swapfile
viminfo        vi       use .viminfo file upon startup and exiting
visualbell     vb       use visual bell instead of beeping
warn                    warn for shell command when buffer was changed
weirdinvert    wi       for terminals that have weird inversion method
whichwrap      ww       allow specified keys to cross line boundaries
wildchar       wc       command-line character for wildcard expansion
winheight      wh       minimum number of lines for the current window
wrap                    long lines wrap and continue on the next line
wrapmargin     wm       chars from the right where wrapping starts
wrapscan       ws       searches wrap around the end of the file
writeany       wa       write to file with no need for "!" override
writebackup    wb       make a backup before overwriting a file
writedelay     wd       delay this many msec for each char (for debug)
.. @+node:ekr.20131105122124.16490: *5* Command-line completion
'wildchar' (default: <Tab>)
    do completion on the pattern in front of the cursor. If there are
    multiple matches, beep and show the first one; further 'wildchar' will
    show the next ones.
                   
CTRL-A  insert all names that match pattern in front of cursor
CTRL-D  list   all names that match the pattern in front of the cursor
CTRL-L  insert longest common part of names that match pattern
CTRL-N  after 'wildchar' with multiple matches: go to next match
CTRL-P  after 'wildchar' with multiple matches: go to previous match
.. @+node:ekr.20131105122124.16491: *5* Special Ex characters
|           separates two commands (not for ":global" and ":!")
"           begins comment

%           current filename (only where filename is expected)
#[number]   alternate filename [number] (only where filename is expected)

Note: The next four are typed literally; these are not special keys!

<cword>     word under the cursor (only where filename is expected)
<cWORD>     WORD under the cursor (only where filename is expected)
<cfile>     file name under the cursor (only where filename is expected)
<afile>     file name for autocommand (only where filename is expected)

After "%", "#", "<cfile>", or "<afile>"
:p          full path
:h          head
:t          tail
:r          root
:e          extension
.. @+node:ekr.20131105122124.16492: *5* Ex ranges
,               separates two line numbers
;               idem, set cursor to the first line number
                before interpreting the second one
{number}        an absolute line number
.               the current line
$               the last line in the file
%               equal to 1,$ (the entire file)
*               equal to '<,'> (visual area)
't              position of mark t
/{pattern}[/]   the next line where {pattern} matches
?{pattern}[?]   the previous line where {pattern} matches
+[num]          add [num] to the preceding line number (default: 1)
-[num]          subtract [num] from the preceding line number (default: 1)
.. @+node:ekr.20131105122124.16493: *5* Starting vim
38 -- Starting VIM


vim [options]                start editing with an empty buffer
vim [options] {file ..}      start editing one or more files
vim [options] -t {tag}       edit the file associated with {tag}
vim [options] -e [fname]     start editing in QuickFix mode, display the first error


39 -- Vim Command Line Arguments


-g                  start GUI (also allows other options)

+[num]              put the cursor at line [num] (default: last line)
+{command}          execute {command} after loading the file
+/{pat} {file ..}   put the cursor at the first occurrence of {pat}
-v                  read-only mode (View), implies -n
-R                  read-only mode, same as -v
-b                  binary mode
-l                  lisp mode
-H                  Hebrew mode ('hkmap' and 'rightleft' are set)
-r                  give list of swap files
-r {file ..}        recover aborted edit session
-n                  do not create swapfile
-o [N]              open N windows (default: one for each file)
-x                  Amiga: do not restart VIM to open a window (for
                        e.g., mail)
-s {scriptin}       first read commands from the file {scriptin}
-w {scriptout}      write typed chars to file {scriptout} (append)
-W {scriptout}      write typed chars to file {scriptout} (overwrite)
-T {terminal}       set terminal name
-d {device}         Amiga: open {device} to be used as a console
-u {vimrc}          read inits from {vimrc} instead of other inits
-i {viminfo}        read info from {viminfo} instead of other files
--                  end of options, other arguments are file names

Automatic option setting when editing a file

vim:{set-arg}: ..       In the first and last lines of the
                        file (see 'ml' option), {set-arg} is
                        given as an argument to ":set"
                        
Automatic execution of commands on certain events.

:au                     List all autocommands
:au {event}             List all autocommands for {event}
:au {event} {pat}       List all autocommands for {event} with {pat}
:au {event} {pat} {cmd} Enter new autocommands for {event} with {pat}
:au!                    Remove all autocommands
:au! {event}            Remove all autocommands for {event}
:au! * {pat}            Remove all autocommands for {pat}
:au! {event} {pat}      Remove all autocommands for {event} with {pat}
:au! {event} {pat} {cmd}  Remove all autocommands for {event} with {pat} and enter new one
.. @+node:ekr.20131105122124.16494: *5* : commands unsorted
:marks                  print the active marks
:ju[mps]                print the jump list
:ta[g][!] {tag}         Jump to tag {tag}
:[count]ta[g][!]        Jump to [count]'th newer tag in tag list
:[count]po[p][!]        Jump back from [count]'th older tag in tag list
:tags                   Print tag list
:dig[raphs]                                 show current list of digraphs
:dig[raphs] {char1}{char2} {number} ...     add digraph(s) to the list
:r [file]               insert the contents of [file] below the cursor
:r! {command}           insert the standard output of {command} below the cursor
:[range]d [x]           delete [range] lines [into register x]
:reg                    show the contents of all registers
:reg {arg}              show the contents of registers mentioned in {arg}
:[range]ce[nter] [width] center the lines in [range]
:[range]le[ft] [indent]  left-align the lines in [range] [with indent]
:[range]ri[ght] [width]  right-align the lines in [range]
:@<a-z>                 execute the contents of register <a-z> as an Ex command
:@@                     repeat previous :@<a-z>
:[range]g[lobal]/{pattern}/[cmd] 
:[range]g[lobal]!/{pattern}/[cmd]     or    :[range]v/{pattern}/[cmd]
:ma[p] {lhs} {rhs}          Map {lhs} to {rhs} in Normal and Visual mode.
:ma[p]! {lhs} {rhs}         Map {lhs} to {rhs} in Insert and Command-line mode.
:no[remap][!] {lhs} {rhs}   Same as ":map", no remapping for this {rhs}
:unm[ap] {lhs}              Remove the mapping of {lhs} for Normal and Visual mode.
:unm[ap]! {lhs}             Remove the mapping of {lhs} for Insert and Command-line mode.
:ma[p] [lhs]         List mappings (starting with [lhs]) for Normal and Visual mode.
:ma[p]! [lhs]        List mappings (starting with [lhs]) for Insert and Command-line mode.
:cmap/:cunmap/:cnoremap 
:imap/:iunmap/:inoremap
:nmap/:nunmap/:nnoremap
:vmap/:vunmap/:vnoremap
:mk[exrc][!] [file]  write current mappings, abbreviations, and settings to [file] (default: ".exrc"; use ! to overwrite)
:mkv[imrc][!] [file] same as ":mkexrc", but with default ".vimrc"
:mapc[lear]          remove mappings for Normal and Visual mode
:mapc[lear]!         remove mappings for Insert and Cmdline mode
:imapc[lear]         remove mappings for Insert mode
:vmapc[lear]         remove mappings for Visual mode
:nmapc[lear]         remove mappings for Normal mode
:cmapc[lear]         remove mappings for Cmdline mode

:ab[breviate] {lhs} {rhs}  add abbreviation for {lhs} to {rhs}
:ab[breviate] {lhs}        show abbr's that start with {lhs}
:ab[breviate]              show all abbreviations
:una[bbreviate] {lhs}      remove abbreviation for {lhs}
:norea[bbrev] [lhs] [rhs]  like ":ab", but don't remap [rhs]
:iab/:iunab/:inoreab       like ":ab", but only for Insert mode
:cab/:cunab/:cnoreab       like ":ab", but only for Command-line mode
:abc[lear]                 remove all abbreviations
:cabc[lear]                remove all abbr's for Cmdline mode
:iabc[lear]                remove all abbr's for Insert mode
:se[t]                  Show all modified options.
:se[t] all              Show all options.
:se[t] {option}         Set toggle option on, show string or number option.
:se[t] no{option}       Set toggle option off.
:se[t] inv{option}      invert toggle option.
:se[t] {option}={value} Set string or number option to {value}.
:se[t] {option}?        Show value of {option}.
:se[t] {option}&        Reset {option} to its default value.
:fix[del]               Set value of 't_kD' according to value of 't_kb'.
:sh[ell]        start a shell
:!{command}     execute {command} with a shell
:cc [nr]        display error [nr] (default is the same again)
:cn             display the next error
:cp             display the previous error
:cl             list all errors
:cf             read errors from the file 'errorfile'
:cq             quit without writing and return error code (to the compiler)
:make [args]    start make, read errors, and jump to first error
:ve[rsion]      show exact version number of this Vim
:mode N         MS-DOS: set screen mode to N (number, C80, C4350, etc.)
:norm[al][!] {commands} Execute Normal mode commands.
:e[dit]              Edit the current file, unless changes have been made.
:e[dit]!             Edit the current file always.  Discard any changes.
:e[dit] {file}       Edit {file}, unless changes have been made.
:e[dit]! {file}      Edit {file} always.  Discard any changes.
:pwd                 Print the current directory name.
:cd [path]           Change the current directory to [path].
:f[ile]              Print the current filename and the cursor position.
:f[ile] {name}       Set the current filename to {name}.
:files               Show alternate filenames.

:argu[ment] N       edit file N
:n[ext]             edit next file
:n[ext] {arglist}   define new arg list and edit first file
:N[ext]             edit previous file
:rew[ind][!]        edit first file
:last               edit last file
:sar[gument] N      edit file N (new window)
:sn[ext]            edit next file (new window)
:sn[ext] {arglist}  define new arg list and edit first file (new window)
:sN[ext]            Edit previous file (new window)
:srew[ind]          Edit first file (new window)
:slast              Edit last file (new window)


:ar[gs]              Print the argument list, with the current file in "[]".
:all  or :sall       Open a window for every file in the arg list.
:wn[ext][!]          Write file and edit next file.
:wn[ext][!] {file}   Write to {file} and edit next file, unless {file} exists.  With !, overwrite existing file.
:wN[ext][!] [file]   Write file and edit previous file.
:[range]w[rite][!]            Write to the current file.
:[range]w[rite] {file}        Write to {file}, unless it already exists.
:[range]w[rite]! {file}       Write to {file}.  Overwrite an existing file.
:[range]w[rite][!] >>         Append to the current file.
:[range]w[rite][!] >> {file}  Append to {file}.
:[range]w[rite] !{cmd}        Execute {cmd} with [range] lines as standard input.
:wall[!]                      write all changed buffers

:q[uit]               Quit current buffer.
:q[uit]!              Quit current buffer always.
:qall                 Exit Vim, unless changes have been made.
:qall!                Exit Vim always, discard any changes.
:cq                   Quit without writing and return error code.

:wq[!]                Write the current file and exit.
:wq[!] {file}         Write to {file} and exit.
:x[it][!] [file]      Like ":wq" but write only when changes have been made
:xall[!]  or :wqall[!]  Write all changed buffers and exit
:st[op][!]              Suspend VIM or start new shell. If 'aw' option is set and [!] not given write the buffer.

:rv[iminfo] [file]      Read info from viminfo file [file]
:rv[iminfo]! [file]     idem, overwrite exisiting info
:wv[iminfo] [file]      Add info to viminfo file [file]
:wv[iminfo]! [file]     Write info to viminfo file [file]

:split                  Split window into two parts
:split {file}           Split window and edit {file} in one of them

:buffers  or  :files    list all known buffer and file names
:ball     or  :sball    edit all args/buffers
:unhide   or  :sunhide  edit all loaded buffers

:bunload[!] [N]         unload buffer [N] from memory
:bdelete[!] [N]         unload buffer [N] and delete it from the buffer list

:[N]buffer [N]      to arg/buf N
:[N]bnext [N]       to Nth next arg/buf
:[N]bNext [N]       to Nth previous arg/buf
:[N]bprevious [N]   to Nth previous arg/buf
:brewind            to first arg/buf
:blast              to last arg/buf
:[N]bmod [N]        to Nth modified buf

:[N]sbuffer [N]     to arg/buf N (in new window)
:[N]sbnext [N]      to Nth next arg/buf (in new window)
:[N]sbNext [N]      to Nth previous arg/buf (in new window)
:[N]sbprevious [N]  to Nth previous arg/buf (in new window)
:sbrewind           to first arg/buf (in new window)
:sblast             to last arg/buf (in new window)
:[N]sbmod [N]       to Nth modified buf (in new window)
.. @+node:ekr.20131105122124.16495: *5* : commands merged (do not sort!)
:!{command}                     execute {command} with a shell
:@<a-z>                         execute the contents of register <a-z> as an Ex command
:@@                             repeat previous :@<a-z>
:N[ext]                         edit previous file
:ab[breviate]                   show all abbreviations
:ab[breviate] {lhs}             show abbr's that start with {lhs}
:ab[breviate] {lhs} {rhs}       add abbreviation for {lhs} to {rhs}
:abc[lear]                      remove all abbreviations
:all  or :sall                  open a window for every file in the arg list.
:ar[gs]                         print the argument list, with the current file in "[]".
:argu[ment] N                   edit file N
:[N]bNext [N]                   to Nth previous arg/buf
:ball     or  :sball            edit all args/buffers
:bdelete[!] [N]                 unload buffer [N] and delete it from the buffer list
:blast                          to last arg/buf
:[N]bmod [N]                    to Nth modified buf
:[N]bnext [N]                   to Nth next arg/buf
:[N]bprevious [N]               to Nth previous arg/buf
:[N]buffer [N]                  to arg/buf N
:brewind                        to first arg/buf
:buffers  or  :files            list all known buffer and file names
:bunload[!] [N]                 unload buffer [N] from memory
:cab/:cunab/:cnoreab            like ":ab", but only for Command-line mode
:cabc[lear]                     remove all abbr's for Cmdline mode
:cc [nr]                        display error [nr] (default is the same again)
:cd [path]                      change the current directory to [path].
:[range]ce[nter] [width]        center the lines in [range]
:cf                             read errors from the file 'errorfile'
:cl                             list all errors
:cmap/:cunmap/:cnoremap 
:cmapc[lear]                    remove mappings for Cmdline mode
:cn                             display the next error
:cp                             display the previous error
:cq                             quit without writing and return error code.
:cq                             quit without writing and return error code (to the compiler)
:[range]d [x]                   delete [range] lines [into register x]
:dig[raphs]                     show current list of digraphs
:dig[raphs] {char1}{char2} {number} ...     add digraph(s) to the list
:e[dit]                         edit the current file, unless changes have been made.
:e[dit] {file}                  edit {file}, unless changes have been made.
:e[dit]!                        edit the current file always.  Discard any changes.
:e[dit]! {file}                 edit {file} always.  Discard any changes.
:f[ile]                         print the current filename and the cursor position.
:f[ile] {name}                  set the current filename to {name}.
:files                          show alternate filenames.
:fix[del]                       set value of 't_kD' according to value of 't_kb'.
:[range]g[lobal]!/{pattern}/[cmd]
:[range]g[lobal]/{pattern}/[cmd] 
:iab/:iunab/:inoreab            like ":ab", but only for Insert mode
:iabc[lear]                     remove all abbr's for Insert mode
:imap/:iunmap/:inoremap
:imapc[lear]                    remove mappings for Insert mode
:ju[mps]                        print the jump list
:last                           edit last file
:[range]le[ft] [indent]         left-align the lines in [range] [with indent]
:ma[p] [lhs]                    list mappings (starting with [lhs]) for Normal and Visual mode.
:ma[p] {lhs} {rhs}              map {lhs} to {rhs} in Normal and Visual mode.
:ma[p]! [lhs]                   list mappings (starting with [lhs]) for Insert and Command-line mode.
:ma[p]! {lhs} {rhs}             map {lhs} to {rhs} in Insert and Command-line mode.
:make [args]                    start make, read errors, and jump to first error
:mapc[lear]                     remove mappings for Normal and Visual mode
:mapc[lear]!                    remove mappings for Insert and Cmdline mode
:marks                          print the active marks
:mk[exrc][!] [file]             write current mappings, abbreviations, and settings to [file] (default: ".exrc"; use ! to overwrite)
:mkv[imrc][!] [file]            same as ":mkexrc", but with default ".vimrc"
:mode N                         MS-DOS: set screen mode to N (number, C80, C4350, etc.)
:n[ext]                         edit next file
:n[ext] {arglist}               define new arg list and edit first file
:nmap/:nunmap/:nnoremap
:nmapc[lear]                    remove mappings for Normal mode
:no[remap][!] {lhs} {rhs}       same as ":map", no remapping for this {rhs}
:norea[bbrev] [lhs] [rhs]       like ":ab", but don't remap [rhs]
:norm[al][!] {commands}         execute Normal mode commands.
:[count]po[p][!]                jump back from [count]'th older tag in tag list
:pwd                            print the current directory name.
:q[uit]                         quit current buffer.
:q[uit]!                        quit current buffer always.
:qall                           exit Vim, unless changes have been made.
:qall!                          exit Vim always, discard any changes.
:r [file]                       insert the contents of [file] below the cursor
:r! {command}                   insert the standard output of {command} below the cursor
:reg                            show the contents of all registers
:reg {arg}                      show the contents of registers mentioned in {arg}
:rew[ind][!]                    edit first file
:[range]ri[ght] [width]         right-align the lines in [range]
:rv[iminfo] [file]              read info from viminfo file [file]
:rv[iminfo]! [file]             idem, overwrite exisiting info
:sN[ext]                        edit previous file (new window)
:sar[gument] N                  edit file N (new window)
:sblast                         to last arg/buf (in new window)
:[N]sbNext [N]                  to Nth previous arg/buf (in new window)
:[N]sbmod [N]                   to Nth modified buf (in new window)
:[N]sbnext [N]                  to Nth next arg/buf (in new window)
:[N]sbprevious [N]              to Nth previous arg/buf (in new window)
:[N]sbuffer [N]                 to arg/buf N (in new window)
:sbrewind                       to first arg/buf (in new window)
:se[t]                          show all modified options.
:se[t] all                      show all options.
:se[t] inv{option}              invert toggle option.
:se[t] no{option}               set toggle option off.
:se[t] {option}                 set toggle option on, show string or number option.
:se[t] {option}&                reset {option} to its default value.
:se[t] {option}={value}         set string or number option to {value}.
:se[t] {option}?                show value of {option}.
:sh[ell]                        start a shell
:slast                          edit last file (new window)
:sn[ext]                        edit next file (new window)
:sn[ext] {arglist}              define new arg list and edit first file (new window)
:split                          Split window into two parts
:split {file}                   Split window and edit {file} in one of them
:srew[ind]                      Edit first file (new window)
:st[op][!]                      Suspend VIM or start new shell. If 'aw' option is set and [!] not given write the buffer.
:[count]ta[g][!]                jump to [count]'th newer tag in tag list
:ta[g][!] {tag}                 jump to tag {tag}
:tags                           print tag list
:una[bbreviate] {lhs}           remove abbreviation for {lhs}
:unhide   or  :sunhide          edit all loaded buffers
:unm[ap] {lhs}                  remove the mapping of {lhs} for Normal and Visual mode.
:unm[ap]! {lhs}                 remove the mapping of {lhs} for Insert and Command-line mode.
:[range]v/{pattern}/[cmd]
:ve[rsion]                      show exact version number of this Vim
:vmap/:vunmap/:vnoremap
:vmapc[lear]                    remove mappings for Visual mode
:[range]w[rite] !{cmd}          execute {cmd} with [range] lines as standard input.
:[range]w[rite] {file}          write to {file}, unless it already exists.
:[range]w[rite]! {file}         write to {file}.  Overwrite an existing file.
:[range]w[rite][!]              write to the current file.
:[range]w[rite][!] >>           append to the current file.
:[range]w[rite][!] >> {file}    append to {file}.
:wN[ext][!] [file]              write file and edit previous file.
:wall[!]                        write all changed buffers
:wn[ext][!]                     write file and edit next file.
:wn[ext][!] {file}              write to {file} and edit next file, unless {file} exists.  With !, overwrite existing file.
:wq[!]                          write the current file and exit.
:wq[!] {file}                   write to {file} and exit.
:wv[iminfo] [file]              add info to viminfo file [file]
:wv[iminfo]! [file]             write info to viminfo file [file]
:x[it][!] [file]                like ":wq" but write only when changes have been made
:xall[!]  or :wqall[!]          Write all changed buffers and exit
.. @+node:ekr.20160405061600.1: *3* Web stuff
.. @+node:ekr.20160318133309.1: *4* Leo in coffeescript
.. @+node:ekr.20151130084237.1: *4* Improve load-leo page
@language rest
@wrap

http://leoeditor.com/load-leo.html

* There are bugs re clones.

- Allow outline/body panes to be resized.
- Support hightlight.js: https://highlightjs.org/
.. @+node:ekr.20160404062404.1: ** Won't/Can't fix
.. @+node:ekr.20050202073944: *3* Can't Fix: Mac bugs
- Icon buttons are not colored, nor do they have square borders, etc.
- Can't delete script buttons
.. @+node:ekr.20110111100539.12257: *4* Fix end-of-line problem (MacOS)
Apparently, ctrl-e is not passed to Leo at all.

This probably can't be fixed.
.. @+node:ekr.20110111100539.12258: *5* Report
http://mail.google.com/mail/#inbox/12c5646c646a90d2

I expect C-e to go to end-of-line, but C-e works as the next line.
Alt-x and check end-of-line and I get the following result.

I use Mac OS X 10.6.5, newest Leo, and Python/Qt.

Leo 4.8 rc1, build 3715, November 15, 2010
Python 2.6.1, qt version 4.7.0
darwin

I remember I could use C-e, but it doesn't work anymore even after I
reinstall the Leo.

As I explained in this post - http://groups.google.com/group/leo-editor/browse_thread/thread/1ee0b35b4f76c999
After having @bool swap_mac_keys = True, I can use C-e.

C-a move the cursor to the start of line, but C-e seems to move the
cursor the first of the next line, which is the end of last line + 1.
If the line is the final one, C-e moves the cursor to the end of line
as there's no next line.

.. @+node:ekr.20031218072017.670: *3* Can't Fix: 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.20110619173515.14896: *3* Can't Fix: Wrong modality level on autocompleter
Just noticed the autocompleter pop-up is modal globally, not just for the Leo windows.  Probably should only block the Leo windows.
.. @+node:ekr.20130916105324.19894: *3* Won't fix: #1226353: @shadow does not retain outline structure properly
@language rest

https://bugs.launchpad.net/leo-editor/+bug/1226353

===== EKR

The most important problem is compatibility.  As I have just verified,
@shadow will work even if the private file does not exist,
but all outline structure will be lost.  Therefore, it may be best
not to try to read old (ver-4thin) files at all.

@shadow does not reload the following simple file correctly!

+ @shadow
   @others
  + child 1
    child 1.1

shadow files (the private files containing the sentinels) use the *old*
(#@+leo-ver=4-thin) sentinels, rather than the new (#@+leo-ver=5-thin)
sentinels.

The old sentinels don't have an explicit notion of nesting level; the new
sentinels do, so it would seem that the way to fix this problem is to use
new sentinels. However, this would be a major change to the inner workings
of the @shadow logic.
.. @+node:ekr.20130908104426.11242: *3* Won't fix: #914221: bound method ViewRenderedController.updated
https://bugs.launchpad.net/leo-editor/+bug/914221

Summary of a *long* discussion: this may be a docutils issue, and does not
seem easy to fix.
.. @-all
.. @@nosearch
.. @-leo
