Re: render rst's toctree directive

[Edward K. Ream]

On Wed, Jul 11, 2018 at 5:04 AM, Jeremy Chen  wrote:

> Hi,
>
> I wonder if it's possible to render toctree when using rst preview.
>

My apologies for the delay in responding.

The answer is "no".  The toctree directive is for Sphinx, not docutils.
There are no plans to change this.

The toctree directive appears in LeoDocs.leo in several places, but this
issue is not serious, at least in LeoDocs.leo.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: curly quotes

[Edward K. Ream]

On Tue, Jul 17, 2018 at 12:54 PM, Jeff Filipovits 
wrote:

> I am a lawyer and would like to use Leo to keep track of research and
> potentially assist in writing briefs. This is a relatively petty thing, but
> it is driving me crazy. Is there a way to get Leo use curly (single and
> double) quotes?
>

#949  is an
enhancement requesting so-called smart quotes.  It will happen for the next
release.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: curly quotes

[Edward K. Ream]

On Monday, August 6, 2018 at 4:51:51 AM UTC-5, Edward K. Ream wrote:
>
>
> On Tue, Jul 17, 2018 at 12:54 PM, Jeff Filipovits  
> wrote:
>
>> I am a lawyer and would like to use Leo to keep track of research and 
>> potentially assist in writing briefs. This is a relatively petty thing, but 
>> it is driving me crazy. Is there a way to get Leo use curly (single and 
>> double) quotes? 
>>
>
> #949  is an 
> enhancement requesting so-called smart quotes. 
>

Rev 383f20c completes the work, for now.  Please reopen if improvements are 
desired.

The present code converts a straight quote (single or double) to an opening 
curly quote if the cursor is at the start of a line or if a blank or tab 
precedes the cursor.  Otherwise, the code converts a straight quote (single 
or double) to a closing curly quote.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Reload settings triggers error

[Edward K. Ream]

On Tue, Jul 31, 2018 at 11:26 AM, Chris George  wrote:

> Hi Rob,
>
> See issue #943 as well as #938.
>

These have both been fixed.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Steps to install leo using pip in python 3.5

[Edward K. Ream]

On Tue, Jul 17, 2018 at 9:09 PM, Brian Theado 
wrote:

> I created this issue: https://github.com/leo-editor/leo-editor/issues/944,
> but I didn't see a way to tag it.
>

I've added some tags.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: About unit testing Leo

[Edward K. Ream]

On Fri, Aug 3, 2018 at 10:56 AM, vitalije  wrote:

My initial post on this thread was quite a long one, tackling many things
> at once. So is Edward's reply. I can't discuss ATM every Edward's point but
> I will focus just on the settings and plugins stuff. The other points are
> very well worth discussing but let's skip them for now.
>
> How do you propose to pre-compile these settings?
>
> ...
>


> Last year I showed in a script how it is possible to take all settings
> from c.config and put them in sqlite data base in memory and retrieve any
> setting from this data base.
>
...

Then just whenever we edit any of settings files we just parse settings in
it before saving outline and update value in c.db['config_pickle'].

Ok.  This complicates the shutdown logic in favor of simplifying the
startup logic.  It may be a reasonable approach.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: About unit testing Leo

[Edward K. Ream]

On Fri, Aug 3, 2018 at 10:56 AM, vitalije  wrote:

Plugins can affect the load process.
>>
>> Yes, I know they can. But do they do this?
>

How should I know?  People are free to create their own private plugins for
special purposes. In particular, plugins might want to monkey-patch Leo.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: About unit testing Leo

[Edward K. Ream]

On Fri, Aug 3, 2018 at 10:08 AM, Terry Brown  wrote:

> Re gui layers etc., I've mentioned it before, but I wonder how using
> something like
> https://pythonhosted.org/blinker/
> would work, performance wise.
>

I don't think performance will be an issue.

