On Tue, Apr 28, 2015 at 8:47 AM, 'Terry Brown' via leo-editor
leo-editor@googlegroups.com wrote:
I've posted examples here:
https://github.com/leo-editor/snippets/blob/master/examples/demo_widget.py
Thanks for this.
Leo's home page now has a link to the snippets page in the left sidebar.
Will do.
On Wednesday, April 29, 2015 at 7:41:24 AM UTC-4, Edward K. Ream wrote:
On Wed, Apr 29, 2015 at 5:57 AM, john lunzer lun...@gmail.com
javascript: wrote:
I looked into this and I found a place in the code that may explain why
Suboutline only does not work as I expect.
Thanks
On Wed, Apr 29, 2015 at 5:57 AM, john lunzer lun...@gmail.com wrote:
I looked into this and I found a place in the code that may explain why
Suboutline only does not work as I expect.
Thanks for this. Good work. I'll investigate soon. Please file an
official bug report if it doesn't
I looked into this and I found a place in the code that may explain why
Suboutline only does not work as I expect. This function in the node
find.initBatchCommands (sets in_headline):
def initBatchCommands (self):
'''Init for find-all and replace-all commands.'''
c = self.c
On Mon, Apr 27, 2015 at 9:40 AM, 'Terry Brown' via leo-editor
leo-editor@googlegroups.com wrote:
i.e. delimiters of `.*=` and `@` which do not play well at all with
Leo. `@` is problematic syntax coloring wise.
Of course I want to use @clean for this, @asis works, but doesn't
support
It's extremely rudimentary at the moment. I wanted to be sure a proof of
concept would work. It doesn't have the bug because right because the
console doesn't have the ability to receive and execute code from a node.
It's just an IPython console that runs in a Leo pane, with zero connection
Issue #165 https://github.com/leo-editor/leo-editor/issues/165requests
the vim-open-*file* command.
This post suggests an easy way to do vim-open-file and asks for your
comments.
*Executive summary*
The vim-open-file command should open the actual external file in vim, not
a temp file.
Sounds right.
If a file being edited in Vim is changed by not-vim, vim detects
the change and offers a dialog asking whether or not to reflect the
new version. Maybe Leo could do the same.
Maintaining cursor location in the Leo - Vim direction looked very
doable, visa versa, not so much.
Thanks for this Terry, it should be helpful to a lot of newcomers.
On Tuesday, April 28, 2015 at 9:47:59 AM UTC-4, Terry Brown wrote:
On Tue, 28 Apr 2015 03:56:14 -0700 (PDT)
john lunzer lun...@gmail.com javascript: wrote:
I'm trying to slosh through bookmarks.py and hack it up to give me
Well done.
1/2 hour, shows when and how to use some scarier git commands
https://www.youtube.com/watch?v=4EOZvow1mk4
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
3 versions exist, Leo buffer, vim buffer and disk version...
Yep. So you are correct that simultaneous changes to both the vim buffer
and leo buffer will conflict but whichever app next saves its buffer, the
other app will notify the user and ask whether to refresh or not. That
works for me
Was there a recent change in how abbreviations handle the insertion point?
Up until yesterday, my abbreviations worked as expected and allowed for me
to start typing over the block (|text|). Today, the insertion point goes
to the end of the abbreviation. Is that intentional or an artifact of
On Wed, Apr 29, 2015 at 12:30 PM, Largo84 larg...@gmail.com wrote:
Was there a recent change in how abbreviations handle the insertion point?
Up until yesterday, my abbreviations worked as expected and allowed for me
to start typing over the block (|text|). Today, the insertion point goes
to
On Wed, Apr 29, 2015 at 7:32 AM, Kent Tenney kten...@gmail.com wrote:
Sounds right.
If a file being edited in Vim is changed by not-vim, vim detects
the change and offers a dialog asking whether or not to reflect the
new version. Maybe Leo could do the same.
Yes. That's what the
On Wed, 29 Apr 2015 06:38:43 -0500
Edward K. Ream edream...@gmail.com wrote:
On Mon, Apr 27, 2015 at 9:40 AM, 'Terry Brown' via leo-editor
leo-editor@googlegroups.com wrote:
i.e. delimiters of `.*=` and `@` which do not play well at all
with
Leo. `@` is problematic syntax coloring
On April 29, 2015 7:20:09 PM CDT, Edward K. Ream edream...@gmail.com wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Largo84 larg...@gmail.com wrote:
Was there a recent change in how abbreviations handle the insertion
point?
Up until yesterday, my abbreviations worked as expected and allowed
for me
If vim-open-file uses the actual instead of a temp:
3 versions exist, Leo buffer, vim buffer and disk version.
either vim or Leo has focus at any time, each alters the disk version upon save.
- the buffer versions can't be compared
- when vim acquires focus it compares it's buffer to disk,
vim-open-node is fine as is, only enhancement I can think of
would be cursor position syncing, not a big deal.
Yep. So you are correct that simultaneous changes to both the vim buffer and
leo buffer will conflict
In practice, I wouldn't anticipate problems:
- if I am changing a file in leo
A few weeks ago I believe that open-with worked as described above. It
opened the file of the highlighted @file/@clean file. Separately, an
@file/@clean that is modified outside of Leo does trigger Leo to ask
whether the file should be updated or not.
What has changed with some revision is
19 matches
Mail list logo
