Re: Vim emulation: ready for testing!

[Steve Zatz]

Thanks.  That's helpful.  While the versions aren't identical, they're
probably close enough.  Another random possibility - I start Leo from the
command line -- can't imagine how that could matter but I'm definitely
grasping at straws ...


On Thu, Aug 14, 2014 at 9:25 PM, gatesphere  wrote:

>  As a data point, '@settings -> @bool vim-mode = True' enables Vim-mode
> with proper : handling for me, and I'm running on:
>
> Leo 4.11 final, build 4f355e273b8d (branch: master), 2014-08-14 21:21:05
>
> Python 2.7.3, PyQt version 4.8.4
>
> Windows 7 AMD64 (build 6.1.7601) SP1
>
>
>  I didn't run with an empty config, though.
> -->Jake
>
>
> On 8/14/2014 8:10 PM, Steve Zatz wrote:
>
> I followed the directions although I wasn't sure what ekr.leo was so I
> just created a new test.leo and inserted the vim = true @ setting in that
> new file and then reloaded that file.  As before vim navigation and key
> sequences like dd work fine.  The print-settings result (see below)  looks
> just like your key bindings but alas no dice with regard to typing a colon.
>
>  Another thought is whether the version of python, PyQt or Windows could
> be a factor.  I am running on the following:
>
>  Python 2.7.2, PyQt version 4.8.5
> Windows 7 AMD64 (build 6.1.7601) SP1
>
>  If I am the only one experiencing this problem (and apparently I am), I
> definitely think you should move on to other issues. I really appreciate
> the time you've spent on it.   I'll try some other machines/OS's and let
> you know if I discover anything.  Thanks again for trying to figure this
> out.
>
>  Steve
>
>  Results of print-settings
>
>  [D] allowclonedrags = True
> [D] bodypanewraps = True
> [D] bodytextfontfamily = Courier
> [D] bodytextfontsize = 9
> [D] bodytextfontslant = roman
> [D] bodytextfontweight = normal
> [D] colordirectivesinplaintext = True
> [D] enabledragmessages = True
> [D] headlinetextfontfamily = None
> [D] headlinetextfontsize = 8
> [D] headlinetextfontslant = roman
> [D] headlinetextfontweight = normal
> [D] ignoreblanklines = True
> [D] initialhorizontalratio = 0.3
> [D] initialhorizontalsecondaryratio = 0.5
> [D] initialsplitorientation = vertical
> [D] initialverticalratio = 0.5
> [D] initialverticalsecondaryratio = 0.7
> [D] initialwindowheight = 600
> [D] initialwindowleft = 10
> [D] initialwindowtop = 10
> [D] initialwindowwidth = 800
> [D] limitcount = 9
> [D] logtextfontfamily = None
> [D] logtextfontsize = 8
> [D] logtextfontslant = roman
> [D] logtextfontweight = normal
> [D] outputdocchunks = True
> [D] pagewidth = 132
> [D] printmismatchinglines = True
> [D] printtrailinglines = True
> [D] searchbody = True
> [D] splitbarcolor = LightSteelBlue2
> [D] splitbarrelief = groove
> [D] splitbarwidth = 7
> [D] tabwidth = -4
> [D] tangleoutputsheader = True
> [D] targetlanguage = python
> [D] underlineundefinedsectionnames = True
> [F] vimmode = True
> [D] wholeword = True
>
> legend:
> leoSettings.leo
> [D] default settings
> [F] loaded .leo File
> [M] myLeoSettings.leo
>
>
>  On Thu, Aug 14, 2014 at 4:37 PM, Edward K. Ream 
> wrote:
>
>> On Thu, Aug 14, 2014 at 2:56 PM, Edward K. Ream 
>> wrote:
>> > On Thu, Aug 14, 2014 at 11:41 AM, Steve Zatz  wrote:
>>
>> >> As below the following files are being read but the only file with any
>> >> settings is myLeoSettings.leo  and it consists of one @settings with @
>> bool
>> >> vim-mode = True
>> >
>> > Thanks for your persistence.  I'll try a similar setup and see what
>> happens...
>>
>>  I disabled leoSettings.leo and myLeoSettings.leo by changing their names.
>>
>> When I tried to load ekr.leo, Leo crashed trying to load an enchant
>> dict.  After correcting that (upped using git) ekr.leo loaded.  I then
>> did the following:
>>
>> 1. disabled the normal @settings node by renaming it.
>>
>> 2. I created another @settings node containing just @bool vim-mode = True.
>>
>> 3. I restarted Leo and loaded ekr.leo.
>>
>> As you say, Leo looks like a dos app :-)
>>
>> 4. I then clicked in the minibuffer area (no key bindings!) and
>> executed the print-settings command by typing "print-settings"
>>
>> I selected the text with the mouse, then clicked the minibuffer area
>> again and did copy-text.  I then pasted the text here.  Here is what I
>> got::
>>
>> [D] allowclonedrags = True
>> [D] bodypanewraps = True
>> [D] bodytextfontfamily = Courier
>> [D] bodytextfontsize = 9
>> [D] bodytextfontslant = roman
>> [D] bodytextfontweight = normal
>> [D] colordirectivesinplaintext = True
>> [D] enabledragmessages = True
>> [D] headlinetextfontfamily = None
>> [D] headlinetextfontsize = 8
>> [D] headlinetextfontslant = roman
>> [D] headlinetextfontweight = normal
>> [D] ignoreblanklines = True
>> [D] initialhorizontalratio = 0.3
>> [D] initialhorizontalsecondaryratio = 0.5
>> [D] initialsplitorientation = vertical
>> [D] initialverticalratio = 0.5
>> [D] initialverticalsecondaryratio = 0.7
>> [D] initialwindowheight = 600
>> [D] initialwindowleft = 10
>> [D] initialwindowtop = 10
>> [D] ini

Re: vim bindings reports

[gatesphere]

I just noticed this:

In real vim, when you're in colon-mode, escape cancels out of the 
minibuffer.  Leo's vim mode does the same thing, except on the commands 
which use the file completion.  Escape there literally appends the 
string 'Escape' to the entry in the file completion process.


-->Jake

On 8/14/2014 11:55 AM, Kent Tenney wrote:

OK, I'll hold my horses, waiting for updates on this thread.

On Thu, Aug 14, 2014 at 10:50 AM, Edward K. Ream  wrote:

On Thu, Aug 14, 2014 at 9:02 AM, Kent Tenney  wrote:

Starting a new thread


in vim :r pastes a copy of the current file at the cursor

I didn't know that.  It will be easy to do once the solution referred
to in this morning's post is in place.  See the P.P.S in that post.

Maybe some confusion: requiring the  is a big problem,
requires learning the 3rd set of bindings.

Kent, I do understand.  Really.

In the real vim, nothing happens if you type :r.  You must either type
:r or :r 

The "solution" I am working on is to allow exactly this operation.  At
present, you must indeed type::

 :r

or::

 :r

but that initial extra  is to go away asap.


status report:

- 'V' should provide line mode visual, it inserts a 'V' at cursor
- 'v' starts visual character mode, 'y' should end visual mode and yank, 'y'
  is ignored until another 'v'
- aliasing  to 'i' is confusing, in vim it advances cursor to next line
- 'x' is backspace in Leo, delete in vim

- '/' and '?' look good, with 'n' going to next find

Thanks.  I'll look into these.


wish list:

- :s /text/replace with this/

All substitutions require the "solution" we are talking about.  It
will happen asap.

Once that is in place, a  vim-mode parser can deal with the entire
command line at once.  This is inherently a simpler problem than
dealing with characters one at a time, but it will require new code.

In short, I am aware of the parsing problems and I appreciate the
status/bug report.  I expect to have everything finished in about a
week.

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: Vim emulation: ready for testing!

[gatesphere]

As a data point, '@settings -> @bool vim-mode = True' enables Vim-mode 
with proper : handling for me, and I'm running on:


Leo 4.11 final, build 4f355e273b8d (branch: master), 2014-08-14 21:21:05

Python 2.7.3, PyQt version 4.8.4
Windows 7 AMD64 (build 6.1.7601) SP1


I didn't run with an empty config, though.
-->Jake



On 8/14/2014 8:10 PM, Steve Zatz wrote:
I followed the directions although I wasn't sure what ekr.leo was so I 
just created a new test.leo and inserted the vim = true @ setting in 
that new file and then reloaded that file.  As before vim navigation 
and key sequences like dd work fine.  The print-settings result (see 
below)  looks just like your key bindings but alas no dice with regard 
to typing a colon.


Another thought is whether the version of python, PyQt or Windows 
could be a factor.  I am running on the following:


Python 2.7.2, PyQt version 4.8.5
Windows 7 AMD64 (build 6.1.7601) SP1

If I am the only one experiencing this problem (and apparently I am), 
I definitely think you should move on to other issues. I really 
appreciate the time you've spent on it.   I'll try some other 
machines/OS's and let you know if I discover anything.  Thanks again 
for trying to figure this out.


Steve

Results of print-settings

