Zettelkasten - Notes Jim but not as we know them.

[Israel Hands]

While looking at the 'rest' mainly for a more graphic view of notes I came across what might be the opposite.  The Archive. It's a MacOs notes organiser based on  Zettelkasten methodology. Which as far I can see means no categories/hierarchies. Which interestingly Tinderbox kind of espouses. https://zettelkasten.de/the-archive/  One thing I found interesting was their implementation  of tags. 

Use a hash before a word - #ThisIsATag and the note becomes tagged with the tag. Click on the tag and all other notes instantly disappear  from the tree. It's not really a tree you see  but a search bar.

I tentatively think this would be cool in Leo.... 

It also has links between notes but I haven't explored them yet.

The Archive - stores all notes as text files in a single directory so interoperability with Leo is easy enough.

Ta

IH

[andyjim]

I'm a journaler, a note-taker, not a programmer.  I've looked for years for the right organizer for notes. I now think Zettelkasten is it, but haven't found a Zettelkasten program that seems adequate. I'm a very raw beginner with Leo, but I'll venture that Leo would be the perfect platform for Zettelkasten.  I hope someone will take it up.

[Matt Wilkie]

Thanks for introducing us (me!) to Zettelkasten. The Zettlelkasten.de Overview page seems to be a better than average guide to their world, and the Tools page has a curated list of implementations. I like that their first focus is principles and education, with the tools they sell playing a secondary though still prominent role. Because it will scroll off their home page soon, I'm also noting this intro - Zettelkasten — How One German Scholar Was So Freakishly Productive to whet appetite.

-matt

[Thomas Passin]

Picking up in this thread -

On Tuesday, February 18, 2020 at 2:11:21 PM UTC-5, andyjim wrote:

It appears you are casting your net beyond Leo a bit too, in case there is something out there that does almost all of what we want.  Brain? MindForge?  Let me know what you find. I was unable to install MindForge on my Mac even though there are instructions to build it. Didn't work.

After spending some hours with Mindforge and a bunch of others, I'm still looking favorably at Leo.  Yes, we will have to write some code, and yes, the display may not be quite as nice as what a dedicated product could give, but Leo has so many strengths that are a good match for our needs that I'd rather work within Leo.

For example, we were talking about timestamps, and @andyjim was talking about wanting to search on timestamps.  If when you import a zettel, you add the timestamp to a note, for example in my format 4, then you could search for it using the "Nav" tab.  The Nav tab is almost miraculous in its searching ability - it is very fast, it displays the results in a readable format, and when you click on a search result it takes you to that node.  Whoever put that together did a fabulous job.

Later we could add better filters - like for time ranges, or whatever.  But out of the box we'd have that ability.

[andyjim]

@Thomas I found the command that allows you to break zettels out of an imported file.  In the body you select the lines you want, hit shift-Command-D and it splits your selection out into a new node (under the parent heading for the imported file) with the first line as the new heading.

So, import file, select lines, make zettels. Can discard unwanted parts in same process. So that's a start on one way to bring a file in and break it up into zettel nodes. 

[Thomas Passin]

On Wednesday, February 19, 2020 at 10:10:03 PM UTC-5, andyjim wrote:

@Thomas I found the command that allows you to break zettels out of an imported file.  In the body you select the lines you want, hit shift-Command-D and it splits your selection out into a new node (under the parent heading for the imported file) with the first line as the new heading.

So, import file, select lines, make zettels. Can discard unwanted parts in same process. So that's a start on one way to bring a file in and break it up into zettel nodes. 

Cool! That's one thing about Leo - it can do so many things, but it can be hard to discover them.  Maybe a zettelkasten?

[Thomas Passin]

I've been spending some time with my bookmark manager again, and I'm remembering some things that may be helpful for our own system eventually.  Recall that I store bookmarks (in the browser) in folders, that may be children of other folders. These folders become headings in what looks like a filing system in the program.  The manager automatically creates certain links between these headings, but I do not create links between the resources (URLs; i.e., web pages) themselves.

When I run a search, the manager actually performs two searches: the resource titles are searched, and separately the headings are searched for the search phrase.  The results are displayed in two tabs, one for the resources and one for the headings.

I often find that the resource title search results aren't too helpful, because there are usually too many unrelated hits.  Going to related headings is more likely to disclose a useful result.  But sometimes there are no hits on the headings, and then the hits on resource titles become the only possibility, even if you have to scan them and try several.  Once you get a resource listed, the system will show you what heading it is under, and has a link to go there.  Then you can see if there are any more resources of interest filed there. And if not, you also see other headings that are related in various ways.

What surprised me us how useful it is to have these two kinds of results - they kind of complement each other.  So of course I'm imagining the same will be true for a zettelkasten.  We could implement the heading side of this by using the existing Leo tags system and simply structuring them (e.g. Knowledge Representation/Semantic Processing/Software).

[john lunzer]

The "clone find" family (clone find flat seems more popular) of commands achieves this without the need for new functionality. 

If you wanted "everything else to disappear" you could hoist the parent node created by "clone find". Personally I find hoisting to have somewhat limited utility, it is not very arduous to focus on a single subtree.

With very little scripting these two actions could be combined into a single command. With no scripting one can simply execute the commands one after the other.

I am sure there are at least 3 other ways to achieve similar results, but this has the least amount of fan-fare, scripting, and keystrokes. 

On Friday, January 10, 2020 at 9:00:23 AM UTC-5, Israel Hands wrote:

[andyjim]

On Wednesday, February 19, 2020 at 11:35:05 PM UTC-5, Thomas Passin wrote:

I've been spending some time with my bookmark manager again,

Thomas, is your bookmarks manager available to 'the general public'?  I am terrible with bookmarks. No organization at all, and (after taking up valuable time counting them) I would blush to report how many I have open right now.

[andyjim]

On Wednesday, February 19, 2020 at 11:19:33 PM UTC-5, Thomas Passin wrote:

Cool! That's one thing about Leo - it can do so many things, but it can be hard to discover them.  Maybe a zettelkasten?

Yes!  Zettelkasten is a bottom-up, self-organizing, multi-faceted journal/database/creativity tool that evolves into a genius, an agent, a multi-channel partner in memory and thinking.  Pardon me while I rave, but it's the best concept I've ever seen.  You don't have to think, 'now where did I put that?'.  When you connect every item three or four different ways (the more the better in my opin), it should never be hard to find. The more ‘handles’ the better, because I think the mind’s own system is that way: a multi-faceted network of connections allowing maximum access, maximum creativity.  Hierarchical headings, tags, keywords, ‘pointers’, direct links, titles, subtitles, first lines, references and more.

End of rant.

[Thomas Passin]

I would love to say yes.  I have no objection, and I'd be happy to have more people using it.  But using it takes some setup. You have to get certain batch files pointing to the right directories, etc.  How about if I work with you to do that?  Limitations are:

1)  It works best with Firefox bookmarks.  Other browsers can export to the same format, but they are organized a little differently, and I have had to hand-edit the export files for them to work with the bookmarks manager.  I could work with you to fix up the bookmarks if you want to move them over to Firefox.

2. While you can add and edit data to the resources (the URLs) - like notes, other URLs, etc, - the process for saving these annotations is very clunky.  That's because browsers themselves won't let you save to the file system as a security measure.

3. I *think* that by using Firefox, you can use the manager without running a web server.  Most other browsers won't let you do it (they all worked without a server back when I developed it, in the 2003-2004 time frame, but no longer).  So if you don't want to use Firefox, we'll have to set you up with a web server on your computer.

4. If you didn't save your bookmarks into a series of folders, then the program won't be of so much help, because it uses the folder names to figure out the links that make the system especially good for serendipity.  You would only have a flat list of resources.  All you could do would be to search them for a text phrase in the title.

OTOH, if you did use folders for saving the bookmarks, you are going to love the thing.  And the various displays and computed linking arrangements built in might stimulate some useful thoughts for the kind of user interface features that a zettelkasten might profit from.  Once it's set up and running, it's very easy to use, and it performs very quickly.

Oh, yes, and  it can read files from specified directories in the files system, too, if they contain URL links or files of some types.  It will, for example, treat a folder full of Internet Explorer bookmarks just like the bookmarks from your browser.  This can be very handy. 

Sometimes I think that if I could make the process of saving your annotations easy, we'd have maybe 3/4 of what we (or I) want in a zettelkasten.  But maybe not.  In my thinking, a zettel would be represented by its URL.  That's all the bookmark manager needs.

So if you want to try it out, check the gmail account that you used for private messages.  I finally found the message that you sent me, and responded to it a few days ago.  It has a better email address for me.  Write me there.

Tom

[Thomas Passin]

Don't forget that the zetelkasten system is just half the story.  I just read the first chapter of "How To Take Smart Notes: 10 Principles to Revolutionize Your Note-Taking and Writing", and it's very clear: coming up with the right workflow for *you* is at least half the battle.  It will probably be different for everyone.  And a zettelkasten might not even be the best tool for everyone. 

[Thomas Passin]

On Thursday, February 20, 2020 at 10:38:19 PM UTC-5, Thomas Passin wrote:

On Thursday, February 20, 2020 at 9:37:43 AM UTC-5, andyjim wrote:

On Wednesday, February 19, 2020 at 11:35:05 PM UTC-5, Thomas Passin wrote:

3. I *think* that by using Firefox, you can use the manager without running a web server.  Most other browsers won't let you do it (they all worked without a server back when I developed it, in the 2003-2004 time frame, but no longer).  So if you don't want to use Firefox, we'll have to set you up with a web server on your computer. 

Good news - the bookmark manager will definitely run right from the file system, no server required.  That's in Firefox. This has the advantage that it can not only display links to, but also load file system files into a browser tab.  This means that one could actually use it as a partial zettelkasten by writing text files into a directory tree, one note per file.  The smarts would come from the names of the directories - consider them to be something like tags.  What it wouldn't provide in its present state is direct links from one zettel to another, and searching by time of the zettel.  It will, however, search by the heading (directory or tag) names.  The headings can have any number of nested levels, which is equivalent to the original paper system of identifying them by a code that gives the position of a zettel in the filing box.

