Re: Leo for organizing notes?

[andyjim]

Thomas, thank you for devoting some time to thinking about this.  It's more 
than I could reasonably expect.  Tried to PM you but seems it didn't go 
through.  I agree that files need to be plain text or markdown, even though 
undoubtedly a database-based system would offer advantages. The 'no 
proprietary formats' principle is part of why I quit using Word five years 
ago and went to Vim and plain text.

I do not quite grasp your Lucene scheme but I have myself wondered about 
arranging my past notes text files into units in a clear format with 
headers (containing tags, etc) and 'code' such that a parser could process 
those files, dice out the individual units and load them into a usable 
system.

For what it's worth I'm on MacOS (refugee from Windows) so don't know if 
that makes something like that more feasible for me anyway.  I do think 
that a good zettelkasten system will require tags, keywords, links, 
indexes, not just text searches.  I think some mapping capabilities would 
be extremely helpful too. A map of tag connections where I could traverse a 
search-generated tag map and access the tagged files would be nice.

I did not quite grasp your ideas about an @zettel tree though it sounds 
interesting.  I'm not familiar enough with Leo I guess, but I'm all for 
maps, trees, webs.  That's kind of an underlying principle with 
zettelkasten.  It's a web of ideas/thoughts that serves as an extension of 
the mind.  Very exciting.

I've heard of noSQL databases that are 'document-based', but I have little 
clue what that means or whether it offers anything useful here.

I suspect the notion of somehow building a better zettelkasten system more 
or less within the Leo architecture (if that's the correct word) is 
probably asking too much, but of course what do I know? Maybe it's doable, 
since Leo seems already to contain most if not all its principles, plus 
principles of its own that could further extend/enhance the zettelkasten 
usefulness.  In any case I hope you can find zettelkasten useful in some 
way.
Andy

On Friday, January 31, 2020 at 11:40:01 AM UTC-5, Thomas Passin wrote:
>
>
> As I think about how Leo could be useful with the zettel-box approach, I 
> do see a way.  But it's not to have each note be a node in a Leo outline.  
> Can you imagine trying to work with thousands or tens of thousands of nodes 
> in the outline pane?  Instead, I can see using an @zettel tree whereby if 
> you put a node name into the headline of the node, Leo would open that note 
> and any notes it linked to.  You could keep them in a group forever in the 
> outline if you liked, or delete the tree when you were done with that 
> activity. 
>
> You would be able to edit any note just like any other markdown node.  In 
> the vewrendered pane you could see a rendered view of the note or the whole 
> tree it was in.  Possibly you could get other kinds of views in the VR 
> pane.  I would favor a mind map type view, myself.
>
> You would be able to launch full text searches of the notes. I'm thinking 
> that the Python Whoosh search engine would be good for that.
>
> You would have the wiki-like ability to create a new note by using its 
> name if it didn't already exist.
>
> Would this be better than using Zettelr?  I don't know, I just installed 
> it and haven't played with it except to see that it has a very good ability 
> to import many file formats, including LibreOffice documents, and convert 
> them to markdown.  Maybe that would be the way to go - use Zettelr to 
> convert to markdown, and then use Leo to work with the converted notes. 
> You'd still be able to use Zettelr for anything it was better at.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c7df6d85-cb11-45f7-ac23-acc66440f03d%40googlegroups.com.

Re: How to start up Leo the dumb way

[Steve Litt]

On Thu, 30 Jan 2020 16:48:27 -0800 (PST)
andyjim  wrote:

> Really dumb question, I know.  MacOS system. I'd like to launch Leo
> from the launch bar instead of from terminal (which is the only way I
> know to launch it). But it ties up the terminal so I can't use it for
> anything else while Leo is running (not that I use terminal much, but
> occasionally), plus it would be easier/quicker to launch from icon.
> I don't find a launchLeo or a runLeo file on my system.
> Andy
> 

I'd suggest investigating dmenu at https://tools.suckless.org/dmenu/ .
It works on Linux, and it's pure X so I don't see a reason it wouldn't
work on a modern Mac. If you can get it working on your Mac, see setup
details here:

http://troubleshooters.com/linux/dmenu/bestpractices.htm

(The preceding link will be back up 2/6/2020)

If you can't get dmenu to work, the following Python script enables you
to run any GUI program with a doublefork, freeing the terminal it's run
from:

=
#!/usr/bin/python3

import sys
import os


if os.fork():
sys.exit(0)
if os.fork():
sys.exit(0)
os.setsid()  ### New to 1.9.3, guarantees complete fork
sys.argv.pop(0)
executable = sys.argv[0]
os.execvp(executable, sys.argv)
=

To run Gnumeric without consuming the terminal, just do the following:

./ufork.py gnumeric

SteveT

Steve Litt 
January 2020 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20200201145134.79914331%40mydesk.domain.cxm.

Re: ENB: About the JS importer and #1481

[Edward K. Ream]

On Saturday, February 1, 2020 at 5:00:51 AM UTC-6, Edward K. Ream wrote:

> This long Engineering Notebook post will discuss this fix, it's 
limitations, further problems and possible fixes for those problems.

After importing an @auto tree, it would be possible to convert @auto to 
@clean. This would allow you to adjust nodes to your complete satisfaction.

> It's "obvious" that the last line of the node "promise.catch function" 
belongs in the *previous* node. However, *such a move can not be done in 
general!*

Worse, the last line belongs after @others, *not* at the very end of the 
previous node. This might be a big ask. True, only one @others may appear 
in the previous node, but a completely sound approach would have to 
retokenize the previous node to determine where the @others is! But that's 
probably taking caution too far :-) In any case, a rethink is necessary.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/63f29256-92fc-4168-b89c-d01f8f6afff9%40googlegroups.com.