[D] allowclonedrags = True
[D] bodypanewraps = True
[D] bodytextfontfamily = Courier
[D] bodytextfontsize = 9
[D] bodytextfontslant = roman
[D] bodytextfontweight = normal
[D] colordirectivesinplaintext = True
[D] enabledragmessages = True
[D] headlinetextfontfamily = None
[D] headlinetextfontsize = 8
[D] headlinetextfontslant = roman
[D] headlinetextfontweight = normal
[D] ignoreblanklines = True
[D] initialhorizontalratio = 0.3
[D] initialhorizontalsecondaryratio = 0.5
[D] initialsplitorientation = vertical
[D] initialverticalratio = 0.5
[D] initialverticalsecondaryratio = 0.7
[D] initialwindowheight = 600
[D] initialwindowleft = 10
[D] initialwindowtop = 10
[D] initialwindowwidth = 800
[D] limitcount = 9
[D] logtextfontfamily = None
[D] logtextfontsize = 8
[D] logtextfontslant = roman
[D] logtextfontweight = normal
[D] outputdocchunks = True
[D] pagewidth = 132
[D] printmismatchinglines = True
[D] printtrailinglines = True
[D] searchbody = True
[D] splitbarcolor = LightSteelBlue2
[D] splitbarrelief = groove
[D] splitbarwidth = 7
[D] tabwidth = -4
[D] tangleoutputsheader = True
[D] targetlanguage = python
[D] underlineundefinedsectionnames = True
[F] vimmode = True
[D] wholeword = True

legend:
leoSettings.leo
[D] default settings
[F] loaded .leo File
[M] myLeoSettings.leo


On Thu, Aug 14, 2014 at 4:37 PM, Edward K. Ream > wrote:


On Thu, Aug 14, 2014 at 2:56 PM, Edward K. Ream
mailto:edream...@gmail.com>> wrote:
> On Thu, Aug 14, 2014 at 11:41 AM, Steve Zatz mailto:slz...@gmail.com>> wrote:

>> As below the following files are being read but the only file
with any
>> settings is myLeoSettings.leo  and it consists of one @settings
with @ bool
>> vim-mode = True
>
> Thanks for your persistence.  I'll try a similar setup and see
what happens...

I disabled leoSettings.leo and myLeoSettings.leo by changing their
names.

When I tried to load ekr.leo, Leo crashed trying to load an enchant
dict.  After correcting that (upped using git) ekr.leo loaded.  I then
did the following:

1. disabled the normal @settings node by renaming it.

2. I created another @settings node containing just @bool vim-mode
= True.

3. I restarted Leo and loaded ekr.leo.

As you say, Leo looks like a dos app :-)

4. I then clicked in the minibuffer area (no key bindings!) and
executed the print-settings command by typing "print-settings"

I selected the text with the mouse, then clicked the minibuffer area
again and did copy-text.  I then pasted the text here.  Here is what I
got::

[D] allowclonedrags = True
[D] bodypanewraps = True
[D] bodytextfontfamily = Courier
[D] bodytextfontsize = 9
[D] bodytextfontslant = roman
[D] bodytextfontweight = normal
[D] colordirectivesinplaintext = True
[D] enabledragmessages = True
[D] headlinetextfontfamily = None
[D] headlinetextfontsize = 8
[D] headlinetextfontslant = roman
[D] headlinetextfontweight = normal
[D] ignoreblanklines = True
[D] initialhorizontalratio = 0.3
[D] initialhorizontalsecondaryratio = 0.5
[D] initialsplitorientation = vertical
[D] initialverticalratio = 0.5
[D] initialverticalsecondaryratio = 0.7
[D] initialwindowheight = 600
[D] initialwindowleft = 10
[D] initialwindowtop = 10
[D] initialwindowwidth = 800
[D] limitcount = 9
[D] logtextfontfamily = None
[D] logtextfontsize = 8
[D] logtextfontslant = roman
[D] logtextfontweight = normal
[D] outputdocchunks = True
[D] pagewidth = 132
[D] printmismatchinglines = True
[D] printtrailinglines = True
[D] searchbody = True
[D

Re: Internal (Wiki-like) link support in Leo?

[gatesphere]

I use a combination of the backlink and graphcanvas plugins for this.  
The new nodetags plugin might help too.  Terry and others swear by the 
bookmarks plugin.


None of those options allows clickable links within the body of a node, 
however.  I imagine ctrl-clicking on a UNL would work, though.  YMMV.


-->Jake

On 8/14/2014 6:31 PM, Christoph wrote:
I consider to migrate from Orgmode to Leo so I would be curious what 
options do I have for internal links (i.e. Wiki-like links linking 
within a Leo doc or within Leo docs, apart from creating clones).


Two ways I guess:

- using restructuredText

- writing a plugin defining them


Anything I have overlooked? Thanks in advance

Christoph



--
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: UI config. settings, step 1.

[Dufriz]

Terry, I have just started testing your latest commit. I ran the Reload 
Styles command in the menu without problems, and the UI appearance changed 
a bit, signifying that some of the modified settings have taken effect. 
Still I can't say much about the new functionality, I need time to tinker 
with the settings and run it again, probably over the weekend.
However one (minor) thing that I have already noticed is that the menu 
entries are no longer highlighted when the mouse hovers over them. This is 
a problem which had already occurred a few months ago, and which you then 
fixed.
I'll let you know when I have experimented a little more.
Thanks for your help.

-- 
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!

[Steve Zatz]

I followed the directions although I wasn't sure what ekr.leo was so I just
created a new test.leo and inserted the vim = true @ setting in that new
file and then reloaded that file.  As before vim navigation and key
sequences like dd work fine.  The print-settings result (see below)  looks
just like your key bindings but alas no dice with regard to typing a colon.

Another thought is whether the version of python, PyQt or Windows could be
a factor.  I am running on the following:

Python 2.7.2, PyQt version 4.8.5
Windows 7 AMD64 (build 6.1.7601) SP1

If I am the only one experiencing this problem (and apparently I am), I
definitely think you should move on to other issues. I really appreciate
the time you've spent on it.   I'll try some other machines/OS's and let
you know if I discover anything.  Thanks again for trying to figure this
out.

Steve

Results of print-settings

[D] allowclonedrags = True
[D] bodypanewraps = True
[D] bodytextfontfamily = Courier
[D] bodytextfontsize = 9
[D] bodytextfontslant = roman
[D] bodytextfontweight = normal
[D] colordirectivesinplaintext = True
[D] enabledragmessages = True
[D] headlinetextfontfamily = None
[D] headlinetextfontsize = 8
[D] headlinetextfontslant = roman
[D] headlinetextfontweight = normal
[D] ignoreblanklines = True
[D] initialhorizontalratio = 0.3
[D] initialhorizontalsecondaryratio = 0.5
[D] initialsplitorientation = vertical
[D] initialverticalratio = 0.5
[D] initialverticalsecondaryratio = 0.7
[D] initialwindowheight = 600
[D] initialwindowleft = 10
[D] initialwindowtop = 10
[D] initialwindowwidth = 800
[D] limitcount = 9
[D] logtextfontfamily = None
[D] logtextfontsize = 8
[D] logtextfontslant = roman
[D] logtextfontweight = normal
[D] outputdocchunks = True
[D] pagewidth = 132
[D] printmismatchinglines = True
[D] printtrailinglines = True
[D] searchbody = True
[D] splitbarcolor = LightSteelBlue2
[D] splitbarrelief = groove
[D] splitbarwidth = 7
[D] tabwidth = -4
[D] tangleoutputsheader = True
[D] targetlanguage = python
[D] underlineundefinedsectionnames = True
[F] vimmode = True
[D] wholeword = True

legend:
leoSettings.leo
[D] default settings
[F] loaded .leo File
[M] myLeoSettings.leo


On Thu, Aug 14, 2014 at 4:37 PM, Edward K. Ream  wrote:

> On Thu, Aug 14, 2014 at 2:56 PM, Edward K. Ream 
> wrote:
> > On Thu, Aug 14, 2014 at 11:41 AM, Steve Zatz  wrote:
>
> >> As below the following files are being read but the only file with any
> >> settings is myLeoSettings.leo  and it consists of one @settings with @
> bool
> >> vim-mode = True
> >
> > Thanks for your persistence.  I'll try a similar setup and see what
> happens...
>
> I disabled leoSettings.leo and myLeoSettings.leo by changing their names.
>
> When I tried to load ekr.leo, Leo crashed trying to load an enchant
> dict.  After correcting that (upped using git) ekr.leo loaded.  I then
> did the following:
>
> 1. disabled the normal @settings node by renaming it.
>
> 2. I created another @settings node containing just @bool vim-mode = True.
>
> 3. I restarted Leo and loaded ekr.leo.
>
> As you say, Leo looks like a dos app :-)
>
> 4. I then clicked in the minibuffer area (no key bindings!) and
> executed the print-settings command by typing "print-settings"
>
> I selected the text with the mouse, then clicked the minibuffer area
> again and did copy-text.  I then pasted the text here.  Here is what I
> got::
>
> [D] allowclonedrags = True
> [D] bodypanewraps = True
> [D] bodytextfontfamily = Courier
> [D] bodytextfontsize = 9
> [D] bodytextfontslant = roman
> [D] bodytextfontweight = normal
> [D] colordirectivesinplaintext = True
> [D] enabledragmessages = True
> [D] headlinetextfontfamily = None
> [D] headlinetextfontsize = 8
> [D] headlinetextfontslant = roman
> [D] headlinetextfontweight = normal
> [D] ignoreblanklines = True
> [D] initialhorizontalratio = 0.3
> [D] initialhorizontalsecondaryratio = 0.5
> [D] initialsplitorientation = vertical
> [D] initialverticalratio = 0.5
> [D] initialverticalsecondaryratio = 0.7
> [D] initialwindowheight = 600
> [D] initialwindowleft = 10
> [D] initialwindowtop = 10
> [D] initialwindowwidth = 800
> [D] limitcount = 9
> [D] logtextfontfamily = None
> [D] logtextfontsize = 8
> [D] logtextfontslant = roman
> [D] logtextfontweight = normal
> [D] outputdocchunks = True
> [D] pagewidth = 132
> [D] printmismatchinglines = True
> [D] printtrailinglines = True
> [D] searchbody = True
> [D] splitbarcolor = LightSteelBlue2
> [D] splitbarrelief = groove
> [D] splitbarwidth = 7
> [D] tabwidth = -4
> [D] tangleoutputsheader = True
> [D] targetlanguage = python
> [D] underlineundefinedsectionnames = True
> [F] vimmode = True
> [D] wholeword = True
>
> legend:
> leoSettings.leo
> [D] default settings
> [F] loaded .leo File
> [M] myLeoSettings.leo
>
> This shows that only default settings are in effect, except that
> ekr.leo sets vim-mode to True.
>
> With these settings, (drum roll please), colon *does* work as expected.
>
> This shows, I think, that *onl

