.. @+leo-ver=5-thin
.. @+node:ekr.20100119205347.6015: * @file ../doc/leoToDo.txt
.. @@language rest
.. @@wrap
.. @+all
.. @+node:ekr.20160405063258.1: ** Unlikely
.. @+node:ekr.20160315141751.1: *3* Code Academy
- 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.20180124140252.1: *3* Coloring
.. @+node:ekr.20111028195854.16607: *4* Unlikely: Allow ruleset-specific colors
Like @color html::tags_markup_color = blue
.. @+node:ekr.20150516123559.1: *4* Unlikely: Doc parts should colorize like rst/md by default
This seems more difficult than I thought.
.. @+node:ekr.20150616085806.1: *4* Unlikely: Support solorized selected text
I don't believe this can be done just using stylesheets.
Probably will need custom painters.
.. @+node:ekr.20180124135223.1: *3* Commands & features
.. @+node:ekr.20150215102218.4: *4* Unlikely: @ns-rst/vo/otl commands
From https://groups.google.com/d/msg/leo-editor/QxK2V62ESLw/vCSolavmw4YJ

EKR: The new importers do most of these.

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


===== @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.20369: *4* Unlikely: @paragraph (offray)
EKR: I don't understand why this would be useful.

I would like to have 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.
.. @+node:ekr.20041219162724: *4* Unlikely: Add dialog to insert recent directories
The multifile plugin contains option to insert a directory string.  I use it alot for the @path directive.  This opens a FileDialog 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.20041130123243: *4* Unlikely: clear-undo command (e)
http://sourceforge.net/forum/message.php?msg_id=2859273

EKR: There's a config option to clear undo on save. That should suffice

Many small edits on an open leo after a few hours can trigger a slow GC cycle. I have no idea if undo is the cause, just guessing.
.. @+node:ekr.20130806211959.17365: *4* Unlikely: Docear, Latex, PDF enhancements
@language rest
@wrap

EIR: To summarize: It seems that Leo already has most of what is needed.

From https://groups.google.com/d/msg/leo-editor/QbQHzlRtioc/uviFCvR9DeMJ

===== Josef <joe_da@gmx.net> 7/30/12
		
Recently I evaluated [docear](http://www.docear.org/), 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. Imo it would have 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?
	
7/30/12
		
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.

Maybe the better approach is connecting Leo to Docear, so you can have the advantages of both.

Offray

===== Terry

I'm not sure how notes get embedded in PDFs.

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

> An alternative may be to sync data somehow between docear and Leo.

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 cmap is better at idea organizing than mindmaps.

The backlinks plugin for Leo allows arbitrary networks of links instead of just the directed tree. The graphcanvas plugin allows graph layout of nodes.  There aren't comparable with the mindmap layouts, but they head in that direction.
.. @+node:ekr.20110529115328.18238: *4* Unlikely: Emacs related
I'll do these if and and only if somebody asks for them.
.. @+node:ekr.20110529104352.18248: *5* Complete k.universalDispatcher
.. @+node:ekr.20110529104352.18249: *5* Complete number-to-register command
.. @+node:ekr.20031218072017.753: *5* 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: *5* Expand 'point' so it indicates node as well as text location
.. @+node:ekr.20071004120359.2: *5* 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: *5* Incremental search in switch-to-buffer
.. @+node:ekr.20060628103226.3: *5* Make sure repeat counts work on basic editing commands
.. @+node:ekr.20051021074728: *5* Space completion
.. @+node:ekr.20111019104425.15892: *4* Unlikely: Enhance Buttons (Kent)
Enhance the button machinery to allow mixed case, spaces, colors.
.. @+node:ekr.20031218072017.748: *4* Unlikely: Import/Export to yaml
Need a good yaml parser first: I don't want to write another parser by hand.
.. @+node:ekr.20130806072439.21337: *4* Unlikely: Improve C importer
From: ne1uno <eltronis@gmail.com>

The new C importer probably suffices.
.. @+node:ekr.20161205102034.1: *4* Unlikely: Modes to support vim dot (EKR)
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.20050127110221: *4* Unlikely: More flexible output (jasonic)
Most of this has already been done.  Flash is dying.
.. @+node:ekr.20180131075327.1: *5* pdf
PDF has it uses. If nicely embedded into Leo via 'reportwriter'and some export scripts {and clear useinterfance} would still be 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.
.. @+node:ekr.20180131075414.1: *5* 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.
.. @+node:ekr.20180131075435.1: *5* flash/swf
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.
.. @+node:ekr.20180131075537.1: *5* flashpaper2 (commercial)
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 literal snapshot, but that turns out to be extremely useful. For example, you visit a page and click on some links. Flashpaper saves the pages exactly as they looks, visted 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/

Flash *players* are 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. Your coleagues can pan and zoom as they like.

I've not quite figured 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.

[Obsolete] Leo's does not have a Print menu, so it's off the sytem's print-devices map, which Flash paper appearing just like any phtycial printer.

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]

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.20031218072017.807: *4* Unlikely: 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.20041016134312.2: *4* Unlikely: Standard Weave command
Use noweb and TeX, or maybe Pyx.
.. @+node:ekr.20180124135104.1: ** Won't do
.. @+node:ekr.20160405063304.1: *3* Commands & features
.. @+node:ekr.20160503093454.2: *4* Won't do: Ignore URL's in scripts
EKR summary: There is no need for this: @button nodes now have a "goto script" popup item.
.. @+node:ekr.20031218072017.790: *4* Won't do: Import dialog improvements
EKR: I'm not sure these kinds of imports are safe.

