Re: Caution: leoSettings.leo fully parameterized settings

2014-09-17 Thread Zoltan Benedek 
Thanks for the wonderful work.
Now I have only one custom color in myLeoSettings.leo in which I'm 
interested. It is much easier to find/change it.

-- 
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: Caution: leoSettings.leo fully parameterized settings

2014-09-17 Thread Edward K. Ream 
On Wed, Sep 17, 2014 at 3:03 AM, Zoltan Benedek  wrote:
> Thanks for the wonderful work.

You're welcome.

> Now I have only one custom color in myLeoSettings.leo in which I'm
> interested. It is much easier to find/change it.

Glad to hear it.

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: Reloading visual settings

2014-09-17 Thread Edward K. Ream 
On Tue, Sep 16, 2014 at 7:19 PM, 'Terry Brown' via leo-editor
 wrote:
> On Tue, 16 Sep 2014 17:06:11 -0700 (PDT)
> "Edward K. Ream"  wrote:
>
>> Imo, it's time to simplify how themes get specified, but we'll have
>> to discuss this...
>
> A @theme node, perhaps?  :-)

Yes!  Good idea.

I know from reading the old "reload" code that it searched for themes
first, and searched for @data qt-gui-plugin-style-sheet nodes only if
no stylesheet & source node is found.  I would like to avoid such
logic.

Happily now that the @data qt-gui-plugin-style-sheet is fully
parameterized, we should only ever need one copy of it.  The theme
will simply provide all the settings that modify this style sheet.

Themes should use the new style sheet: otherwise there will be *two*
sets of style-sheet-related settings floating around, and that will
really cause confusion. So, imo, themes should be defined in terms of
the new settings (and @value) names, not in terms of old @value names.

Themes could use a new style sheet, say @data
qt-gui-theme-style-sheet, for selectors not found in @data
qt-gui-plugin-style-sheet.  However, I would rather avoid yet another
style sheet if possible.  If @data qt-gui-theme-style-sheet contained
just a few selectors they could be made part of the standard @data
qt-gui-plugin-style-sheet.

My first draft of this reply worried about redundant theme-related
settings, but that's not a big issue because the settings will be
copied to myLeoSettings.leo, *not* leoSettings.leo.

Still, the user will have to take care to remove all existing
gui-related settings when installing a theme.  That should not be too
difficult.  BTW, I don't remember which settings take effect when
there are duplicates--the first or the last.  Either way will cause
troubles for some users--far simpler if they remove any potential
duplicates.

In short, copying an @theme node to myLeoSettings.leo, with all its
inner @color, @font and @string nodes, should be be the first step
when installing a new theme.  If necessary, an install-theme command
would complete the installation, perhaps with an associated button.
Install-theme would search for a *unique* @theme node in the @setting
tree, and refuse to continue if there are several.

These are just my first impressions.  Your comments, please.

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: OT: LMAO: Read these reviews

2014-09-17 Thread Jacob Peck 

Some of my favorites:

http://www.amazon.com/Images-SI-Uranium-Ore/product-reviews/B000796XXM/ref=cm_cr_dp_see_all_summary?ie=UTF8&showViewpoints=1&sortBy=byRankDescending

and

http://www.amazon.com/JL421-Badonkadonk-Land-Cruiser-Tank/product-reviews/B00067F1CE/ref=cm_cr_dp_see_all_summary?ie=UTF8&showViewpoints=1&sortBy=byRankDescending

:p

-->Jake

On 9/16/2014 5:02 PM, Matt Wilkie wrote:

hihohoh! thanks Edward :-)

"The book is too hard to follow, the author randomly shifts from one 
number to another without any prior warning."


indeed.

...in a totally different yet oddly similar line of thought, just 
yesterday someone shared this review with me: 
http://www.amazon.com/Veet-Hair-Removal-Creme-200ml/product-reviews/B000KKNQBK





On Mon, Sep 15, 2014 at 7:55 AM, Edward K. Ream > wrote:



http://www.amazon.com/Million-Random-Digits-Normal-Deviates/product-reviews/0833030477/ref=dpx_acr_txt?showViewpoints=1
-- 
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.


--
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: OPI

2014-09-17 Thread Edward K. Ream 
On Wednesday, September 10, 2014 5:34:02 PM UTC-5, Edward K. Ream wrote:
>
> On Tue, Aug 19, 2014 at 3:24 PM, Segundo Bob  
> wrote: 
>

> When I hit  after selecting "selectPosition," I get the following 
> > error message in the log pane: 
> > 
> > Unexpected exception... 
> > Traceback (most recent call last): 
> >   File "/home/ldi/git/leo-editor/leo/core/leoUndo.py", line 1323, in 
> > setUndoTypingParams 
> > old_start,old_end = oldSel 
> > TypeError: 'NoneType' object is not iterable 
>