Internal (Wiki-like) link support in Leo?

[Christoph]

I consider to migrate from Orgmode to Leo so I would be curious what 
options do I have for internal links (i.e. Wiki-like links linking 
within a Leo doc or within Leo docs, apart from creating clones).


Two ways I guess:

- using restructuredText

- writing a plugin defining them


Anything I have overlooked? Thanks in advance

Christoph

--
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: Git hooks for version reporting

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 16:51:03 -0500
"'Terry Brown' via leo-editor"  wrote:

> The point of this is that leo/extensions/hooks/install_hooks.py is

Um, make that leo/core/commit_timestamp.json

-- 
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: Git hooks for version reporting

['Terry Brown' via leo-editor]

So to finish up, if a dev. installs the hooks in 
leo/extensions/hooks/ (with or without the
leo/extensions/hooks/install_hooks.py script), their commits will
update the content of leo/core/commit_timestamp.json automagically.

{
"asctime": "Thu Aug 14 16:10:38 2014", 
"parent": "a69585e26f8162e652bee9eb6d982e55ec615e0e", 
"timestamp": "20140814161038"
}

But someone (Jacob?) still needs to update the code which prints the
build info. in the log window so that it displays that timestamp as the
Leo build ID.

The point of this is that leo/extensions/hooks/install_hooks.py is
always present, whereas .git is not present when the user gets the
latest code via the snapshot.  The user of a timestamp rather than
a sha1 for the build ID is ok I think, a very minor burden for
developers, and simpler for everyone else.

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.

Git hooks for version reporting

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 16:23:14 -0500
"'Terry Brown' via leo-editor"  wrote:

[snip]
> hmmm, it occurs to me it should be possible to include the commit
> message in here, oddly enough.

Or maybe not, you can modify files in the commit in `pre-commit`,
but not in commit-msg.

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.

OT: Science Magazine: A sensational new computer architecture

[Edward K. Ream]

This is likely to change the world:

An overview: http://www.sciencemag.org/content/345/6197/614.full.pdf

The abstract: http://www.sciencemag.org/content/345/6197/668.abstract

QQQ
Inspired by the brain’s structure, we have developed an efficient, 
scalable, and flexible non–von Neumann architecture that leverages 
contemporary silicon technology. To demonstrate, we built a 
5.4-billion-transistor chip with 4096 neurosynaptic cores interconnected 
via an intrachip network that integrates 1 million programmable spiking 
neurons and 256 million configurable synapses. Chips can be tiled in two 
dimensions via an interchip communication interface, seamlessly scaling the 
architecture to a cortexlike sheet of arbitrary size. The architecture is 
well suited to many applications that use complex neural networks in real 
time, for example, multiobject detection and classification. With 
400-pixel-by-240-pixel video input at 30 frames per second, the chip 
consumes 63 milliwatts.
QQQ

That's 63 milliwatts, not 63 megawatts ;-)  This computer consumes about 4 
orders of magnitude less power than state-of-the-art supercomputers.

It you have access to Science, the full article is here: 
http://www.sciencemag.org/content/345/6197/668.full.pdf

supplemental material (many details): 
http://www.sciencemag.org/content/345/6197/668/suppl/DC1

If you don't subscribe to Science, you really should ;-)

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: Help! Messing with UI settings.

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 15:14:46 -0500
"Edward K. Ream"  wrote:

> On Thu, Aug 14, 2014 at 3:00 PM, 'Terry Brown' via leo-editor
>  wrote:
> 
> 
> >> > So, we need a git commit hook to update version.py on every
> >> > commit.
> 
> > I have a draft hook written, will share soon.

Ok, so this is way more complicated than it seems :-)

1) We can't put the sha1 of the commit into the version file, because
that would change the version file, which would change the sha1...

So I propose identifying builds with text of the form: 20140814161038

2) I've written two hooks, a pre-commit hook that checks if there's
anything to commit, and if there is, updates
leo/core/commit_timestamp.json, which looks like this:

{
"asctime": "Thu Aug 14 16:10:38 2014", 
"parent": "a69585e26f8162e652bee9eb6d982e55ec615e0e", 
"timestamp": "20140814161038"
}

hmmm, it occurs to me it should be possible to include the commit
message in here, oddly enough.

and a commit-msg hook that grabs the Leo Build ID (timestamp) from here,
and adds it to the commit message.

So when a user complains about build 20140814161038, a quick

git log --grep=20140814161038

will report the commit.  I usually browse the repo with gitk, which can
also search for these build IDs easily.

3) Finally, I said this was complicated, hooks execute arbitrary code
on your computer, so git won't install them automatically, hence:
leo/extensions/hooks/install_hooks.py which a developer must run to
install the hooks.

Oh, and the hooks are written in Python and start with
#!/usr/bin/python and install_hooks.py does 
os.chmod(data[hook+"PATH"], 0o744) but I don't know if that's
sufficient on Windows.

Cheers -Terry
  
> Excellent.  Thanks you.
> 
> I'm investigating what happens without any settings file, except for
> the file being loaded.
> 
> 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: Vim emulation: ready for testing!

[Edward K. Ream]

On Thu, Aug 14, 2014 at 2:56 PM, Edward K. Ream  wrote:
> On Thu, Aug 14, 2014 at 11:41 AM, Steve Zatz  wrote:

>> As below the following files are being read but the only file with any
>> settings is myLeoSettings.leo  and it consists of one @settings with @ bool
>> vim-mode = True
>
> Thanks for your persistence.  I'll try a similar setup and see what happens...

I disabled leoSettings.leo and myLeoSettings.leo by changing their names.

When I tried to load ekr.leo, Leo crashed trying to load an enchant
dict.  After correcting that (upped using git) ekr.leo loaded.  I then
did the following:

1. disabled the normal @settings node by renaming it.

2. I created another @settings node containing just @bool vim-mode = True.

3. I restarted Leo and loaded ekr.leo.

As you say, Leo looks like a dos app :-)

4. I then clicked in the minibuffer area (no key bindings!) and
executed the print-settings command by typing "print-settings"

I selected the text with the mouse, then clicked the minibuffer area
again and did copy-text.  I then pasted the text here.  Here is what I
got::

[D] allowclonedrags = True
[D] bodypanewraps = True
[D] bodytextfontfamily = Courier
[D] bodytextfontsize = 9
[D] bodytextfontslant = roman
[D] bodytextfontweight = normal
[D] colordirectivesinplaintext = True
[D] enabledragmessages = True
[D] headlinetextfontfamily = None
[D] headlinetextfontsize = 8
[D] headlinetextfontslant = roman
[D] headlinetextfontweight = normal
[D] ignoreblanklines = True
[D] initialhorizontalratio = 0.3
[D] initialhorizontalsecondaryratio = 0.5
[D] initialsplitorientation = vertical
[D] initialverticalratio = 0.5
[D] initialverticalsecondaryratio = 0.7
[D] initialwindowheight = 600
[D] initialwindowleft = 10
[D] initialwindowtop = 10
[D] initialwindowwidth = 800
[D] limitcount = 9
[D] logtextfontfamily = None
[D] logtextfontsize = 8
[D] logtextfontslant = roman
[D] logtextfontweight = normal
[D] outputdocchunks = True
[D] pagewidth = 132
[D] printmismatchinglines = True
[D] printtrailinglines = True
[D] searchbody = True
[D] splitbarcolor = LightSteelBlue2
[D] splitbarrelief = groove
[D] splitbarwidth = 7
[D] tabwidth = -4
[D] tangleoutputsheader = True
[D] targetlanguage = python
[D] underlineundefinedsectionnames = True
[F] vimmode = True
[D] wholeword = True

