Re: OT
I loved this, thanks for the link Kent On Monday, August 4, 2014 3:39:03 PM UTC+2, Kent Tenney wrote: http://radar.oreilly.com/2014/08/programming-in-concert-mode.html live coding of music with narration, quite remarkable. Answers the question 'What's all this excitement around functional programming?' Is that Lighttable he's on? -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Terry, what's the recommended way to change border colors
On Mon, Aug 4, 2014 at 9:53 PM, 'Terry Brown' via leo-editor
leo-editor@googlegroups.com wrote:
On Mon, 4 Aug 2014 17:56:34 -0500
Edward K. Ream edream...@gmail.com wrote:
By analogy, I tried the following, with no joy, but the background is
pink.
QTextEdit#richTextEdit [vim_state ~= vim_normal] {
border: solid 3px red;
}
QTextEdit#richTextEdit [vim_state ~= vim_insert] {
border: solid 3px blue;
}
QTextEdit#richTextEdit [vim_state ~= vim_visual] {
border: solid 3px yellow;
}
I'd try it without the spaces before the '['.
Cheers -Terry
--
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
--
Edward K. Ream: edream...@gmail.com Leo: http://leoeditor.com/
Speak the truth, but not to punish--Thich Nhat Hanh
--
--
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Re: Terry, what's the recommended way to change border colors
On Tue, Aug 5, 2014 at 5:43 AM, Edward K. Ream edream...@gmail.com wrote:
For now vc.set_border will jam the border style by hand using
w.setStyleSheet(s).
Success at last. The syntax for the border property is picky. It must be::
{ border: 5px solid red; }
**not**:
{ border: solid 5px red; }
To summarize, Terry's original suggestion works::
selector = 'vim_%s' % (vc.state)
w.setProperty('vim_state',selector)
w.style().unpolish(w)
w.style().polish(w)
*provided* the stylesheets are correct. Here are mine::
QTextEdit#richTextEdit[vim_state~=vim_normal] {
border: 5px solid red;
}
QTextEdit#richTextEdit[vim_state~=vim_insert] {
border: 5px solid blue;
}
QTextEdit#richTextEdit[vim_state~=vim_visual] {
border: 5px solid green;
}
Edward
--
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Re: A quick-and-dirty tag API can now be had with the nodetags.py plugin
On 8/4/2014 11:39 PM, 'Terry Brown' via leo-editor wrote: On Mon, 04 Aug 2014 13:59:38 -0400 Jacob Peck gatesph...@gmail.com wrote: I just added a minimal tag browser UI. Very cool. And of course you can move it out of the tabs window with the free-layout options on the pane divider context menus. Very minor - if, for some odd reason, you have two nodes with the same name but different tag sets, it lists both of them, but doesn't show the different tag sets when you click on the different nodes. Hmm. That's a good point. I'm using positions instead of vnodes... I should fix that. Thanks! --Jake Cheers -Terry -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Vim emulation: ready for testing!
Hi Edward, I've tested a bit vim-mode on Kubuntu 12.04, Python 2.7.3, PyQt 4.8.1, Leo 063ef7af39f The body pane seems ok, but I don't know how to work on outlines. Changing to outline pane and using arrow keys jumps back to the body pane. (Ex: Alt + t, Left arrow) I missed something? Thanks On Tuesday, August 5, 2014 6:14:19 AM UTC+3, Edward K. Ream wrote: On Mon, Aug 4, 2014 at 10:04 PM, Edward K. Ream edre...@gmail.com javascript: wrote: P.P.S. At present, vim mode's colon command is exactly equivalent to Alt-X: it does *not* put a colon in the minibuffer. Fixed at rev 55f2004...Here is the checkin log: QQQ The vim colon command now enters a colon into the minibuffer. It's not protected, meaning that you can backspace over it. QQQ EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Terry, what's the recommended way to change border colors
On Tue, 5 Aug 2014 06:16:47 -0500
Edward K. Ream edream...@gmail.com wrote:
{ border: 5px solid red; }
**not**:
{ border: solid 5px red; }
Sorry about that, CSS, or at least most browsers, are less picky than
Qt. Nice to know the right way works though, makes it easier for users
to style to match their themes etc.
Cheers -Terry
--
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Re: OT
On Tue, Aug 5, 2014 at 8:29 AM, Kent Tenney kten...@gmail.com wrote: It's got to be one of the Lisps. One hears the Lispers going on (and on) about power and efficiency, this is the best demonstration of it I've seen. Seems analogous to learning to fly a plane, lots goes into the learning curve compared to driving, but then you can go _really fast_. Meh. You make a library, and then you can go really fast. If the library were in Python, you could actually understand it. All he's doing is changing code on the fly. It's possible in Python. EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: A quick-and-dirty tag API can now be had with the nodetags.py plugin
On 8/4/2014 11:39 PM, 'Terry Brown' via leo-editor wrote: Very minor - if, for some odd reason, you have two nodes with the same name but different tag sets, it lists both of them, but doesn't show the different tag sets when you click on the different nodes. This was a bigger bug than I expected! I was using the harebrained scheme of just headlines as keys to map list items to positions... so identical headlines always pointed to whichever node was added to the list last. Fixed in the most recent commit, though, along with a bunch of other edge cases that could have arisen. Also switched the internals of some of the API around (but the interfaces and signatures remain the same) to use vnodes instead of positions to prevent duplicated work in some cases with clones. Nice catch! Thanks again! --Jake -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: OT
The article links to this: https://github.com/digego/extempore Looks like it's a custom flavor of Scheme, which is a dialect of Lisp. --Jake On 8/5/2014 9:29 AM, Kent Tenney wrote: It's got to be one of the Lisps. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: A quick-and-dirty tag API can now be had with the nodetags.py plugin
There isn't an easy way for non-programmers at the moment... that's coming soon though! I suppose the easiest way for now would be to type the following into the node you wish to tag: c.theTagController.add_tag(p,'your tag here') Then highlight that line and hit Ctrl+B. You can then remove that line from your node. If you'd like to remove a tag, use this line instead: c.theTagController.remove_tag(p,'your tag here') I'll be adding UI elements to make this easier though. I promise! --Jake On 8/5/2014 9:45 AM, Chris George wrote: Disclaimer: IANAP What is the easiest way for me to add and remove tags? Chris On Tuesday, August 5, 2014 6:43:05 AM UTC-7, Jacob Peck wrote: On 8/4/2014 11:39 PM, 'Terry Brown' via leo-editor wrote: Very minor - if, for some odd reason, you have two nodes with the same name but different tag sets, it lists both of them, but doesn't show the different tag sets when you click on the different nodes. This was a bigger bug than I expected! I was using the harebrained scheme of just headlines as keys to map list items to positions... so identical headlines always pointed to whichever node was added to the list last. Fixed in the most recent commit, though, along with a bunch of other edge cases that could have arisen. Also switched the internals of some of the API around (but the interfaces and signatures remain the same) to use vnodes instead of positions to prevent duplicated work in some cases with clones. Nice catch! Thanks again! --Jake -- 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 leo-editor+unsubscr...@googlegroups.com mailto:leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com mailto:leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Vim emulation: ready for testing!
in normal mode vim: dd = delete entire line, regardless of cursor position Leo: dd = delete from cursor to end of line = vim: D in both cases vim maintains the newline, dd in Leo deletes newline joining this line with next. On Tue, Aug 5, 2014 at 8:10 AM, Edward K. Ream edream...@gmail.com wrote: On Tue, Aug 5, 2014 at 7:51 AM, Zoltan Benedek benzol...@gmail.com wrote: Changing to outline pane and using arrow keys jumps back to the body pane. (Ex: Alt + t, Left arrow) I missed something? Nope. This is on the short list to be fixed before I start eating my own dog food. For now, the workaround is to hold down the Alt key when using the arrow keys so you stay in the outline. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: OT
On Tue, Aug 5, 2014 at 8:59 AM, Jacob Peck gatesph...@gmail.com wrote: The article links to this: https://github.com/digego/extempore Looks like it's a custom flavor of Scheme, which is a dialect of Lisp. extempore is indeed impressive. And suggestive. Could we imagine an 'execute-script-continuously' command in Leo that would do something similar ;-) Anyone want to try. I'm kinda busy just now :-) EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Vim emulation: ready for testing!
On Tue, Aug 5, 2014 at 9:43 AM, Kent Tenney kten...@gmail.com wrote: in normal mode vim: dd = delete entire line, regardless of cursor position Leo: dd = delete from cursor to end of line = vim: D in both cases vim maintains the newline, dd in Leo deletes newline joining this line with next. Thanks for this correction. I'll fix it soon. EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: OT
Edward, first step for that would indeed fix the Leo gui responsiveness bug we talked about: When a script is executing in any open Leo, all the open Leo windows shared from that GUI will be irresponsive, so a command could do nothing since it would make Leo irresponsive, and the user wouldnt be able to edit the realtime code. I think this has to do with threading, but know no more about that. An easy test is to make a script time.sleep(60) Until 1 min goes by, you wont be able to use Leo, not any of the open files there. That is, if you werent kidding about execute-script-continuously =) On Tue, Aug 5, 2014 at 4:47 PM, Edward K. Ream edream...@gmail.com wrote: On Tue, Aug 5, 2014 at 8:59 AM, Jacob Peck gatesph...@gmail.com wrote: The article links to this: https://github.com/digego/extempore Looks like it's a custom flavor of Scheme, which is a dialect of Lisp. extempore is indeed impressive. And suggestive. Could we imagine an 'execute-script-continuously' command in Leo that would do something similar ;-) Anyone want to try. I'm kinda busy just now :-) EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: OT
On Tue, Aug 5, 2014 at 9:59 AM, Fidel N fidelpe...@gmail.com wrote: When a script is executing in any open Leo, all the open Leo windows shared from that GUI will be irresponsive, so a command could do nothing since it would make Leo irresponsive, and the user wouldnt be able to edit the realtime code. That is, if you weren't kidding about execute-script-continuously =) I was neither kidding nor volunteering ;-) At present, Leo's execute-script commands uses Python's exec in Leo's thread. Not sure how to run Python in another thread: presumably it would be something like interfacing with IPython. Maybe IPython itself could be used... EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: OT
This is for further reference and some more information on how we could fix the hang up fix. I was recently 'fighting' against pyqt way of executing code (will stop everything when a new GUI opens to, for instance, ask the user for input) versus Kivy (code goes on running, the programmer defines what happens when the user closes such a dialogue). My conclusion after reading for a while, was that to avoid this behaviour the execution of the code within pyqt must be threaded, or the GUI will hang, as it happens now. So according to what I learned, this should just be fixed by the code calling exec through threading instead of directly, like this: from threading import Thread def threaded_function(arg): exec(script_we_got_from_a_node) thread = Thread(target = threaded_function, args = ()) thread.start() I got that code from here,in stackoverflow http://stackoverflow.com/questions/2905965/creating-threads-in-python. Disclaimer: Not sure this will work, but its the first thing I would try. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Threading thread
There are a lot of different issues with this threading discussion. 1) live code execution like LightBox and the lisp music demo - any useful live code execution mode would have to parse the code (ast trees?), execute it expression by expression, and display the results, probably in a specific environment. It would be an interesting experiment, but probably separate from how Leo executes scripts and whether Leo hangs when it is executing scripts. 2) Leo hanging on scripts that don't interact with Leo - there could be a new run-script command to execute scripts in the background, although it doesn't take too much to do it explicitly: from threading import Thread def do_something(): t = Thread(target=do_something) t.start() 3) Scripts that interact with Leo - these are probably better implemented using hooks / callbacks including onIdle. How threads can bite unexpectedly - a slow running script that changes the tree is going to be very hard to run in a separate thread, because as it continues to run it will keep invalidating positions in the main thread, making it impossible to do anything - not unexpected. But even a script that simply runs without touching Leo (c, g, the interface) until it's done and then does `c._slow_answer = foo` may cause trouble. When you assign to c._slow_answer you're updating c.__dict__. Another thread (the main thread) might be iterating c.__dict__ to find an attribute of c, or adding an attribute, and get interrupted by the sub-thread such that one of them ends up with an inconsistent view of c.__dict__. There are ways around this, but you have to write the code to anticipate the problems. queue.Queue is thread safe for example, you could do `c._slow_answer` = queue.Queue() *in the main thread*, your background thread can stick its answer there when its done, and Leo can check for new answers in c._slow_answer onIdle or on user demand. Queue does behind the scenes stuff to ensure that threads don't trip each other up working with the same data. Cheers -Terry -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Threading thread
Wow very insightful. So its actually safer for the user not to be touching the tree while a script runs, since if he changes a position (or does any other change) that can explode in many ways. Thanks for the great explanation Terry. On Tue, Aug 5, 2014 at 6:07 PM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: There are a lot of different issues with this threading discussion. 1) live code execution like LightBox and the lisp music demo - any useful live code execution mode would have to parse the code (ast trees?), execute it expression by expression, and display the results, probably in a specific environment. It would be an interesting experiment, but probably separate from how Leo executes scripts and whether Leo hangs when it is executing scripts. 2) Leo hanging on scripts that don't interact with Leo - there could be a new run-script command to execute scripts in the background, although it doesn't take too much to do it explicitly: from threading import Thread def do_something(): t = Thread(target=do_something) t.start() 3) Scripts that interact with Leo - these are probably better implemented using hooks / callbacks including onIdle. How threads can bite unexpectedly - a slow running script that changes the tree is going to be very hard to run in a separate thread, because as it continues to run it will keep invalidating positions in the main thread, making it impossible to do anything - not unexpected. But even a script that simply runs without touching Leo (c, g, the interface) until it's done and then does `c._slow_answer = foo` may cause trouble. When you assign to c._slow_answer you're updating c.__dict__. Another thread (the main thread) might be iterating c.__dict__ to find an attribute of c, or adding an attribute, and get interrupted by the sub-thread such that one of them ends up with an inconsistent view of c.__dict__. There are ways around this, but you have to write the code to anticipate the problems. queue.Queue is thread safe for example, you could do `c._slow_answer` = queue.Queue() *in the main thread*, your background thread can stick its answer there when its done, and Leo can check for new answers in c._slow_answer onIdle or on user demand. Queue does behind the scenes stuff to ensure that threads don't trip each other up working with the same data. Cheers -Terry -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Vim emulation: ready for testing!
On Tuesday, August 5, 2014 9:49:13 AM UTC-5, Edward K. Ream wrote: On Tue, Aug 5, 2014 at 9:43 AM, Kent Tenney kten...@gmail.com wrote: in normal mode vim: dd = delete entire line, regardless of cursor position Leo: dd = delete from cursor to end of line = vim: D in both cases vim maintains the newline, dd in Leo deletes newline joining this line with next. dd and 5dd now work in vim mode now work exactly as they do in vim itself, include special cases at the end of the buffer. EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Threading thread
On Tue, 5 Aug 2014 11:07:36 -0500 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: 1) live code execution like LightBox and the lisp music demo - any useful live code execution mode would have to parse the code (ast trees?), execute it expression by expression, and display the results, probably in a specific environment. It would be an interesting experiment Interesting and not that complex after all: https://github.com/leo-editor/snippets/blob/master/live_code.py (python 2.7 only) Cheers -Terry -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
key logging
Hi: Im working in a way to make Leo do auto-suggestions depending on your recent actions, and for that im needing some short of key-logging. I got some questions about it: Is there a way to check the recent keys written in Leo? After a long search I found where the recent commands are stored: c.k.mb_history Is there a way to get a similar history for the new vim mode? Is there something similar for recent keypress? Thanks! -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: key logging
On 8/5/2014 2:05 PM, Fidel N wrote: Is there a way to check the recent keys written in Leo? alt-X 'view-lossage' prints this data out to the log. It looks like you can access this data with g.app.lossage... g.es(list(reversed(g.app.lossage))) Looks like they're tuples, where [0] is a char, and [1] is a KeyStroke object, which seems to be documented here: leoPy.leo#Notes:1--@file%20../doc/leoNotes.txt:0--Notes:0--About%20Key%20handling:3--About%20the%20KeyStroke%20class:2 Hope this helps! --Jake -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Vim emulation: ready for testing!
On Tuesday, August 5, 2014 7:51:15 AM UTC-5, Zoltan Benedek wrote: Changing to outline pane and using arrow keys jumps back to the body pane. (Ex: Alt + t, Left arrow) This was fixed by delegating all non-Alt keys back to Leo's traditional key handling. It works great. With this change vim-mode is just about ready for prime time. I'll be adding the most-requested features in the coming days. I am using it now myself for daily work. Most rough edges are pretty much gone. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: key logging
Awesome! Spent a couple of hours searching and only found the command history. This perfectly solves my needs, big thanks!! Edit: Just checked, doesn't work with the new vim mode, but Im guessing its just too early for that hehe. -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Vim emulation: ready for testing!
On Tue, Aug 5, 2014 at 3:44 PM, Kent Tenney kten...@gmail.com wrote: in normal mode dw: delete word, word is the only text object I use, there are many http://blog.carbonfive.com/2011/10/17/vim-text-objects-the-definitive-guide/ (just discovered diw, useful!) v, V, ctrl-v : visual select character, line, column O open line above current, start insert mode y yank (copy) p paste after P paste before ^ goto line start $ goto line end Excellent . These should be dead easy to add. The framework is already in place. Besides these kinds of commands, which are pretty much fill-in-the-blanks projects, there are two other important projects: 1. The dot doesn't work for insert modes, presumably for a fairly trivial reason. 2. Handling find commands. I just now saw the way forward. There are just a few considerations we have to satisfy: A. Little or no reliance on control keys. B. The commands must be repeatable/composable with the dot. C. The commands must be repeatable with * and #, etc. All should be easy to do using Leo's *existing* find machinery. Here's how: A. (Most important): train Leo user's to use Leo's minibuffer find :-) - Invoke the find: Ctrl-F in non-vim mode, something else in vim mode. B. Just before executing the search, Leo's core find code will call a vc method to remember/compose the equivalent dot command C. Do the find as always, using all of Leo's existing machinery. - Invoke * or # from vim normal mode to repeat searches. D. Use Leo's existing find commands when replaying the dot. This should satisfy points 1 and 2 above, which gives us the power of vim's search commands without having to redo any real find code. Unless I am greatly mistaken, it's a day or two's work. At that point, we should have most of vim's key features. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