Imo, something like this is worth pursuing. Otoh, the handlers won't
necessarily be much simplified. The most important handlers are
(over-ridden) onBodyChanged, onHeadChanged and the base-class
LeoTree.select.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

edit-pane-csv separator

[Josef]

To my delight I just found out that leo has since a couple of versions the 
command edit-pane-csv.
This is extremely useful!

My problem is, that I have to deal with many CSV files, which often are 
tab-separated of semicolon separated.

So far I was only able to edit comma-separated files with this command.

Since I also could not find any documentation, I am asking this question 
here:

Is there a way to set the CSV separator?

Ideally it should allow arbitrary separators, but at least commas, tabs and 
semicolons, since these are very common (in Europe, Excel uses a semicolon, 
since the comma is used as decimal separator instead of a dot here).

Now for the "pie in the sky" wishes:

Even better would be to allow also "&" and simultaneously "\\" (two 
backslashes) as separator.
That way LaTeX tables could be more easily edited too.
LaTeX uses "&" as separator and a double backslash at the end of each row,
however there could be additional commands following the double backslash, 
like "\midrule".
The double backslash and anything that follows it, should remain at the end 
of their rows,
even if the last column is moved.
In the case o LaTeX tables, It would be even better if the source code 
would get aligned as well (all the "&"  aligning).

Also, is this command capable of allowing fields with embedded newline 
characters (not just at the end of each record, but inside a string as part 
of the string) ?

- Josef

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

language latex

[Josef]

Currently latex syntax highlighting is activated automatically when reading 
any *.tex file,
however also *.latex, *.sty and *.cls files are LaTeX files.

I would appreciate, if at least *.latex and *.sty files, would 
automatically be recognized as LaTeX. 
One writes rather rarely new document class definitions (*.cls), 
so this is less important and may conflict with some other file type,
but editing *.sty I find rather common.

Also, the colorizer currently only recognizes the common built-in latex 
commands like \section,
but not any newly defined command, like \fooboo.
In general, any backslash followed by any combination of letters (up to the 
first number or special character) should be seen as a command.

It would be too much to ask that every command is properly recognized,
since you can pretty much redefine about everything in LaTeX and even 
invent your own syntax for commands,
but I think it is fairly common to use \newcommand{} and friends to define 
a command,
and any such command should be colored.
Instead of checking for every \newcommand, \renewcommand, \def, 
\DefineRobustCommand, ... (there are a lot of variants and it is possible 
to define your own),
it should suffice to color every backslash followed by any combination of 
letters (up to the first number or special character).

I think this might be a minor change to the exisitig code.
Since I have no time to look into this, I would certainly appreciate if 
someone else volunteers.

- Josef

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: edit-pane-csv separator

[Edward K. Ream]

On Mon, Aug 6, 2018 at 7:46 AM, Josef  wrote:

To my delight I just found out that leo has since a couple of versions the
> command edit-pane-csv.
>


> Is there a way to set the CSV separator?
>

Terry should know.  He wrote the editpane.py plugin.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: language latex

[Edward K. Ream]

On Mon, Aug 6, 2018 at 8:12 AM, Josef  wrote:

I would appreciate, if at least *.latex and *.sty files, would
> automatically be recognized as LaTeX.
>

Does 6d17bb in "devel" do what you want?

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Update re: new model

[Edward K. Ream]

On Saturday, August 4, 2018 at 2:39:26 PM UTC-5, vitalije wrote:

> initialization code should be kept free and clean of any gui calls.

Debatable.

> Either writeFromString must not call gui methods like endEditing, either 
reload_settings, init_env in abbrevCommands must not call writeFromString.

Even more debatable.

> Clearly we should here have two methods:

This crosses the line from debatable to misguided.
 