legend:
leoSettings.leo
[D] default settings
[F] loaded .leo File
[M] myLeoSettings.leo

This shows that only default settings are in effect, except that
ekr.leo sets vim-mode to True.

With these settings, (drum roll please), colon *does* work as expected.

This shows, I think, that *only* the @bool vim-mode setting is
necessary to use vim mode.

= Conclusion

I recommend that you do the following:

1. Get rev a69585e... from git. This fixes a startup problem when no
settings exist.

2. Follow exactly the steps that I have just taken and report what
colon does in vim mode.

Thanks.

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.

UI config. settings, step 1.

['Terry Brown' via leo-editor]

Short version:

Dufriz, if you want, grab the latest version, open your
myLeoSettings.leo, and use the new Reload Styles item from the Settings
menu.  It will hopefully either work, or give sensible feedback.

Long version:

Interesting pit fall with including code in Leo outlines like the
`stylesheet & source` node the instructions wanted you to execute, or
the `@button reload-styles` which was supposed to be included in
all settings type files.  In either case, Leo specific code which the
user isn't supposed to need to touch is being copied around, creating
duplicate versions, without easy updates... big anti-pattern.

The correct way is for style reloading to be handled by a Leo command
defined in Leo's core (well, the Qt interface core, anyway) so it can
be changed and updated as needed.

So the instructions to execute `stylesheet & source` and the `@button
reload-styles` are still out there, with their broken calls to
g.expand_css_constants etc., they'll have to be rounded up somehow.
Anyway, *now* the way to recompile the tree form of a theme into a
style-sheet (if your using a theme) and apply the style-sheet (from a
theme or simple static) is to Alt-X style-reload, or just
Settings->Reload Styles.

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: Help! Messing with UI settings.

[Edward K. Ream]

On Thu, Aug 14, 2014 at 3:00 PM, 'Terry Brown' via leo-editor
 wrote:


>> > So, we need a git commit hook to update version.py on every commit.

> I have a draft hook written, will share soon.

Excellent.  Thanks you.

I'm investigating what happens without any settings file, except for
the file being loaded.

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: Help! Messing with UI settings.

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 14:51:53 -0500
"Edward K. Ream"  wrote:

> On Thu, Aug 14, 2014 at 10:58 AM, 'Terry Brown' via leo-editor
>  wrote:
> 
> 
> > It's not ok to require that people use `git` to get it, that's
> > unreasonable.
> 
> I agree.  It's not a requirement--it's just the easiest, quickest
> way :-)
> 
> > So, we need a git commit hook to update version.py on every commit.
> 
> Yes.  This will save lots of time and confusion in the long run.  I've
> put it my immediate to-do list, unless you would like to take a
> crack...

I have a draft hook written, will share soon.

Cheers -Terry


> 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: Vim emulation: ready for testing!

[Edward K. Ream]

On Thu, Aug 14, 2014 at 11:41 AM, Steve Zatz  wrote:
> As below the following files are being read but the only file with any
> settings is myLeoSettings.leo  and it consists of one @settings with @ bool
> vim-mode = True

Thanks for your persistence.  I'll try a similar setup and see what happens...

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: Help! Messing with UI settings.

[Edward K. Ream]

On Thu, Aug 14, 2014 at 10:58 AM, 'Terry Brown' via leo-editor
 wrote:


> It's not ok to require that people use `git` to get it, that's
> unreasonable.

I agree.  It's not a requirement--it's just the easiest, quickest way :-)

> So, we need a git commit hook to update version.py on every commit.

Yes.  This will save lots of time and confusion in the long run.  I've
put it my immediate to-do list, unless you would like to take a
crack...

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: Help! Messing with UI settings.

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 10:16:32 -0700 (PDT)
Dufriz  wrote:

> On Thursday, 14 August 2014 17:49:08 UTC+1, Fidel N wrote:
> >
> > I knew very few of programming, nothing of python, and now I know
> > both, because I had the time, loved the concept of Leo, and could
> > devote my time to study both.
> >
> 
> I intend to take the same path as you. I just wish I have the time
> and the patience required.
>  
> 
> I also asked for a settings GUI, because IMO, this is screening out a
> lot 
> > of people that would otherwise use Leo for non-programming related
> > stuff. Something as simple as Notepad++ settings/preferences menu,
> > just a simple tick menu, would make much more people remain in Leo.
> > Even if you love the concept, clones, etc, if you must learn python
> > and pyqt and Leo structures and Leo @node_id inheritance before you
> > can edit that, you simply wont.
> > I know someone will think "its not neccesary to know pyqt to change
> > the background colors", but I have been there, and otherwise you
> > dont really know what you are touching // how to edit that.
> > Also, having to restart the app for every change to make effect
> > makes everything much slower (for a newbie), all of this resulting
> > in non programmers running away from Leo as fast as they can.
> > Just a few comboboxes with option lists, + tickboxes for boolean
> > values, would make a huge difference. If the need to restart Leo
> > was removed, that would make things perfect.
> >
> > But then again, this is a dev time problem, so only thing I can do
> > till I get some extra time to develop that myself, is to remain
> > extremely grateful for Leo as is right now.
> >
> 
> I do believe that a middle ground could be struck for the management
> of settings, between the excessively dumbed down UI of all other
> general-use programs and the overly complicated (as in the current

Indeed the previously discussed blueprint for making UI config easier
is a middle ground along the lines you describe, and once the tricky
bits are done, it should be quite easy to set it up to cover a lot
config. options very quickly.  The tricky parts are copying sufficient
but not excessive content from LeoSettings to myLeoSettings, and
accounting for themes.  It's so easy to think "tell the user to move
all but one theme node out of their @settings tree"... but that's back
where we started.  Anyway, I'll try and find time.

Cheers -Terry

> case) Qt-based-only interface which excludes those who are not
> advanced programmers. I, for one, have programming experience, though
> not with Python/PyQt, so I am not at all scared of editing text files
> for settings. HOWEVER, don't you think that the present method of
> managing settings is way too complicated, and unnecessarily so? I
> mean, the user has to manually modify the text-based settings (which
> is OK, although it is not at all easy) but then he also has to *run a
> script in order to compile the settings via the script*. Come on.
> Does anyone think that this is even remotely normal?!?
> (No hard feelings, I hope)
> 
> The middle way I was hinting to would be having something similar to
> this:
> 
> color-background-body-pane:
> color-foreground-body-pane:
> font-size-text-body-pane:
> font-type-body-pane:
> color-background-log-pane:
> color-foreground-log-pane:
> font-size-text-log-pane:
> font-type-log-pane:
> 
> and so on...
> 
> The settings management would be still text-based, but it would be:
> 1) all within one node
> 2) no scripts required
> 3) clearly understandable variable names
> 
> In short, it would be something humanly readable and understandable.
> 
> 

-- 
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: Help! Messing with UI settings.

[Dufriz]

On Thursday, 14 August 2014 17:49:08 UTC+1, Fidel N wrote:
>
> I knew very few of programming, nothing of python, and now I know both, 
> because I had the time, loved the concept of Leo, and could devote my time 
> to study both.
>

I intend to take the same path as you. I just wish I have the time and the 
patience required.
 

I also asked for a settings GUI, because IMO, this is screening out a lot 
> of people that would otherwise use Leo for non-programming related stuff.
> Something as simple as Notepad++ settings/preferences menu, just a simple 
> tick menu, would make much more people remain in Leo.
> Even if you love the concept, clones, etc, if you must learn python and 
> pyqt and Leo structures and Leo @node_id inheritance before you can edit 
> that, you simply wont.
> I know someone will think "its not neccesary to know pyqt to change the 
> background colors", but I have been there, and otherwise you dont really 
> know what you are touching // how to edit that.
> Also, having to restart the app for every change to make effect makes 
> everything much slower (for a newbie), all of this resulting in non 
> programmers running away from Leo as fast as they can.
> Just a few comboboxes with option lists, + tickboxes for boolean values, 
> would make a huge difference. If the need to restart Leo was removed, that 
> would make things perfect.
>
> But then again, this is a dev time problem, so only thing I can do till I 
> get some extra time to develop that myself, is to remain extremely grateful 
> for Leo as is right now.
>

I do believe that a middle ground could be struck for the management of 
settings, between the excessively dumbed down UI of all other general-use 
programs and the overly complicated (as in the current case) Qt-based-only 
interface which excludes those who are not advanced programmers. I, for 
one, have programming experience, though not with Python/PyQt, so I am not 
at all scared of editing text files for settings. 
HOWEVER, don't you think that the present method of managing settings is 
way too complicated, and unnecessarily so? I mean, the user has 
to manually modify the text-based settings (which is OK, although it is not 
at all easy) but then he also has to *run a script in order to compile the 
settings via the script*. Come on. Does anyone think that this is even 
remotely normal?!?
(No hard feelings, I hope)