I have never been able to reproduce this, but clearly oldSel was None 
during the crash.  A recent rev adds a guard that is supposed to fix this 
problem.  Please let me know if it occurs again.

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: Incorrect text highlighted using Find commands

2014-09-17 Thread Edward K. Ream 
On Thursday, September 11, 2014 9:15:40 PM UTC-5, lewis wrote:

>
> *Open LeoDocs.leo*
> *search for 'sphinx'*
> * Find Next: F3*
> * it highlights sphinx correctly however when it reaches node*
> *LeoDocs.leo#Web pages-->@edit html\conf.py*
>
> *at line 5:*
> *   # sphinx-quickstart on Mon Mar 30 16:39:02 2009.*
> *find now highlights the 'inx-qu'*
>

Fixed (I think) at  d8bfd2c

This another example of the wretched newline problem. @edit nodes preserve 
'\r' characters, and that messes up the counts in the find command.

I don't *think* this will cause problems on the Mac, which uses (sheesh) 
'\r' characters instead of '\n'.  But no guarantees...

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: Reloading visual settings

2014-09-17 Thread 'Terry Brown' via leo-editor 
On Wed, 17 Sep 2014 05:52:59 -0500
"Edward K. Ream"  wrote:

> On Tue, Sep 16, 2014 at 7:19 PM, 'Terry Brown' via leo-editor
>  wrote:
> > On Tue, 16 Sep 2014 17:06:11 -0700 (PDT)
> > "Edward K. Ream"  wrote:
> >
> >> Imo, it's time to simplify how themes get specified, but we'll have
> >> to discuss this...
> >
> > A @theme node, perhaps?  :-)
> 
> Yes!  Good idea.

Yes, more explicit than the current text find.

> I know from reading the old "reload" code that it searched for themes
> first, and searched for @data qt-gui-plugin-style-sheet nodes only if
> no stylesheet & source node is found.  I would like to avoid such
> logic.
> 
> Happily now that the @data qt-gui-plugin-style-sheet is fully
> parameterized, we should only ever need one copy of it.  The theme
> will simply provide all the settings that modify this style sheet.

Theme stylesheets can be vastly different from 
"@data qt-gui-plugin-style-sheet", which I would consider a theme
itself, the "default" theme.  It is impossible to fully cover the range
of possible customization with settings (@values) alone.

> Themes should use the new style sheet: otherwise there will be *two*
> sets of style-sheet-related settings floating around, and that will
> really cause confusion. So, imo, themes should be defined in terms of
> the new settings (and @value) names, not in terms of old @value names.

I think theme designers should try as much as possible to use existing
(i.e. new) @value names, where relevant @value names exist.  Where they
don't, they should be free to invent their own.

Background: the two components of a theme I can think of
that aren't covered by what we've been talking about so far are (a) a
path fragment used to find theme specific icons etc., and (b) a @bool
indicating whether the theme is "dark" or "light", which can be used by
code to make rendering choices.  These are both fairly trivial items.

The "stylesheet & source" machinery was largely to achieve hierarchical
@data nodes, which we have in core now, a major plus, so some of that
complexity is removed.

I could see "settings only" themes, which don't supply a stylesheet,
only some settings, and "settings and stylesheet" themes, which supply
both.

But I'm not sure the distinction between them is very important.
Setting aside, temporarily, issues of theme management and keeping the
user informed, something like this would seem to work quite well to me.

In myLeoSettings.leo, somewhere under @settings, showing only organizer
nodes for the @values nodes, not the @value nodes themselves:

@theme default
@bool theme_is_dark = False
theme settings
font settings
color settings
body colors
tree colors
border settings
@data qt-gui-plugin-style-sheet
@theme greens
theme settings
color settings
body colors
tree colors
@theme dark theme
@bool theme_is_dark = True
@string theme_path = leo_dark_0
theme settings
font settings
color settings
body colors
tree colors
border settings
@data qt-gui-plugin-style-sheet

So the user has the default theme installed, with modifications from
the "greens" color modifying theme, and then they've installed a dark
theme which is probably overriding most of the other two.  I don't see
any problem with this arrangement, apart from keeping the user aware of
what's going on, an perhaps suggesting they move the first two out of
@settings for simplicity.

Out of time, but the rest of your post suggests we're at least facing
in the same direction :-)

Cheers -Terry


