Re: Travis tests still failling on devel and gutter

[Matt Wilkie]

"fatal: No names found, cannot describe anything" is from executing `git
describe --tags` in a shallow clone that isn't deep enough to include a
tagged commit. Fixed in travis.yml by increasing the clone depth from
default of 50 to 100 with commit 4d7e814
.
Note added to LeoDist.

In the next commit: setup reverts to Leo internal version if git version
number fails to parse (i.e. same behaviour as when not in a git clone).

Matt

-- 
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: Dreaming big dreams

['tfer' via leo-editor]

I'm glad this came up, I was going to say something on this under the 
title: "Leo, an embarrassment of riches that are too well hidden."

I was involved in another editor in the past, in it we followed another 
convention for documentation.  Say you added support for another language, 
well, along with the plugin to support it, you created a file to talk about 
its features and demonstrate them.  This file was a "live document", for 
example, it would talk about a certain type of completion it added, then 
have a code block that once you entered enabled the language-mode, let you 
jump to point where there was a hint that could completed, and let you hit 
the tab to try out the completion.  Note that these demo-files where opened 
from templates so you weren't making changes to them when you explored them.

So to generalize this, I'm suggesting that there be an Examples directory 
in the distribution, where any file in it or a sub directory of it is 
treated as such a template.  It would contain live documents for plugins, 
workflows, debugging demos, design notes, generic add a language demo, unit 
test demo, todo plugin demo, etc.

So, now the Leo supports Jupyter notebooks, I imagine a lot of this stuff 
will use that format, but I don't know, because I've never tried that in 
Leo, there aren't any examples. :-)

Tom

-- 
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: Dreaming big dreams

[Zoom.Quiet]

 于2018年10月11日周四 上午7:01写道：
>

>
> I recently went through all the settings in Leo, and wow, there's quite a bit 
> of good stuff there. How much of that is in the docs? Had I not decided to 
> look at *all* the settings, I would not have discovered many of them. I'd 
> like a page that lists all the settings, with descriptions. Many @settings 
> nodes have descriptions, and many others do not, so I have little idea as to 
> what they do. Part of the documentation effort should be to put a good 
> description of each one. Is Leo "aware" of all its settings? Is it not 
> possible then to have a script that will generate documentation for all Leo's 
> settings as an HTML (or part of the docs' rst) - and make sure this is on the 
> web site. Trust me, it would make Leo a lot more useable if people had a page 
> where they could see all the settings and just search for what they want.
>

Sayeahooo... me 2,
but doc and code, is different mind working, code good not means doc. good,
so, i agree MyLeoSettings.leo style:
- self explain
- explain on the spot
- of course: no need explain is best ~ need the naming skill for every
setup item or variable name ...


> I want to add support for a new language (syntax highlighting, etc). How well 
> is this documented? Does it just say to look at the source code?
>
> Are all the default keybindings documented?
>
> Leo is almost tragic in how powerful it is, and how much its adoption is held 
> back by poor documentation. Good documentation will be a major endeavour, but 
> well worth it.
>

Yes, i meet same problems,
but the reason is simple:
- Leo release so many years, but the core developer always only EKR
- so means more and more knowledge for EKR as natural truth, not need explain
- and servicing big document.leo project is not funny and tired...

so how to fix it? anlifer is right:
- for EKR, just augment all docstrings in every source code
- for Leo community, need running one document team, build friendly
document for Leo

of course...the 2nd way, need EKR inti.


> On Wednesday, October 10, 2018 at 12:10:38 PM UTC-7, Edward K. Ream wrote:
>>
>> On Wed, Oct 10, 2018 at 1:22 PM  wrote:
>>
>> > My dream is that the documents be vastly improved.
>>
>> Please tell me what you think should be added to CheatSheet.leo, or to the 
>> tutorials.
>>
>> Typing completion in the minibuffer is a good way to discover commands.
>>
>> After that, leoPyRef.leo contains all the answers.
>>
>> 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.



-- 
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!

-- 
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: Dreaming big dreams

[anlifer]

Below are some random examples. It's hard for me to give you a fuller 
answer as I now do know some Leo and so I'm less confused when I read the 
docs - so I can't easily point out problems.

In the main tutorial page, the script in Accessing Outline Data doesn't 
work - it's missing a parenthesis.

It's not clear to me how to even run the script. I happen to know Ctrl-B, 
but is it in the tutorial? I took the script and put it in a @button node, 
and the button didn't show up. I'm not sure if something is wrong with my 
Leo or the docs. It may be obvious, but it would be nice for that code 
snippet to have @language python. 

In the scripting tutorial, it would be nice if it pointed out that .h and 
.b refer to the headline and body. I know most will figure it out, but I 
think it should be spelled out explicitly.

Will any command I create that manipulates texts/nodes automatically be 
undo-able? If not, what do I need to do to ensure it is?

A lot of stuff in the cheat sheet with regards to scripting is just a list 
with no explanation. Asking people to look at the source code to figure it 
out is not documenting anything. If all these classes/functions had good 
docstrings, one could autogenerate the docs using a script. 

What is an ivar?

I could not get unit testing to work in a way that is useful for me (see my 
other email on the mailing list). 

The Miscellany of Scripts page used to have scripts that didn't work. I 
think the ones I complained about may have been fixed. In general, though, 
I think all the scripting docs are disorganized. Some of it is in one page, 
some in another, with no clear structure. I have to keep going to various 
pages and hitting Ctrl-F.

The commands reference page mentions macros. Do they work? Last time I 
tried they did not. That page mentions Emacs behavior commands like kill 
and yank. Yet yank does *not* behave like it does in Emacs. In Emacs, if 
you yank, and then yank again, it will replace the region. Here it keeps 
appending. 

How do I comment and uncomment multiple lines? Is that documented?

I recently went through all the settings in Leo, and wow, there's quite a 
bit of good stuff there. How much of that is in the docs? Had I not decided 
to look at *all* the settings, I would not have discovered many of them. 
I'd like a page that lists all the settings, with descriptions. Many 
@settings nodes have descriptions, and many others do not, so I have little 
idea as to what they do. Part of the documentation effort should be to put 
a good description of each one. Is Leo "aware" of all its settings? Is it 
not possible then to have a script that will generate documentation for all 
Leo's settings as an HTML (or part of the docs' rst) - and make sure this 
is on the web site. Trust me, it would make Leo a lot more useable if 
people had a page where they could see all the settings and just search for 
what they want.