The middle way I was hinting to would be having something similar to this:

color-background-body-pane:
color-foreground-body-pane:
font-size-text-body-pane:
font-type-body-pane:
color-background-log-pane:
color-foreground-log-pane:
font-size-text-log-pane:
font-type-log-pane:

and so on...

The settings management would be still text-based, but it would be:
1) all within one node
2) no scripts required
3) clearly understandable variable names

In short, it would be something humanly readable and understandable.


-- 
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: Help! Messing with UI settings.

[Dufriz]

Terry said:
>(Summary - quite possibly Dufriz is using the latest code, can't tell 
>from the log pane content) 

Precisely. The version I am running was downloaded from git itself 
yesterday or the day before. The About window (whose data I had copied into 
the post) does not report updated info about the version.

Terry said:
> Well, if you'd read the instructions, you'd have been able to get 
> frustrated at a completely different step in the process :-} :-) 
...
> Sorry about all the frustration, and to be fair with it being broken 
> by the missing "c," thing, maybe you had followed this procedure 
> at one point and understandably thought it didn't work, on account 
> of it not working :-/ 

Yes, as a matter of fact I do recall trying to run a script at one point, 
and getting an error message.

Anyway, I have now followed your latest instructions, but I still get an 
error message while running the script.

Moreover, the part of the script that I corrected as per your instructions 
was commented out. Of course I removed the leading # before running the 
script. 
Here is the error message that I get:

exception executing script
AttributeError: 'NoneType' object has no attribute 'children'

  line 471: p = self
* line 472: return len(p.v.children)
  line 473: #@+node:ekr.20031218072017.915: *4* p.getX & VNode 
compatibility traversal routines
  line 474: # These methods are useful abbreviations.

By the way, the next line below what you mentioned is commented out:
# c.selectPosition(nd)
Should I uncomment it too?

By the way, I noticed yet another commented out line, above:
#X cp = c.p

Could these be responsible for the error?


-- 
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: Help! Messing with UI settings.

[Fidel N]

Dufriz is facing the same exact problems with GUI config I had when I
joined Leo.
I knew very few of programming, nothing of python, and now I know both,
because I had the time, loved the concept of Leo, and could devote my time
to study both.

I also asked for a settings GUI, because IMO, this is screening out a lot
of people that would otherwise use Leo for non-programming related stuff.
Something as simple as Notepad++ settings/preferences menu, just a simple
tick menu, would make much more people remain in Leo.
Even if you love the concept, clones, etc, if you must learn python and
pyqt and Leo structures and Leo @node_id inheritance before you can edit
that, you simply wont.
I know someone will think "its not neccesary to know pyqt to change the
background colors", but I have been there, and otherwise you dont really
know what you are touching // how to edit that.
Also, having to restart the app for every change to make effect makes
everything much slower (for a newbie), all of this resulting in non
programmers running away from Leo as fast as they can.
Just a few comboboxes with option lists, + tickboxes for boolean values,
would make a huge difference. If the need to restart Leo was removed, that
would make things perfect.

But then again, this is a dev time problem, so only thing I can do till I
get some extra time to develop that myself, is to remain extremely grateful
for Leo as is right now.



On Thu, Aug 14, 2014 at 6:35 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:

> On Thu, 14 Aug 2014 09:26:30 -0700 (PDT)
> Chris George  wrote:
>
> > "It's not ok to require that people use `git` to get it,
> > that's unreasonable."
> >
> > Why?
> >
> > The primary target user for Leo is a programmer, is it not?
>
> No, although I can understand why someone might think that was the
> case :-)
>
> Also, there are programmers (the docutils dev. team for example) who
> are not interested in using git, and would probably regard needing to
> use it to download and try a piece of software as a reason not to try
> the software.
>
> > Perhaps
> > once the development solidifies enough and begins targeting
> > non-programmers (average user), then it might need a little dumbing
> > down of the distribution method.
> >
> > I may be a bit on the edge as a user, I use a rolling distribution
> > for my operating system so I am familiar with the model, but Leo is
> > currently fluid, and as a user that is one of its strengths to me.
> > Installing git and writing a script to pull down the latest Leo and
> > start it was simple, and I can't see it being any more difficult on
> > other platforms. I guess I see the use of git as a feature. :-)
>
> For a programmer.  I think expecting people to unzip a zip is not
> unreasonable, although it will screen out some people, but they were
> probably not going to find Leo to their liking.  Hence the problem with
> the .zip reporting misleading version info.
>
> Cheers -Terry
>
> > Chris
> >
> > On Thursday, August 14, 2014 8:59:02 AM UTC-7, Terry wrote:
> > >
> > > On Thu, 14 Aug 2014 10:40:23 -0500
> > > "Edward K. Ream" > wrote:
> > >
> > > > On Thu, Aug 14, 2014 at 9:02 AM, Dufriz  > > > >
> > > wrote:
> > > > > I am on Windows 8.1, running Python 3.3.5 with
> > > > > PyQt4-4.10.4-gpl-Py3.3-Qt4.8.5-x64.
> > > > > I am using Leo 4.11 final, build 6240.
> > > >
> > > > Thanks for this.  This looks like ancient history, though I might
> > > > be mistaken. Recent builds (from git) look like:
> > > >
> > > > Leo 4.11 final, build 6e21a6dc12f0 (branch: master), 2014-08-13
> > > > 08:30:03
> > >
> > > That's a good point of course, my comments about needing "c, "
> > > added in that call apply to the current trunk, not sure about that
> > > version.
> > >
> > > Actually Houston, we have a problem.
> > >
> > > Leo uses the model "use the trunk, it's stable" - ok
> > >
> > > It's not ok to require that people use `git` to get it, that's
> > > unreasonable.
> > >
> > > But no problem, they can use the snapshot,
> > > https://github.com/leo-editor/leo-editor/archive/master.zip
> > >
> > > But... that identifies itself in the log window as
> > >
> > > Leo 4.11 final, build 6240, 2013-11-06
> > > Python 2.7.6, PyQt version 4.8.6
> > >
> > > which is completely misleading.  It does that because it falls back
> > > on version.py or similar, I assume, when the .git directory's not
> > > present.
> > >
> > > So, we need a git commit hook to update version.py on every commit.
> > >
> > > Or, not use git-hub for snapshots, but it seems git-hub is so close
> > > to doing exactly what we need it's worth getting version reporting
> > > in git-hub snapshots to work.
> > >
> > > (Summary - quite possibly Dufriz is using the latest code, can't
> > > tell from the log pane content)
> > >
> > > Cheers -Terry
> > >
> > > > Could you pull down the latest git version?  Alternatively, you
> > > > could get a recent daily snapshot?  That way we can all be
> > > > discussing 

Re: Vim emulation: ready for testing!

[Steve Zatz]

As below the following files are being read but the only file with any
settings is myLeoSettings.leo  and it consists of one @settings with @ bool
vim-mode = True

reading settings in C:\home\slzatz\leo-editor\leo\config\leoSettings.leo

reading settings in C:\Users\szatz\.leo\myLeoSettings.leo

reading settings in c:\home\slzatz\test.leo


This is consistent with the fact that my version of Leo now looks like a
dos application.  ;-)


On Thu, Aug 14, 2014 at 8:53 AM, Edward K. Ream  wrote:

> On Thu, Aug 14, 2014 at 6:44 AM, Steve Zatz  wrote:
>
> > I am typing a colon -- meaning I am typing Shift and the key that
> contains
> > the colon and semi-colon. For whatever reason, the log file message
> > references semi-colon and appears to be missing the fact that the shift
> key
> > is pressed.  If I am insert mode, I get the expected colon.  And since I
> can
> > type any cap character, I don't think it's my shift key.
>
> Very interesting.
>
> > I have just tried completely commenting out the @settings in the global
> > leosettings, which, as an aside is pretty interesting to see Leo with
> > absolutely no  settings active.  Alas, the problem continues.
>
> I wouldn't be so sure.
>
> Leo will report when it reads a settings file, both in the console
> window and in the log pane of the first-loaded file.  Are you *sure*
> that no settings files are active?
>
> 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: Help! Messing with UI settings.

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 09:26:30 -0700 (PDT)
Chris George  wrote:

> "It's not ok to require that people use `git` to get it, 
> that's unreasonable."
> 
> Why?
> 
> The primary target user for Leo is a programmer, is it not? 

No, although I can understand why someone might think that was the
case :-)

Also, there are programmers (the docutils dev. team for example) who
are not interested in using git, and would probably regard needing to
use it to download and try a piece of software as a reason not to try
the software.

> Perhaps
> once the development solidifies enough and begins targeting
> non-programmers (average user), then it might need a little dumbing
> down of the distribution method.
> 
> I may be a bit on the edge as a user, I use a rolling distribution
> for my operating system so I am familiar with the model, but Leo is
> currently fluid, and as a user that is one of its strengths to me.
> Installing git and writing a script to pull down the latest Leo and
> start it was simple, and I can't see it being any more difficult on
> other platforms. I guess I see the use of git as a feature. :-)