ENB: About the JS importer and #1481

[Edward K. Ream]

Recent revs in the js-importer branch provide a basic fix for #1481 
. This long 
Engineering Notebook post will discuss this fix, it's limitations, further 
problems and possible fixes for those problems.

As always, feel free to ignore. However, this post describes important 
aspects of the code and its design. It may more than usual interest to 
Leo's devs.

*The immediate problem*

Perfect import failed for reveal.js because *i.gen_lines* failed to 
allocate lines properly to nodes. This caused lines to appear out of order.

i.gen_lines is part of the *pipeline*, defined in the base *Importer class*. 
At present, the *JS_Importer* class (and most other importers) are 
subclasses of the Importer class. Iirc, all importers use i.gen_lines 
unchanged. The JS importer overrides i.starts_block, one of i.gen_lines's 
helpers.

i.gen_lines uses a *parse state* to determine the start and end of *blocks*. 
For Javascript, these blocks correspond (roughly) to classes and functions. 
Alas, there are many ways to define a class or function in JS. JS is, by 
far, the most difficult language to parse of all the languages handled by 
Leo's importers.

Perfect import failed for reveal.js because the importer mistook a line 
like if('function'){ as the start of a function. The present fix will 
usually work (Leo can now import reveal.js), but not always, as I'll now 
explain...

*Tokenizing Javascript*

You ask, how hard can it be to recognize strings like 'function' in JS? The 
answer is "very very hard". Tokenizing JS depends on context. In 
particular, it is difficult to determine whether a '/' character is the 
"div" arithmetic operator or the start of a regular expression! JS is, by 
far, the most difficult language to scan (tokenize) of all the languages 
handled by Leo's importers.

*i.scan_line* updates the parse state after *carefully* tokenizing each 
line. The JS importer method *js_i.scan_line* overrides i.scan_line to 
handle '/' properly. As you can see, it's not pretty. The bug happened 
because *js_i.starts_block* contained regex's that didn't distinguish the 
"function" keyword from a string containing "function". The partial fix is 
mostly a hack. js_i.starts_block now keeps track of whether function *looks* 
like it is in a string. But this faux tokenizing could fail if quotes (or 
"function") appear in a regex, as they very well might.

A proper fix would involve fully tokenizing each line, in *both *js_i.scan_line 
and in js_i.starts_block. Therefore, we want a stand-alone javascript 
tokenizer, written in python. Present revs include a copy of JsLex.py 
, but it isn't hooked 
up yet. The JsLex code contains a note that it doesn't handle non-ascii 
characters properly, so it may need substantial revision. Happily, JsLex 
does contain a suite of unit tests.

*Other problems*

The lines of reveal.js that caused the perfect import to fail are not 
handled very well even after perfect import succeeds. Here are the 
complications...

The JS importer must be completely immune from indentation, and it is. As a 
direct consequence, perfect import tests ignore leading whitespace. 
However, once lines are allocated to nodes, the importer tries to *adjust 
*nodes 
to make them as pleasing as possible. In particular, the importer removes 
*common 
leading whitespace* from all nodes. In addition, under special 
circumstances, the importer may try to move one or more lines from the end 
of one node to the start of the previous or following sibling node. The *post 
pass* part of the pipeline handles all these adjustments. It would be 
difficult/impossible to handle them in gen_lines.

At present, the JS importer only generates @others directives, never 
section references. This could be changed, but imo using @others is much 
better. However, @others does impose additional constraints on what the 
post pass can do. It's time for an extended example.  Here is the gist of 
the code that caused perfect import to fail:

function startEmbeddedContent( element ) {
toArray( element.querySelectorAll( 'video, audio' ) ).forEach( function( 
el ) {
if('function') { // The culprit
promise.catch( function() {
el.addEventListener( 'play', function() {
el.controls = false;
} );
} );
}
}
}

To have any chance of understanding what is going on, the post pass must be 
disabled.  Here are the results, without the post pass.  Headlines are 
preceded by ===:

=== function startEmbeddedContent

function startEmbeddedContent( element ) {
@others
}

=== toArray( element.querySelectorAll('video, audio')).forEach function

toArray( element.querySelectorAll('video, audio')).forEach( function(el) 
{
if('function') {
@others
}

=== promise.catch function

promise.catch(function() {

Re: Mechanics of private messages in the forum

[Edward K. Ream]

On Fri, Jan 31, 2020 at 8:37 PM andyjim  wrote:

> Another dumb question (I've got a million of 'em, but sorry to take up
> bandwidth with them).
>

There are no stupid questions, just stupid answers.

I see how to send a private message, and have done so, but that message
> 'disappeared', so I cannot review it and don't know if the intended
> recipient got it. The intended recipient has posted again in the thread,
> but I don't know if that was a private message to me or a public post. How
> do I know when I've received a private message, and how can I view a
> private message I've sent?  I haven't found a help item that answers this.
>

I don't know anything about private messages. My advice is to keep all
communications public. Don't worry about "wasting" people's time, provided
you have done your homework first.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2Xcsu6xdcQzffYGEAkpb9hJuEo9zVCRjxGjK0UkWZohw%40mail.gmail.com.