> Themes could use a new style sheet, say @data
> qt-gui-theme-style-sheet, for selectors not found in @data
> qt-gui-plugin-style-sheet.  However, I would rather avoid yet another
> style sheet if possible.  If @data qt-gui-theme-style-sheet contained
> just a few selectors they could be made part of the standard @data
> qt-gui-plugin-style-sheet.
> 
> My first draft of this reply worried about redundant theme-related
> settings, but that's not a big issue because the settings will be
> copied to myLeoSettings.leo, *not* leoSettings.leo.
> 
> Still, the user will have to take care to remove all existing
> gui-related settings when installing a theme.  That should not be too
> difficult.  BTW, I don't remember which settings take effect when
> there are duplicates--the first or the last.  Either way will cause
> troubles for some users--far simpler if they remove any potential
> duplicates.
> 
> In short, copying an @theme node to myLeoSettings.leo, with all its
> inner @color, @font and @string nodes, should be be the first step
> when installing a new theme.  If necessary, an install-theme command
> would complete the installation, perhaps with an associated button.
> Install-theme would search for a *unique* @theme node in the @setting
> tree, and refuse to continue if there are several.
> 
> These are just my first impressions.  Your c

Re: Reloading visual settings

2014-09-17 Thread Edward K. Ream 
On Wed, Sep 17, 2014 at 12:07 PM, 'Terry Brown' via leo-editor
 wrote:

To start with your last comment:

> the rest of your post suggests we're at least facing in the same direction :-)

I agree.  We are making excellent progress.

> Theme stylesheets can be vastly different from @data 
> qt-gui-plugin-style-sheet.

Ok.

> I think theme designers should try as much as possible to use existing
> (i.e. new) @value names, where relevant @value names exist.  Where they
> don't, they should be free to invent their own.

Yes.

> Background: the two components of a theme I can think of
> that aren't covered by what we've been talking about so far are (a) a
> path fragment used to find theme specific icons etc., and (b) a @bool
> indicating whether the theme is "dark" or "light", which can be used by
> code to make rendering choices.  These are both fairly trivial items.

Yes.

> The "stylesheet & source" machinery was largely to achieve hierarchical
> @data nodes, which we have in core now, a major plus, so some of that
> complexity is removed.

Oh good.

> In myLeoSettings.leo, somewhere under @settings, showing only organizer
> nodes for the @values nodes, not the @value nodes themselves:
>
> @theme default
> @bool theme_is_dark = False
> theme settings
> font settings
> color settings
> body colors
> tree colors
> border settings
> @data qt-gui-plugin-style-sheet
> @theme greens
> theme settings
> color settings
> body colors
> tree colors
> @theme dark theme
> @bool theme_is_dark = True
> @string theme_path = leo_dark_0
> theme settings
> font settings
> color settings
> body colors
> tree colors
> border settings
> @data qt-gui-plugin-style-sheet

This seems like a natural organization.

However, many settings are duplicated. At present, Leo can't honor
such duplicate settings.  I'll talk about possible solutions below.

> So the user has the default theme installed, with modifications from
> the "greens" color modifying theme, and then they've installed a dark
> theme which is probably overriding most of the other two.  I don't see
> any problem with this arrangement, apart from keeping the user aware of
> what's going on, an perhaps suggesting they move the first two out of
> @settings for simplicity.

How about a "global" setting that would specify which theme/themes, if
any, to use.  Something like @data themes, where the body lists the
themes in which their stylesheets are concatenated.  This instantly
will provide safety and flexibility.

There are at least two solutions to the problem of duplicate settings
in different @theme trees:

1. Namespaces for settings.  This would be neat, but it seems like an
heroic solution.  It would not be easy to do, imo.

2. Scripts (config methods), much like the script in the 'stylesheet &
source' node.  Here is my present thinking.

Suppose, first of all, that Leo's config code initially ignores @theme
(singular) trees.  This does away with duplicates.  Heh, heh.

Next, when the configuration code finds the (presumably unique)
@themes (plural) node, a new config method, say config.create_theme,
would do the following:

1. Find all the @theme trees mentioned in the the body of the @themes node.

I see no particular reason to require that all @theme trees be
children of the @themes node, though that wouldn't be an odious
requirement...

2. For each @theme tree, config.create_theme would a) parse all the
"inner" settings in the @theme tree and b) create an **internal theme
stylesheet**

3. Create the final themes stylesheet by concatenating all internal
theme stylesheets.

To summarize, @theme nodes present special challenges because Leo
lacks settings namespaces.  As a workaround, Leo's config code could
ignore  @theme trees, while a new create_theme method would compose a
theme stylesheet by processing all the nodes mentioned in the body of
an @themes node.

These are just first thoughts, but they show the problem is tractable,
following the ideas behind your theme-creating script.

Your comments?

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: Delayed loading of large nodes

2014-09-17 Thread Edward K. Ream 
On Sunday, September 7, 2014 3:00:00 PM UTC-5, Edward K. Ream wrote:

> Rev 6adccac now corrects some problems with the button code. I consider 
this alpha code.  The code is disabled by default.