Oh, and some settings appear to be "fake" - as in they are in the settings 
file, but when I do a cff in the code base all references to those settings 
are commented out. Staleness is a common problem. I would even argue that 
there should be a script to ensure that all the settings in @settings 
actually ARE settings. And in the other direction, if Leo has a setting, 
ensure it exists in the main settings file.

We have various directives. Can I create my own? This may well be 
documented, but I don't know if it is.

Quite a lot of functions in the code base have no docstring. And the code 
is not that easy to read as so many variables are short single letter 
variables. I think good docstrings on functions would help a lot.

I want to add support for a new language (syntax highlighting, etc). How 
well is this documented? Does it just say to look at the source code?

Are all the default keybindings documented? 

Leo is almost tragic in how powerful it is, and how much its adoption is 
held back by poor documentation. Good documentation will be a major 
endeavour, but well worth it.

On Wednesday, October 10, 2018 at 12:10:38 PM UTC-7, Edward K. Ream wrote:

> On Wed, Oct 10, 2018 at 1:22 PM > wrote:
>
> > My dream is that the documents be vastly improved. 
>
> Please tell me what you think should be added to CheatSheet.leo, or to the 
> tutorials.
>
> Typing completion in the minibuffer is a good way to discover commands.
>
> After that, leoPyRef.leo contains all the answers.
>
> 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: Travis tests still failling on devel and gutter

[Matt Wilkie]

> Recent revs have fixed all Leo-related problems.  Now there is a setup.py 
> problem:
> [...]
>  File "/home/travis/build/leo-editor/leo-editor/leo/core/leoGlobals.py", 
> line 4890, in gitDescribe
>  tag, distance, commit = describe[0].rsplit('-',2)
> IndexError: list index out of range
>
> Matt, I think this is for you.
>

I've encountered and fixed it before, I thought. It came up when there is 
no git history to reference for the version number. It's supposed to fall 
back gracefully. I'll look again!

Matt

-- 
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: Dreaming big dreams

[Edward K. Ream]

On Wed, Oct 10, 2018 at 1:22 PM  wrote:

> My dream is that the documents be vastly improved.

Please tell me what you think should be added to CheatSheet.leo, or to the
tutorials.

Typing completion in the minibuffer is a good way to discover commands.

After that, leoPyRef.leo contains all the answers.

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: Dreaming big dreams

[Kent Tenney]

I expect Emacs is of comparable complexity,how does
it offer such good documentation?

On Wed, Oct 10, 2018 at 1:22 PM  wrote:

> I came to Leo because I wanted a programmable text editor that I can
> program in Python. I am an Emacs user who did not want to learn Emacs Lisp.
>
> My dream is that the documents be vastly improved. As it is, when it comes
> to scripting in Leo so I can customize my experience, the docs are no help.
> I have to ask what I want here or Github. I often find my answers in the
> archives of this list instead of the docs. While the community is very
> helpful, it is really no substitute to better documentation. Code snippets
> often don't work, and the docs refer to features that don't exist, etc.
>
> My dream is that Leo becomes as powerful as Emacs, and that people keep
> producing useful "Leo packages" with Python just as you see in Emacs.
>
> While I still attempt to use Leo, I've mostly resigned myself to learning
> Emacs Lisp. Sadly, it is now easier for me to learn Emacs lisp than to
> figure out how to customize Leo with Python.
>
>
> --
> 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.
>

-- 
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: Dreaming big dreams