> def writeFromString(self, root, s, forcePythonSentinels=True, useSentinels
> =True):
> """
> Write a 4.x derived file from a string.
>
> This is at.write specialized for scripting.
> """
> self.c.endEditing()
> # Capture the current headline, but don't change the focus!
> return self._writeFromString(root, forcePythonSentinels, useSentinels)
>
> def _writeFromString(root, forcePythonSentinels, useSentinels):
> at = self; c = self.c
> ... rest of method
>
>
What you are proposing are global constraints on when and where methods are 
called.  To my knowledge, there are *zero* such constraints in Leo.  If 
there are any, then they should be removed.

Leo's guiding architectural principle is: 
*There shall be no global architectural dependencies.*

Scripts, plugins and Leo itself should be able to call c.endEditing() 
anytime, anywhere.  Period.  Even if the call does not actually make a lot 
of sense, c.endEditing should recover gracefully from such "misguided" 
calls.

Typically this involves various guards or other consistency checks.  These 
checks are essential, and they make Leo's code base robust.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

On topic? Guidelines for math writing

[Edward K. Ream]

This page  
contains guidelines for good mathematical writing. Imo, it generalizes 
pretty well to any kind of technical writing.

The first principle, "Know your audience" applies to our recent discussions 
of code refactoring and simplification. There are at least two "audiences" 
for Leo's own code.  The first audience is Leo's devs.  The second, even 
more important audience is "scripting users", that is, writers of 
scripts/plugins.  We always want to minimize the effects of "cleanups" on 
scripting users.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: On topic? Guidelines for math writing

[vitalije]

On Monday, August 6, 2018 at 5:06:11 PM UTC+2, Edward K. Ream wrote:
>
> This page  
> contains guidelines for good mathematical writing. Imo, it generalizes 
> pretty well to any kind of technical writing.
>
>
Great resource. I've bookmarked it.

Vitalije

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Update re: new model

[Terry Brown]

On Mon, Aug 6, 2018 at 9:09 AM Edward K. Ream  wrote:
>
> On Saturday, August 4, 2018 at 2:39:26 PM UTC-5, vitalije wrote:
>
> > initialization code should be kept free and clean of any gui calls.
> Leo's guiding architectural principle is: There shall be no global 
> architectural dependencies.

> Scripts, plugins and Leo itself should be able to call c.endEditing() 
> anytime, anywhere.  Period.  Even if the call does not actually make a lot of 
> sense, c.endEditing should recover gracefully from such "misguided" calls.

I think there are a couple of subtleties here.  (1) try and find
another app. that recognizes (app.) global key commands while editing
in a line edit widget.  I think Leo's behavior in this respect is very
unusual.  E.g. in any app. try editing the find string (Ctrl-F) and
see if Ctrl-S initiates a save when you're in the find line edit
widget.  Usual behavior is that only Ctrl-A/C/X/V/Z work in line edit
widgets.  But, it's really cool being able to type "tss;;" (my
abbreviation for time-stamp-short) in a headline widget and get
201808. It's only because Leo actually allows invoking Save while
editing a line edit widget that c.endEditing() is needed.

(2) I think is a design issue.  It's counter-intuitive that writing a
string to a file should be impacted by GUI state.  Leo doesn't have a
GUI free layer.  If it did things might be broken up differently:
  c.outline.
  c.gui.

Then the debate would be whether c.gui should just be None or absent
in the absence of a gui, so
c.gui.endEditing() would raise AttributeError None has no attribute
endEditing, or whether c.gui, when there is no gui, should
be some clever object that (a) evaluates to None, (b) is callable,
returning None, and (c) returns itself for any attribute access, so
that
c.gui.tree.scrollUp() would silently do nothing instead of raising the
AttributeError.  Basically it comes down to requiring, or not
requiring, the user to do
if c.gui:
  c.gui.endEditing()
(or `c.gui and c.gui.endEditing()`)

Finally I think the idea that Save (or whatever) should capture the
text of a line entry currently being edited is a bit of a toss up.  If
you're taking notes in an outliner kind of way, I guess it makes
sense.  There might be alternate key-handler patterns that avoid the
issue, although there's still the case of background save events etc.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Update re: new model