For a programmer.  I think expecting people to unzip a zip is not
unreasonable, although it will screen out some people, but they were
probably not going to find Leo to their liking.  Hence the problem with
the .zip reporting misleading version info.

Cheers -Terry

> Chris
> 
> On Thursday, August 14, 2014 8:59:02 AM UTC-7, Terry wrote:
> >
> > On Thu, 14 Aug 2014 10:40:23 -0500 
> > "Edward K. Ream" > wrote: 
> >
> > > On Thu, Aug 14, 2014 at 9:02 AM, Dufriz  > > > 
> > wrote: 
> > > > I am on Windows 8.1, running Python 3.3.5 with 
> > > > PyQt4-4.10.4-gpl-Py3.3-Qt4.8.5-x64. 
> > > > I am using Leo 4.11 final, build 6240. 
> > > 
> > > Thanks for this.  This looks like ancient history, though I might
> > > be mistaken. Recent builds (from git) look like: 
> > > 
> > > Leo 4.11 final, build 6e21a6dc12f0 (branch: master), 2014-08-13 
> > > 08:30:03 
> >
> > That's a good point of course, my comments about needing "c, "
> > added in that call apply to the current trunk, not sure about that
> > version. 
> >
> > Actually Houston, we have a problem. 
> >
> > Leo uses the model "use the trunk, it's stable" - ok 
> >
> > It's not ok to require that people use `git` to get it, that's 
> > unreasonable. 
> >
> > But no problem, they can use the snapshot, 
> > https://github.com/leo-editor/leo-editor/archive/master.zip 
> >
> > But... that identifies itself in the log window as 
> >
> > Leo 4.11 final, build 6240, 2013-11-06 
> > Python 2.7.6, PyQt version 4.8.6 
> >
> > which is completely misleading.  It does that because it falls back
> > on version.py or similar, I assume, when the .git directory's not
> > present. 
> >
> > So, we need a git commit hook to update version.py on every commit. 
> >
> > Or, not use git-hub for snapshots, but it seems git-hub is so close
> > to doing exactly what we need it's worth getting version reporting
> > in git-hub snapshots to work. 
> >
> > (Summary - quite possibly Dufriz is using the latest code, can't
> > tell from the log pane content) 
> >
> > Cheers -Terry 
> >
> > > Could you pull down the latest git version?  Alternatively, you
> > > could get a recent daily snapshot?  That way we can all be
> > > discussing recent code.  If you use git you can instantly get any
> > > improvements. 
> > > 
> > > 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: Help! Messing with UI settings.

[Chris George]

"It's not ok to require that people use `git` to get it, 
that's unreasonable."

Why?

The primary target user for Leo is a programmer, is it not? Perhaps once 
the development solidifies enough and begins targeting non-programmers 
(average user), then it might need a little dumbing down of the 
distribution method.

I may be a bit on the edge as a user, I use a rolling distribution for my 
operating system so I am familiar with the model, but Leo is currently 
fluid, and as a user that is one of its strengths to me. Installing git and 
writing a script to pull down the latest Leo and start it was simple, and I 
can't see it being any more difficult on other platforms. I guess I see the 
use of git as a feature. :-)

Chris

On Thursday, August 14, 2014 8:59:02 AM UTC-7, Terry wrote:
>
> On Thu, 14 Aug 2014 10:40:23 -0500 
> "Edward K. Ream" > wrote: 
>
> > On Thu, Aug 14, 2014 at 9:02 AM, Dufriz > 
> wrote: 
> > > I am on Windows 8.1, running Python 3.3.5 with 
> > > PyQt4-4.10.4-gpl-Py3.3-Qt4.8.5-x64. 
> > > I am using Leo 4.11 final, build 6240. 
> > 
> > Thanks for this.  This looks like ancient history, though I might be 
> > mistaken. Recent builds (from git) look like: 
> > 
> > Leo 4.11 final, build 6e21a6dc12f0 (branch: master), 2014-08-13 
> > 08:30:03 
>
> That's a good point of course, my comments about needing "c, " added in 
> that call apply to the current trunk, not sure about that version. 
>
> Actually Houston, we have a problem. 
>
> Leo uses the model "use the trunk, it's stable" - ok 
>
> It's not ok to require that people use `git` to get it, that's 
> unreasonable. 
>
> But no problem, they can use the snapshot, 
> https://github.com/leo-editor/leo-editor/archive/master.zip 
>
> But... that identifies itself in the log window as 
>
> Leo 4.11 final, build 6240, 2013-11-06 
> Python 2.7.6, PyQt version 4.8.6 
>
> which is completely misleading.  It does that because it falls back on 
> version.py or similar, I assume, when the .git directory's not present. 
>
> So, we need a git commit hook to update version.py on every commit. 
>
> Or, not use git-hub for snapshots, but it seems git-hub is so close to 
> doing exactly what we need it's worth getting version reporting in 
> git-hub snapshots to work. 
>
> (Summary - quite possibly Dufriz is using the latest code, can't tell 
> from the log pane content) 
>
> Cheers -Terry 
>
> > Could you pull down the latest git version?  Alternatively, you could 
> > get a recent daily snapshot?  That way we can all be discussing recent 
> > code.  If you use git you can instantly get any improvements. 
> > 
> > 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: Help! Messing with UI settings.

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 10:40:23 -0500
"Edward K. Ream"  wrote:

> On Thu, Aug 14, 2014 at 9:02 AM, Dufriz  wrote:
> > I am on Windows 8.1, running Python 3.3.5 with
> > PyQt4-4.10.4-gpl-Py3.3-Qt4.8.5-x64.
> > I am using Leo 4.11 final, build 6240.
> 
> Thanks for this.  This looks like ancient history, though I might be
> mistaken. Recent builds (from git) look like:
> 
> Leo 4.11 final, build 6e21a6dc12f0 (branch: master), 2014-08-13
> 08:30:03

That's a good point of course, my comments about needing "c, " added in
that call apply to the current trunk, not sure about that version.

Actually Houston, we have a problem.

Leo uses the model "use the trunk, it's stable" - ok

It's not ok to require that people use `git` to get it, that's
unreasonable.

But no problem, they can use the snapshot,
https://github.com/leo-editor/leo-editor/archive/master.zip

But... that identifies itself in the log window as

Leo 4.11 final, build 6240, 2013-11-06
Python 2.7.6, PyQt version 4.8.6

which is completely misleading.  It does that because it falls back on
version.py or similar, I assume, when the .git directory's not present.

So, we need a git commit hook to update version.py on every commit.

Or, not use git-hub for snapshots, but it seems git-hub is so close to
doing exactly what we need it's worth getting version reporting in
git-hub snapshots to work.

(Summary - quite possibly Dufriz is using the latest code, can't tell
from the log pane content)

Cheers -Terry

> Could you pull down the latest git version?  Alternatively, you could
> get a recent daily snapshot?  That way we can all be discussing recent
> code.  If you use git you can instantly get any improvements.
> 
> 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: vim bindings reports

[Kent Tenney]

OK, I'll hold my horses, waiting for updates on this thread.

On Thu, Aug 14, 2014 at 10:50 AM, Edward K. Ream  wrote:
> On Thu, Aug 14, 2014 at 9:02 AM, Kent Tenney  wrote:
>> Starting a new thread
>>
 in vim :r pastes a copy of the current file at the cursor
>>
>>>I didn't know that.  It will be easy to do once the solution referred
>>>to in this morning's post is in place.  See the P.P.S in that post.
>>
>> Maybe some confusion: requiring the  is a big problem,
>> requires learning the 3rd set of bindings.
>
> Kent, I do understand.  Really.
>
> In the real vim, nothing happens if you type :r.  You must either type
> :r or :r 
>
> The "solution" I am working on is to allow exactly this operation.  At
> present, you must indeed type::
>
> :r
>
> or::
>
> :r
>
> but that initial extra  is to go away asap.
>
>> status report:
>>
>> - 'V' should provide line mode visual, it inserts a 'V' at cursor
>> - 'v' starts visual character mode, 'y' should end visual mode and yank, 'y'
>>  is ignored until another 'v'
>> - aliasing  to 'i' is confusing, in vim it advances cursor to next 
>> line
>> - 'x' is backspace in Leo, delete in vim
>>
>> - '/' and '?' look good, with 'n' going to next find
>
> Thanks.  I'll look into these.
>
>> wish list:
>>
>> - :s /text/replace with this/
>
> All substitutions require the "solution" we are talking about.  It
> will happen asap.
>
> Once that is in place, a  vim-mode parser can deal with the entire
> command line at once.  This is inherently a simpler problem than
> dealing with characters one at a time, but it will require new code.
>
> In short, I am aware of the parsing problems and I appreciate the
> status/bug report.  I expect to have everything finished in about a
> week.
>
> 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: vim bindings reports

[Edward K. Ream]

On Thu, Aug 14, 2014 at 9:02 AM, Kent Tenney  wrote:
> Starting a new thread
>
>>> in vim :r pastes a copy of the current file at the cursor
>
>>I didn't know that.  It will be easy to do once the solution referred
>>to in this morning's post is in place.  See the P.P.S in that post.
>
> Maybe some confusion: requiring the  is a big problem,
> requires learning the 3rd set of bindings.