The code is still alpha-quality, but I have just enabled it.  It's time to 
test it before releasing 5.0 a1.

Here is the checkin log for 63578c0:

QQQ
Enabled "big-text" buttons.  These buttons appear in the body pane when the 
body text exceeds the limit given by the @int max-pre-loaded-body-chars

To disable these buttons, set @int max-pre-loaded-body-chars to zero.

Leo build: 20140917142108
QQQ

Please report any problems immediately.

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: Delayed loading of large nodes

2014-09-17 Thread Fidel N 
it works great here, thanks for this Edward

With the update, also noticed the big blue square surrounding the selected
widget, its also great. Those things improve usability big time IMO :D

On Wed, Sep 17, 2014 at 9:26 PM, Edward K. Ream  wrote:

> On Sunday, September 7, 2014 3:00:00 PM UTC-5, Edward K. Ream wrote:
>
> > Rev 6adccac now corrects some problems with the button code. I consider
> this alpha code.  The code is disabled by default.
>
> The code is still alpha-quality, but I have just enabled it.  It's time to
> test it before releasing 5.0 a1.
>
> Here is the checkin log for 63578c0:
>
> QQQ
> Enabled "big-text" buttons.  These buttons appear in the body pane when
> the body text exceeds the limit given by the @int max-pre-loaded-body-chars
>
> To disable these buttons, set @int max-pre-loaded-body-chars to zero.
>
> Leo build: 20140917142108
> QQQ
>
> Please report any problems immediately.
>
> 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: Incorrect text highlighted using Find commands

2014-09-17 Thread Edward K. Ream 


On Thursday, September 11, 2014 9:15:40 PM UTC-5, lewis wrote:
>
> Hi Edward,
>
> Terry has fixed the todo.py issue..
> The original query remains on the latest commit 3b3cc8bfc629.
>
> *Open LeoDocs.leo*
> *search for 'sphinx'*
> * Find Next: F3*
> * it highlights sphinx correctly however when it reaches node*
> *LeoDocs.leo#Web pages-->@edit html\conf.py*
>
> *at line 5:*
> *   # sphinx-quickstart on Mon Mar 30 16:39:02 2009.*
> *find now highlights the 'inx-qu'*
>

Are you running on Windows?  Stripping '\r' worries me greatly on the Mac.

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.

launchLeo failed

2014-09-17 Thread F.S. 
Well this is the first time I am running the files from git repo. In the 
past this was never a problem. But now I got the following message from the 
github downloaded version:

Traceback (most recent call last):
  File "launchLeo.py", line 8, in 
leo.core.runLeo.run()
  File "c:\Users\h\proj\pkgs\leo-editor\leo\core\runLeo.py", line 81, in ru
n
g.app.loadManager.load(fileName,pymacs)
  File "c:\Users\h\proj\pkgs\leo-editor\leo\core\leoApp.py", line 1944, in
load
lm.doPrePluginsInit(fileName,pymacs)
  File "c:\Users\h\proj\pkgs\leo-editor\leo\core\leoApp.py", line 1988, in
doPrePluginsInit
lm.readGlobalSettingsFiles()
  File "c:\Users\h\proj\pkgs\leo-editor\leo\core\leoApp.py", line 1912, in
readGlobalSettingsFiles
g.app.forgetOpenFile(c.fileName())
AttributeError: 'NoneType' object has no attribute 'fileName'

Appreciate any 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: launchLeo failed

2014-09-17 Thread F.S. 
I should add that this was an installation on a new computer and I don't 
have a global settings file.

On Wednesday, September 17, 2014 7:01:58 PM UTC-7, F.S. wrote:
>
> Well this is the first time I am running the files from git repo. In the 
> past this was never a problem. But now I got the following message from the 
> github downloaded version:
>
> Traceback (most recent call last):
>   File "launchLeo.py", line 8, in 
> leo.core.runLeo.run()
>   File "c:\Users\h\proj\pkgs\leo-editor\leo\core\runLeo.py", line 81, in ru
> n
> g.app.loadManager.load(fileName,pymacs)
>   File "c:\Users\h\proj\pkgs\leo-editor\leo\core\leoApp.py", line 1944, in
> load
> lm.doPrePluginsInit(fileName,pymacs)
>   File "c:\Users\h\proj\pkgs\leo-editor\leo\core\leoApp.py", line 1988, in
> doPrePluginsInit
> lm.readGlobalSettingsFiles()
>   File "c:\Users\h\proj\pkgs\leo-editor\leo\core\leoApp.py", line 1912, in
> readGlobalSettingsFiles
> g.app.forgetOpenFile(c.fileName())
> AttributeError: 'NoneType' object has no attribute 'fileName'
>
> Appreciate any 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.