[Edward K. Ream]

On Mon, Aug 6, 2018 at 1:13 PM, Terry Brown  wrote:

On Mon, Aug 6, 2018 at 9:09 AM Edward K. Ream  wrote:
>
> > Scripts, plugins and Leo itself should be able to call c.endEditing()
> anytime, anywhere.  Period.  Even if the call does not actually make a lot
> of sense, c.endEditing should recover gracefully from such "misguided"
> calls.
>
> I think there are a couple of subtleties here.  (1) try and find
> another app. that recognizes (app.) global key commands while editing
> in a line edit widget.


Some hacks are needed to make this work, but they are localized.  They do,
however, complicate the init code.

>  It's only because Leo actually allows invoking Save while
> editing a line edit widget that c.endEditing() is needed.
>

That may be true, but I don't think this way.  I just want as much as
possible to work regardless of context.

(2) I think is a design issue.  It's counter-intuitive that writing a
> string to a file should be impacted by GUI state.  Leo doesn't have a
> GUI free layer.


I just want classes (and modules) to be as independent as possible.

leoNodes.py is "gui free".  Almost everything else is concerned with the
gui, in one way or another.

The WrapperAPI class defines the abstract interface for used throughout
Leo's core.  This has (several times) allowed us to change the actual gui
without making any substantial changes to Leo's core.  So the WrapperAPI
could be said to be the text's gui layer.  Imo, it has worked well.

> Then the debate would be whether c.gui should just be None or absent
> in the absence of a gui, so
> c.gui.endEditing() would raise AttributeError None has no attribute
> endEditing, or whether c.gui, when there is no gui, should
> be some clever object that (a) evaluates to None, (b) is callable,
> returning None, and (c) returns itself for any attribute access, so
> that
> c.gui.tree.scrollUp() would silently do nothing instead of raising the
> AttributeError.  Basically it comes down to requiring, or not
> requiring, the user to do
> if c.gui:
>   c.gui.endEditing()
> (or `c.gui and c.gui.endEditing()`)
>

That's a lot of work, a lot of infrastructure, a lot of constraints and
extra mental load.  Putting one or more guards in  c.endEditing() avoids
all that bother.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

What's important

[Edward K. Ream]

I'd like to discuss what I think is most important, and why.  The simplest, 
easiest, most general ideas are often the most important.  Complexity 
definitely is not the same as importance.  Let's look at some examples:

*Eliminating caching using super-fast reading*

Vitalije's code essentially in-lined the entire read code. The result was 
almost exactly as fast as recreating the outline from the cache.  So the 
file cache was no longer needed.  Not only did this eliminate the horrid 
caching code, it eliminated a source of confusion for users. No more 
--no-cache option. This is the highlight of this year's work.

*Caching only non-essential attributes*

Leo caches marked and expanded bits, selected node and (maybe) topmost 
visible node.  .leo files no longer contain these data, thereby reducing 
unnecessary diffs.  An important simplification, well worth the work.

*Better tree redrawing*

The present Qt tree redrawing code is extremely slow when many nodes are 
visible.  Happily, however, this does not happen often, especially when Leo 
is configured to automatically collapse nodes that are not in the subtree 
containing c.p.

It would be possible to fix this bug without changing Leo's data model.  
Vitalije may have other ideas.  We'll all evaluate the code when it becomes 
available.  It would be good to fix this bug, but it isn't particularly 
urgent to do so.

*New data model*

The new data model may make tree redraw easier. The new data model is 
advertised to "stabilize" positions, though just how is not yet clear to 
me. This promises to simplify c.deletePositionsInList. I am *most *interested 
in whether the new data model will make it possible to represent huge 
outlines. 

*Refactoring code*