Kent, I do understand.  Really.

In the real vim, nothing happens if you type :r.  You must either type
:r or :r 

The "solution" I am working on is to allow exactly this operation.  At
present, you must indeed type::

:r

or::

:r

but that initial extra  is to go away asap.

> status report:
>
> - 'V' should provide line mode visual, it inserts a 'V' at cursor
> - 'v' starts visual character mode, 'y' should end visual mode and yank, 'y'
>  is ignored until another 'v'
> - aliasing  to 'i' is confusing, in vim it advances cursor to next 
> line
> - 'x' is backspace in Leo, delete in vim
>
> - '/' and '?' look good, with 'n' going to next find

Thanks.  I'll look into these.

> wish list:
>
> - :s /text/replace with this/

All substitutions require the "solution" we are talking about.  It
will happen asap.

Once that is in place, a  vim-mode parser can deal with the entire
command line at once.  This is inherently a simpler problem than
dealing with characters one at a time, but it will require new code.

In short, I am aware of the parsing problems and I appreciate the
status/bug report.  I expect to have everything finished in about a
week.

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: Help! Messing with UI settings.

[Edward K. Ream]

On Thu, Aug 14, 2014 at 9:02 AM, Dufriz  wrote:
> I am on Windows 8.1, running Python 3.3.5 with
> PyQt4-4.10.4-gpl-Py3.3-Qt4.8.5-x64.
> I am using Leo 4.11 final, build 6240.

Thanks for this.  This looks like ancient history, though I might be
mistaken. Recent builds (from git) look like:

Leo 4.11 final, build 6e21a6dc12f0 (branch: master), 2014-08-13 08:30:03

Could you pull down the latest git version?  Alternatively, you could
get a recent daily snapshot?  That way we can all be discussing recent
code.  If you use git you can instantly get any improvements.

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: Help! Messing with UI settings.

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 07:15:58 -0700 (PDT)
Dufriz  wrote:

> BTW, the dark theme which I am trying to modify is the *last* node of
> the myLeoSetting outline.