And you *can* in fact link one of these zettels to another - with the existing system - and have that link be clickable (backlinks aren't provided, though).  It's just that it's very clumsy to save the information. Once I figure out how to store annotations in a more practical way, that problem will be solved (it might require a server).

[Thomas Passin]

Bingo!  I had a brainstorm.  Now I know how we can use Leo to write text zettels, have them organized in a tree of files on disk - for almost no effort - and then use them in my bookmark manager.  We can have - right now, today - enough of zettelkasten functionality to start actually trying it out, so we can learn how best to author zettels and organize them, and have the bookmark manager link them up and provide the GUI.  The manager has some limitations, but we can either add functionality to it, or write code for Leo to do some of the additional things we want - as we use the system and find out what we really need.  And the zettels are automatically saved as text files, as we said we want.

In a previous post, I pointed out that the bookmark manager is a bit of a beast to set up.  Once it's set up, it just quietly works.  If other people want to try this thing out, I will have to spend some time working out how to make it easier to get going.

Here is the how you make it all happen.  The zettels are to be written in Restructured Text format (RsT), which can be just plain text.  In the Leo outline of the zettelkasten, outline heading nodes have to start with "@path", and zettel nodes have to start with "@rst".  This is not a large burden, to add these directives to the node title.  Remember that the bookmark manager does much of its magic by using the heading titles - basically they are organizing thoughts.  So it pays to come up with good names for them.

So a zettelkasten tree might look like this:

@path zettels

   @rst zettel basics

   @rst linking zettels

   @path zettels and creativity

      @rst ...

@path note-taking

    @rst note-taking techniques

    @rst zettelkasten are not for taking notes at a lecture

    @path software

       @rst ...

To create or update the tree on disk, you run the Leo command "rst3".  Leo will create or update the entire tree for you.

To process this tree for the bookmark manager, you just run a batch file, for example by double clicking it.  Or we could create a Leo button to run it.

To get the updated data into the bookmarks manager, you just reload it.

With RsT, you can set up links between zettels or parts of them.  It's a manual process, but at some point it ought to be possible to write a plugin to help, much like the backlinks plugin (if we made links with the backlinks plugin, the bookmark manager would have no way to know about them).

As an additional benefit of doing things this way, The entire collection of notes or a subset could be converted by Sphinx to a lovely, readable cross-linked set of web files, for almost no more effort.  The process can be launched by another leo command or button.  If you don't know about these Sphinx-generated documents, here's an example - https://solidity.readthedocs.io/en/v0.6.3/

I'm stoked, let me tell you!

[Thomas Passin]

Here are some screen shots of the hybrid Leo-bookmark manager in action.  The first show a Leo outline for my little zettelkasten.  In the middle pane, the body editor displays the text of one of the zettels.  In the right hand pane, the viewrendered3 plugin displays a rendering of one of the zettels, which includes a link to another file (node) in the zettel.  Sadly, at this point the file will only open as a plain text file - it will not be rendered.  In the future it ought to be possible to have Leo move to the linked node and display a rendered version.

The viewrendered3 plugin is nearly ready for me to release.  I just have to work out a couple of things first.  The older viewrendered plugin ought to show the same rendering.

"TM4J" is the bookmark manager.  The three gifs with "tm4j" in their names depict the bookmark manager after a search for the string "zettel".  It shows hits from both my browser bookmarks and the small Leo zettelkasten outline.  They are treated exactly the same.  The search finds hits among the bookmark's folder names, the zettel @path nodes (which are used as organizing headers), and the titles of web pages.  Actual web pages are called "Resources".

The bookmark manager opens URLs in another tab or window.  So an actual zettel will open as a text file, not as a rendered RsT document.  Maybe that can be changed in the future, although I haven't found a javascript RsT renderer yet.

On Friday, February 21, 2020 at 2:05:06 PM UTC-5, Thomas Passin wrote:

Bingo!  I had a brainstorm.  Now I know how we can use Leo to write text zettels, have them organized in a tree of files on disk - for almost no effort - and then use them in my bookmark manager.  We can have - right now, today - enough of zettelkasten functionality to start actually trying it out, so we can learn how best to author zettels and organize them, and have the bookmark manager link them up and provide the GUI.  The manager has some limitations, but we can either add functionality to it, or write code for Leo to do some of the additional things we want - as we use the system and find out what we really need.  And the zettels are automatically saved as text files, as we said we want.

[snip]

[andyjim]

I  look forward to getting into this.  So on the Leo side I need to start setting up a heading structure.  I also need to learn about Leo tags. And start learning some RsT and write some zettels at least for testing.

It's looking interesting.

[Thomas Passin]

On Saturday, February 22, 2020 at 9:26:11 PM UTC-5, andyjim wrote:

I  look forward to getting into this.  So on the Leo side I need to start setting up a heading structure.  I also need to learn about Leo tags. And start learning some RsT and write some zettels at least for testing.

It's looking interesting.

I'm using my suggested format 4.  My idea for going forward is to get everything working with the bookmarks manager and learn as much s we can.  Then we can start to migrate functionality from it into a Leo plugin, and add new functionality after we get more clarity about what seems to work well.  The format for the zettels will be forward compatible - that is, it should not need to be changed except possibly adding a little more metadata or changing the format of, say, links.

Right now I am not favoring the use of either the backlinks or tags plugins, because they don't store their information in the zettel files themselves.  Since my current approach is to create those files from the outline by using the rst3 command, I want all the linking data to be in the files themselves.

I have developed two commands that insert the node id and current timestamp into the zettel. I'm already using them in my little experimental zettelkasten. The results look like this:

:id: TomP.20200221221759.1
:timestamp: 02/22/2020 08:25:29

Since the creation time is included in the node id, we are free to use the timestamp to record the modification time if that's what we want.

I should be able to have a command to navigate to a node id soon.  The examples of links I gave in my earlier post work, but they won't keep working if the structure of the outline gets changed.  That's not desirable. Using the node id, the details of the outline structure won't matter.

I will attach my zettelkasten outline in another post as a guide to creating a structure that works on its own and also with the bookmarks manager.

[Thomas Passin]

On Saturday, February 22, 2020 at 10:11:51 PM UTC-5, Thomas Passin wrote:

I will attach my zettelkasten outline in another post as a guide to creating a structure that works on its own and also with the bookmarks manager.

Attached is the Leo file for my little zettelkasten.  It includes @settings nodes for the commands and keyboard shortcuts for inserting the node id and timestamp.  

The structure uses @path nodes to create directories.  When you run the rst3 command on the tree, it will create a directory tree in the file system that matches the structure of the Leo outline.  The bookmark manager uses this directory structure to build its internal data structures linking different parts of the outline together.  This procedure also gives you the ability to export the files if you should ever want to move to some other system.

So the @path directives are only needed if you plan to make use of the bookmark manager (when I get it ready for use).  Otherwise, you would still want those nodes, but they wouldn't have to have the @path directives.  Ultimately my plan is to use them with a Leo plugin to do the kind of linking I currently do in the bookmark manager.  So it would be wise to include the organizing nodes, and to give them meaningful titles. And even without the behind-the-scenes data structures, they will still be useful for searching in the Nav tab.

The @rst directives are only needed for using the rst3 command. But I think that's worthwhile.

Oh, and here is a command to open Explorer (Windows only) at the directory of the path of the current outline.  It's very useful for getting to those directories you just made with rst3.

from subprocess import Popen
cmd = 'explorer.exe .'
Popen(cmd)

Put this into the body of an @button node, press the script-button button, and you will have a button to open the directory.

The script could be modified for linux, but details would depend on which linux flavor you are using.

[Thomas Passin]

On Saturday, February 22, 2020 at 9:26:11 PM UTC-5, andyjim wrote:

...  I also need to learn about Leo tags. And start learning some RsT and write some zettels at least for testing.

One simple way to get tags is to simply include a line or lines like this in the zettel node:

:tag: tagname

Note that you *must* include the space after the second colon, at least for it to render nicely in Restructured Text.

Now you can search on tagname or :tag: tagname or even : tagname. Granted, you can't easily get a listing of all the tags - until we have a zettelkasten plugin that can create one - but you could maintain a zettel that only contains the tag names. It would be almost as good.

I've attached an example of the RsT rendering of a node with this format of metadata.  BTW, notice the :links: item?  I've started including them for my links, with the future in mind.  It should not be hard to parse out the links from those items when we have a plugin going.  Probably we will be able to to it just with a command, no plugin needed.  The command could be bound to a key, so, for example, ALT+F6 would take you right to the linked node.  The node ids are not going to change, so no matter how we implement it, this metadata will be useful.

I am unsure, though, whether to allow more than one link per line.  One link per line would be easier to write the code for, yet more than one would be easier to author and would reduce the visual clutter.  I'm open to suggestions here (and everywhere else!).

[Thomas Passin]

On Saturday, February 22, 2020 at 10:11:51 PM UTC-5, Thomas Passin wrote:

I have developed two commands that insert the node id and current timestamp into the zettel. I'm already using them in my little experimental zettelkasten. The results look like this:

:id: TomP.20200221221759.1
:timestamp: 02/22/2020 08:25:29

Since the creation time is included in the node id, we are free to use the timestamp to record the modification time if that's what we want.

I should be able to have a command to navigate to a node id soon.  The examples of links I gave in my earlier post work, but they won't keep working if the structure of the outline gets changed.  That's not desirable. Using the node id, the details of the outline structure won't matter.

I now have a command with keyboard shortcut that works like this:

1. Put the cursor on a line that starts with ":link:"  If it's not on such a line, nothing will happen.

2. Hit the shortcut key.  I am using Alt+F6.

3. The selection point jumps to the node with that ID.

4. If the target node does not include a :link: back to the starting point, one is inserted.

So this gives us automatic backlinks.  No plugins required.

[Thomas Passin]

With the command to add a backlink, I would say that we have a working zettelkasten system that has essentially all the features of the original paper system, with better searching and reorganizing abilities.

1. Zettels (notes) that include an ID and links, including backlinks.

2. Although the zettel IDs do not follow the original system, where the number encoded a note's location, with closely related IDs generally physically close - this is known as co-location in library science - the nodes are presented in hte outline view in an equivalent way that is much easier to work with.

3. Zettels can contain links to other zettels, and these links can be traversed at a keystroke.

4. Zettel text and headlines can be searched.

5. Tags can be added and searched on.

6. If you follow my suggestions about using the @path directive for organizing nodes and @rst for the zettels, you can easily save the whole collection to a tree of text files.

7.  If you include those directives, and create the file system tree, the whole tree can be imported into my bookmarks manager, which provides other views of the relations between headings.

8.  If you make the zettel text to be Restructured Text, it will render nicely using the Viewrendered or Viewrendered3 plugin.  It's easy to make these kinds of notes be proper RsT, and thecommands I worked up for inserting node IDs and timestamps do insert them as RsT.

So I say we're ready to rock and roll!

[andyjim]

On Sunday, February 23, 2020 at 7:09:33 PM UTC-5, Thomas Passin wrote:

So I say we're ready to rock and roll!

 

Wonderful!  Didn't expect z-day anything like so soon.  I look forward to starting.

[Thomas Passin]

On Sunday, February 23, 2020 at 7:09:33 PM UTC-5, Thomas Passin wrote:

With the command to add a backlink, I would say that we have a working zettelkasten system that has essentially all the features of the original paper system, with better searching and reorganizing abilities.

I am attaching the requirements that I wrote up a while ago.  They may have changed a tiny bit since then. I just went over them and yes, I think that with the three commands I've come up with, and the outline structure, we meet everything in them.  Make sure to download the attached file and open it in a browser, since it is an HTML file.

#3, Simple Section Demarkations, is not specifically provided for.  But with the single-line notation like :cite: xxxxx, and the ability to use RsT to put in sections and things like footnotes, I think #3 is covered.

#10, Display Styles, is still a bit limited, but since you can build a tree section using clones, you can build any node arrangement you want in addition to the original tree.  I expect that eventually we'll know what other kinds of display we want, and a plugin would be a good place to put code for implementing them.

#11, Citations, can be done in any number of ways, and it might be different for different types of citations.  A URL of a web page can be put in, say, a :url: xxxx.edu kind of marked line.  Leo automatically makes that ctrl-clickable to open the web page.  Academic citations could be put in a :cite: xxxx line, and a set of zettels could be used to hold all the complete citations.  That's what the original zettelkasten did.

BTW, be aware that the ":meta-name: xxx"  RsT notation requires a space after the second colon character. RsT often wants to have a blank line at the end, and this is especially important if you merge a number of the nodes in a subtree together as viewrendered3 can.

[Edward K. Ream]

On Saturday, February 22, 2020 at 9:47:41 PM UTC-6, Thomas Passin wrote:

Attached is the Leo file for my little zettelkasten.  It includes @settings nodes for the commands and keyboard shortcuts for inserting the node id and timestamp.

This is excellent. The overall looks like a good Leonine prototype.

The structure uses @path nodes to create directories.  When you run the rst3 command on the tree, it will create a directory tree in the file system that matches the structure of the Leo outline.  The bookmark manager uses this directory structure to build its internal data structures linking different parts of the outline together.  This procedure also gives you the ability to export the files if you should ever want to move to some other system.

Is TM4J your bookmark manager? The .leo file has this broken link for .. _Zettels: file:///D:/Tom/devel/zettelkasten/zettel1/zettels.txt

Is there a web link?

So the @path directives are only needed if you plan to make use of the bookmark manager (when I get it ready for use).  Otherwise, you would still want those nodes, but they wouldn't have to have the @path directives.  Ultimately my plan is to use them with a Leo plugin to do the kind of linking I currently do in the bookmark manager.  So it would be wise to include the organizing nodes, and to give them meaningful titles. And even without the behind-the-scenes data structures, they will still be useful for searching in the Nav tab.

The @rst directives are only needed for using the rst3 command. But I think that's worthwhile.

Oh, and here is a command to open Explorer (Windows only) at the directory of the path of the current outline. 

I like this prototype a lot. Already the outline has answered a lot of questions.

Edward

[Edward K. Ream]

On Fri, Feb 21, 2020 at 1:05 PM Thomas Passin <tbp1...@gmail.com> wrote:

Bingo!  I had a brainstorm.  Now I know how we can use Leo to write text zettels, have them organized in a tree of files on disk - for almost no effort - and then use them in my bookmark manager.  We can have - right now, today - enough of zettelkasten functionality to start actually trying it out, so we can learn how best to author zettels and organize them, and have the bookmark manager link them up and provide the GUI.  The manager has some limitations, but we can either add functionality to it, or write code for Leo to do some of the additional things we want - as we use the system and find out what we really need.  And the zettels are automatically saved as text files, as we said we want.

Excellent. Working code (or in this case, a working outline), is worth gazillions of words and requirements :-) Much easier to understand.

Edward

[Thomas Passin]

On Monday, February 24, 2020 at 8:21:33 AM UTC-5, Edward K. Ream wrote:

On Saturday, February 22, 2020 at 9:47:41 PM UTC-6, Thomas Passin wrote:

Attached is the Leo file for my little zettelkasten.  It includes @settings nodes for the commands and keyboard shortcuts for inserting the node id and timestamp.

Is TM4J your bookmark manager?  Is there a web link?

Yes, that's right. There's only a link to an obsolete version that I wouldn't recommend.  I have to do some work on it to package it up so other people can use it.  For example, it uses batch files that use absolute paths, and the python parts of the codes are for v2.1 or maybe earlier.  It's a unix-like mix of batch files in a processing pipeline that uses batch, python, and xslt templates playing together.  We didn't have JSON back when I developed it (2003 - 2004), so there is an xslt template that actually is a code generator that outputs javascript code to build the data structures in the browser.  Awkward, but in return I didn't have to invent a syntax and an in-browser parser for it.  I'm sure it would have been easier to debug the code generator than to debug a parser.

I should work up the changes and packaging .. but not until I finish VR3!

 

The .leo file has this broken link for .. _Zettels: file:///D:/Tom/devel/zettelkasten/zettel1/zettels.txt

I copied the outline to a new one (my own has other things in the .leo file besides the zettelksten outline), but I should have cloned it instead because of course all the identifiers got changed.  I tried to correct them, but I might have missed something.  Also, any actual file references like that would be wrong.  IIRC, I was just experimenting with different ways to have clickable links, and that was probably one of them.  Obviously it wasn't the best way to go because of the absolute path.  It looks like it's pointing to one of the files generated by the rst3 command.  Just an experiment.

[Thomas Passin]

On Monday, February 24, 2020 at 8:22:56 AM UTC-5, Edward K. Ream wrote:

Excellent. Working code (or in this case, a working outline), is worth gazillions of words and requirements :-) Much easier to understand.

Often, yes, but a good set of requirements can help you to keep your eye on the ball so you end up with what you intend.  Of course, if you don't know that, then no requirements can help you!

[Thomas Passin]

Here is the code for the command that I mentioned before, to go to a node and insert a backlink in the target node.  I put this code into an @setting node with the headline:

@command zettel-goto-node @key=Alt+F6

The @setting node goes into the myLeoSettings.leo file.

This code could use a bit more work.  The main thing is that it may reorder the metadata lines in a zettel node.  This does not change any behavior, but I like to have those lines in a particular order.  I like them to start with the node id, then a timestamp, like this:

:id: TomP.20200221124629.1
:timestamp: 02/22/2020 08:24:58
:link: TomP.20200221221759.1 TM4J
:link: TomP.20200223153257.1

The order may get changed when the code inserts a new backlink in the target node because one did not exist before.