Simplifications are always welcome, provided that they don't become mammoth 
projects.  Simplifications aren't worth doing if they break lots of 
existing scripts or plugins. Leo's overall architecture is sound, whatever 
Leo's code level defects. There are more important issues than reducing 
localized code complexity.  

The LoadManager class contains Leo's init code. Whatever its complexity, it 
works.  Simplifying it must retain *all* existing features, including 
compatibility with plugins. 

*New directions*

This is the most important of all, but it's not completely separate from 
the above.  Surely, eliminating file caching is a new direction for Leo.

The recent discussion about supporting intermixed code and comments is a 
truly new direction. It's been on my mind for a long time, and variations 
have been frequently requested. More independent body widgets would also be 
welcome.

The most important new directions of all involve new environments and new 
ways of collaborating with other tools.  Joe Orr's work is one example.  
Better importers aren't so glamorous, but are still very important.  I look 
forward to seeing what new importer framework Vitalije may create.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: On topic? Guidelines for math writing

[Rob]

That's a great article and highlights something I preach/teach all the 
time; know your audience. I also think there's a third, and significantly 
larger audience of 'users'. Perhaps most of them aren't interested in the 
code base itself, but simply in how Leo works. I count myself as part of 
that audience, despite sometimes wanting to be part of audience #2; just 
don't have the programming 'chops' to get there quickly and easily.

Rob...

On Monday, August 6, 2018 at 11:06:11 AM UTC-4, Edward K. Ream wrote:
>
> This page  
> contains guidelines for good mathematical writing. Imo, it generalizes 
> pretty well to any kind of technical writing.
>
> The first principle, "Know your audience" applies to our recent 
> discussions of code refactoring and simplification. There are at least two 
> "audiences" for Leo's own code.  The first audience is Leo's devs.  The 
> second, even more important audience is "scripting users", that is, writers 
> of scripts/plugins.  We always want to minimize the effects of "cleanups" 
> on scripting users.
>
> 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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: edit-pane-csv separator

[Terry Brown]

On Mon, 6 Aug 2018 05:46:55 -0700 (PDT)
Josef  wrote:

> To my delight I just found out that leo has since a couple of
> versions the command edit-pane-csv. This is extremely useful!
> 
> My problem is, that I have to deal with many CSV files, which often
> are tab-separated of semicolon separated.

Well duh, I can't believe I left that out.  Will add that for 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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Installation on MacOS (10.10)

[matelot]

nobody runs Leo on Mac, really ?

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Update re: new model

[Terry Brown]

On Mon, 6 Aug 2018 14:48:18 -0500
"Edward K. Ream"  wrote:

> > AttributeError.  Basically it comes down to requiring, or not
> > requiring, the user to do
> > if c.gui:
> >   c.gui.endEditing()
> > (or `c.gui and c.gui.endEditing()`)
> > 
> That's a lot of work, a lot of infrastructure, a lot of constraints
> and extra mental load.  Putting one or more guards in  c.endEditing()
> avoids all that bother.

Another way to avoid the surprise of finding GUI involvement in a write
string to file operation would be to make changes to p.h immediate,
like changes to p.b.  So p.h changes as you type in the headline
line-edit, then endEditing() wouldn't be needed.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: About unit testing Leo

[Terry Brown]

On Mon, 6 Aug 2018 07:11:49 -0500
"Edward K. Ream"  wrote:

> On Fri, Aug 3, 2018 at 10:56 AM, vitalije  wrote:
> 
> Plugins can affect the load process.
> >>
> >> Yes, I know they can. But do they do this?
> 
> How should I know?  People are free to create their own private
> plugins for special purposes. In particular, plugins might want to
> monkey-patch Leo.

There may be existing personal plugins that would break if plugins were
loaded after the outline was fully loaded, but then again it's possible
to devise code that breaks in response to any change in Leo, it's
impossible to avoid (particularly with no bright line between API and
internals) - it's certainly happened to me often enough.