Other options I though would be really handy:

1. Use an existing node as a source also: parse-body does something like this.

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.20111010122531.15569: *4* Won't do: print-bindings/commands/settings create nodes
Leo's print-settings, print-commands and print-bindings commands could create nodes.

There is no need for this.  Cut/paste from the log pane suffices.
.. @+node:ekr.20130806072439.21443: *4* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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.20180124135356.1: *3* Config
.. @+node:ekr.20081119132758.2: *4* Won't do: @ifgui in settings trees
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.
.. @+node:ekr.20150503061351.1: *4* Won't do: Enable plugins separately from loading plugins?
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.20111026075003.16481: *4* Won't do: 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.20180124135340.1: *3* Directives
.. @+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.20160318134258.1: *3* Docs
.. @+node:ekr.20150413163840.1: *4* Won't do: Migrate wiki to github
https://github.com/leo-editor/leo-editor/wiki
.. @+node:ekr.20111019104425.15887: *4* Won't do: Host the PyQt demo inside Leo
.. @+node:ekr.20180124135930.1: *3* Dom & File format
.. @+node:ekr.20130806072439.21349: *4* Won't do: @nosent puts 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.20110527084258.18378: *4* Won't do: Ashland: new file format
* Treat gnx's as strings: don't parse them.
  http://mail.google.com/mail/#inbox/12f3d4950fbabeea

- 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://leoeditor.com/leo_toc.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://leoeditor.com/leo_toc.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://leoeditor.com/leo_toc.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://leoeditor.com/leo_toc.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://leoeditor.com/leo_toc.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://leoeditor.com/leo_toc.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.20141017110114.18265: *4* Won't do: Ashland: 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.20160319151013.1: *4* Won't do: 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.20141108064630.19: *4* Won't do: 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.20130806072439.21298: *4* Won't do: 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.20061002093442: *4* Won't do: Add opml support to open & save commands
opml is an xml format!
.. @+node:ekr.20180124140045.1: *3* Gui
.. @+node:ekr.20130806072439.21464: *4* Won't do: body editors in a grid
From: "Ville M. Vainio" <vivainio@gmail.com>

The old "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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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: *5* 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.20120516140545.9992: *4* 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: *4* Won't do: Make headline widgets scrollable
It doesn't seem easy.
.. @+node:ekr.20160318113605.1: *4* Won't do: 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.21380: *4* Won't do: Use QML
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.20130919120947.12506: *4* 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.20180131055225.1: ** zz Completed
.. @+node:ekr.20140730175636.17982: *3* Completed: Vim emulation
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
.. @-all
.. @@nosearch
.. @-leo
