Re: Leo for organizing notes?
A draft of my 'user's story', in hopes it gives a glimpse of how I see the system playing out. Much is left out of this draft; I just intend it to give a flavor. On Thursday, February 6, 2020 at 1:30:36 PM UTC-5, Thomas Passin wrote: > > > > On Wednesday, February 5, 2020 at 10:30:26 PM UTC-5, andyjim wrote: >> >> >> Thomas, tell me if this is an inappropriate suggestion, but I wonder if >> this thread has pretty much played out its level of pertinence and interest >> to the Leo community, since it's not directly about Leo and may be on a >> subject of limited interest here. Given your own zettelkasten-like program >> and your interest in knowledge and semantic processing, and your direct >> questions to me about my ideas (I'm working on it), would it be appropriate >> for us to continue the discussion by email? That would be much easier for >> me, but if not appropriate I'll continue here, though this thread waxes >> long now and I feel I don't function well in a forum venue. >> > > I've been wondering the same thing. Trouble is, if we use email, it's > just us, and we miss out on other people's thinking. We could set up a > whole new Google group, but I'd like to keep the discussion in the Leo > context if we can do so - would you agree? And it's clear that there is > some degree of interest, as we see from @Xavier's post. > > What I'm thinking is to open a new thread in the Leo group - and to keep > opening new threads when and as one gets too long to work with. Just now, > we're wrestling with what we really want to accomplish and how it ought to > work, and it would make sense to open a new thread on requirements and > concept of operation (this could include your narratives). How's this > sound to everyone? > > I've gone beyond the requirements I posted a few days ago, and tried to > come up with a note format that > >1. Can be typed and read easily; >2. Can be processed by software easily; >3. Could be used in a paper Zettelkasten if one really had to do that; >4. The system could export note files in this format without too much >difficulty; >5. Contains most of the essential information, so that the software >could reconstruct the entire zettelkasten just from these notes if need be >(possibly with a small amount of information loss); > > I think I've gotten most of this. The main things I haven't worked out so > far are links to other notes that might be embodied right in the text of > the note (if we really want these). and similarly how links to other > non-text media would be captured in the zettel. There is no end of ways > these things could be done, and my interest is in coming up with something > that is especially easy to type and read. > > Why my emphasis on typing the zettels? Because the alternative is to use > some software system that tries to "help" you. Now we'll certainly want > something like that as an option, but having to use a number of select or > drop-down lists or whatnot all the time really interferes with one's flow. > Straight typing is better where possible. > > In my concept of operations, one would be able to type into a new zettel - > either in a Leo node or even in a separate file - and then the system would > hook it up based on the info you typed. Later, the system would help you > change, add to, or update the references; you could do that when you > weren't so involved with the thoughts you were typing. > -- 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/4c27b213-43da-4c64-a6c6-f3d51562bfeb%40googlegroups.com. user_story_aj-1 Description: Binary data
Goals for Viewrendered3
Viewrendered3 is finally close to preliminary release, after I got diverted by a few red herrings. As I clean up the anomalies I know about, please look over the attached set of goals for the project. I don't want to seriously enlarge the scope at this time, but if anyone thinks that something should be added or changed, or that one of my goals isn't thought out correctly, this would be a good time to let me know. One thing that is still up in the air for me is the relationship between *viewrendered *and *vr3* with regard to displaying Leo information like the docstrings of other plugins. Should *vr3* simply replace *vr* for this purpose? If yes, I don't know how this communication is accomplished, but right now, the two interfere. And I see that *vr *gets loaded somehow even if it's not called for in an *enabled-plugins* setting. I'm going to need to understand how this all works, and any guidance will be very helpful. TomP -- 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/cac893cf-f064-4f96-a092-e206124103ba%40googlegroups.com. Title: Goals for VR3 Enhancements The primary intent of Viewrendered3 is to enhance the Viewrendered plugin to able to: view an entire sub-tree at once; mix text and code while still being able to execute the code. Enhancements to ViewRendered for @rst and @md nodes: Render an entire subtree. Code Blocks Optionally render only code blocks. Colorize code blocks. Optionally execute Python code in code blocks. Display print() output below code blocks. Delineate code blocks started by @language markers in addition to md or RsT code block formatting. Preserve Python decorators in code blocks. Correctly treat RsT or md when they are in a Python docstring. That is, render the docstring correctly as text. Ability to export rendered results to system browser. Omit lines between @ and @c markers, except in docstrings. Render math content using MathJax rendering. Non-goals At this time, the following are not goals: Render math with css or any other method besides MathJax. Nodes with mixed @rst and @md sections. Executing other languages besides Python. Understanding @others directives or <>. Inserting graphical or other non-print() execution output into the tree. Saving a code-only file from any node or subtree. Note that a code-only file can be gotten by exporting the code-only rendering, then highlighting the page in the browser, copying it, and pasting into a file.
Re: Leo for organizing notes? [Experimental Restructuered Text format for a zettel]
> On Friday, February 7, 2020 at 12:00:43 AM UTC-5, Thomas Passin wrote:
>>
>>
>>
>> On Thursday, February 6, 2020 at 11:04:30 PM UTC-5, andyjim wrote:
>>>
>>> attached is my first draft for a zettel format.
>>>
>>
>> Thanks. Here's my first cut at a format.
>>
>
Here is a Restructured Text version that uses RsT syntax features. I think
this is the best I've come up with so far. Attached is the text file and
an HTML file showing how it looks rendered by an RsT processor.
This format is nearly as easy to type and read in plain text as the
original plain text version, uses only standard RsT features, and is very
readable when rendered to HTML.
--
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/2d35b3ce-31f4-4952-8d75-2a87f5409bf8%40googlegroups.com.
:title: expermental zettel format 3
:id: t-zformat-3
:index-term: zettel/format
:parent: t-zformat-2
:date: 2020/2/5
:format: rst
.. this is a comment line, using the RsT line comment marker.
.. Keywords are delineated with colons(:).
.. :order of these keyword entries is not important.
.. :cite: for citations to published sources
.. :url: for URLs to relevant web pages.
.. :rel: for relations to other zettels.
.. :child: id of child zettel.
.. :time: 1830
.. Body of note is not introduced by any identifier.
.. All data items are optional.
This format is basically the same as Format 2, except that the keyword lines
start with a colon (:). RsT automatically renders them in a nicely readable
way. Also, comments are delineated using the RsT comment marker ("..").
Note that Markdown does not have a convenient syntax for the inline keyword
lines or for comment lines. This makes me think that Restructured Text is the
best way to go for zettels.
**Pros**: Uses only standard RsT syntax.
**Cons**: *Slightly* more typing for the keywords and comments, compared with
plain text format version.
Title: format_4.txt
format_4.txt
title:expermental zettel format 3
id:t-zformat-3
index-term:zettel/format
parent:t-zformat-2
Date:
2020/2/5
format:rst
This format is basically the same as Format 2, except that the
keyword lines start with a colon (:). RsT automatically renders them in
a nicely readable way. Also, comments are delineated using the RsT
comment marker ("..").
Note that Markdown does not have a convenient syntax for the inline
keyword lines or for comment lines. This makes me think that
Restructured Text is the best way to go for zettels.
Pros: Uses only standard RsT syntax.
Cons: Slightly more typing for the keywords and comments, compared with plain text format version.