I don't think we should say plugin loading time shouldn't be changed to
reduce complexity, although that doesn't mean making such a change is
any kind or priority or that it even needs to happen.

If however there's a major complexity reduction gain to be had, I don't
really see a downside, *because* I can't think of a single outline
manipulation that a plugin couldn't perform *after* the initial outline
load.  Given that plugins acting after initial load can change the
outline in anyway they want, I can't see how there can be a
manipulation that requires plugins to load early in the process.

grep -C4 -ri before-create-leo-frame *

Suggests that before-create-leo-frame is never used in the known
code base, doesn't tell us about plugins monkey patching Leo, but
doesn't throw up any examples of needing to act before outline load
either.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Installation on MacOS (10.10)

[Terry Brown]

On Mon, 6 Aug 2018 19:16:58 -0700 (PDT)
matelot  wrote:

> nobody runs Leo on Mac, really ?

People do, I think Brian's one of them.

Brian's suggestion was the first step to answering the question.  You
appear to have PyQt installed, but it fails to import.  So entering

python

and then

from PyQt5 import QtCore

in the same command line environment you're running Leo in would be
very informative.

For example just now I got:

leo-editor:0> python
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34) 
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyQt5 import QtCore
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named PyQt5

because I only have PyQt5 installed for python3

I notice you list:

pyqt  5.9.2py36h62a_0anaconda
PyQt5 5.11.2

which makes it seem like there might be two versions installed, not
necessarily an issues, but again, `from PyQt5 import QtCore` would be
really interesting.

An aside, when did GCC hit version 7?  Yikes :-}

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Installation on MacOS (10.10)

[matelot]

thanks for the replies folks. Leo is running now:

Leo 5.7.3, build 20180525162844, Fri May 25 16:28:44 CDT 2018
Not running from a git repo
Python 3.6.6, PyQt version 5.9.6
darwin
** isPython3: True
** caching enabled



I simply did an "update-all" and these are the output relevant to Leo & its 
dependencies:
I don't see nothing new from the paste in my original paste. Strange.  
Maybe the error was due to maybe my starting leo in the same cmd session 
right after installing all the stuff 

The following packages will be downloaded:

package|build
---|-
qt-5.9.6   |   h74ce4d9_078.6 MB
sip-4.19.8 |   py36h0a44026_0 252 KB
pyqt-5.9.2 |   py36h62a_0 4.7 MB


The following packages will be UPDATED:

pyqt:5.9.2-py36h62a_0  anaconda --> 5.9.2-py36h62a_0
qt:  5.9.6-h74ce4d9_0  anaconda --> 5.9.6-h74ce4d9_0
scikit-learn:0.19.0-np112py36_0 --> 
0.19.1-py36hffbff8c_0
scipy:   0.19.1-np112py36_0 --> 1.1.0-py36hcaad992_0
sip: 4.19.8-py36h0a44026_0 anaconda --> 
4.19.8-py36h0a44026_0
twisted: 17.5.0-py36_0 anaconda --> 17.5.0-py36_0

Proceed ([y]/n)? y


 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: edit-pane-csv separator

[Terry Brown]

On Mon, 6 Aug 2018 05:46:55 -0700 (PDT)
Josef  wrote:

> Is there a way to set the CSV separator?

I've made a start on this in the csv_delim branch.

It's not finished, because I'm trying to cover the LaTeX table case:

1 & 2 & 3 \\
a & b & c \\

My initial thought was to let the delimiter be a regex, &| in the
above case, but then what do you use to put the delimiters back in, &
or \\?  We know it's & except at the end of the line, but that's LaTeX
specific.

Also allows delimiters like [,;], i.e. , or ; - but again, which do you
use to reconstruct the text?

I think perhaps regex is a bad idea, and I should just extend
edit-pane-csv to allow any set string as a delimiter, and right
edit-pane-latex-table as a special case.

But not tonight.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.