On Sat, Nov 22, 2008 at 7:04 AM, Kent Tenney [EMAIL PROTECTED] wrote:
p = c.currentPosition()
d = g.scanDirectives(c,p=p) #Get access to derived file's path
file_path = g.os_path_join(d.get('path'),filename)
Where does the ``filename`` argument come from?
p.isX will tell you if p is some
On Tue, Nov 25, 2008 at 7:50 AM, Edward K. Ream [EMAIL PROTECTED] wrote:
On Sat, Nov 22, 2008 at 7:04 AM, Kent Tenney [EMAIL PROTECTED] wrote:
p = c.currentPosition()
d = g.scanDirectives(c,p=p) #Get access to derived file's path
file_path = g.os_path_join(d.get('path'),filename)
Where
On Mon, Nov 24, 2008 at 9:41 AM, Kent Tenney [EMAIL PROTECTED] wrote:
To get the file name, type p.a to get the following list:
Ah, it works for the node with the @file headline, not the descendants
as I was hoping, and it doesn't understand @path
Abe Lincoln's quote about sharpening the
On Tue, Nov 25, 2008 at 10:04 AM, Edward K. Ream [EMAIL PROTECTED] wrote:
On Mon, Nov 24, 2008 at 9:41 AM, Kent Tenney [EMAIL PROTECTED] wrote:
To get the file name, type p.a to get the following list:
Ah, it works for the node with the @file headline, not the descendants
as I was hoping,
... and it doesn't understand @path
Can you clarify? I use fileActions to launch derived files as
programs and it uses the @path declarations.
... it works for the node with the @file headline, not the descendants ...
I've created a nodeActions plugin that works like fileActions but
works
On Tue, Nov 25, 2008 at 3:44 PM, TL [EMAIL PROTECTED] wrote:
... and it doesn't understand @path
Can you clarify?
I've created confusion by replying to an old thread without
understanding the context properly.
When I get a chance to figure this out I'll start a new thread
if I still need
On Mon, Sep 15, 2008 at 10:28 AM, Ville M. Vainio [EMAIL PROTECTED] wrote:
On Mon, Sep 15, 2008 at 4:54 PM, Edward K. Ream [EMAIL PROTECTED] wrote:
I'm not inclined to do that. It's too specialized. You would bind a
key to read-at-shadow-nodes.
The point is that this kind of specialized
On Mon, Sep 15, 2008 at 8:54 AM, Edward K. Ream [EMAIL PROTECTED] wrote:
On Sun, Sep 14, 2008 at 7:40 AM, Kent Tenney [EMAIL PROTECTED] wrote:
I would really like the option for this behaviour:
- Vim plugin active
- click on a node in a @shadow tree
- the FILE opens in Vim, not the node
I use the FileActions plugin to specify that the following code be
executed when a @shadow file node is double clicked. The code
performs the same function that the OpenWith plugin does but it grabs
the derived file instead of the node's contents. This solves part of
your workflow.
Here's how
On Mon, Sep 15, 2008 at 4:54 PM, Edward K. Ream [EMAIL PROTECTED] wrote:
I'm not inclined to do that. It's too specialized. You would bind a
key to read-at-shadow-nodes.
The point is that this kind of specialized feature can easily be done
with @button or @command nodes. I would prefer
On Mon, Sep 15, 2008 at 10:28 AM, Ville M. Vainio [EMAIL PROTECTED] wrote:
On Mon, Sep 15, 2008 at 4:54 PM, Edward K. Ream [EMAIL PROTECTED] wrote:
I'm not inclined to do that. It's too specialized. You would bind a
key to read-at-shadow-nodes.
The point is that this kind of specialized
I would really like the option for this behaviour:
- Vim plugin active
- click on a node in a @shadow tree
- the FILE opens in Vim, not the node
- when leaving Vim after changes, Leo re-chunks (@auto import) the edited file
This would take care of the newline between nodes issue for me, when
12 matches
Mail list logo