I decided to have the link meta-lines have optional labels, because they help you know which links goes where. In the older paper-based system, identifiers generally looked like this (from https://www.lesswrong.com/posts/NfdHG6oHBJ8Qxc26s/the-zettelkasten-method-1):

"I might have a train of thought which goes across cards 11, 11a, 11b, 11b1, 11b1a, 11b1a1, 18, 18a…"

All well and good, but a few months later, if you see "11b1a1" in a link, you probably won't know what it goes to.  You would have to fish around trying all the link references in your zettel to see which ones you might be interested it.

Using an optional label seems better.

[andyjim]

I suspect my overly long posts and attachment files`stirred the mild consternation over "gazillions of words" moreso than yours, Thomas.  And indeed, this process has helped me a lot to sharpen up my concepts.  When the time comes for me to bring up more of my wish list I will seek to be more concise about it. I reckon I have hitherto felt I need to justify and sell my ideas (in rich context), not just define them. Perhaps I don't need to do that, or maybe just learn to do it concisely. 

I still think Leo and Zettelkasten are a natural fit, and that Leo can significantly enhance the functionalities and value of Zettelkasten.  Thank you kindly, Edward, for supporting the project.

[andyjim]

On Monday, February 24, 2020 at 9:38:53 AM UTC-5, Thomas Passin wrote:

I decided to have the link meta-lines have optional labels, because they help you know which links goes where. In the older paper-based system, identifiers generally looked like [...]

Using an optional label seems better.

Very much agreed. It's hard to imagine a situation where we wouldn't want a literate label with any link, though there might be such a case.  Should/could the literate label precede the UID in the line, for prominance?

[andyjim]

On Saturday, February 22, 2020 at 11:05:32 PM UTC-5, Thomas Passin wrote:

Granted, you can't easily get a listing of all the tags - until we have a zettelkasten plugin that can create one - but you could maintain a zettel that only contains the tag names. It would be almost as good.

We do need some sort of indexing or search method list for tags and other handles. I'm still wondering exactly how Luhmann's indexing played out.  With 90k zettels it must have been efficient and effective indeed, for him to use the system so productively.  Seems like there's a whole layer (maybe more than one layer) of his system that we don't know enough about.  It seems like we might need to innovate something here.

 

I am unsure, though, whether to allow more than one link per line.  One link per line would be easier to write the code for, yet more than one would be easier to author and would reduce the visual clutter.

Personally I very much favor one link per line.

 

One of the types of links I'm very interested in is what I've called 'pointers', which is a poor term for what I mean. In addition to links to related zettels the notion of questions or germs of ideas for further thought is, I think, exceedingly creativity inducing.  The example in the format we saw I-forget-where appealed to me. The ideas/questions for further work followed after the body text (because the ideas were stimulated by the content of the text) and they would automatically create new zettels, which in turn could be indexed somehow so that, in a spare moment we can be stimulated by 'ideas to pursue'. The term 'pointers' came to mind meaning 'this points to another path to be investigated', but I'm sure there's a better term. In other uses of the system (besides notes), there could be other uses for such links; further work needing done on this part of a project, memos/comments...

[Edward K. Ream]

On Mon, Feb 24, 2020 at 7:46 AM Thomas Passin <tbp1...@gmail.com> wrote:

Is TM4J your bookmark manager?  Is there a web link?

Yes, that's right. There's only a link to an obsolete version that I wouldn't recommend.  I have to do some work on it to package it up so other people can use it.  For example, it uses batch files that use absolute paths, and the python parts of the codes are for v2.1 or maybe earlier.  It's a unix-like mix of batch files in a processing pipeline that uses batch, python, and xslt templates playing together.  We didn't have JSON back when I developed it (2003 - 2004), so there is an xslt template that actually is a code generator that outputs javascript code to build the data structures in the browser.  Awkward, but in return I didn't have to invent a syntax and an in-browser parser for it.  I'm sure it would have been easier to debug the code generator than to debug a parser.

I should work up the changes and packaging .. but not until I finish VR3!

:-) Thanks for the clarifications.

Edward

[Thomas Passin]

My current code has the link id preceding its label.  That's convenient for coding, and I think it looks well, too. Here's an example:

:link: TomP.20200221124629.1 Zettels

Having the label at the end makes it stand out more, at least to me, compared with having it embedded in the middle.

[Thomas Passin]

On Monday, February 24, 2020 at 2:28:05 PM UTC-5, andyjim wrote:

On Saturday, February 22, 2020 at 11:05:32 PM UTC-5, Thomas Passin wrote:

Granted, you can't easily get a listing of all the tags - until we have a zettelkasten plugin that can create one - but you could maintain a zettel that only contains the tag names. It would be almost as good.

We do need some sort of indexing or search method list for tags and other handles. I'm still wondering exactly how Luhmann's indexing played out.  With 90k zettels it must have been efficient and effective indeed, for him to use the system so productively. 

I can't emphasize enough how really useful the Nav tab is for searching.  And its display separates out node headlines hits from body hits.  It's also very fast, even with a very large Leo file. So if we used the following for tags:

:tag: some cool tag

Then we could just search for "g: some cool"  and we'd get all the matches. Clicking on one takes you right to that node.

 

Seems like there's a whole layer (maybe more than one layer) of his system that we don't know enough about.  It seems like we might need to innovate something here.

I gather that he used a overall index to the top level headings, and (I think) a separate set of slips for citations.

 

I am unsure, though, whether to allow more than one link per line.  One link per line would be easier to write the code for, yet more than one would be easier to author and would reduce the visual clutter.

Personally I very much favor one link per line.

I now definitely like one link per line, and the commandsI included with the sample zettelkasten  rely on that.

 

One of the types of links I'm very interested in is what I've called 'pointers', which is a poor term for what I mean. In addition to links to related zettels the notion of questions or germs of ideas for further thought is, I think, exceedingly creativity inducing.  The example in the format we saw I-forget-where appealed to me. The ideas/questions for further work followed after the body text (because the ideas were stimulated by the content of the text) and they would automatically create new zettels, which in turn could be indexed somehow so that, in a spare moment we can be stimulated by 'ideas to pursue'. The term 'pointers' came to mind meaning 'this points to another path to be investigated', but I'm sure there's a better term. In other uses of the system (besides notes), there could be other uses for such links; further work needing done on this part of a project, memos/comments...

Here's one way.  Create a new node for the idea-in-progress.  Refer to it this way:

.. note:: This is a simple **note** box.
    .. link: TomP.20200221124629.1 Zettels

It will format when rendered as a nice looking note box, and it would be easy to write a command to find the reference and go to it.  It wouldn't be much harder to have the command create the new node if it didn't exist.

[Thomas Passin]

Wondering what Luhmann's original zettel cards looked like?  This page has a photo of one -

https://emvi.com/blog/luhmanns-zettelkasten-a-productivity-tool-that-works-like-your-brain-N9Gd2G4aPv

Notice that he wrote the links in a different color.  The card seems to be mostly a collection of links, with only a bit of writing.

Note: Luhmann was the inventer of the zettelkasten.

[Marcel Franke]

Am Montag, 24. Februar 2020 20:28:05 UTC+1 schrieb andyjim:

 

I'm still wondering exactly how Luhmann's indexing played out. 

 He used manual maintained index-cards of keywords. Just big lists of keywords with reference-numbers which he used a startingpoint to dig into a topic. You can look it up in the Luhmann-Archive, where they scanned his whole papers & boxes and work now on digitizing the text.

With 90k zettels it must have been efficient and effective indeed, for him to use the system so productively. 

 You overhype Luhmann. That guy was famous because he was maintaining his system decades before personal computers and modern organisation-methods were a thing. By todays standard his system is not so special. It's basically just a web-forum on paper.

Seems like there's a whole layer (maybe more than one layer) of his system that we don't know enough about.  It seems like we might need to innovate something here.

 

That Layer is Luhmann himself. He didn't bother with system and details, but found something that worked for him and invested most of his life on filling it. There is no big secret behind his knowledgebase, it's just stupid manual labor over a long period of time. For most people this does not work, becuase they are busy with optimizing every single detail, building big complex buildings which they can't maintain anymore at some point, instead of just doing the simple things they original aimed for.

[Marcel Franke]

Am Dienstag, 25. Februar 2020 02:37:13 UTC+1 schrieb Thomas Passin:

Note: Luhmann was the inventer of the zettelkasten.

Ok, just for clarification: No he was not. Zettelkasten is a german word for a box (=kasten) of paperslips (=zettel). It's pretty common tool. People before Luhmann used them, people after Luhmann used them. Even his System is not really special, as most of it is just a simplified system of how librarys are organising books, Actually, libraries are pretty guilty in using Zettelkästen in very organised ways even today.

Luhmann is famous because he was successful in using those in things in a slightly different way then other people, while being famus enough to be recognized for it, and stuborn enough to use them for a long time.

[Thomas Passin]

All right; I've not seen the term "zettelkasten" applied to systems before Luhmann's got publicised.  I've been under the impression that his particular way of indexing and linking is what characterizes the term.  But yes, the word itself is pretty general and if we stick with a generic term we might as well just say "filing system" and be done with it.

To me, I don't really care much about detailed differences in how different people may have used similar systems.  I *am* interested in simplicity and usefulness, and what has worked.  And even if I tried to do things exactly as Luhmann seems to have done them, my own note collection would turn out to be very different because - I'm sure - I conceptualize and link things differently from the way he did.

In a sense, Luhmann's zettelkasten was nearly the same as the World Wide Web.  He had "resources" - his cards, and "links" - his index strings.  He also used backlinks, which can be added to a web page but it's not so easy to know how it could be done automatically, since you wouldn't want to add the URL of just any page that had a hyperlink to your target.

In this case, though, I'm interested in having a system that doesn't need to use someone else's web server.  I wouldn't mind using my own server on my own machine, but if it isn't necessary, so much the better. 

[Micah Joel]

There is something *very* much like the Zettelkasten addressing scheme in Ted Nelson's Xanadu project. Tumblers.

If ZK used numbers only and not alpha, and made the scope the entire 'docuverse' ...

https://en.wikipedia.org/wiki/Tumbler_%28Project_Xanadu%29

[Marcel Franke]

Am Dienstag, 25. Februar 2020 17:33:10 UTC+1 schrieb Thomas Passin:

All right; I've not seen the term "zettelkasten" applied to systems before Luhmann's got publicised. 

 Well, I can't speak for the etymology of the word. It's even in germany not the most popular usage for this word (today) and not the usual way to adress those paperslip-boxes.

But the usage seems to predate the recent Luhmann-hype by several decades. So I guess he did not coin the word.

I've been under the impression that his particular way of indexing and linking is what characterizes the term. 

 Yes, for some reasons there is a cargo-cult growing around Luhmann and his knowledge-system.

Which is kinda strange, as it's really not that special and we today have many better systems in use.

The only significant strength is the reference-system, and that only really works well with paperslips.

Maybe it's fueled from the ongoing active research regarding his work or because internet just works that way.

Before internet, people just used their tools in natural ways and didn't talk about the details much.

But today people share everything and talk about anything make a cult out of any little detail and trick&twist.

Details are important, they drive understanding, communication and research. But details you don't understand only lead down the wrong roads.

And even if I tried to do things exactly as Luhmann seems to have done them, my own note collection would turn out to be very different because - I'm sure - I conceptualize and link things differently from the way he did.

Indeed. The worth of any knowledge is not in the system generating it, but the work invested into building it, and the mind who did it.
People all use the same tools, yet they all produce different results, because the mindsa re different, not the tools.

In a sense, Luhmann's zettelkasten was nearly the same as the World Wide Web.  He had "resources" - his cards, and "links" - his index strings.  He also used backlinks, which can be added to a web page but it's not so easy to know how it could be done automatically, since you wouldn't want to add the URL of just any page that had a hyperlink to your target.

 Yeah, no, partly. WWW is a hypertext-system and decentraliced. The notable trait of a hypertext-system are hidden references,

meaning you have meaningful text with embedded references. Luhmann is also using references in text,

but the references have no meaning for the text. And using references in text is quite common in science.

The notable difference by Luhmann made is his reference-system.

But his general concept is akin to hypertext in the sense that it's also a graph-system. But then I would compare it more to a Wiki.

And classical wiki also lack embedded references, using direct in-text-references instead. WWW is not a knowledgebase, nor a limited system.

But Wikis, and also Luhmanns Zettelkasten are limited sytems and that makes them useful for this usecase.

In this case, though, I'm interested in having a system that doesn't need to use someone else's web server.  I wouldn't mind using my own server on my own machine, but if it isn't necessary, so much the better. 

 A server is just a technical detail. You can run it locally, in your own cloud, or generate the HTML in-app without a server.
But from a practical view, a server as a centralized single point of access has several advantages for tooling and handling of your data.

For my own system I also move to a server-solution as a managed layer around my data. Compromising with poor solutions is so painful on the long way.

[andyjim]

On Wednesday, February 26, 2020 at 5:24:19 AM UTC-5, Marcel Franke wrote:

 Yes, for some reasons there is a cargo-cult growing around Luhmann and his knowledge-system.

Which is kinda strange, as it's really not that special and we today have many better systems in use.

I really appreciate your comments here. I must frankly admit that the only reason I am barking up the zettelkasten tree is that I have failed to run across a better system, one better suited to my usage, which will be similar to, though of course not a replica of Luhmann's. If I can indeed discover an existing system that does what zettelkasten does and more and better, I for one will immediately abandon all interest in zettelkasten and quickly become an avid user and proponent of such a system. I am looking at zettelkasten only because I had despaired of finding something better.

So please, if you would, point us toward at least a few of the many better systems for this general type of usage that you have discovered. I do not think anyone here will object to the mention of specific softwares, and you could save us quite a lot of wasted effort reinventing the wheel when the wheel apparently is not that good to begin with.

Thanks much

[Thomas Passin]

Very relevant here are the repeated remarks in "Taking Smart Notes" - I have my copy now - that more important then slip-case details are how you take, write, and interconnect the slips.  It is that work that really makes all the difference.

With that in mind, I really want to start with a very simple computer system, one that has almost nothing to remember or get in the way.  So for now, I'm happy with my  outline structure, and the three keystroke commands I came up with.

I still am interested in using mindmaps together with the slip-case, though.  I just found viewer software for many of my old mind map files.  I used it to look at a mindmap that I used in a funding proposal over 15 years ago, one that I had forgotten about.  In a few minutes, it all came back to me.  I remember the proposed project and why I was interested in it, and the technical approach I wanted to take.

I haven't found any suitable free software so far (I'm not that taken with Freemind and Freeplane, though I may not have tried them long enough).  My concept right now is to export a section of the zettelkasten you are working with to a mind map (with the links) that opens in a new Leo panel, and a click on an object in the mind map would take you to the Leo node for that object in your zettelkasten, and possibly display the note in the panel too.  Best of both worlds!

[Marcel Franke]

Am Mittwoch, 26. Februar 2020 23:50:11 UTC+1 schrieb andyjim:

I must frankly admit that the only reason I am barking up the zettelkasten tree is that I have failed to run across a better system

You never played with Wikis? Or generally Hypertext?

though of course not a replica of Luhmann's.

Yes, that's the problem. When you won't go by the book, then focusing on Luhmann has no real purpose anyway, for this the system is just to simplified.
You better focus on the general area where his systems is located to find inspirations and answers. Which would mean Wiki, Hypertext, graphs and outliners.

Or are you specifically interessted in his addressing-system?

But in general you are not wrong here. Leo Editor can be used that way, even though it's not be the best for this. But it's not the worst either. It depends on how you polish it and yourself. Using Leo in a way to copy Luhmanns Zettelkasten could be done with 2-3 Simple functions. All you need is something to get the reference of node, and something to got from a link in text to the referenced node. First one is quite simple, just add an entry to the context-menu to get the leo-internal id. Second one could be achived by reusing the existing Hyperlink-Click-function and add support for links with leo:// as protocol. Then the rest is up to you to use it and fill your box.

But if you really aim to make proper use of Leo for this, I would advice you to learn at least some basic programing with leo. It's quite helpful to be able to import/export and sanitize your data automatically. Just be careful and make enough backups. Python is otherwise really simple to handle. And if you are comfortable enough with it, you can add more tools to handle your box.

you could save us quite a lot of wasted effort reinventing the wheel when the wheel apparently is not that good to begin with.

The wheel is as good as the driver using it. There is no magic software (yet) which can solve all those problems for you. At the end it always depends on the personal demand and abilities. Notetaking and knowledgemanagment is so personal; everyone has different demand, different habits and reasoning, different skills. From my experience, any workflow must be forged by the user themself over a long time. You can collect as many tools as you want, as long as you don't know how to wield them, they are worthless.

Though, it's true that starting simple is usually better. So maybe that's what people drive to Luhmanns Zettelkasten?

[Thomas Passin]

On Thursday, February 27, 2020 at 9:32:08 AM UTC-5, Marcel Franke wrote:

Am Mittwoch, 26. Februar 2020 23:50:11 UTC+1 schrieb andyjim:

But in general you are not wrong here. Leo Editor can be used that way, even though it's not be the best for this. But it's not the worst either. It depends on how you polish it and yourself. Using Leo in a way to copy Luhmanns Zettelkasten could be done with 2-3 Simple functions. All you need is something to get the reference of node, and something to got from a link in text to the referenced node. First one is quite simple, just add an entry to the context-menu to get the leo-internal id. Second one could be achived by reusing the existing Hyperlink-Click-function and add support for links with leo:// as protocol. Then the rest is up to you to use it and fill your box.

Just so. That's what I have worked out in some of the posts on this thread;  a small example, with working code for the three functions, is attached to my Feb 25 post on the thread  "Comments re the ZettelKasten work".  The idea is to have something as minimal and non-obtrusive as possible, yet still be useful.

[Marcel Franke]

Am Donnerstag, 27. Februar 2020 15:46:04 UTC+1 schrieb Thomas Passin:

But in general you are not wrong here. Leo Editor can be used that way, even though it's not be the best for this. But it's not the worst either. It depends on how you polish it and yourself. Using Leo in a way to copy Luhmanns Zettelkasten could be done with 2-3 Simple functions. All you need is something to get the reference of node, and something to got from a link in text to the referenced node. First one is quite simple, just add an entry to the context-menu to get the leo-internal id. Second one could be achived by reusing the existing Hyperlink-Click-function and add support for links with leo:// as protocol. Then the rest is up to you to use it and fill your box.

Just so. That's what I have worked out in some of the posts on this thread;  a small example, with working code for the three functions, is attached to my Feb 25 post on the thread  "Comments re the ZettelKasten work".  The idea is to have something as minimal and non-obtrusive as possible, yet still be useful.

Yes, that's also a way to do it. But I was talking more about a way to insert links in text, and let the choose. So you can have as many links in a node as you want.

After all that's some differences in Luhmanns system. But I guess this is not something that can be done in a @command or plugin.

But you could build a search-interface for listing multiple links in a node and choosing a target.

But funny that we both came up with the same colon-based-syntax for embedding metadata in nodes :)

BTW Using "created" instead of "timestamp" would be more self-documentating.

[Matt Wilkie]

any workflow must be forged by the user themself over a long time.

Yes!

It does help to start with capable and flexible tools that don't get in the way too much. Though this can be challenging as what counts as capable and flexible for each individual is quite varied. This is why I would underline or otherwise emphasize "over a long time". It takes time to learn and refine what works for ourselves, to adapt the tool to us and us to the tool.

One piece of advice I would give my younger self is that the pesonal knowledge management solution is process as much as tool and method and to allocate more attention to process.

-matt

[Thomas Passin]

On Thursday, February 27, 2020 at 10:31:57 AM UTC-5, Marcel Franke wrote:

Am Donnerstag, 27. Februar 2020 15:46:04 UTC+1 schrieb Thomas Passin:

But in general you are not wrong here. Leo Editor can be used that way, even though it's not be the best for this. But it's not the worst either. It depends on how you polish it and yourself. Using Leo in a way to copy Luhmanns Zettelkasten could be done with 2-3 Simple functions. All you need is something to get the reference of node, and something to got from a link in text to the referenced node. First one is quite simple, just add an entry to the context-menu to get the leo-internal id. Second one could be achived by reusing the existing Hyperlink-Click-function and add support for links with leo:// as protocol. Then the rest is up to you to use it and fill your box.

Just so. That's what I have worked out in some of the posts on this thread;  a small example, with working code for the three functions, is attached to my Feb 25 post on the thread  "Comments re the ZettelKasten work".  The idea is to have something as minimal and non-obtrusive as possible, yet still be useful.

Yes, that's also a way to do it. But I was talking more about a way to insert links in text, and let the choose. So you can have as many links in a node as you want.

In what I am suggesting, you can have as many links in a node as you like.  So I think we're covered here.

 

After all that's some differences in Luhmanns system. But I guess this is not something that can be done in a @command or plugin.

But you could build a search-interface for listing multiple links in a node and choosing a target.

 

I think the capabilities of the Nav tab will go a long way.  Eventually, a dedicated plugin may be useful, but I don't think that time is yet.  Think of it - if you type a search phrase into the Nav box, but don't type <ENTER> yet, it will show you all the headlines that contain the search phrase.  That will probably be all you need in many cases.  If not, you can go ahead and press <ENTER>, and in addition see all the bodies that have matching text.  It's true that you can't do boolean searches and wildstrings in the current Nav box, but presumable that could be a future enhancement.

And the Nav search is *fast*. I loaded the leoPyRef.leo outline, which contains much of the Leo codebase, and found a string in the last node.  Then I selected the root node and ran a Nav search for that string.  There was no perceptible delay.

But funny that we both came up with the same colon-based-syntax for embedding metadata in nodes :)

BTW Using "created" instead of "timestamp" would be more self-documentating.

That's up in the air for me.  Should it represent the creation time or the last-modified time?  @AndyJim sounded like he'd like to use a last-modified time, because he likes to see what he was working on at a certain period.  I don't want to add yet another piece of metadata if it's not needed.  It would be simple to modify the id insertion command to also insert a time the command was run, so it's doable if people think it would be important. Yet the Leo id does actually include a timestamp for the creation time.  It's just not formatted to be as readable.  So by inserting the id, we automatically have it anyway.

The way I see it working, if you are editing a note and you want to capture the timestamp, you just highlight the existing timestamp line and hit F7.  I haven't found that too intrusive.  It would quickly become automatic, if that's what you want to do.  And the command could be changed so you only would need to place the cursor somewhere on the timestamp line and press the key (F7 for me so far).

I'd like to settle on one specific name for that timestamp, though, and finalize it soon before I have too many nodes the other way.

[andyjim]

On Thursday, February 27, 2020 at 8:11:20 PM UTC-5, Thomas Passin wrote:

That's up in the air for me.  Should it represent the creation time or the last-modified time?  @AndyJim sounded like he'd like to use a last-modified time, because he likes to see what he was working on at a certain period.  I don't want to add yet another piece of metadata if it's not needed.  It would be simple to modify the id insertion command to also insert a time the command was run, so it's doable if people think it would be important. Yet the Leo id does actually include a timestamp for the creation time.  It's just not formatted to be as readable.  So by inserting the id, we automatically have it anyway.

I'd like to settle on one specific name for that timestamp, though, and finalize it soon before I have too many nodes the other way.

I'm afraid my preference and use case on this will complicate rather than simplify. You have to do what works for you, but what I personally am interested in is the date I first wrote the thought plus the date modified.  But to make it considerably worse, the items I want to import originated over a 25 year period. It is meaningful and helpful to me to know the date I wrote it. Somewhere in the process I will obviously have to enter original dates by hand for everything except a new unit for a new thought. I accept that. There is no way to automate it. The system's automated time stamp when the item is created is fine for a new thought, though uniform format for both situations would be nice. Personally, though American, I have gotten used to the European date format: YYMMDD and have come to prefer it. I've used it in filenames as well as internally in files for about five years now (actually I hyphenate it: YY-MM-DD).

But that's just me. You must do what works for you.  Bottom line is you must work within the limitations of Leo and also your time and interest budget for this project. I already know and accept that my personal vision for all that would go into my own optimal system is way too ambitious for the scope of this project.

Another ugly and inconvenient question: Are you contemplating a command to automate starting a new zettel (is it ok to use that term for the time being? I gather you plan to find a new term.)?  Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing.  I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel, that I might end up not using the system.  Currently all I do to start a new thought is skip a line and write. I never have to shift attention to accomplishing a mechanical process before I can start writing the new thought.  For my very peculiar (and inconvenient) profile of creative thought process I need it to be very nearly that simple, quick and non-distracting.

It's this kind of thing that leads me to say you must do what works for you. I think even trying to meet some of my nastier requirements would impose way too much load for what you are able to invest in this project.

[Marcel Franke]

Am Freitag, 28. Februar 2020 02:11:20 UTC+1 schrieb Thomas Passin:

I think the capabilities of the Nav tab will go a long way. 

True, there is also that. I always forget it, because it's so bad UX.

BTW Using "created" instead of "timestamp" would be more self-documentating.

That's up in the air for me.  Should it represent the creation time or the last-modified time? 

Both have value, so add both.

 I don't want to add yet another piece of metadata if it's not needed. 

 It's always better to collect more than neccessary than to some day miss what's needed. Storage is cheap.

Yet the Leo id does actually include a timestamp for the creation time. 

It's not expliciet, nor portable. You must be aware of it when you decide to change the ID or software some day.

And this is something which can be easily move out of sight. Ok, that's my habits as a devloper shining.

Non-devs probably see it different. But general experience with those things is that they should be clear.

I'd like to settle on one specific name for that timestamp, though, and finalize it soon before I have too many nodes the other way.

Strictly spoken, the name alone is not much of a problem. One can always write a script for mass-changing this. that is the advantage of structured data.

What it can't do is adding missing data. But of course I only speak from perspektive of a developer, so take it with a grain.

[Marcel Franke]

Am Freitag, 28. Februar 2020 04:51:42 UTC+1 schrieb andyjim:

Another ugly and inconvenient question: Are you contemplating a command to automate starting a new zettel (is it ok to use that term for the time being? I gather you plan to find a new term.)?  Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing.

I have a function bind to a key doing that and can confirm, it's very useful to have a new entry generated and focused instantly.

I also let it search the proper node in the my prefered leo-file, so it will always created at the same location.

  I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel,

Leo has a function to replace text as you type ( http://leoeditor.com/abbreviations.html ), which you could use to create a new entry from  template in an empty node.

But what do you mean with title? Leo does not force you to use a title, but for something meaningful you can't automate this, or do you?

 

[Thomas Passin]

On Thursday, February 27, 2020 at 10:51:42 PM UTC-5, andyjim wrote:

Another ugly and inconvenient question: Are you contemplating a command to automate starting a new zettel (is it ok to use that term for the time being? I gather you plan to find a new term.)?  Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing.  I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel, that I might end up not using the system.  Currently all I do to start a new thought is skip a line and write. I never have to shift attention to accomplishing a mechanical process before I can start writing the new thought.  For my very peculiar (and inconvenient) profile of creative thought process I need it to be very nearly that simple, quick and non-distracting.

Here's what I've been doing, and I find it very unobtrusive.  I create a new node where I want it, using the usual <CTRL>-I.  Of course, I type in the node's name as usual. Then <ALT>-F8, <ALT>-F7.  I hardly notice I'm doing it.  It would be easy to combine all three of these commands in a single keystroke, but so far I haven't felt the need.

[Thomas Passin]

On Thursday, February 27, 2020 at 10:51:42 PM UTC-5, andyjim wrote:

. Personally, though American, I have gotten used to the European date format: YYMMDD and have come to prefer it. I've used it in filenames as well as internally in files for about five years now (actually I hyphenate it: YY-MM-DD).

This one is easy to adjust.  You would put another setting into MyLeoSettings.py with the time format you want.  If you like, myself or someone could write down the string format for your particular format. The name of the setting is

body-time-format-string

 

[Thomas Passin]

On Thursday, February 27, 2020 at 10:51:42 PM UTC-5, andyjim wrote:

 Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing.  I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel, that I might end up not using the system.  Currently all I do to start a new thought is skip a line and write.

I think in terms of one node per zettel.  Leo will let you have a node without a headline - that is, the name of the node - but I think that's asking for trouble, so I always give it a name.  These names are very helpful when you scan a group of zettels, and when searching.  So for me, I always want a node name, and I consider that to be the title of the zettel,  I don't have to type it into the zettel itself.

If you want to type in a stream of consciousness manner, then it would be easy to write a script to split the text into separate nodes.  The script would need some way to know where to split.  That could be, say, two blank lines in a row - if you will never use two blank lines for anything else -  my preferred marker of '===========================', or something similar.

The script would not be able to divine a name for the new nodes, though.  So you still would need some way to designate that.  The easiest thing would be to use the first line after the marker as the title.

This wouldn't be too intrusive for you, would it?

[Thomas Passin]

On Friday, February 28, 2020 at 8:49:45 AM UTC-5, Thomas Passin wrote:

On Thursday, February 27, 2020 at 10:51:42 PM UTC-5, andyjim wrote:

 Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing.  I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel, that I might end up not using the system.  Currently all I do to start a new thought is skip a line and write.

I revised the command to insert an ID, so that it also inserts the creating date.  Here's the new script:

"""Insert a node id/tomestamp string at the cursor."""
undoType = 'zettel-insert-id'
w = c.frame.body.wrapper
oldSel = w.getSelectionRange()
w.deleteTextSelection()
s = ':id: ' + p.gnx
id_label = f':id: {p.gnx}\n'
time_string = ':created: ' + c.getTime(body=True) + '\n'

i = w.getInsertPoint()
w.insert(i, f'{id_label}{time_string}')

c.frame.body.onBodyChanged(undoType, oldSel=oldSel)

Now to create a new node for a zettel, create a node, type in its name, click the mouse in the body, and hit <ALT>-F8 (or bind it to any other key you like).  You get both the id line and a second line that starts with :created:.

The headline of the node for this command in MyLeoSettings would be

@command zettel-insert-id @key=Alt+F8

[Thomas Passin]

On Friday, February 28, 2020 at 5:37:53 AM UTC-5, Marcel Franke wrote:

Am Freitag, 28. Februar 2020 02:11:20 UTC+1 schrieb Thomas Passin:

BTW Using "created" instead of "timestamp" would be more self-documentating.

That's up in the air for me.  Should it represent the creation time or the last-modified time? 

Both have value, so add both.

 I don't want to add yet another piece of metadata if it's not needed. 

 It's always better to collect more than neccessary than to some day miss what's needed. Storage is cheap.

It's not about storage, it's about reducing visual clutter in the text.

 

Yet the Leo id does actually include a timestamp for the creation time. 

It's not expliciet, nor portable. You must be aware of it when you decide to change the ID or software some day.

Well, that's a point.  I had pictured running some script over all the notes to pick out the time format from the id string when and if you decided to change.  So there wouldn't need to be a separate line for the creation time. After all, how likely is it that some other system could used the exact format of the zettels with no change at all?  But maybe it would be good to have that creation string be in the same, more readable format as the timestamp date I'm already providing.

 

And this is something which can be easily move out of sight. Ok, that's my habits as a devloper shining.

Non-devs probably see it different. But general experience with those things is that they should be clear.

I'd like to settle on one specific name for that timestamp, though, and finalize it soon before I have too many nodes the other way.

Strictly spoken, the name alone is not much of a problem. One can always write a script for mass-changing this. that is the advantage of structured data.

What it can't do is adding missing data. But of course I only speak from perspektive of a developer, so take it with a grain.

A good developer puts on the hat of a user, and switches back and forth, all the time.  Though that user might be the developer's own self because the developer wants to use the system once developed.

More important than capturing all the metadata one might ever want, is to make the system backwards compatible so that if you add something later, the earlier work is still as usable as ever.

[Marcel Franke]

Am Freitag, 28. Februar 2020 15:19:38 UTC+1 schrieb Thomas Passin:

 It's not about storage, it's about reducing visual clutter in the text.

Understandable. I have that problem too. Im thinking about moving my metadata to p.v.u
and adding a metadata-widget on the editor-side to not forget them. But this makes
exporting data a bit more cumbersome.

Something other I think about is adding alternative editor-widgets, so you can choose preferable view
per data, which then would just show an editor with embedded metadta-view, while the node-content would
stay together as it is now. But this demands some patches in leo, which cumbersome in it's own way.

 After all, how likely is it that some other system could used the exact format of the zettels with no change at all?

Well, I use the same metadata-format...and probably some people might be starting using it too at some point.
Why should this be a problem? It's not like we all share our personal data.

From your other mail:

 I revised the command to insert an ID, so that it also inserts the creating date.  Here's the new script:

Something you may be interessted for this:

    new = c.insertChild()
    new.b = f'{id_label}{time_string}'

I'm not sure about about focus on the title in this case, as I removed this. But this should simplify your code and process.

It creates a child-node, gives it focus and sets the body-text.

If the headline is not in edit-mode, you can try calling c.editHeadline()

[Thomas Passin]

On Friday, February 28, 2020 at 10:47:05 AM UTC-5, Marcel Franke wrote:

Something you may be interessted for this:

    new = c.insertChild()
    new.b = f'{id_label}{time_string}'

I'm not sure about about focus on the title in this case, as I removed this. But this should simplify your code and process.

It creates a child-node, gives it focus and sets the body-text.

Yes, that would be a way to get everything done with one keystroke.  The reason I haven't moved to to doing it this way is only because I have thought that it would be better to stay with good old <CTRL>-I for node insertions.  It's an interesting little UX question, isn't it?

[andyjim]

On Friday, February 28, 2020 at 5:52:09 AM UTC-5, Marcel Franke wrote:

I have a function bind to a key doing that and can confirm, it's very useful to have a new entry generated and focused instantly.

I also let it search the proper node in the my prefered leo-file, so it will always created at the same location.

  I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel,

Leo has a function to replace text as you type ( http://leoeditor.com/abbreviations.html ), which you could use to create a new entry from  template in an empty node.

I would like to learn how to do that.  And how to make the appropriate template to create a new 'zettel' in Thomas' format.

But what do you mean with title? Leo does not force you to use a title, but for something meaningful you can't automate this, or do you?

In Thomas Passin's prototype, which I downloaded, 1st he types a title heading, 2nd a @rst subheading, with title (for Sphinx, which is fine), 3rd a @path heading, with title, 4th a @rst subheading, again with title, and that 4th node is our zettel.  Four new nodes, four titles before I start writing.  At least that is how I understand it (Thomas correct me).  For me that is a lot of overhead and distraction before I can start typing.  I don't even want to decide upon a title, because I may not know yet what the best title should be.  I just want to hit a hot key and start writing/thinking.  Title can come after I've completed the thought.

You see Thomas, in his posts below, holding my hand.  That's because I am a Leo newbie and also I'm not a programmer.  Everything in this playground is baby steps for me, which is why I am leaning on Thomas, who is taking the lead on this.  I am a pain in the derriere to these great folks, but so far they haven't thrown me out.

[andyjim]

On Friday, February 28, 2020 at 8:31:34 AM UTC-5, Thomas Passin wrote:

Here's what I've been doing, and I find it very unobtrusive.  I create a new node where I want it, using the usual <CTRL>-I.  Of course, I type in the node's name as usual. Then <ALT>-F8, <ALT>-F7.  I hardly notice I'm doing it.  It would be easy to combine all three of these commands in a single keystroke, but so far I haven't felt the need.

Ok, I just did that. But I don't understand why we went through the four headings to create the node in your prototype (I copied that for my first attempt), but for this new one all we do is write the title and then ID it and time stamp it and that's our zettel. One heading instead of four. No @rst headings, no @path heading. Don't understand what's going on.

Also realized I don't have to title it until I'm darn good and ready.  And I don't have to ID it and time stamp it before writing either. I can do those later as well.  All of that is a great help, yet my optimum situation would still be: no matter where I am in my system, when a new thought strikes, I just hit a hot key and start typing.  I don't have to locate and go to the outline where I want the new zettel, position the focus and the cursor where I want the new zettel.  Probably I don't even know yet where I will want it, but at any rate I don't want to think about any of that. Just hit a hot key and type. Take care of all the overhead later, after I've completed the thought. 

With The Archive zettelkasten software, for example, you hit command-N and start typing. That simple. In Mr. Luhmann's case, he pulls a new blank slip from his supply, directly to hand I presume, and starts writing.  Does the overhead later. And people thought this pure genius!  Maybe it is.

I'm not easy to get along with, am I?  And your proper response to me, I would think, will be, "Son, if you want things exactly your way like that, learn python and Leo yourself and learn how to make stuff like that happen!"

[Thomas Passin]

On Friday, February 28, 2020 at 10:29:54 PM UTC-5, andyjim wrote:

In Thomas Passin's prototype, which I downloaded, 1st he types a title heading, 2nd a @rst subheading, with title (for Sphinx, which is fine), 3rd a @path heading, with title, 4th a @rst subheading, again with title, and that 4th node is our zettel.  Four new nodes, four titles before I start writing.  At least that is how I understand it (Thomas correct me).  For me that is a lot of overhead and distraction before I can start typing.  I don't even want to decide upon a title, because I may not know yet what the best title should be.  I just want to hit a hot key and start writing/thinking.  Title can come after I've completed the thought.

I agree, and as I said earlier, I only used the @rst and @path in the node names because I wanted a quick and dirty way to export the tree to the file system.  And I only wanted that at the start because I wanted to see how it integrated with my bookmark manager.

I'm not doing that any more, because I'm convinced that writing an exporter will be pretty easy.  If you download the more recent example I posted, which has only the node name in the headline, (and change to the latest version of the insert-id command I also posted) the process goes like this:

1. <CTRL>-I to create a new node. Type the node title you want into the headline.

2. Click in the body (in the future, we will move the cursor into the body as part of the insert-id command if that's what people want).

3. <ALT-F8> to insert the id and timestamp at the same time.

4. Start typing.

You would have to do 1, 2 and 4 anyway, to get a new node.  So step 3 is the only new step, and I've found it's very quick and becomes automatic very soon.

Oh, by the way, to get the timestamp format you said you like, create a node as a child of the @settings node in MyLeoSettings,leo.  Paste the following into the node's headline (i.e., its name):

@string body-time-format-string = %Y-%m-%d %H:%M:%S

Or you can even put it into the leo file that has your zettelkasten (ZK).  Then reload the settings, using the Settings menu (Settings->Reload Settings->Reload-All-Settings).

If you put it into the ZK leo file, it will affect the format of the timestamp for only that leo file.  If you put it into MyLeoSettings.leo, it will apply to all outlines.

I have already done this on my system.

If you want to type a lot of material into a node and then split it out later, we can write a command to do that splitting for you, as long as you are willing to insert some kind of separator between the sections to be split.  If the first line after the separator was always a title for the node, that would be even better.  Otherwise you would have to add a title for each of the split-out nodes after they were created.

But don't forget, the published suggested way to get the most out of the system is to think carefully about the contents of each zettel.  Creating and naming a new node would be a small part of that effort.

[Thomas Passin]

On Friday, February 28, 2020 at 11:28:37 PM UTC-5, andyjim wrote:

Also realized I don't have to title it until I'm darn good and ready.  And I don't have to ID it and time stamp it before writing either. I can do those later as well. 

That's exactly right.  For myself, I don't like to have unlabeled nodes floating around, because I forget pretty soon what they are supposed to be, especially if there are more than one.  The ID will never change, so you can put it in any time.  The "create" timestamp will just be whenever you put it in.  That seems fine to me.

 

All of that is a great help, yet my optimum situation would still be: no matter where I am in my system, when a new thought strikes, I just hit a hot key and start typing.  I don't have to locate and go to the outline where I want the new zettel, position the focus and the cursor where I want the new zettel. 

The way I am picturing it, when you say "hit a hot key", I think that you mean "create a new node".  I do that by hitting <CTRL>-I.   Isn't how you do it already?  That gives you a new node.  Click in the body and start typing, give it a name and get the id/timestamp later. 

If you don't mean that, now would be a good time to say so.

For any node (zettel), where ever it is at the moment, that's not cast in concrete.  You can always move it around later.  That doesn't change the id.

 

Probably I don't even know yet where I will want it, but at any rate I don't want to think about any of that. Just hit a hot key and type. Take care of all the overhead later, after I've completed the thought. 

Right, that's just what you get with <CTRL>-I.  The only difference is that the node comes up with the cursor in the headline instead of the body.  If that's what you really want, we could change current insert-id command (as I think I said in my previous post) so that it creates a new node, inserts the id and timestamp, and puts the cursor in the body for you.

 

With The Archive zettelkasten software, for example, you hit command-N and start typing. That simple. In Mr. Luhmann's case, he pulls a new blank slip from his supply, directly to hand I presume, and starts writing.  Does the overhead later.

From my reading, he immediately numbered it. Then he added links to other likely zettels.  And then he got into the writing.  He didn't write these slips quickly, but only after mulling over temporary notes he had taken previously.  Maybe temporary notes are really what you have in mind here.  My own notion for that is to have a top-level node, maybe outside the zettelkasten top-level node but in the same leo file.  These temporary notes would all go there.

We could even have the hot-key put the new node into the temporary notes section, if that's what you want.  From a programming point of view, there would have to be a node with a fixed name, like "temporary notes".  Otherwise the command behind the hot key wouldn't know where to put the new node.  If you don't want that, it would just create the new node right where you are in the ZK, and you could move it yourself.  We already just about have that, with <CTRL>-I.

 

And people thought this pure genius!  Maybe it is.

I'm not easy to get along with, am I?  And your proper response to me, I would think, will be, "Son, if you want things exactly your way like that, learn python and Leo yourself and learn how to make stuff like that happen!"

No, not necessarily.  This kind of back-and-forth is needed to home in on how the thing should work. Well, there's going to be a limit to how much time someone is willing to spend on a feature that you want one way but they don't think it should work that way.  As long as we are figuring that out together, to come up with features that could be fairly general, it's all good.

[andyjim]

On Saturday, February 29, 2020 at 12:28:27 AM UTC-5, Thomas Passin wrote:

From my reading, he immediately numbered it. Then he added links to other likely zettels.  And then he got into the writing.  He didn't write these slips quickly, but only after mulling over temporary notes he had taken previously.  Maybe temporary notes are really what you have in mind here.  My own notion for that is to have a top-level node, maybe outside the zettelkasten top-level node but in the same leo file.  These temporary notes would all go there.

I think something like that is exactly what I need.  Luhmann didn't capture his ephemeral note with a computer.  I expect it went in the wastebasket after he gave it careful consideration and wrote a well-thought out zettel from it.  What I want to do is really just a tweak on that. I want to capture the ephemeral note, the spontaneous thought, on a blank slip with no title. Then after I chase that thought and write it well enough for the moment, I'll place it in the system by entering headings, tags, keywords, links, pointers.  Or, I don't even have to do that until another time.

I think a 'slush file', a file even of untitled slips is probably the solution for my crazy thought process. That way I'm not constrained in any way, except that at some point I have to complete the task of headings, titles, tags, keywords, links, pointers. I do like the idea of the first line being the default title if I don't enter a title myself. 

We could even have the hot-key put the new node into the temporary notes section, if that's what you want.  From a programming point of view, there would have to be a node with a fixed name, like "temporary notes".  Otherwise the command behind the hot key wouldn't know where to put the new node.  If you don't want that, it would just create the new node right where you are in the ZK, and you could move it yourself.  We already just about have that, with <CTRL>-I.

I think that's the solution for my use case. If, for example, as in The Archive, Command-N (no matter where I am at the moment) creates a new zettel, in the 'temporary notes' node, plants the id, and the 'created' timestamp, and shifts focus to the body, then I have a distraction-free way to immediately capture a new thought bubble. This will cleanly initiate the process of thought capture.  I might want a 'back button' to take me back where I was before this event, but that's another matter for another day.

Then I have the process of entering all the 'hooks' (headings, tags, title, keywords, links, pointers, references, each of which is a different type, a different hook for searches), but I can do that whenever I 'get a round tuit'.  That too is a process of creative thinking, but a very different one from the spontaneous process of capturing the bubbles.  And it is an enormous relief, believe me, to separate these two creative processes, each of which is an adventure in its own right, but each of which can interfere with the other if you try to do them both at once. At least that's the way my crazy mind works.

No, not necessarily.  This kind of back-and-forth is needed to home in on how the thing should work. Well, there's going to be a limit to how much time someone is willing to spend on a feature that you want one way but they don't think it should work that way.  As long as we are figuring that out together, to come up with features that could be fairly general, it's all good.

Thanks, I'll try to keep enunciating my wild ideas about how it should work, and you keep doing only what you have space and energy to do.  I get that.  Likely none of us will ever see our ideal vision play out.  But that won't keep us from wishing.

[Thomas Passin]

On Saturday, February 29, 2020 at 9:59:33 AM UTC-5, andyjim wrote:

[snip]

On Saturday, February 29, 2020 at 12:28:27 AM UTC-5, Thomas Passin wrote:

I think that's the solution for my use case. If, for example, as in The Archive, Command-N (no matter where I am at the moment) creates a new zettel, in the 'temporary notes' node, plants the id, and the 'created' timestamp, and shifts focus to the body, then I have a distraction-free way to immediately capture a new thought bubble. This will cleanly initiate the process of thought capture.  I might want a 'back button' to take me back where I was before this event, but that's another matter for another day.

Here is a modified version of the "Insert-Zettel" command.  It creates a new node. inserts the id and creation date, and puts the cursor in the node under them ready to type.  It doesn't locate the new node in a "temporary" part of the outline - that could be added later. 

"""Insert a node with id and creation timestamp strings"""
undoType = 'zettel-insert-node'
c.k.simulateCommand('insert-node')

w = c.frame.body.wrapper
oldSel = w.getSelectionRange()
w.deleteTextSelection()
s = ':id: ' + p.gnx
id_label = f':id: {p.gnx}\n'
time_string = ':created: ' + c.getTime(body=True) + '\n'

i = w.getInsertPoint()
w.insert(i, f'{id_label}{time_string}')

c.bodyWantsFocusNow()
c.frame.body.onBodyChanged(undoType, oldSel=oldSel)

To use this command, delete the old @setting node for inserting the id, and then create a new @setting node with the headline

@command zettel-insert-node @key=Alt+F8

Paste the code above into this new node.  The new node has be a child of an @settings node in either your MyLeoSettings.leo file or your ZK leo file, so move it as needed.  Then reload the settings.  The hot-key will be ALT-F8.

If you decide you'd rather leave the cursor in the node's headline instead, change the next to last line so it reads like this:

#c.bodyWantsFocusNow()

This will turn the line into a comment and cause it not to be executed.

[andyjim]

On Saturday, February 29, 2020 at 11:30:58 AM UTC-5, Thomas Passin wrote:

Paste the code above into this new node.  The new node has be a child of an @settings node in either your MyLeoSettings.leo file or your ZK leo file, so move it as needed.  Then reload the settings.  The hot-key will be ALT-F8.

Ok, added it to my current Leo zk file. What it does now:

  does not create new node

  inserts id line in the body of the selected node

  does not insert timestamp

  does not shift focus to the body

If I hit it again, repeats the id line under the previous one, same id number

Added it also to myLeoSettings file; same thing

Removed it from the Leo zk file, leaving it in the myLeoSettings file; same thing.

Then realized I didn't know what 'reload settings' entails. Did Settings>Reload Settings>Reload-Settings, also Reload-All-Settings.

Same thing.

Finally I quit Leo and restarted.  Now it does not respond to Alt-F8 at all. Still responds correctly to Alt-F7. Also, for some reason it dropped all tabs except the one I had open when I quite Leo. Before it has reloaded all tabs I had when I shut down.

[andyjim]

On Friday, February 28, 2020 at 8:36:29 AM UTC-5, Thomas Passin wrote:

This one is easy to adjust.  You would put another setting into MyLeoSettings.py with the time format you want.  If you like, myself or someone could write down the string format for your particular format. The name of the setting is

body-time-format-string

Looks like I do need help on that. A search did not find it in Leo help. I think the best for the 'created:' line would be YYYY-MM-DD. I don't see the need for HH-MM-SS, as I just want to know the date created. I prefer hyphens to slashes.

example: "created: 2020-02-29"

Now, I want the 'created' date to refer to the date the original content was created, not the date the zettel was created, so while it's fine to automate it for a new note in a new zettel, I'll need to be able to reset that data manually for imported items, which go back to 1990. Maybe when the parser sees a "created:" line in the formatted zettel-to-be-imported, it accepts it and does not insert a 'created:' line.

I also would like to know last modified date, but that complicates it I'm sure. My own preference would be that it auto-updates the 'modified' date whenever the file saves. Sometimes imported files will have both 'created' and 'modified' dates, as I do enter those in files I write.

[Thomas Passin]

On Saturday, February 29, 2020 at 8:01:42 PM UTC-5, andyjim wrote:

On Saturday, February 29, 2020 at 11:30:58 AM UTC-5, Thomas Passin wrote:

Paste the code above into this new node.  The new node has be a child of an @settings node in either your MyLeoSettings.leo file or your ZK leo file, so move it as needed.  Then reload the settings.  The hot-key will be ALT-F8.

Ok, added it to my current Leo zk file. What it does now:

  does not create new node

  inserts id line in the body of the selected node

  does not insert timestamp

  does not shift focus to the body

Hmm, it's working on my system.  The command needs to be the child of an @settings node - meaning that the name of the node is @settings.  Normally that node is the first node in the file, but I don't know if that is required or not.

 

If I hit it again, repeats the id line under the previous one, same id number

Added it also to myLeoSettings file; same thing

Removed it from the Leo zk file, leaving it in the myLeoSettings file; same thing.

Then realized I didn't know what 'reload settings' entails. Did Settings>Reload Settings>Reload-Settings, also Reload-All-Settings.

Same thing.

You always need to do Reload Settings after any change like this to the settings.

Finally I quit Leo and restarted.  Now it does not respond to Alt-F8 at all. Still responds correctly to Alt-F7. Also, for some reason it dropped all tabs except the one I had open when I quite Leo. Before it has reloaded all tabs I had when I shut down.

I don't have a mac, but I installed the commands on a linux version -- I'm running one in a virtual machine.  It doesn't work there, either.  This is a shock to me - everything in the code should work no matter what the OS.  I'll see if I can track down what's going on.

[Thomas Passin]

On Saturday, February 29, 2020 at 11:02:07 PM UTC-5, Thomas Passin wrote:

I don't have a mac, but I installed the commands on a linux version -- I'm running one in a virtual machine.  It doesn't work there, either.  This is a shock to me - everything in the code should work no matter what the OS.  I'll see if I can track down what's going on.

The commands work on linux (and I was able to remove some unnecessary code).  The problem seems to be that Linux intercepts Alt-F8 and Alt-F7 for its own purposes (like resizing a window).  Presumably it's more or less the same on the Mac.  I'm trying to come up with alternate shortcut keys that aren't in use by either the OS or Leo.

[Xu Wang]

I tried to figure out which key is "Alt" on Mac, but never find out.

The "Command" key is catched as Ctrl,  the "Control" and "Option" key are all catched as Meta on my MacBook.

Thomas Passin <tbp1...@gmail.com> 于2020年3月1日周日 下午12:36写道：

On Saturday, February 29, 2020 at 11:02:07 PM UTC-5, Thomas Passin wrote:

I don't have a mac, but I installed the commands on a linux version -- I'm running one in a virtual machine.  It doesn't work there, either.  This is a shock to me - everything in the code should work no matter what the OS.  I'll see if I can track down what's going on.

The commands work on linux (and I was able to remove some unnecessary code).  The problem seems to be that Linux intercepts Alt-F8 and Alt-F7 for its own purposes (like resizing a window).  Presumably it's more or less the same on the Mac.  I'm trying to come up with alternate shortcut keys that aren't in use by either the OS or Leo.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/0906031d-4c80-4c6e-b0be-9d43fd0e10e1%40googlegroups.com.

[andyjim]

On Sunday, March 1, 2020 at 12:36:28 AM UTC-5, Thomas Passin wrote:

The commands work on linux (and I was able to remove some unnecessary code).  The problem seems to be that Linux intercepts Alt-F8 and Alt-F7 for its own purposes (like resizing a window).  Presumably it's more or less the same on the Mac.  I'm trying to come up with alternate shortcut keys that aren't in use by either the OS or Leo.

Both Alt-F8 and Alt-F7 worked correctly initially. Alt-F7 still does.  I'll reinstall the first Alt-F8 command and see if it works as it did before (as soon as I find it again).

[Thomas Passin]

I changed the hot keys  to Ctrl+F8. Ctrl+F7, Ctrl+F6.  They don't seem to conflict with either the OS hot keys, or Leo key assignments.  According to what @Austin(Xu)Wang wrote above, you might have to edit them to use "Meta" instead of "Ctrl".

I also fixed a bug I hadn't known about for the insert new zettel command.  I've attached the revised leo file with the commands.  Just replace the old version with it.  This file with the revised commands works for me on both Windows and Linux.

[andyjim]

On Sunday, March 1, 2020 at 11:36:00 AM UTC-5, Thomas Passin wrote:

I changed the hot keys  to Ctrl+F8. Ctrl+F7, Ctrl+F6.  They don't seem to conflict with either the OS hot keys, or Leo key assignments.  According to what @Austin(Xu)Wang wrote above, you might have to edit them to use "Meta" instead of "Ctrl".

I also fixed a bug I hadn't known about for the insert new zettel command.  I've attached the revised leo file with the commands.  Just replace the old version with it.  This file with the revised commands works for me on both Windows and Linux.

It works in your file. I deleted the @settings node in my file and copied yours to it. Reloaded All Settings. Does not work. I opened a new file and copied it into that, reloaded All Settings. Does not work. Still works in your file. 

Wow.  A puzzle.

Ok, restarted Leo. Now it works.

[Thomas Passin]

I always save the file after a change to any @settings.  I'm no sure, but I *think* that Reload Settings saves all the changed files, but I'm not sure so I play it safe.  And I have also had cases where I had to restart Leo to get a setting to work.  Dunno why.

[andyjim]

I've begun to use it.

And already I see that I could use a command to slap a UID into an already existing zettel that doesn't yet have one. I can do it (and have done it) by making a new zettel and copy-pasting the body of the old one to the new one, then delete the old, but that's a bit cumbersome.

Oh boy, this gets complicated quickly. I'll also need to be able to select a section of a file and create a zettel out of it. It can go in a to-be-dealt-with node.  Maybe these are actually parser functions.

Eventually I hope, at least my vision hopes, to 'run the show' from inside the zettels. For example, I prep an external (or it can be an already imported file) for the leokasten and turn the parser loose on it.  What I want to happen, what happens in my vision, is the prepped zettels in the file are brought in, placed in their proper headings with all the hooks in place. Hooks meaning headings, title, subtitle, abstract, tags, body, links, keywords, sum-next, pointers, references/citations,  Most of these optional but all of them supported, is the idea.

And they are all written into the zettel, so the system just reads the zettel, does all the behind the scenes work, and I have virtually no overhead because I've done it all right there in the zettel. Plus I can alter or add anything later, which is essential in building up the network of interlaced connections.

I know. Soon you're going to have to tell me to go sit in the corner and shut up. Probably right after the following:

I have yet another Luhmann-based concern.  Luhmann's numbering system created ordered, branched threads, meaningfully connected, meaningfully ordered. It wasn't just a way to create UIDs, though the numbers did also serve as UIDs. If he were to pull out all the cards numbered under "37", for example, it would be an ordered, multi-branched tree of sequenced thoughts. When he had a link from some card under "16" to some card under "37", in effect it created a link, not just between those two cards, but between one ordered, branched tree and another.  He could pull out the entire tree(s) and walk up and down the sequence, investigating its branches in search of usable ideas. 

I think Zettelkasten people tend to say the automated UID system plus the tags system fulfills the purpose of this, but I don't think it does.  Luhmann also used tags, but that was a separate system entirely, and gave him yet another cross-connected, indexed system within the system. He used tags for a different purpose. I think if tags had been able to take the place of those cascading threads of sequenced thoughts he would have had no need for the complex, branched, silly-looking numbering system he used. There was method in his madness.  The branched threads represented stepwise, connected thoughts, while the tags represented relationships not based in any way on sequence, but merely shared or related topics. He wanted both, plus he also had headings systems and index systems.

This is quite a mind dump, and I am very hard to get along with. Oh well, hopefully some of this is stimulating/amusing at worst and maybe a little of it possibly useful at best.

[andyjim]

On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:

I think Zettelkasten people tend to say the automated UID system plus the tags system fulfills the purpose of this, but I don't think it does. ... The branched threads represented stepwise, connected thoughts, while the tags represented relationships not based in any way on sequence, but merely shared or related topics. He wanted both, plus he also had headings systems and index systems.

I think we're not as far off as I have thought.  Luhmann's numbering system provided ordered, two-way connections. We are doing two-way links, though not ordered, just as Luhmann's direct slip-to-slip links were not ordered, afaik. I may need to provide literate/semantic ordering somehow within the system we have, in place of (and possibly better than, if I can do it well) a Luhmann-type numbering system.

Then too, a mind-map is a form of semantic ordering (hope I'm not misusing 'semantic'). Luhmann achieved mind-mapping by pulling clusters of slips out of the box and arranging them on a table; a very physical, flexible and effective way to play with the order and connections of the slips, in search of pattern, meaning, inspiration.  It seems there is a real advantage to a physical zk in this respect, but maybe we can achieve at least some of this benefit with mind-mapping functionality.

[Thomas Passin]

On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:

I've begun to use it.

And already I see that I could use a command to slap a UID into an already existing zettel that doesn't yet have one. I can do it (and have done it) by making a new zettel and copy-pasting the body of the old one to the new one, then delete the old, but that's a bit cumbersome.

Oh boy, this gets complicated quickly. I'll also need to be able to select a section of a file and create a zettel out of it. It can go in a to-be-dealt-with node.  Maybe these are actually parser functions.

The way my system works is that each zettel is represented by a Leo node, and its identifier is Leo's own identifier for that node.  It's know as its gnx.  Leo needs to know that in order to move to that node.  If you are thinking about inserting your own identifiers into a body of text that you wrote before putting sections of it into Leo nodes, well, you can't know what they would be before a node is created.

Creating your own unique identifiers can be hard.  Some of the issues:  making them truly unique, cut-and-paste errors, typos.  They can't be regenerated if they accidentally become deleted.  Using the gnx, they can be retrieved if needed (it's almost trivial to write a command for that).

 

My own plan for this kind of thing is to take the text that I want to split up into zettels and go through it a section at a time.  For each section, make a new zettel in Leo.  Then start to link them in Leo.  Remember, with the Ctrl+F6 hot key, Leo will automatically insert a back link for you.  The way these links work, you place the cursor on the line that starts with :link:,  and hit the hot key.  Leo will jump to that node and insert the backlink if there isn't one.  You can keep expanding the set of zettels as you work through your original text.  Any other kind of meta data that you want to put in, you can add either in the original text or in the zettel once it has been populated.  I urge you to mark each bit of meta data just like :id: and :link: - with colons front and back (and a piece of metadata would have to be on a single line).

I've attached a screenshot of an example.  It shows the Leo view of a zettel and also the Restructured Text rendering.  The URL is clickable in both the Leo and the rendered panes.

BTW, you may notice that on the id line, after the actual identifier there is a string.  The string is optional, but when the hot key command creates a backlink, it looks for that string and adds it to the backlink.  If there is none, it adds the node's headline.  That way, you have some idea of what that backlink points to, and you get that for no effort on your part.

[Thomas Passin]

On Monday, March 2, 2020 at 8:32:14 AM UTC-5, andyjim wrote:

On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:

I think Zettelkasten people tend to say the automated UID system plus the tags system fulfills the purpose of this, but I don't think it does. ... The branched threads represented stepwise, connected thoughts, while the tags represented relationships not based in any way on sequence, but merely shared or related topics. He wanted both, plus he also had headings systems and index systems.

I think we're not as far off as I have thought.  Luhmann's numbering system provided ordered, two-way connections. We are doing two-way links, though not ordered, just as Luhmann's direct slip-to-slip links were not ordered, afaik. I may need to provide literate/semantic ordering somehow within the system we have, in place of (and possibly better than, if I can do it well) a Luhmann-type numbering system.

Luhmann wrote that the numbers were arbitrary, but that was not quite the case.  A succeeding number usually indicated an extension of the though of its predecessor, or a new thought that had been triggered by it.  In theory, these numbers wouldn't need to be related because links could serve that purpose.  But this organization allows one to quickly find closely related thoughts and trains of thought. This property is called "co-location" in library science.  For example, in a physical library you'd expect to find all the books on mountain climbing on the same section of shelves.

We've got that by means of the Leo outline structure.  The proximity and nesting of the Leo nodes fills exactly the same function.  That's why I didn't try to add any structure to the zettel for this purpose.  It just isn't needed.  And you can always rearrange the outline any time you want.  The links will still go to the right zettels.

I've actually been making new organizing nodes contain the IDs, because I know from experience with my bookmarks manager that it can be useful to jump to headings instead of only to specific items.

[Thomas Passin]

On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:

[snip]

Eventually I hope, at least my vision hopes, to 'run the show' from inside the zettels. For example, I prep an external (or it can be an already imported file) for the leokasten and turn the parser loose on it.  What I want to happen, what happens in my vision, is the prepped zettels in the file are brought in, placed in their proper headings with all the hooks in place. Hooks meaning headings, title, subtitle, abstract, tags, body, links, keywords, sum-next, pointers, references/citations,  Most of these optional but all of them supported, is the idea.

And they are all written into the zettel, so the system just reads the zettel, does all the behind the scenes work, and I have virtually no overhead because I've done it all right there in the zettel. Plus I can alter or add anything later, which is essential in building up the network of interlaced connections.

The only way that this kind of information can be parsed out of a text file would be if you create it using a standard syntax that is unambiguous and (preferably) easy to parse.  And you will have to conform to it rigorously.  That's not so easy.  I suggest that most of that work could and should be done after you have split out the text into zettels.  No parser required, except perhaps to split out the sections into zettels.

[snip]

[Thomas Passin]

On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:

I've begun to use it.

[snip]

This is quite a mind dump, and I am very hard to get along with. Oh well, hopefully some of this is stimulating/amusing at worst and maybe a little of it possibly useful at best.

It can be a good idea to break a long post like this into a series of shorter ones.

As for " very hard to get along with", well, I couldn't really say.  What I can say, though, is that a ZK computer program can't read your mind. So you will need to have some degree of consistency in the syntax and planning of what you write and in your working procedures.  The simpler those things turn out to be, the easier it will be for them to stay invisibly out of the way.

It's better that the user's procedures be simpler rather than the programming, since the point of the programming is to make your life simpler.  But too much complexity in the programming is asking for trouble, because it is more likely to lead to bugs, and also because it can be so hard or time-consuming to write and debug that the effort may be out of line with the benefit.  There's always a balance to be struck.

In all cases, simpler is better.

[andyjim]

On Monday, March 2, 2020 at 8:57:30 AM UTC-5, Thomas Passin wrote:

On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:

And already I see that I could use a command to slap a UID into an already existing zettel that doesn't yet have one.

Creating your own unique identifiers can be hard. 

Yes, I do not contemplate writing my own UIDs. I realize that UIDs belong to Leo, not to me. I meant that if I have an existing node, OR, a section of a file, that has not yet become a zettel in the system, with UID, I need a direct, quick way to accomplish that.

 

My own plan for this kind of thing is to take the text that I want to split up into zettels and go through it a section at a time.  For each section, make a new zettel in Leo.

How do you go about making a section of text a zettel? Copy paste it into the body of an already created (with UID) empty (i.e. no body as yet) zettel? That's ok for a few, but I will have large numbers of them.

 I urge you to mark each bit of meta data just like :id: and :link: - with colons front and back (and a piece of metadata would have to be on a single line).

I've attached a screenshot of an example.  It shows the Leo view of a zettel and also the Restructured Text rendering.  The URL is clickable in both the Leo and the rendered panes.

BTW, you may notice that on the id line, after the actual identifier there is a string.  The string is optional, but when the hot key command creates a backlink, it looks for that string and adds it to the backlink.  If there is none, it adds the node's headline.  That way, you have some idea of what that backlink points to, and you get that for no effort on your part.

Good, all of this starts to build a picture. I've not yet done links but will shortly. And the notion of all the meta lines being right there in the zettel, where you can modify or add to your heart's content (except for the UID of course) places control where it belongs, within the zettels. It's a bottom up system.

Two pieces are not under control of the zettel: the UID (and that necessarily belongs to the system, so no problem there), and the outline heading(s). I've really only begun to think about the Leo outline structure and how to use it to enhance the functionality/utility of the zk system. Cloning provides another sort of connection. In some cases I will want to place zettels under multiple headings.

Hierarchical outlining is a top-down system, so we have a sort of dynamic tension between top-down and bottom up in this, and I think that attempts to model the mind's ability to think both top-down and bottom-up.

[andyjim]

On Monday, March 2, 2020 at 9:26:17 AM UTC-5, Thomas Passin wrote:

 So you will need to have some degree of consistency in the syntax and planning of what you write and in your working procedures.

 

Yes, I am aware that the different elements of the zettel must conform strictly to syntax specific to the element, so the system can correctly execute the functionality of the specific element. I've done a small smattering of programming and know that exactitude is required.  Computers are much more precise in their communication that we mere humans.

[Thomas Passin]

On Monday, March 2, 2020 at 9:39:07 AM UTC-5, andyjim wrote:

On Monday, March 2, 2020 at 8:57:30 AM UTC-5, Thomas Passin wrote:

On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:

And already I see that I could use a command to slap a UID into an already existing zettel that doesn't yet have one.

Creating your own unique identifiers can be hard. 

Yes, I do not contemplate writing my own UIDs. I realize that UIDs belong to Leo, not to me. I meant that if I have an existing node, OR, a section of a file, that has not yet become a zettel in the system, with UID, I need a direct, quick way to accomplish that.

 

My own plan for this kind of thing is to take the text that I want to split up into zettels and go through it a section at a time.  For each section, make a new zettel in Leo.

How do you go about making a section of text a zettel? Copy paste it into the body of an already created (with UID) empty (i.e. no body as yet) zettel? That's ok for a few, but I will have large numbers of them.

Here's an example of one way I've done this in the past.  It's been very effective.  The parser is simple.  I used this format to index the file for a full text search engine (Lucene).  I like the format because it is easy to type, easy to read, and easy to parse.  Note that this is an actual fragment from one of my files - it's not made up for this post.

===============================================================================
[Get or find computer-unique computer-specific id identifier] 2007-04-17

Find or get an identifier (hostid or host id) unique to a specific computer.

Windows: vol <drive> gives the drive serial number.
[e:\]vol c:
 Volume in drive C is unlabeled      Serial number is 2839:BCC4

Windows: ipconfig /all gives the network adapter address, in a line
Physical Address. . . . . . . . . : 00-18-DE-9B-D8-31

Linux: /sbin/ifconfig | grep HWaddr returns a line with the network adapter

==============================================================
[Run Java app as service] 2007-04-12

For running java apps as services on Windows or *nix
Java Service Wrapper http://wrapper.tanukisoftware.org/doc/english/introduction.html

It is open source, with an MIT license.

Jetty comes with source code to implement a Windows wrapper that uses Java Service Wrapper.
=================================================================

The line of "=" characters marks a section break, the text in brackets becomes the title, and the date speaks for itself.  The number of "=" characters in a line doesn't matter as long as 1) the line starts with an "=" and 2) there are at least some minimum number of them.

As I see it, when you want to convert one of your text files to zettel-hood, you would go through the file and add these section breaks as you go.  Then paste the entire thing into a Leo node (or import the file into a node), hit a hot key, and the system would split out all your zettels, in order, with the titles as the headlines.  They'd all be at the same level of indentation.  After that, you could move them into the ZK, add organizing zettels, link them, add citations, etc to your heart's delight.

Does that sound like it would work for you?

[Thomas Passin]

On Monday, March 2, 2020 at 10:07:00 AM UTC-5, Thomas Passin wrote:

[snip]

  I used this format to index the file for a full text search engine (Lucene).  I like the format because it is easy to type, easy to read, and easy to parse.  Note that this is an actual fragment from one of my files - it's not made up for this post.

===============================================================================
[Get or find computer-unique computer-specific id identifier] 2007-04-17

Find or get an identifier (hostid or host id) unique to a specific computer.

[snip]

Actually, this system worked pretty nicely.  I ran a batch file that would read your search phrase and open a page in the browser.  The page contained a list of section titles for sections that matched your request.  Clicking on one of them took you to the full text of that section.

I didn't use this system as much as I might have because it was slow to create the page and open the browser.  Lucene is written in Java, and so I wrote my code in Jython (a version of Python implemented in Java).  This was fine, but it was very slow to load the Jython runtime for each search.  I probably should have turned it into a service, but I never got around to it.

Now there's a full-python search engine, and I could re-implement it using that.  But since I'm using Leo all the time now, I want to concentrate my energies on it rather than re-implementing the old system.  It was pretty nice, though.

[andyjim]

On Monday, March 2, 2020 at 9:07:09 AM UTC-5, Thomas Passin wrote:

We've got that by means of the Leo outline structure.  The proximity and nesting of the Leo nodes fills exactly the same function.

Somehow I don't see it as quite the same thing.  The outline structure is hierarchical while the numbered thread structure, while it does represent ordered sequence, does not necessarily imply hierarchy (although it can). But the other aspect that I see as different (and a necessary difference) is that outline headings are categories or topics, while thought sequences are another sort of thing.  A thought may be an observation, a viewpoint, an opinion, a deduction, a question. I might think of it as more of a process than a topic, although it will always have a topic. We will have entire sequences of thoughts on one topic, and topic-wise, we do indeed need the outline structure, which I consider a top-down function.

But the sequences of thoughts, and their branches and connections do not, to me, closely resemble a hierarchically arranged set of topics. They can indeed be, and should be, classed within such a structure, but it appears to me that allowing them only a topic-based structure might break the dynamic of the sequenced thread of thought.  This forum thread is an example of a sequenced thread of thought that would be difficult, I think, to represent as a hierarchical outline of headings. Sub-topics topics could indeed be identified, and we could build an outline structure of those sub-topics (in fact it would likely be helpful to do so), yet that structure would not, I think, reflect or adequately (though it could to a degree) illuminate the sequential thought processes that develops through this thread.  A thought thread or 'train of thought' is a sequential, ordered process, not just an organization of topics.  Just my viewpoint for what it's worth.

I've actually been making new organizing nodes contain the IDs, because I know from experience with my bookmarks manager that it can be useful to jump to headings instead of only to specific items.

So an organizing node is itself a zettel, I gather. Hmm, so a note zettel could have a backlink to one or more organizing zettels.  And organizing zettels form yet another interlaced system and add a powerful search capability. I haven't even begun to think about organizing nodes.  I am very interested in your concepts and approaches.

I completely agree on the utility, the necessity of headings, indexes, various top-down organizational structures/functions, even while seeing, I believe, shortcomings with them as well.  And by the way, if possible, I am very interested in your bookmarks manager.  Need a zk for bookmarks/URLs, a sort of adjunct to the notes/thoughts zk.

And Thomas, I can hardly express how very much I appreciate your work on this.  I expect I come across sometimes as unappreciative.  I'd like to correct that impression if I can.  I think that you are exactly the right person to do this.  Wish I could help in more substantive ways, not just throwing silly ideas out there.

[Thomas Passin]

On Monday, March 2, 2020 at 11:13:24 AM UTC-5, andyjim wrote:

On Monday, March 2, 2020 at 9:07:09 AM UTC-5, Thomas Passin wrote:

We've got that by means of the Leo outline structure.  The proximity and nesting of the Leo nodes fills exactly the same function.

Somehow I don't see it as quite the same thing.  The outline structure is hierarchical while the numbered thread structure, while it does represent ordered sequence, does not necessarily imply hierarchy (although it can). But the other aspect that I see as different (and a necessary difference) is that outline headings are categories or topics, while thought sequences are another sort of thing.  A thought may be an observation, a viewpoint, an opinion, a deduction, a question. I might think of it as more of a process than a topic, although it will always have a topic. We will have entire sequences of thoughts on one topic, and topic-wise, we do indeed need the outline structure, which I consider a top-down function.

But the sequences of thoughts, and their branches and connections do not, to me, closely resemble a hierarchically arranged set of topics. They can indeed be, and should be, classed within such a structure, but it appears to me that allowing them only a topic-based structure might break the dynamic of the sequenced thread of thought.  This forum thread is an example of a sequenced thread of thought that would be difficult, I think, to represent as a hierarchical outline of headings. Sub-topics topics could indeed be identified, and we could build an outline structure of those sub-topics (in fact it would likely be helpful to do so), yet that structure would not, I think, reflect or adequately (though it could to a degree) illuminate the sequential thought processes that develops through this thread.  A thought thread or 'train of thought' is a sequential, ordered process, not just an organization of topics.  Just my viewpoint for what it's worth.

[snip]

Here's where   I have the advantage over you, because of the work I did to come up with my bookmarks manager.  My bookmarks are arranged in folders and subfolders.  What I had to understand is that this arrangement is not really a strict hierarchy, and that it's not necessarily frozen for all time.  The way in which the organizing headings are arrived at isn't even consistent or even logical over time.  But the headings had some useful meaning at the time.  Also, like you, I didn't want to spend time agonizing over where something should go, I just wanted to be able to find it later.  There's more on this in the paper, to which you already have a link.

That's why the outline structure shouldn't really be considered a strict hierarchy, and why there's a need for more than one kind of view.

But I stand by my claim that the outline has implicit links - child and subordinate links - that map exactly to Luhmann's numbering system.   Go ahead, sketch out a few zettels based on his system.  The slips are linked by the numbers.  They are what's called isomorphic.

[andyjim]

On Monday, March 2, 2020 at 10:07:00 AM UTC-5, Thomas Passin wrote:

The line of "=" characters marks a section break, the text in brackets becomes the title, and the date speaks for itself.  The number of "=" characters in a line doesn't matter as long as 1) the line starts with an "=" and 2) there are at least some minimum number of them.

As I see it, when you want to convert one of your text files to zettel-hood, you would go through the file and add these section breaks as you go.  Then paste the entire thing into a Leo node (or import the file into a node), hit a hot key, and the system would split out all your zettels, in order, with the titles as the headlines.  They'd all be at the same level of indentation.  After that, you could move them into the ZK, add organizing zettels, link them, add citations, etc to your heart's delight.

Does that sound like it would work for you?

Yes it does.

So prepping a file consists of adding the separators, [title in brackets] on first line, a space and then the 'created' date (where I see you used the same YYYY-MM-DD format that is my preference.

Will the system then zettel-ize it with a UID? And where will it place the title (within the zettel that is)?

And can the 'created' date be automated?  Well, that would be nice, but since I need to type in the created date anyway I might as well make a :created: YYYY-MM-DD line.

And if the system extracts the title for the heading, perhaps I need to copy the title into the 'body', below.  Or it could even differ from the heading if there is any reason to do that. Can you have multiple identical headings in an outline? Actually, yes, I've already discovered that you can.

So this gives a way to set the heading from within the zettel, removing a step from the process.  A bit less overhead, at least when I bring a zettel in that way.

In the example you posted, "Salmon with Whole Lemon Dressing" is the heading, and also the title in the rendered pane.  But in the body pane, what follows the id is "Salmon Lemon Dressing", so the rendered title is the same as the heading, but not the same as what is in the body pane.

[Thomas Passin]

On Monday, March 2, 2020 at 12:10:38 PM UTC-5, andyjim wrote:

On Monday, March 2, 2020 at 10:07:00 AM UTC-5, Thomas Passin wrote:

The line of "=" characters marks a section break, the text in brackets becomes the title, and the date speaks for itself.  The number of "=" characters in a line doesn't matter as long as 1) the line starts with an "=" and 2) there are at least some minimum number of them.

As I see it, when you want to convert one of your text files to zettel-hood, you would go through the file and add these section breaks as you go.  Then paste the entire thing into a Leo node (or import the file into a node), hit a hot key, and the system would split out all your zettels, in order, with the titles as the headlines.  They'd all be at the same level of indentation.  After that, you could move them into the ZK, add organizing zettels, link them, add citations, etc to your heart's delight.

Does that sound like it would work for you?

Yes it does.

So prepping a file consists of adding the separators, [title in brackets] on first line, a space and then the 'created' date (where I see you used the same YYYY-MM-DD format that is my preference.

Will the system then zettel-ize it with a UID? And where will it place the title (within the zettel that is)?

The easiest thing to do (and the way I have been visualizing it) is to use the [title] for the headline of the zettel node.  You'd want to keep it short and (if possible) informative, but you should do that anyway.  The date could be separated by any amount of whitespace, as long as it's on the same line.  A date could even be optional.

The node identifier would be the node's gnx, as my zettel-insert-node (CTRL+F8) command already does.  There's no need to have another uid.  It would be possible to build a new command that captures a node's gnx to the clipboard so you can paste it where ever you want, but I don't know that would worth binding to a hot key.

BTW, about these "commands" I keep mentioning.  Each of them consists of code bound to a name.  If you have used the emacs editor you will recognize how to use them.  You hit Alt-X, or click in the "minibuffer" line at the screen bottom, then type in the name of the command.  It does completion, so type, for example, "ze" then hit TAB, and a panel will show you all the commands that start with "ze". Type enough more characters then hit tab again to complete one of them.  Then <ENTER> executes the command.

That's how you can use commands that are not bound to keys.

If you  go to my zettel2.leo example file, and try the above, you'll see the following commands:

   zettel-goto-node
   zettel-insert-node
   zettel-insert-time

Those are the commands in the @command nodes.

[Thomas Passin]

On Monday, March 2, 2020 at 12:10:38 PM UTC-5, andyjim wrote:

In the example you posted, "Salmon with Whole Lemon Dressing" is the heading, and also the title in the rendered pane.  But in the body pane, what follows the id is "Salmon Lemon Dressing", so the rendered title is the same as the heading, but not the same as what is in the body pane.

That's intentional.  Suppose you want to create a backlink to a node that doesn't have a title.  It would be good if it did have one, so you could know whether you want to go look at it.  The command looks to see if the :id: line already has a title. Then it uses that title, even if it doesn't match the headline or the label in the sending node.  Otherwise, it uses the headline as a label for the backlink.

This label is purely for the user's convenience.  It is not used to find the node to navigate to.  The idea is that you might want a different label than what's in the headline.  Maybe the headline is too short or too long, and you want something different.  It's basically visual clutter vs usefulness.

And you can always change the label in the :id: or :link: lines. That won't affect the navigation functionality, though it might affect certain searches.

I'm trying to have the system do as much as possible while still staying simple and unobtrusive for the user.  I discovered as I started to use my ZK that I wanted to type in link labels, and that led to the current scheme where I don't but I can change them if I want to.

[Thomas Passin]

On Monday, March 2, 2020 at 12:10:38 PM UTC-5, andyjim wrote:

[snip]

And if the system extracts the title for the heading, perhaps I need to copy the title into the 'body', below.  Or it could even differ from the heading if there is any reason to do that. Can you have multiple identical headings in an outline? Actually, yes, I've already discovered that you can.

I don't think there is any need to have the zettel's title in the body.  If you are looking to the outline pane, there it is in the headline.  If you are looking at the rendered pane, the rendering code adds the headline as the top-level heading automatically.  BTW, the rendering pane can export the rendered view to your system browser.  It can also render an entire subtree if that's what you want.

[Thomas Passin]

BTW, with Restructured Text your zettels can have note boxes, sidebars, and tables that render well. See the attached screen shots.

[Thomas Passin]

A zettel thought experiment.

I ran through an imaginary scenario for using a ZK, once it's populated.  I based this on how I use my bookmark manager.  Note that my bookmark collection does not actually have some of these headings and bookmarks.

I have a piece of cod to cook for dinner ( I really do).  I look for "cod".  I find some recipes.  Might there be more?  I check related headings, and find that "Cooking" has some more recipes.  I find a few there.  What else?  How about "Fish"?  I find a number of headings related to "Fish".  Wait- what's that?  "Fish-ancestral".. Hmm, let's see what that is, I don't remember it.  Look at this - "Ancient DNA from Fossil Fishes".  Oh, interesting, can you actually get DNA from fish fossils?

Wonder what those old fish tasted like?  Supposedly you can figure out hair color for humans from dna, I wonder if you can get the flavor too.  Hmm, if I were around back then, would fish taste the same to me anyway?  Maybe our sense of taste evolves over time.  Hmm, can that be studied?  And what would it even mean, since we can never really know what a given kind of sensation seems like to another person?

So in about five minutes we have wandered from a dinner recipe to paleo history to philosophical questions about the meaning and stability of sensory perceptions.  We've actually come up with several possible research projects and a topic for a philosophical essay.  All in about five minutes.

All this, and there's virtually nothing in my ZK yet!  I'm just visualizing how I might use it.  This serendipidy, that's one of the main things I'm interested in -  that, and helping me and my fallible memory find things again.

Of course, I still have to cook the fish!

[Edward K. Ream]

On Mon, Mar 2, 2020 at 2:13 PM Thomas Passin <tbp1...@gmail.com> wrote:

BTW, with Restructured Text your zettels can have note boxes, sidebars, and tables that render well. See the attached screen shots.

Nifty.

Edward

[andyjim]

On Monday, March 2, 2020 at 3:43:08 PM UTC-5, Thomas Passin wrote:

A zettel thought experiment.

...

So in about five minutes we have wandered from a dinner recipe to paleo history to philosophical questions about the meaning and stability of sensory perceptions.  We've actually come up with several possible research projects and a topic for a philosophical essay.  All in about five minutes.

All this, and there's virtually nothing in my ZK yet!  I'm just visualizing how I might use it.  This serendipidy, that's one of the main things I'm interested in -  that, and helping me and my fallible memory find things again.

Zettelkasten = structured serendipity! A self-organizing thought factory! How to partner creatively with your own brain! An intelligent memory bank that digests what you feed it and provides instant, connected, pre-clustered, organized access to everything you've ever written!   

End of rant.

[Thomas Passin]

I wouldn't say "instant", exactly.  You have to put  the work in, you may have to do some rooting around and be receptive to following up links that may not seem too relevant, and you have to have put thought and effort into creating the notes and links in the first place.  And that comes from reading and thinking.

The rooting around can be fun as well as productive, though.

[Edward K. Ream]

On Wed, Mar 4, 2020 at 7:13 AM andyjim <andy...@gmail.com> wrote:

On Monday, March 2, 2020 at 3:43:08 PM UTC-5, Thomas Passin wrote:

A zettel thought experiment.

...

So in about five minutes we have wandered from a dinner recipe to paleo history to philosophical questions about the meaning and stability of sensory perceptions.  We've actually come up with several possible research projects and a topic for a philosophical essay.  All in about five minutes.

All this, and there's virtually nothing in my ZK yet!  I'm just visualizing how I might use it.  This serendipity, that's one of the main things I'm interested in -  that, and helping me and my fallible memory find things again.

Zettelkasten = structured serendipity! A self-organizing thought factory! How to partner creatively with your own brain! An intelligent memory bank that digests what you feed it and provides instant, connected, pre-clustered, organized access to everything you've ever written!  

It's good to see this excitement. It means we are moving away from details.

Edward