So in addition to what I just said, it's important that (a) the dark
theme subtree be a descendant of the @settings node in myLeoSettings,
not a sibling, and (b) that there be no other 
`@data qt-gui-plugin-style-sheet` node following the theme subtree,
although you've probably got that covered by making it the last child
of @settings.  I'd delete / disable (@@data) an other `@data
qt-gui-plugin-style-sheet` nodes in @settings just to be sure.

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: Help! Messing with UI settings.

['Terry Brown' via leo-editor]

On Thu, 14 Aug 2014 07:02:52 -0700 (PDT)
Dufriz  wrote:

> I am on Windows 8.1, running Python 3.3.5 with 
> PyQt4-4.10.4-gpl-Py3.3-Qt4.8.5-x64.
> I am using Leo 4.11 final, build 6240.
> 
> I have partially obtained the color combination I was looking for,
> simply by importing Terry's solarized theme which takes care of most
> things. However, this is not to say that I have solved the
> difficulties related to the UI configuration. I am still in the dark
> as to how settings should be properly managed. It's really
> infuriating, especially when you change a setting and for some reason
> it does not take effect.
> 
> For instance, based on Terry's dark (solarized) theme 0, which I am
> trying to modify:
> I am now trying to change the background color of the minibuffer's
> edit line, to make it stand out from the surrounding background
> color. So, I go to the node mini-buffer & status (under stylesheet &
> source) and I edit the background-color parameter, setting it to
> another color (drastically different, so I can easily see if the
> change took place). Then I save and restart Leo, and the change did
> not take effect! (despite having been saved correctly).

Well, if you'd read the instructions, you'd have been able to get
frustrated at a completely different step in the process :-} :-)

The README node in the theme sub trees says:
  
  *IMPORTANT:* to change the stylesheet, edit the Leo tree under the
  `stylesheet & source` node below, not the 
  `@data qt-gui-plugin-style-sheet` node itself.
  
  Then select the `stylesheet & source` node and click the `run-script`
  button. This creates a new `@data qt-gui-plugin-style-sheet` node and
  disables the old one by adding `@@data`.

You got the first part, but not the second.  Unfortunately, when you
`run-script` on `stylesheet & source`, it calls 

   g.expand_css_constants(nd.b)

and this now needs to be changed to

   g.expand_css_constants(c, nd.b)

specifically the code in `stylesheet & source` that reads

  # make the style active
  g.app.gui.frameFactory.masterFrame.setStyleSheet(
  g.expand_css_constants(nd.b))

needs to read
  
  # make the style active
  g.app.gui.frameFactory.masterFrame.setStyleSheet(
  g.expand_css_constants(c, nd.b))
  
With that change in place, clicking run-script or hitting Ctrl-B with
the `stylesheet & source` node active should immediately *compile* and
apply your new settings.

Sorry about all the frustration, and to be fair with it being broken by
the missing "c," thing, maybe you had followed this procedure at one
point and understandably thought it didn't work, on account of it not
working :-/

> I am wondering: is there any other setting which overrides this?!?
> This is a common problem in Leo settings, from what I understand (as
> I encountered it in other settings). The user is likely to mad if he
> has to check and counter-check all these cross-referenced settings!
> 
> Anyway, these are just some the difficulties I am encountering in
> changing the settings.
> I believe a radical restucturing of the way settings are handled, or
> at least presented to the end-user, is really called for here.

I think everyone's in complete agreement with the latter view, the way
this stuff is presented to the user needs changing and there's a
blueprint for what it should look like, it's just a matter of dev.
time.  There are so many things to develop on Leo, not necessarily
deficiencies, that it's hard to know what to pick and I suspect
whatever's top of mind and most interesting seeming gets picked, but
I'll try and get the user interface to UI config. revamp rolling as my
first priority for Leo dev. time.

Cheers -Terry

> There is no point in Leo being totally configurable if the user
> cannot manage to change even the simplest settings like the UI colors!
> 

-- 
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: Help! Messing with UI settings.

[Dufriz]

BTW, the dark theme which I am trying to modify is the *last* node of the 
myLeoSetting outline.

-- 
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: Meaning of "mode prompt"?

[Dufriz]

Sorry, but I was not able to understand your answer.
Above all, what is a "prompt"?

-- 
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: Help! Messing with UI settings.

[Dufriz]

I am on Windows 8.1, running Python 3.3.5 with 
PyQt4-4.10.4-gpl-Py3.3-Qt4.8.5-x64.
I am using Leo 4.11 final, build 6240.

I have partially obtained the color combination I was looking for, simply 
by importing Terry's solarized theme which takes care of most things. 
However, this is not to say that I have solved the difficulties related to 
the UI configuration. I am still in the dark as to how settings should be 
properly managed. It's really infuriating, especially when you change a 
setting and for some reason it does not take effect.

For instance, based on Terry's dark (solarized) theme 0, which I am trying 
to modify:
I am now trying to change the background color of the minibuffer's edit 
line, to make it stand out from the surrounding background color. So, I go 
to the node mini-buffer & status (under stylesheet & source) and I edit the 
background-color parameter, setting it to another color (drastically 
different, so I can easily see if the change took place). Then I save and 
restart Leo, and the change did not take effect! (despite having been saved 
correctly).
I am wondering: is there any other setting which overrides this?!?
This is a common problem in Leo settings, from what I understand (as I 
encountered it in other settings). The user is likely to mad if he has to 
check and counter-check all these cross-referenced settings!

Anyway, these are just some the difficulties I am encountering in changing 
the settings.
I believe a radical restucturing of the way settings are handled, or at 
least presented to the end-user, is really called for here.
There is no point in Leo being totally configurable if the user cannot 
manage to change even the simplest settings like the UI colors!

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

vim bindings reports

[Kent Tenney]

Starting a new thread

>> in vim :r pastes a copy of the current file at the cursor

>I didn't know that.  It will be easy to do once the solution referred
>to in this morning's post is in place.  See the P.P.S in that post.

Maybe some confusion: requiring the  is a big problem,
requires learning the 3rd set of bindings.

status report:

- 'V' should provide line mode visual, it inserts a 'V' at cursor
- 'v' starts visual character mode, 'y' should end visual mode and yank, 'y'
 is ignored until another 'v'
- aliasing  to 'i' is confusing, in vim it advances cursor to next line
- 'x' is backspace in Leo, delete in vim

- '/' and '?' look good, with 'n' going to next find

wish list:

- :s /text/replace with this/

-- 
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: Meaning of "mode prompt"?

[Edward K. Ream]

On Wed, Aug 13, 2014 at 10:47 AM, Dufriz  wrote:

> I am still going through the Leo documentation, so bear with me.
> Could you please explain to me the meaning of a mode "prompt", as in the
> following:
>
> - If the @mode headline contains ::, everything following the :: is the
>   mode prompt. For example::
>
> @mode abc :: xyz
>
> creates the enter-abc-mode command, but the prompt for the command is xyz.
>
> What is meant by "prompt" here?

When Leo is in a mode create by an @mode prompt, Leo can (optionally,
iirc) show keys valid in the mode in a tab in the log pane.  The
prompt appears somewhere (don't remember where) either as the first
lines of the tab's text area, or in the tab's name itself.

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: Vim emulation: ready for testing!

[Edward K. Ream]

On Thu, Aug 14, 2014 at 6:44 AM, Steve Zatz  wrote:

> I am typing a colon -- meaning I am typing Shift and the key that contains
> the colon and semi-colon. For whatever reason, the log file message
> references semi-colon and appears to be missing the fact that the shift key
> is pressed.  If I am insert mode, I get the expected colon.  And since I can
> type any cap character, I don't think it's my shift key.

Very interesting.

> I have just tried completely commenting out the @settings in the global
> leosettings, which, as an aside is pretty interesting to see Leo with
> absolutely no  settings active.  Alas, the problem continues.

I wouldn't be so sure.

Leo will report when it reads a settings file, both in the console
window and in the log pane of the first-loaded file.  Are you *sure*
that no settings files are active?

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: Help! Messing with UI settings.

[Edward K. Ream]

On Wed, Aug 13, 2014 at 12:45 PM, Dufriz  wrote:
> Leo's convoluted settings system is really trying my patience.

I'm sorry you are having problems.  I can relate :-)

First, what version of Leo are you using, and what platform are you on?

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: :r and :tabnew and file-open-by-name now have file-name completion

[Edward K. Ream]

On Wed, Aug 13, 2014 at 5:02 PM, 'Terry Brown' via leo-editor
 wrote:
> On Wed, 13 Aug 2014 14:31:21 -0700 (PDT)
> "Edward K. Ream"  wrote:

> It would be great to be able to type things like:
>
> d = 
> read.csv("/mnt/usr1/usr1/home/tbrown/Proj/NPC/DLP-WSU-SSU/plots/wlsystem/splits.csv")
>
> with the help of filename completion.  So not actually accessing the
> file, just typing its name.

Great idea.  Let's see if I can code it right now...

k.getFileName now takes a callback argument, a function to be called
when the file name is completed. The callback takes a single argument,
the completed file name.

The following @command node works, invoked using the shortcut or from
the minibuffer:

@command insert-file-name @key=Alt-8

w = g.app.gui.get_focus()
w_name = g.app.gui.widget_name(w)
if w_name == 'richTextEdit':
w = c.frame.body
elif w_name.startswith('head'):
w = w.wrapper
else:
w = None
if w:
def callback(arg,w=w):
i = w.getInsertPoint()
w.insert(i,arg)
# Undo only if we are in the body.
if w_name == 'richTextEdit':
c.frame.body.onBodyChanged(undoType='Typing')
# oldSel=None,oldText=None,oldYview=None)
c.k.getFileName(callback=callback)
else:
g.es('not a text widget',w_name)

I'll make this an official Leo command today.

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: Vim emulation: ready for testing!

[Steve Zatz]

Edward,

Thanks much for taking another look at this.  I have continued to try to
track down the issue.

I am typing a colon -- meaning I am typing Shift and the key that contains
the colon and semi-colon. For whatever reason, the log file message
references semi-colon and appears to be missing the fact that the shift key
is pressed.  If I am insert mode, I get the expected colon.  And since I
can type any cap character, I don't think it's my shift key.

I have just tried completely commenting out the @settings in the global
leosettings, which, as an aside is pretty interesting to see Leo with
absolutely no  settings active.  Alas, the problem continues.

I am willing to bet 50 cents that there is actually some  global setting
that is necessary for a colon to place you in command mode although that's
easy for you to test -- just remove all your global settings and only have
vim-mode = True in personal settings and see what happens.  Separately,
I'll try to find another computer to see if there is ghost somewhere in my
current machine.

Again, thanks for taking another look at this.  Leo is invaluable but
shifting back and forth between different editing frameworks is frustrating
and if I could use vim-style bindings it would be a major advance.

Steve


On Thu, Aug 14, 2014 at 7:13 AM, Edward K. Ream  wrote:

> On Wed, Aug 13, 2014 at 8:33 PM, Steve Zatz  wrote:
> >>  recommend looking at the output of the print-bindings and
> print-settings
> >> commands
> > Here are the key bindings.  Not sure what I am looking for but nothing
> > stands out as being in conflict with responding to a ":" in normal mode.
>
> Thanks for this.
>
> My apologies for the problems you are having.  I'm sure it's frustrating.
>
> This is a strange one.  Let's do some sleuthing right now.
>
> The message about ignoring ":" in normal mode is coming from the
> vc.ignore method. I see from an earlier post that the statement
> g.trace(g.callers()) in vc.ignore yields:
>
> ignore masterKeyHandler,do_key,do_normal_mode,do_state
>
> vc.do_normal mode is just::
>
> def do_normal_mode(vc):
> vc.do_state(vc.normal_mode_dispatch_d,'normal')
>
> That is as expected.  Looking at the code for do_state, we see the
> following, slightly edited::
>
> func = d.get(vc.stroke)
> if func:
> func()
> elif vc.is_plain_key(vc.stroke):
> vc.ignore()
> else:
> vc.delegate()
>
> For vc.ignore to be called, both of the following must be true:
>
> 1. vc.stroke is not in vc.normal_mode_dispatch_d
> (the dict passed to vc.do_state by do_normal_mode)
>
> 2. vc.is_plain_key(vc.stroke) is True.
>
> But 'colon' *is* in the vc.normal_mode_dispatch_d!
>
> Whoa!  I went back an re-read your original message.  It is::
>
> ignoring semicolon in normal mode
>
> Oops.  You must type a colon, not a semicolon.  If your eyes are
> anywhere as old as mine, it's easy to confuse ':' and ';'.
>
> I should have picked up on the "ignoring semicolon" message much
> earlier.  Again, my apologies.  Here's hoping all is well now.
>
> 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: Vim emulation: ready for testing!

[Edward K. Ream]

On Wed, Aug 13, 2014 at 8:33 PM, Steve Zatz  wrote:
>>  recommend looking at the output of the print-bindings and print-settings
>> commands
> Here are the key bindings.  Not sure what I am looking for but nothing
> stands out as being in conflict with responding to a ":" in normal mode.

Thanks for this.

My apologies for the problems you are having.  I'm sure it's frustrating.

This is a strange one.  Let's do some sleuthing right now.

The message about ignoring ":" in normal mode is coming from the
vc.ignore method. I see from an earlier post that the statement
g.trace(g.callers()) in vc.ignore yields:

ignore masterKeyHandler,do_key,do_normal_mode,do_state

vc.do_normal mode is just::

def do_normal_mode(vc):
vc.do_state(vc.normal_mode_dispatch_d,'normal')

That is as expected.  Looking at the code for do_state, we see the
following, slightly edited::

func = d.get(vc.stroke)
if func:
func()
elif vc.is_plain_key(vc.stroke):
vc.ignore()
else:
vc.delegate()

For vc.ignore to be called, both of the following must be true:

1. vc.stroke is not in vc.normal_mode_dispatch_d
(the dict passed to vc.do_state by do_normal_mode)

2. vc.is_plain_key(vc.stroke) is True.

But 'colon' *is* in the vc.normal_mode_dispatch_d!

Whoa!  I went back an re-read your original message.  It is::

ignoring semicolon in normal mode

Oops.  You must type a colon, not a semicolon.  If your eyes are
anywhere as old as mine, it's easy to confuse ':' and ';'.

I should have picked up on the "ignoring semicolon" message much
earlier.  Again, my apologies.  Here's hoping all is well now.

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: Leo and Org-Mode

[Edward K. Ream]

On Wed, Aug 13, 2014 at 7:21 PM, Christoph  wrote:
> Hi,
>
> Today I managed to import, modify and write within Leo an org-mode file I
> had previously created with Emacs. I must say that I'm impressed. Great
> work!

Thanks.
>
> When importing an org-mode file the @auto-org-mode directive does not get
> inserted automatically. However, without having it, the original
> org-mode-file is written in a way that makes it unusable for Emacs. So one
> has to insert @auto-org-mode by hand. I assume there is a reason for that
> but for the moment I don't understand why.

Sure there's a reason: it's a bug :-)  I'll see if I can fix it today.

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.

Leo and Org-Mode

[Christoph]

Hi,

Today I managed to import, modify and write within Leo an org-mode file 
I had previously created with Emacs. I must say that I'm impressed. 
Great work!


When importing an org-mode file the @auto-org-mode directive does not 
get inserted automatically. However, without having it, the original 
org-mode-file is written in a way that makes it unusable for Emacs. So 
one has to insert @auto-org-mode by hand. I assume there is a reason for 
that but for the moment I don't understand why. Wouldn't it be more 
convenient? After all when importing the org-mode file Leo automatically 
recognizes that it is an org-mode file. So why not acknowledging that 
fact by inserting an @auto directive. (Sorry, if the answer is obvious, 
I just have begun to experiment with Leo). Thanks in advance.


Kind regards

Christoph


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