Ctrl-o now can handle non .leo files
Edward K. Ream
Selecting a non-.leo file will load that file into a new node in the
present outline. For known languages and file extensions, the
inserted text starts with an @language directive is inserted for known
languages. Otherwise, the text starts with @killcolor.
This plugs maybe the biggest hole in Leo's history. It should have
been done ages ago, and in fact could have been done any time in the
last seven years.
At present, @killcolor doesn't short-circuit Leo's syntax coloring, so
placing a large file in a node can create performance problems. I
hope to solve those problems today.
Edward
Kent Tenney
>
> As of rev 1546 of Leo's trunk, ctrl-o shows all files by default.
> Selecting a non-.leo file will load that file into a new node in the
> present outline.
Configurable?
What about:
- create a node
- headline text = @auto project/myfile.py
- execute ctrl-0
- Leo does read-at-auto (correct equivalent)
Kent Tenney
> Selecting a non-.leo file will load that file into a new node in the
> present outline.
The file contents are placed into a regular node,
no connection to the external file. The headline is
the bare file name, no path.
Variations that come to mind:
- maintain path in headline text, probably relative, possibly absolute
- this would ease manual conversion to @<filetype>
- treat the selected file as a @<filetype> automatically
Terry Brown
approach, here's the about plugin text for the active_path.py plugin.
Tk only at the moment, until leo-qt handles clicks on the tree.
Synchronize @path nodes with folders.
If a node is named '@path path_to_folder', the content (file and folder
names) of the folder and the children of that node will synchronized
whenever the node's status-iconbox is double clicked.
For files not previously seen in a folder a new node will appear on top
of the children list (with a mark).
Folders appear in the list as /foldername/. If you double click on the
icon-box of the folder node, it will have children added to it based on
the contents of the folder on disk. These folders have the '@path'
directive as the first line of their body text.
When files are deleted from the folder and the list is updated by
double clicking the files will appear in the list as filename
(or /foldername/).
You can describe files and directories in the body of the nodes.
You can organize files and directories with organizer nodes, an
organizer node name cannot contain with '/'.
Files and folders can be created by entering a node with the required
name as its headline (must start and/or end with "/" for a folder) and
then double clicking on the node's status-iconbox.
@auto nodes can be set up for existing files by double
clicking on the node's status-iconbox. If you prefer @shadow or
something else use the "active_path_attype" setting, without the "@".
There are commands on the Plugins active_path submenu:
show path - show the current path
set absolute path - changes a node "/dirname/" to
"@path /absolute/path/to/dirname". purge vanished (recursive) - remove
entries update recursive - recursive load of directories, use with
caution on large file systems If you want to use an input other than
double clicking a node's status-iconbox set active_path_event to a
value like 'iconrclick1' or 'iconclick1'.
active_path is a rewrite of the at_directory plugin to use @path
directives (which influence @auto and other @file type directives), and
to handle sub-folders more automatically.
Ville M. Vainio
> Kent and others who might be looking for a file system integration
> approach, here's the about plugin text for the active_path.py plugin.
> Tk only at the moment, until leo-qt handles clicks on the tree.
Here's a related idea familiar from ILeo:
How about a "act-on-node" command?
This would be similar to alt-I (push-to-ipython), in that it would
invoke whatever operation is associated with the node. Currently, many
plugins hook to low-level stuff like "double click on tree icon" or
whatever, which is sort of annoying if you mostly use keyboard.
I'm emphatically not referring to the fact that plugins can create
commands that can be hooked on any key you want - I'm thinking of one
key to remember that did the "logical" thing depending on the node
that is activated. Possibly a plugin could also open its own special
menu from that.
@url nodes would be opened, active_paths would be expanded, @graphs
would be launched, insert-plugin-specific-stuff here.
One way to implement this is to use the same approach as ipython does
with TryNext exception - all the registered hooks are run, the hook
function takes a look at the node, and either handles it or raises
TryNext exception (which propagates the call to next hook).
Basic framework for this could be snatched directly from
IPython/hooks.py (CommandChainDispatcher, which is a command chain
dispatcher (duh) that runs the hooks in priority order).
--
Ville M. Vainio
http://tinyurl.com/vainio
Edward K. Ream
> Variations that come to mind:
>
> - maintain path in headline text, probably relative, possibly absolute
> - this would ease manual conversion to @<filetype>
putting. YMMV.
> - treat the selected file as a @<filetype> automatically
quibble.
The actual code is very simple. See createNodeFromExternalFile. Feel
free to improve this as you see fit.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > - maintain path in headline text, probably relative, possibly
> > absolute
> > - this would ease manual conversion to @<filetype>
>
> The first version of the code did that. I found the long path off-
> putting. YMMV.
active_path.py hides paths (which I agree are distracting) by taking
advantage of the possibility of putting @path on the first line of the
body, but this assumes the outline's following the filesystem structure.
Cheers -Terry
Kent Tenney
>
> Kent and others who might be looking for a file system integration
> approach, here's the about plugin text for the active_path.py plugin.
> Tk only at the moment, until leo-qt handles clicks on the tree.
am not inclined to switch back for testing.
Does this issue have a bug filed?
I don't know enough about *handling clicks on the tree* to file one.
active_path sounds really cool.
Thanks,
Kent
Terry Brown
Kent Tenney <kte...@gmail.com> wrote:
>
> On Fri, Feb 13, 2009 at 10:35 AM, Terry Brown
> <terry_...@yahoo.com> wrote:
> >
> > Kent and others who might be looking for a file system integration
> > approach, here's the about plugin text for the active_path.py
> > plugin. Tk only at the moment, until leo-qt handles clicks on the
> > tree.
>
> This is a showstopper for me at the moment, I'm spoiled by qt and
> am not inclined to switch back for testing.
> Does this issue have a bug filed?
so I guess I'll check the todo list first.
Cheers -Terry
Kent Tenney
>
> On Fri, 13 Feb 2009 13:57:57 +1800
> Kent Tenney <kte...@gmail.com> wrote:
>
>>
>> On Fri, Feb 13, 2009 at 10:35 AM, Terry Brown
>> <terry_...@yahoo.com> wrote:
>> >
>> > Kent and others who might be looking for a file system integration
>> > approach, here's the about plugin text for the active_path.py
>> > plugin. Tk only at the moment, until leo-qt handles clicks on the
>> > tree.
>>
>> This is a showstopper for me at the moment, I'm spoiled by qt and
>> am not inclined to switch back for testing.
>
> I agree, qt's too pretty :-)
BTW, can that be configured/made persistent?
Kent Tenney
>
> On Feb 12, 10:07 am, Kent Tenney <kten...@gmail.com> wrote:
>
>> Variations that come to mind:
>>
>> - maintain path in headline text, probably relative, possibly absolute
>> - this would ease manual conversion to @<filetype>
>
> The first version of the code did that. I found the long path off-
> putting. YMMV.
>
>> - treat the selected file as a @<filetype> automatically
>
> Not a good idea if the file contains sentinels, but perhaps this is a
> quibble.
ctrl-o means 'open a file'
Leo doesn't open the file, it 'reads' it.
to 'open' is to connect to a file on the file system, to
'read' is to access the content of a file, very different operations.
I think ctrl-o should be changed to ctrl-r and the dialog named
'Read' instead of 'Open'
I think crtl-o should create an @auto node,
ie: 'I opened the file, I want to edit it and save my work to the file I opened'
Thanks,
Kent
Edward K. Ream
I think this behaviour will surprise users.
Yes, We have already seen that it is confusing.
ctrl-o means 'open a file' Leo doesn't open the file, it 'reads' it.
to 'open' is to connect to a file on the file system, to
'read' is to access the content of a file, very different operations.
I think ctrl-o should be changed to ctrl-r and the dialog named
'Read' instead of 'Open'
Your distinction between opening and reading is valid, but it has no chance of ending confusion for newbies.
I think crtl-o should create an @auto node,
An excellent idea. It is dead easy to do. I'll do it within 3 days :-)
If an @auto node isn't wanted, the user can just delete the @auto in the headline.
This would be a good time to add a "slurp" option that would apply to ctrl-O.
Edward
Kent Tenney
> On Sat, Feb 14, 2009 at 8:04 AM, Kent Tenney <kte...@gmail.com> wrote:
>>
>> I think this behaviour will surprise users.
>
> Yes, We have already seen that it is confusing.
>>
>> ctrl-o means 'open a file' Leo doesn't open the file, it 'reads' it.
>> to 'open' is to connect to a file on the file system, to
>> 'read' is to access the content of a file, very different operations.
>>
>> I think ctrl-o should be changed to ctrl-r and the dialog named
>> 'Read' instead of 'Open'
>
> Your distinction between opening and reading is valid, but it has no chance
> of ending confusion for newbies.
If by newbies we mean people with lots of editing experience, new to Leo,
I think they will expect 'open' to connect to a file, and placing the content of
a file into a node to be a distinct operation.
I say 'read' because in vim the command ':r(ead) <filename>' will
place the content
of <filename> into the current buffer at the cursor position.
and ':e(dit) <filename>' creates a new buffer associated with <filename>
maybe ctrl-o should list .leo files, ctrl-e select from all, create @auto nodes,
ctrl-r place file contents into current node.
Too vimcentric? What are the emacs equivalents?
I guess you're right, confusion is inevitable.
Edward K. Ream
I say 'read' because in vim the command ':r(ead) <filename>' will
place the content of <filename> into the current buffer at the cursor position.
and ':e(dit) <filename>' creates a new buffer associated with <filename>
maybe ctrl-o should list .leo files, ctrl-e select from all, create @auto nodes,
ctrl-r place file contents into current node.
Too vimcentric? What are the emacs equivalents?
Geeze, it's been a week, and this was supposed to be a 3-day bug :-)
Good questions. Imo, the actual names don't matter as much as the operations they name. The question is, what use case (or cases) do we want to support cleanly?
In other words, we need something akin to opening a file in Emacs or vim and optionally modifying and saving the file.
@auto is the obvious candidate to use. We "slurp" all the text into the node.
But, alas, that only works the first time. That is, @auto will, by default, *parse* the file, and there may be whitespace errors when that happens.
My second thought was @nosent, but that fails because it doesn't do a import/read.
Looking at the plugins, it looks like the at_folder and at_view plugins do roughly what is wanted. I'll investigate further, but in any case, it appears we need an entirely new kind of @<file> directive to handle this use case.
I'm not sure what to call it. Maybe @view (as in the plugin) . Maybe @open?? I don't think @slurp will fly :-) Any suggestions?
Edward
P.S. Whatever name is chosen, it should be relatively easy to implement. Even if it weren't easy, it would be worth doing to help newbies and others. This is a major hole that must be plugged immediately.
EKR
Edward K. Ream
On Feb 12, 11:38 am, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> How about a "act-on-node" command?
> This would be similar to alt-I (push-to-ipython), in that it would
> invoke whatever operation is associated with the node. Currently, many
> plugins hook to low-level stuff like "double click on tree icon" or
> whatever, which is sort of annoying if you mostly use keyboard.
them as the "node action" could open up even more possibilities.
Rather than using events (hooks), uA's might be simpler. Plugins or
scripts could create a uA called, say, designatedAction. Perhaps some
(all?) nodes could have default designated actions. The value of the
uA would be a script, and the act-on-node command would simply execute
that script.
I'm just thinking out loud. This is a promising new line of inquiry.
Edward
Edward
Kent Tenney
Kent Tenney
- capability to register a node with an external file, allowing
editing the file from Leo, adding no sentinels to the external file.
- offer the option of parsing the external file into nodes which
reflect the structure of the content
- offer the option of not parsing the external file, it's entire content
is in the body of the @auto <filename> node
What if a button named 'Parse' would toggle the file
between 'all in one node' and 'reflect the structure of the file'
>
> EKR
>
>
> >
>
Edward K. Ream
@edit ?
> I'm not sure what to call it. Maybe @view (as in the plugin) . Maybe
> @open?? I don't think @slurp will fly :-) Any suggestions?
I like it. Good suggestion.
Edward
Edward K. Ream
To review, we are discussing:
- capability to register a node with an external file, allowing
editing the file from Leo, adding no sentinels to the external file.
Yes. File:Open will create @edit nodes.
- offer the option of parsing the external file into nodes which
reflect the structure of the content
I think the user can get this simply by changing @edit to @auto and saving. The first write will just write the entire node, so there is no possibility of changing the file. The next time the @auto node is read, Leo will do the import as usual. In particular, whitespace or other import problems may result, as usual, in an @ignore directive being inserted.
- offer the option of not parsing the external file, it's entire content
is in the body of the @auto <filename> node
That's what @edit does.
What if a button named 'Parse' would toggle the file
between 'all in one node' and 'reflect the structure of the file'
Hmm. In effect, the button would simply change @edit to @auto. This would work, I suppose, provided @edit nodes are *written* using the @auto algorithm. Whether writing @edit or @auto, an @others directive would be needed if the root node has any descendants.
But this is a minor feature. In essence, I think @edit as a synonym for @slurp gives us just about everything.
Edward