[anlifer]

I came to Leo because I wanted a programmable text editor that I can 
program in Python. I am an Emacs user who did not want to learn Emacs Lisp.

My dream is that the documents be vastly improved. As it is, when it comes 
to scripting in Leo so I can customize my experience, the docs are no help. 
I have to ask what I want here or Github. I often find my answers in the 
archives of this list instead of the docs. While the community is very 
helpful, it is really no substitute to better documentation. Code snippets 
often don't work, and the docs refer to features that don't exist, etc.

My dream is that Leo becomes as powerful as Emacs, and that people keep 
producing useful "Leo packages" with Python just as you see in Emacs.

While I still attempt to use Leo, I've mostly resigned myself to learning 
Emacs Lisp. Sadly, it is now easier for me to learn Emacs lisp than to 
figure out how to customize Leo with Python.


-- 
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: Travis tests still failling on devel and gutter

[Edward K. Ream]

On Wednesday, October 10, 2018 at 6:32:54 AM UTC-5, Edward K. Ream wrote:

> "@test event classes" is failing because QtCore hasn't been imported 
correctly:

Recent revs have fixed all Leo-related problems.  Now there is a setup.py 
problem:

$ python setup.py bdist_wheel | grep -v -e '^adding' -e '^copying'
fatal: No names found, cannot describe anything.
Traceback (most recent call last):
 File "setup.py", line 150, in 

Removing build, dist and egg directories
 version=get_version(__file__),
 File "setup.py", line 31, in get_version
 version = git_version(file)
 File "setup.py", line 43, in git_version
 tag, distance, commit = g.gitDescribe(root)
 File "/home/travis/build/leo-editor/leo-editor/leo/core/leoGlobals.py", 
line 4890, in gitDescribe
 tag, distance, commit = describe[0].rsplit('-',2)
IndexError: list index out of range

Matt, I think this is for you.

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.

Travis tests still failling on devel and gutter

[Edward K. Ream]

"@test event classes" is failing because QtCore hasn't been imported 
correctly:

==
ERROR: runTest (leo.core.leoTest.GeneralTestCase)
@test event classes

Traceback (most recent call last):
 File "/home/travis/build/leo-editor/leo-editor/leo/core/leoTest.py", line 
198, in runTest
 builtins.execfile(scriptFile, d)
 File "/home/travis/.leo/scriptFile.py", line 5, in 
 import leo.plugins.qt_frame as qt_frame # EventWrapper
 File "/home/travis/build/leo-editor/leo-editor/leo/plugins/qt_frame.py", 
line 16, in 
 import leo.plugins.qt_events as qt_events
 File "/home/travis/build/leo-editor/leo-editor/leo/plugins/qt_events.py", 
line 46, in 
 class LeoQtEventFilter(QtCore.QObject):
AttributeError: 'NoneType' object has no attribute 'QObject'

I'm all ready a fan of continuous integration. Let's hope this is easily 
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: Dreaming big dreams

[Edward K. Ream]

On Wed, Oct 10, 2018 at 2:50 AM 'tfer' via leo-editor <
leo-editor@googlegroups.com> wrote:

> Even with the caveats I've mentioned, Neovim should be one of the easiest
> to put into Leo.  On non window systems you could embed the terminal
> version into the n-curses like version of Leo.  For all systems you'd take
> the Qt front end version of Neovim and get it to take the place of the
> editor pane, (i.e. the screen location).   Then, add msg-pack to Leo and
> use that to complete the integration.  Note that you can already detach and
> close the Leo;'s editor pane.
>

Thanks, Kent and Tom.  I've just created #990
 for this.  You are
both assigned to this issues as consultants and testers.

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: Dreaming big dreams

[Edward K. Ream]

On Tue, Oct 9, 2018 at 11:12 AM Kent Tenney  wrote:

> I also think it would be great if Leo could use neovim for the editing
> experience.
>
> This project
> https://github.com/neovim/python-client
>
> says:
>
> You can embed neovim into your python application instead of binding to a
> running neovim instance.
>
> >>> from neovim import attach
> >>> nvim = attach('child', argv=["/bin/env", "nvim", "--embed"])
>
> Not sure if that works with QT
>
> https://gitlab.com/Muream/neovim-pyqt
> seems to subclass a QT class to provide neovim in a QT window
>

Thanks, Kent.  This is worth investigating, even if it becomes a Linux-only
feature of 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: Dreaming big dreams

['tfer' via leo-editor]

Even with the caveats I've mentioned, Neovim should be one of the easiest 
to put into Leo.  On non window systems you could embed the terminal 
version into the n-curses like version of Leo.  For all systems you'd take 
the Qt front end version of Neovim and get it to take the place of the 
editor pane, (i.e. the screen location).   Then, add msg-pack to Leo and 
use that to complete the integration.  Note that you can already detach and 
close the Leo;'s editor pane.

This has the advantage of leaving Leo's log and outline pane and code in 
place.

Tom

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