Leo for organizing notes?

[andyjim]

Uh, complete newbie here, and I feel like I'm walking into a high end programmers convention here and raising my hand red-faced to ask for a bit of kindergarten help. Everything in this forum is Greek to me. I am NOT a programmer. Repeat: I am not a programmer.

My intended usage for Leo is organizing notes & ideas. I'm raising my hand here because perhaps Leo's outlining/organizing capabilities may be what I need. I'm hoping folks here can tell me if I'm even knocking on the right door by looking at Leo. But it looks like Leo's flexibility in outlining may be unsurpassed and may be what I'm looking for. Hope so.

I've looked for years for a software to help me organize my notes and ideas. Here's the problem: I've been journaling for 25 years, writing thoughts, notes, ideas on probably hundreds of topics, and totaling probably a few million words in a few thousand files. But I haven't done much organizing. Most of my journal files have notes on multiple topics. Generally my files are named by date rather than topic, though I have perhaps a few hundred by topic. For years I wrote in Word, often using outline format, usually writing most notes in one file per year, in outline format. If you're concluding it's a mess, you are right (though it could be worse). What's not in Word is mostly in text files. I switched to writing in Vim a few years ago, and am now writing in Spacemacs. Org mode has been recommended to me but I have not undertaken it. I suspect Leo is better than org mode for my needs but who am I to know? Is it?

My project, which will undoubtedly take a couple of years, is to class and organize all notes into a "thoughtbase", perhaps comparable in some ways to a Zettelkasten. I want to sort through the mess, clip notes out by topic and organize them such that I can readily access anything and everything. I hope to cluster topics under a few (perhaps 25) main headings, some number of sub-headings, and individual topics with all notes on each topic stacked together.

Perhaps there's a book or two or three there, but to find such a book or books will require that all this be organized so I can see it, access it, massage it, move clips around, stack them up, try things, remember things I wrote 20 years ago, .... Sound like fun? You don't have to answer that.

My thought is to arrange all this in external plain text files initially, with the outline organization being in Leo, leaving the files external (eventually that is. Perhaps this isn't the best approach. But I'm getting ahead of myself. My first question is (and I'm hoping I've given a somewhat comprehensible thumbnail of what I'm looking for), is Leo capable of this, or perhaps Leo in combination with other software? Maybe some of the text-crunching and manipulating would be best done outside of Leo? BBEdit? DevonThink? InfoQube? Zettelkasten? Eastgate's Tinderbox? Heck I don't know.  Oh yeah, MacOS High Sierra on an older (2010) iMac; just installed Leo 6.1.

One reason I'm looking at Leo for this is that I think I'm going to have to just start bringing material into an outline system, note by note, and evolve the classing and relationships 'as she goes'. I think it would be too much to try to come up with the entire classing system out the outset. Evolve it instead. And I suspect that is where Leo may outshine any other. Is this true? Others claim similar qualities, where the optimum organization emerges as you bring more material into the system and deal with it as the spirit moves, piece by piece. Patterns emerge, relationships develop, that sort of thing. That is ultimately what needs to happen. Is Leo the best bet? Or some combo of software?

In addition to some general thoughts on all this, I'd like a few pointers to get me started. I have learned how to create an external file in Leo, but I haven't found how to open/import a file (text or Word). That will be a key function in putting together a thoughtbase. I'm sure Leo can do, but I haven't discovered how to do it.

Thanks,  Andy

[Chris George]

On Sat, Jan 18, 2020 at 3:36 PM andyjim <andy...@gmail.com> wrote:

Uh, complete newbie here, and I feel like I'm walking into a high end programmers convention here and raising my hand red-faced to ask for a bit of kindergarten help. Everything in this forum is Greek to me. I am NOT a programmer. Repeat: I am not a programmer.

Welcome, Andy. I am not a programmer either, but I have been using Leo for a bit over a decade.

 

My intended usage for Leo is organizing notes & ideas. I'm raising my hand here because perhaps Leo's outlining/organizing capabilities may be what I need. I'm hoping folks here can tell me if I'm even knocking on the right door by looking at Leo. But it looks like Leo's flexibility in outlining may be unsurpassed and may be what I'm looking for. Hope so.

Leo can be without peer when it comes to organizing notes and ideas.

 

I've looked for years for a software to help me organize my notes and ideas.

 

It took me a while to find Leo. I run linux and used to have spotty Internet, so a program that supported clones and wasn't a website was important to me.

 

Here's the problem: I've been journaling for 25 years, writing thoughts, notes, ideas on probably hundreds of topics, and totaling probably a few million words in a few thousand files. But I haven't done much organizing. Most of my journal files have notes on multiple topics. Generally my files are named by date rather than topic, though I have perhaps a few hundred by topic. For years I wrote in Word, often using outline format, usually writing most notes in one file per year, in outline format. If you're concluding it's a mess, you are right (though it could be worse). What's not in Word is mostly in text files. I switched to writing in Vim a few years ago, and am now writing in Spacemacs. Org mode has been recommended to me but I have not undertaken it. I suspect Leo is better than org mode for my needs but who am I to know? Is it?

Step one for me was converting my knowledge base into text files. Step two was getting it all into Leo. Step three (which I am still doing) was organizing it all.

For example, a text file that came out of a wordprocessor would often have a headline and a bunch of text. Once imported into a node I would select all of the text I would like in a new node, including the headline, and hit Ctrl-Shift-D. This creates a child node with the headline as the node headline and the balance of the selected text as the node. Very quick, very easy.

 

My project, which will undoubtedly take a couple of years, is to class and organize all notes into a "thoughtbase", perhaps comparable in some ways to a Zettelkasten. I want to sort through the mess, clip notes out by topic and organize them such that I can readily access anything and everything. I hope to cluster topics under a few (perhaps 25) main headings, some number of sub-headings, and individual topics with all notes on each topic stacked together.

Using clones you can create whatever organizational scheme you like. Add in a couple of plugins, like bookmarks, tags, and backlinks, and that ability explodes.

 

Perhaps there's a book or two or three there, but to find such a book or books will require that all this be organized so I can see it, access it, massage it, move clips around, stack them up, try things, remember things I wrote 20 years ago, .... Sound like fun? You don't have to answer that.

My thought is to arrange all this in external plain text files initially, with the outline organization being in Leo, leaving the files external (eventually that is. Perhaps this isn't the best approach. But I'm getting ahead of myself. My first question is (and I'm hoping I've given a somewhat comprehensible thumbnail of what I'm looking for), is Leo capable of this, or perhaps Leo in combination with other software? Maybe some of the text-crunching and manipulating would be best done outside of Leo? BBEdit? DevonThink? InfoQube? Zettelkasten? Eastgate's Tinderbox? Heck I don't know.  Oh yeah, MacOS High Sierra on an older (2010) iMac; just installed Leo 6.1.

One reason I'm looking at Leo for this is that I think I'm going to have to just start bringing material into an outline system, note by note, and evolve the classing and relationships 'as she goes'. I think it would be too much to try to come up with the entire classing system out the outset. Evolve it instead. And I suspect that is where Leo may outshine any other. Is this true? Others claim similar qualities, where the optimum organization emerges as you bring more material into the system and deal with it as the spirit moves, piece by piece. Patterns emerge, relationships develop, that sort of thing. That is ultimately what needs to happen. Is Leo the best bet? Or some combo of software?

Everything you have outlined is doable in Leo.

In addition to some general thoughts on all this, I'd like a few pointers to get me started. I have learned how to create an external file in Leo, but I haven't found how to open/import a file (text or Word). That will be a key function in putting together a thoughtbase. I'm sure Leo can do, but I haven't discovered how to do it.

Leo is a text editor. Once I got over my burning desire to have my writing in 13.2pt, chartreuse, unicorn fonts and such I began to realize that as a writer all of that WYSIWYG fluff was exactly that. Fluff.

Convery everything into text files. Use pandoc/docutils etc. etc. Stick it all into a file system that makes sense to you. Install the active path plugin and suck it all into Leo. Once that is done I think you will find yourself wondering why you would even bother cluttering your file system with a bunch of external files. For programmers, that ability is key. For writers, and likely for you, it is an extra step that you likely won't find much use for.

 

Thanks,  Andy

HTH,

Chris

 

--
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/248fa329-2734-4d05-9660-3aee3a274fc3%40googlegroups.com.

[lewis]

Hello Andy,

Re: My project, which will undoubtedly take a couple of years, is to class and organize all notes into a "thoughtbase"

I have attached a simple small file which demonstrates the power of Leo clones. It is a list which uses clones to organise and classify items.

One way I use Leo-editor is to manage material lists for engineering. You can see it can be easily adapted to manage any list and operate as a database.

There is no need to have the Master list of cloned items; I only use that for convenience.

Under the settings there is a node (@button Show-Clones) which presents Leo's show-clones command in a simple to use menu button.

Select any cloned item and press the Show-Clones menu button. The log pane will show clickable links!

In effect this is a 'Where Used' report from the data.

You can use clones as attributes of an item or Topic, and may be well suited to your task of organising main headings, and any number of sub-headings.

I am not a programmer either, but via Leo and the community I have learnt how to write python scripts and also simple external python programs.

Regards
Lewis

[andyjim]

Thank you Lewis.  Unfortunately I do not know how to open this file in Leo.  Maybe some day I'll figure it out.  Somehow I fail to find instructions how to do the simple things: Open a file. Enable and use a plugin, or even a directive.  I've tried some things but haven't got off the ground.  It seems like programmers are born knowing the fundamentals. If there is a very simple, fundamental introduction to how to do the most basic and elementary of beginner's things in Leo, I have failed to find it.

[andyjim]

Thanks Chris, your comments are encouraging.  But I do not know how to install plugins.  I do not know how to use plugins.  I do not know how to use directives.  I do not know how to open files in Leo.  I've looked around, tried to find my way through the maze, tried some things based on what I did find.  Nothing has worked so far.  I do not find clear instructions for the beginner, spelling out the most basic of things in a clear, step by step way.  I hate to drop Leo just because I'm too dumb to figure it out, as it looks too good, but so far it seems not to have an entry path for the (non-programming) beginner.  If there is such an entry path ("Complete dummies start here!") I'd be grateful to be pointed in that direction.

Andy

To unsubscribe from this group and stop receiving emails from it, send an email to leo-e...@googlegroups.com.

[Chris George]

Hi Andy,

I feel for you. It took me a while to get rolling too.

If any of this is confusing, ask questions.

The very best advice I can give you is to open LeoDocs.leo from within Leo.

File, Open Specific Leo File, LeoDocs.leo

Start at Leo's Documentation in the Outline Pane and slowly work your way through. This documentation is preferred to the website as it is much easier to navigate and to search.

The tutorials can be handy, the FAQ contains most of the entry level bits you are looking for..

And ask questions here. The documentation is in general excellent but the steep learning curve can be intimidating. The documentation can always be improved and has been many times during my time using Leo, often after I expressed my own frustrations with understanding how to make Leo do what I want it to do.

A quick overview of plugins requires and understanding of how settings work. This is not going to be comprehensive, but should give you the general idea.

There are different levels of setting. The more local settings take precedence.

LeoSettings.leo are the default settings. Do not mess with these at all, ever. Do take the time to read through them. When you come across a setting you would like to change, copy that node and paste it into myLeoSettings.leo which are your user settings. THe next level of settings is local to an individual Leo file but we can skip that for now.

So for plugins we want to copy the @enabled-plugins node to from LeoSettings.leo and paste it into myLeoSettings.leo as a child node of @settings. Then you can edit this node and the changes will take precedence over the same node in LeoSettings.leo. To enable a plugin simply delete the # in front of it, save myLeoSettings.leo, close Leo and re-open Leo. From the Plugins menu you can select a plugin and the docstring will appear in the rendered pane to give you an idea how it works.

Again, ask questions. Don't be embarrassed. I started into Leo in 2007 and it took me two years to get really comfortable with it. Now I spend most of my time at my computer in Leo.

HTH,

Chris

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/1c11b6db-6c53-4450-8710-16b1386d1962%40googlegroups.com.

[andyjim]

Chris and Lewis, thanks.  I think you've got me started.  I'm sure I'll be back for more soon.

Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/1c11b6db-6c53-4450-8710-16b1386d1962%40googlegroups.com.

[Israel Hands]

Hi Andy,

File Menu / Read/Write Files / Read-file-into-node will suck in the file you point it at. Leo won't understand a word file so start with your text files.Leo has a mini buffer command line at the bottom of the screen. This has command completion and you can type the command directly in there. Click in the buffer and type read-file  and hit tab.

However a much more powerful tool is the active-path plug in. This can recursively read a whole directory into Leo nodes. Leo plugins are great.

As regards your project you are starting in the right place - get all your files ordered first, and get them into plain text. Then Leo or some other tool can ingest them and allow you to move them round/sort them. 

Like you I'm no programmer or even much of a note organiser but here's my experience.

Leo is fantastic, super powerful  and free. And Edward (EKR the developer is the nicest man in show business) indeed this group is full of lovely helpful people.  However you have correctly observed something about the group. A lot of users here are most interested in Leo as an IDE.

On the other bits of software - DevonThink I have never tried I'm sure it is brilliant.  Tinderbox is brilliant. And it offers to 'activate' your notes in an unique way. And you can enjoy the visual approach of the map view. But the pricing model puts me off. I can't get Leo to talk to Tinderbox via OPML - see posts below.

I have recently downloaded The Archive - https://zettelkasten.de/the-archive/  and it is brilliant. It does about 5% of what Leo does but it lives and breathes notology. Free to try. Search and display are tops in The Archive. And in fact as it also deals with text files in a directory you can wrangle the same data in both Leo and The Archive for different purposes or until one becomes a preferred tool.

have fun. IH

[Matt Wilkie]

If any of this is confusing, ask questions.

Yes, please do! Some answers may take awhile to roll in, which can be excruciating when you're in the midst of confusion, but still please do ask.

Adding an external file:

Easiest way to start is just drag and drop from your file manager onto the Outline panel.

If the exension is recognized Leo will create an "at-file" directive like @auto (ref). Leo does it's best to calculate a sensible tree structure if it can, though that works best for source code so might not do much for you (initially).

Get comfortable with this before trying the Active Path plugin.

Quickstart for plugins:

   Leo >> Settings menu >> Open myleoSettings file.

   The file will be created if it doesn't exist.

Expand @settings then @enabled-plugins.

A line beginning with hash symbol (#) is ignored.

To activate a plugin remove the #, save, exit and restart Leo. Restarting isn't always needed, but it's a guaranteed method.

Unfortunately finding out what plugins you might want and how to use them is a bit of an easter egg hunt. Ask us; some are pretty old. The plugins page in the Leo User's Guide includes a brief description of each plugin.

Active Path plugin quickstart:

• Enable it as per above
• r-click in Outline pane >> Path >> active-path-pick-dir
• 2x-click on the rectangular box at left of newly created headline node
• new nodes for each file and sub-folder within that folder will be created
• 2x-click any file you want Leo to load. Doing so should create a node the same as drag-and-drop above
  

Hopefully this helps makes the entry a bit smoother ;-)

-matt

[Steve Litt]

On Sat, 18 Jan 2020 17:44:51 -0800
Chris George <techn...@gmail.com> wrote:

> On Sat, Jan 18, 2020 at 3:36 PM andyjim <andy...@gmail.com> wrote:

> > My intended usage for Leo is organizing notes & ideas. I'm raising
> > my hand here because perhaps Leo's outlining/organizing
> > capabilities may be what I need. I'm hoping folks here can tell me
> > if I'm even knocking on the right door by looking at Leo. But it
> > looks like Leo's flexibility in outlining may be unsurpassed and
> > may be what I'm looking for. Hope so.
>
> Leo can be without peer when it comes to organizing notes and ideas.

Hi Chris,

I have one specific question: Can I have a Leo file appear as a
headline in another Leo file, so I can hotkey the headline and have the
separate file appear? If so, can I assume I can get infinite
"drilldown?" It would be great to have a "master" Leo file from which I
can get to other Leo files, directly or indirectly.

Thanks,

SteveT

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

[Steve Litt]

On Tue, 21 Jan 2020 10:04:39 -0800 (PST)
Israel Hands <alis...@mcgh.ee> wrote:

> Hi Andy,
>
> File Menu / Read/Write Files / Read-file-into-node will suck in the
> file you point it at. Leo won't understand a word file so start with
> your text files.

What if he wants the original file to be separate, and just hotkey a
Leo headline to open that file in its natural program (LibreOffice for
instance)? Can you just have a headline with the filename and the
program to open it up with, and hotkey that headline?

[Chris George]

Hi Steve,

I never discovered a way to do that. In fact, for the first seven years of using Leo, I used only one Leo file to organize my life and handle all of my different writing projects.

Chris

--
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/20200123032620.336cf5a7%40mydesk.domain.cxm.

[Matt Wilkie]

I have one specific question: Can I have a Leo file appear as a
headline in another Leo file, so I can hotkey the headline and have the
separate file appear? If so, can I assume I can get infinite
"drilldown?" It would be great to have a "master" Leo file from which I
can get to other Leo files, directly or indirectly.

You can get partway there using Uniform Node Location (UNL) links,

For example put something like this in headline or body and ctrl-2x-click on it:

unl://D:/code/studies/study-shortcutter.leo

The draw back is that they must be full path (it doesn't take into account any @path statements you might have in the current branch).

[later] After reading http://leoeditor.com/slides/plugins.html#unl-py I see there is also @url for use in headlines. It's smart enough to open a specific node, not just the file

@url D:/code/studies/study-shortcutter.leo#MyChanges-->create_shortcut-->Docs

I'm not sure what the relationship is between these two forms.

There was a lot of discusion a few years ago on "cross file links" that might yield other gems.

-matt

[Thomas Passin]

On Saturday, January 18, 2020 at 8:45:08 PM UTC-5, Chris George wrote:

Using clones you can create whatever organizational scheme you like. Add in a couple of plugins, like bookmarks, tags, and backlinks, and that ability explodes.

One Leo feature for organization that I use a lot is called "chapters".  A chapter is a kind of grouping where you can collect nodes that you think belong together.  There is a select box titled "Chapters".  When you select a chapter in it, the outline pane will only show the headline nodes for that chapter.  Searches, though, can still search the entire Leo file if you want them to.

To create chapters, add a new top-level node near the top of the outline nodes, and it give the title "@chapters" (but without the quotation marks).  Your chapter nodes will be children of this node - that is, you will move them then so they are indented one level under the @chapters node.  Give each chapter node a name that begins with @chapter, like this:

@chapter Book Reviews 2019

You don't have to do anything more - Leo will take care of the details of setting things up.  Now just move any nodes you want under (i.e.,below, and indented more than) the @chapter node that you want them to be in.

[Thomas Passin]

On Thursday, January 23, 2020 at 5:18:17 PM UTC-5, Matt Wilkie wrote:

[later] After reading http://leoeditor.com/slides/plugins.html#unl-py I see there is also @url for use in headlines. It's smart enough to open a specific node, not just the file

@url D:/code/studies/study-shortcutter.leo#MyChanges-->create_shortcut-->Docs

This does work - it's almost like magic to ctrl-click on the node and see the Leo outline open in Leo right at the specified node.  Other file types seem to get opened by their standard system file handlers, like the text editor for .txt files..

[john lunzer]

Chapters are indeed useful and are generally speaking a more organized type of hoisting. They're not often discussed so I would also encourage checking them out as a means of organization.

[Matt Wilkie]

Chapters are indeed useful and are generally speaking a more organized type of hoisting. They're not often discussed so I would also encourage checking them out as a means of organization.

Until today I never understood what Chapters were and have just deleted them from my docs. A self imposed ignorance because I hadn't bothered to read up on them, or rather I read but since 'hoist' didn't mean anything the definition didn't help and I lacked the motivation to keep digging into further definitions! Thanks for the bump.

For the record of other dwelling-in-darkeness people like myself:

Hoist & dehoist

Hoisting a node redraws the screen that node and its descendants becomes the only visible part of the outline. Leo prevents the you from moving nodes outside the hoisted outline. Dehoisting a node restores the outline. Multiple hoists may be in effect: each dehoist undoes the effect of the immediately preceding hoist.

Using Chapters

@chapter trees define chapters. Selecting a chapter makes only those nodes in the chapter visible, much like a hoist

-matt

[andyjim]

Many thanks to all. I've only just now got back to this thread and gratified to see tips have kept coming in.  It will take me awhile to check all these out but it looks good indeed.

I also want to put in a plug here if I may, for someone to undertake a robust Zettelkasten plugin for Leo.  I think Zettelkasten is the best available idea for notes, and I think Leo may be capable of implementing it better than anyone else has done (disclaimer: this is the relatively uninformed opinion of a Leo newbie and a non-programmer as well). It seems to me (again as a complete newbie) that Leo already utilizes some (maybe all?) of the core principles of Zettelkasten, and more besides, that would only enhance the concept.  It could truly be a marvelous piece of software.  Wish I knew python.

[Thomas Passin]

On Wednesday, January 29, 2020 at 10:45:58 PM UTC-5, andyjim wrote:

Many thanks to all. I've only just now got back to this thread and gratified to see tips have kept coming in.  It will take me awhile to check all these out but it looks good indeed.

I also want to put in a plug here if I may, for someone to undertake a robust Zettelkasten plugin for Leo.  I think Zettelkasten is the best available idea for notes, and I think Leo may be capable of implementing it better than anyone else has done (disclaimer: this is the relatively uninformed opinion of a Leo newbie and a non-programmer as well). It seems to me (again as a complete newbie) that Leo already utilizes some (maybe all?) of the core principles of Zettelkasten, and more besides, that would only enhance the concept.  It could truly be a marvelous piece of software.  Wish I knew python.

I put a lot of time some years ago looking into how to get the most out of my browser bookmarks, and I arrived at some of the same principles as I now read about for a Zettelkaste.  And I tackled some of the things that seem to be glossed over in the material I've seen on Zettelkastens.  You can read a paper about the work here -

http://conferences.idealliance.org/extreme/html/2003/Passin01/EML2003Passin01.html

The user interface is much better now, but the underlying system is the same.  Briefly, with a typical browser, you can save bookmarks in (virtual) folders.  But the only information you can store are 1) the title of the page, and 2) the folder name that you create.  Not much to go on.  I wanted to get the most possible out of it. Some of the difficulties come from the size of a large collection (I have more than 20,000 bookmarks).  You can't remember most of it, and you can't remember the folder names where you put things.  Over time, you may get duplicates, and you will probably invent new folder names even though they may do the same job as the older ones.  And you will probably end up with the same bookmark in several folders.  How do you find things, and how do you find related pages?  Oh, and the system needs to be very simple to use or it won't be used.

Do these issues sound familiar?

Well, my system is limited to bookmarks, and it has some limitations to work around the fact that you can't store data to the file system from a browser.  OTOH, it doesn't need to use a database, and it runs in the browser.

Why I'm bringing this up here is that from time to time I toy with ideas for generalizing it to go beyond bookmarks (you can already annotate bookmarks with the system, which is much like linking notes to web pages - trouble is, it's very clumsy at present).  I could see implementing some variation in Leo.

The real difficulty in coming up with a system like this is in making it work at a large scale; that and a good interface.  With a Zettelkasten, you want to link a note to other related ones.  But how do you find those other related notes?  How do you work with tens of thousands or more of notes and find what you want?  How can you design a user interface that will be clear, simple, and usable at that scale?  How do you deal with many-to-many relationships between notes?  How can you promote serenditious discovery? Those are really hard issues.

@andyjim, would you be interested in exploring this area further?

[Edward K. Ream]

On Wed, Jan 29, 2020 at 9:46 PM andyjim <andy...@gmail.com> wrote:

I want to put in a plug here for someone to undertake a robust Zettelkasten plugin for Leo. 

I did a google search on Zettelkasten. The first hit on the search suggests auto-completing links that might not exist yet. That's a pretty cool idea. It should be straightforward to do. Is that generally what you are thinking of?

Edward

[Edward K. Ream]

On Wed, Jan 29, 2020 at 10:35 PM Thomas Passin <tbp1...@gmail.com> wrote:

I put a lot of time some years ago looking into how to get the most out of my browser bookmarks, and I arrived at some of the same principles as I now read about for a Zettelkaste.  And I tackled some of the things that seem to be glossed over in the material I've seen on Zettelkastens.  You can read a paper about the work here -

http://conferences.idealliance.org/extreme/html/2003/Passin01/EML2003Passin01.html

Interesting.

...with a typical browser, you can save bookmarks in (virtual) folders...How do you find things, and how do you find related pages?  Oh, and the system needs to be very simple to use or it won't be used.

It does seem like links are the key, and that links to to-be-created notes would be great. All this should be straightforward to do.

Terry's bookmarks.py plugin uses a "distinguished" node to hold bookmarks, but perhaps this isn't necessary. If a link doesn't yet exist, a new node could be created as the "originating" node's child, or sibling. That would make it possible to organize nodes as we like, without constraints.

This page lists lists principles of Zettlekasten. The "unique home" principle might be relaxed to handle clones. The plugin might turn the [[link]] syntax into a special abbreviation, or something like that.

In short, a Zettlekasten plugin should be easy to do. I have just created #1482 for this.

Edward

[Thomas Passin]

On Thursday, January 30, 2020 at 7:23:11 AM UTC-5, Edward K. Ream wrote:

On Wed, Jan 29, 2020 at 10:35 PM Thomas Passin <tbp1...@gmail.com> wrote:

I put a lot of time some years ago looking into how to get the most out of my browser bookmarks, and I arrived at some of the same principles as I now read about for a Zettelkaste.  And I tackled some of the things that seem to be glossed over in the material I've seen on Zettelkastens.  You can read a paper about the work here -

http://conferences.idealliance.org/extreme/html/2003/Passin01/EML2003Passin01.html

Interesting.

...with a typical browser, you can save bookmarks in (virtual) folders...How do you find things, and how do you find related pages?  Oh, and the system needs to be very simple to use or it won't be used.

It does seem like links are the key, and that links to to-be-created notes would be great. All this should be straightforward to do.

Terry's bookmarks.py plugin uses a "distinguished" node to hold bookmarks, but perhaps this isn't necessary. If a link doesn't yet exist, a new node could be created as the "originating" node's child, or sibling. That would make it possible to organize nodes as we like, without constraints.

...

 

My bookmarks app doesn't have to persist the internal data structures.  Instead it is able to recreate them from the original file when it is opened.  The original file is actually the html file that Firefox saves when you save your bookmarks.  I process that, using a combination of python and xslt, producing a file of javascript code that when run produces the data structures (this was all written before we had JSON).  The browser opens an html page that imports the javascript file using a <script> element.

For a Zettelkastens, given that @andyjim has a large pile of existing note files, the big issue is how to get years worth of notes into the system in the first place.  No one will want want to spend months retyping the note files into the new system.

[Thomas Passin]

On Thursday, January 30, 2020 at 7:23:11 AM UTC-5, Edward K. Ream wrote:

...

This page lists lists principles of Zettlekasten. The "unique home" principle might be relaxed to handle clones. The plugin might turn the [[link]] syntax into a special abbreviation, or something like that.

In short, a Zettlekasten plugin should be easy to do. I have just created #1482 for this.

Here's a writeup by someone who's doing it in the SublimeText editor.  It actually sounds pretty good -

http://www.dansheffler.com/blog/2015-05-11-my-zettelkasten-in-sublime/

[andyjim]

Thanks so much Edward for checking in here. The page that you linked to here concerns one minor feature, and doesn't offer a picture of what Zettelkasten is, though there's quite a bit on that website. Um, I'm no expert on Zettelkasten, and certainly not on Leo, but I still believe Leo is probably capable of most if not all features of Zettelkasten and more, but the idea of a Zettelkasten plugin would be to wrap it all into a slick, dedicated framework.
I guess what I'm proposing really would amount to a stand alone program with its own GUI, etc that incorporates all Zettelkasten and some additional Leo features. Remember I'm not a programmer but as I think about it, it looks to me like probably way more than just a plugin, and I begin to think I'm probably dreaming way too big and asking way too much here.
If I had to describe Zettelkasten in one sentence: It's a framework for creative thinking, building a personal thoughtbase and from that thoughtbase to generate and express new ideas, create documents (up to book size), and more [added: come to think of it, these sound a bit like Leo principles, no?]. Much more a tool for writers, academics, psychologists, journalers (more or less my gig), sociologists and such than a programmer's tool.
That said, if anyone feels moved to look into it, I'll offer a few links to introduce the basic concept.

[andyjim]

Definitely, Thomas, and thanks so much for your interest. What I recommend as a starting point is to get one or more Zettelkasten programs yourself to familiarize yourself with the concepts and also the sort of GUI that is generally used (I am a very inadequate resource myself).  Personally, I want some enhancements to the GUI.

https://zettelkasten.de/ is a general site on Zettelkasten, but the authors have their own, called The Archive. Free. I have it but haven't gone much into it as yet.

https://github.com/EFLS/zetteldeft  is one for emacs  (I don't have it)

https://takesmartnotes.com/  An entire book on the ideas. Under 'The Book' on the homepage you can get the first chapter in pdf, which is really an Intro, and does a great job of it. Well worth reading.

https://www.zettlr.com/  A writer produced this version. I have it but haven't done much with it yet. Free.

https://roamresearch.com/  looks great but I think it's cloud-based, subscription.  One thing it has is two-way links.

https://writingcooperative.com/zettelkasten-how-one-german-scholar-was-so-freakishly-productive-997e4e0ca125  Article on the theory and practice

https://github.com/renerocksai/sublimeless_zk  The guy that wrote the plugin for Sublime wrote this to stand alone. Looks PDG to me, but he seems to have abandoned it 2 yrs ago. Free, I have it.

Also note the existing post specifically on Zettelkasten. Maybe these links and discussion should go there.

I think only a couple of these will import, which is one reason I turned to Leo, besides that I think Leo's capabilities for this kind of thing are probably more robust, just need to be wrapped together in a neat package.  But what do I know?  If you pursue this you will shortly be more of a Zetteler than I currently am. My learning pace is slow.

Andy

[Thomas Passin]

On Thursday, January 30, 2020 at 7:23:28 PM UTC-5, andyjim wrote:

Definitely, Thomas, and thanks so much for your interest. What I recommend as a starting point is to get one or more Zettelkasten programs yourself to familiarize yourself with the concepts and also the sort of GUI that is generally used (I am a very inadequate resource myself).  Personally, I want some enhancements to the GUI.

The GUI will be the hard part, no doubt about it.  A bad GUI is easy!

 

https://zettelkasten.de/ is a general site on Zettelkasten, but the authors have their own, called The Archive. Free. I have it but haven't gone much into it as yet.

Most of the products seem to be MAC or linux only.  I use Windows, though I sometimes run Linux in a virtual machine.

 

https://github.com/EFLS/zetteldeft  is one for emacs  (I don't have it)

https://takesmartnotes.com/  An entire book on the ideas. Under 'The Book' on the homepage you can get the first chapter in pdf, which is really an Intro, and does a great job of it. Well worth reading.

https://www.zettlr.com/  A writer produced this version. I have it but haven't done much with it yet. Free.

https://roamresearch.com/  looks great but I think it's cloud-based, subscription.  One thing it has is two-way links.

https://writingcooperative.com/zettelkasten-how-one-german-scholar-was-so-freakishly-productive-997e4e0ca125  Article on the theory and practice

https://github.com/renerocksai/sublimeless_zk  The guy that wrote the plugin for Sublime wrote this to stand alone. Looks PDG to me, but he seems to have abandoned it 2 yrs ago. Free, I have it.

From what I've seen so far, the idea is basically a wiki with enhancements.  Enhancements may include name completion for links to other notes, retrieving groups of linked notes, and so on.

I would be interested in adding several capabilities if they turn out to be feasible:

1. Full text search of the notes by a search engine.

2. Special processing based on certain semantic features in the notes, if they can be written with a bit of structure. 

3. Including URLs to web pages in the links.

4. Including images in the notes in some fashion.

For item 2, I'm thinking partly of the following.  Although each note is usually written about as being about one thing, if you are thinking about how two things relate together, that in itself is a topic or idea.  In my work on bookmark organization, when the system encountered one of these compound topics, it took it apart and linked to the other topics for each piece.  This is one way to promote serendipidy.  For example,  I had a topic "Python", and a topic "Services".  A page stored under the heading "Python And Services"  would get linked to both "Python" and "Services", so a search for one would also get the other.  I have found this pretty useful.  Probably a good full-text search would accomplish this, but it will work better if the notes can be lightly structured.

Could you say a little more about how your existing notes are organized and stored, and file formats if they are not all text?  We'd want to ingest them with minimal hand effort if possible.

[vitalije]

There is one program that I immediately thought of after reading a few pages about Zettelkasten: fossil and its wiki feature. It is a single executable (a rather small one ~ 2-3Mb), that can work on any platform. It supports tagging, timeline view. One can see the history of any given note. With some basic Tcl programming one can easily generate cross reference pages of links between notes. It is not overly complicated to put the content of your repository online so that you can access it from anywhere. It supports markdown format for writing wiki pages (= notes). The whole archive content is in a single file which makes it easy to copy from one computer to another. It is easy to clone entire archive over the internet and work locally and later synchronize work with the other archives/repositories.

It uses a web browser for its UI. User can choose from several themes or write a new one.

Right now, I intend to start my own Zettelkasten using fossil, but I am not sure that I will persist keeping it.

Vitalije

[vitalije]

On Friday, January 31, 2020 at 1:47:45 AM UTC+1, Thomas Passin wrote:

I would be interested in adding several capabilities if they turn out to be feasible:

1. Full text search of the notes by a search engine.

2. Special processing based on certain semantic features in the notes, if they can be written with a bit of structure. 

3. Including URLs to web pages in the links.

4. Including images in the notes in some fashion.

Thomas I believe fossil provides all of these features.

Vitalije

[Edward K. Ream]

Thanks to all for the links and comments. I've scheduled design work for Leo 6.2.

Edward

[Edward K. Ream]

Here's a writeup by someone who's doing it in the SublimeText editor.  It actually sounds pretty good -

http://www.dansheffler.com/blog/2015-05-11-my-zettelkasten-in-sublime/

Thanks for the link. I've bookmarked it.

I'm going to pause this project for now. There are too many bugs and other loose ends to complete before starting anything new.

I'll do a plugin only if it can be done easily and without any changes to Leo's gui.

Edward

[Thomas Passin]

On Friday, January 31, 2020 at 4:54:50 AM UTC-5, vitalije wrote:

There is one program that I immediately thought of after reading a few pages about Zettelkasten: fossil and its wiki feature. It is a single executable (a rather small one ~ 2-3Mb), that can work on any platform. It supports tagging, timeline view. One can see the history of any given note. With some basic Tcl programming one can easily generate cross reference pages of links between notes. It is not overly complicated to put the content of your repository online so that you can access it from anywhere. It supports markdown format for writing wiki pages (= notes). The whole archive content is in a single file which makes it easy to copy from one computer to another. It is easy to clone entire archive over the internet and work locally and later synchronize work with the other archives/repositories.

Now that I have actually gotten a couple of zettel-programs and thought about it some more, I'm convinced that the notes need to be kept out of databases and unduly specialized systems.  Those may provide special features more easily and "efficiently", but when you are talking about the sum of someone's research and thinking for years or decades, they absolutely MUST be able to take the information and use it in some other way with some other method. I'm going to claim (I'm not the only one) that only simple text-format notes can do that.

Yes, fossil says they export an "archival" format that will be around and usable forever.  But it's filled with hashes and metadata that the researcher doesn't want and can't use or even read.  And issue tracking ticket systems are always finicky to use, and require the user to spend too much time in the machinery, which time does not contribute to the thinking process.

With a set of text (including say Markdown) files, one can fall back to full text searches if no other system ends up working well enough.  Or even to keeping a paper Zettel-box that refers to the text files by name, if you really had to.

[Thomas Passin]

On Friday, January 31, 2020 at 9:26:31 AM UTC-5, Thomas Passin wrote:

With a set of text (including say Markdown) files, one can fall back to full text searches if no other system ends up working well enough.  Or even to keeping a paper Zettel-box that refers to the text files by name, if you really had to.

One method I have used is to write notes into a text file using a simple structure:

Each note starts with a header line, for example

[Transims server information] 2007-07-02

Each note ends with a line "============================" (it doesn't matter how many "=" characters there are.  This format is simple enough that I find it's no trouble typing the header and footer lines.

I wrote a simple python parser to identify the notes and get their title and date.  I use this with the Lucene search engine.  I had to write some python code to write the Lucene index, and to get the search results.  The output loads right into a browser for readibility, with some useful links.  Just this simple system works surprising well.  But since you can't get a 64-bit python wrapper for Lucene on Windows in binary form**, I had to actually use jython.  This works well, but it's inconvenient because the startup time for each query is very slow.  I suppose I could put it on a server and make it more workable, but I was looking for a serverless solution.

This is to show that fairly simple text format notes can be very effective.

** Apparently building the Lucene python wrapper on Windows in darn near impossible for most folks.

[Thomas Passin]

As I think about how Leo could be useful with the zettel-box approach, I do see a way.  But it's not to have each note be a node in a Leo outline.  Can you imagine trying to work with thousands or tens of thousands of nodes in the outline pane?  Instead, I can see using an @zettel tree whereby if you put a node name into the headline of the node, Leo would open that note and any notes it linked to.  You could keep them in a group forever in the outline if you liked, or delete the tree when you were done with that activity.

You would be able to edit any note just like any other markdown node.  In the vewrendered pane you could see a rendered view of the note or the whole tree it was in.  Possibly you could get other kinds of views in the VR pane.  I would favor a mind map type view, myself.

You would be able to launch full text searches of the notes. I'm thinking that the Python Whoosh search engine would be good for that.

You would have the wiki-like ability to create a new note by using its name if it didn't already exist.

Would this be better than using Zettelr?  I don't know, I just installed it and haven't played with it except to see that it has a very good ability to import many file formats, including LibreOffice documents, and convert them to markdown.  Maybe that would be the way to go - use Zettelr to convert to markdown, and then use Leo to work with the converted notes. You'd still be able to use Zettelr for anything it was better at.

[andyjim]

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

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

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

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

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

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

Andy

[Edward K. Ream]

On Fri, Jan 31, 2020 at 10:40 AM Thomas Passin <tbp1...@gmail.com> wrote:

Can you imagine trying to work with thousands or tens of thousands of nodes in the outline pane? 

It could be done easily, if that is what you wanted.

Instead, I can see using an @zettel tree whereby if you put a node name into the headline of the node, Leo would open that note and any notes it linked to.  You could keep them in a group forever in the outline if you liked, or delete the tree when you were done with that activity.

Yes, something like this is reasonable.

You would have the wiki-like ability to create a new note by using its name if it didn't already exist.

A plugin would keep track of all existing names somewhere, perhaps in a uA, perhaps in a special node.

Would this be better than using Zettelr? 

Imo, it is clear that Leo's organization strengths will easily handle whatever tasks we give it.

Edward

[Thomas Passin]

On Sunday, February 2, 2020 at 6:48:32 AM UTC-5, Edward K. Ream wrote:

On Fri, Jan 31, 2020 at 10:40 AM Thomas Passin <tbp1...@gmail.com> wrote:

Can you imagine trying to work with thousands or tens of thousands of nodes in the outline pane? 

It could be done easily, if that is what you wanted.

Well, yes, technically, but it's not at all easy for a user to work with an outline or select list with too many items. Too hard to read, too much scrolling! (Yes, I know that good organization and searching helps a lot - look at LeoRef.leo, for example).

One way I dealt with this in the past, in a browser application, was to have the list be able to fold or unfold locally, at each node.  To unfold a folded tree, you press the control key and drag the mouse over the node (and probably adjacent nodes).  Dragging with the shift key folds them up again.  This is not a standard UI method, but it was pretty effective.

Hmm, do you know if QT5 would support this?

[andyjim]

Thank you again Edward.  I wandered in here shyly with an idea I didn't think would get much attention.  And it still may not warrant or deserve a lot of interest here.  Also the Leo community is about to begin work on 6.2 so I expect there isn't time to spare on something like this.  Nonetheless I'm surprised and grateful for what attention and comment it has received.

I want to say that I have only touched here on my ideas about it. The zettelkasten concept is central to it indeed, but there's a lot more to my whole concept than the zettelkasten model.  I've spent several years dreaming, as a non-programmer, on an optimal program for the writer, note-taker, organizer, thinker, journaler, what have you . All assembled, my ideas (some my own, some already implemented somewhere) would, imo, make a better program for this kind of work than anything I've been able to find (had I found it I'd already have it).

Sure wish I were a programmer.  Sometimes I've thought maybe I should dive into programming just to gain the skills to build this myself, but I think that's likely way too ambitious, especially at my age.

But if/when someone here wants to/has time to give it a look, I would love to have the opportunity to submit a more lengthy 'essay' outlining in some detail what I've evolved in my imagination over a few years of thinking about this.  Naming a few features doesn't get the idea across.  I haven't written it up in one piece as yet.  I need to scramble through all my past notes about it; might take 3-5 pages.  Heck, maybe it's not as good a set of ideas as I think, but what I envision sure appeals to me for what I do with writing.  Wish I'd had it 20 years ago.

Andy

On Sunday, February 2, 2020 at 6:48:32 AM UTC-5, Edward K. Ream wrote:

[Matt Wilkie]

 

I would love to have the opportunity to submit a more lengthy 'essay' outlining in some detail what I've evolved in my imagination over a few years of thinking about this.  Naming a few features doesn't get the idea across.  I haven't written it up in one piece as yet.  I need to scramble through all my past notes about it; might take 3-5 pages.  Heck, maybe it's not as good a set of ideas as I think, but what I envision sure appeals to me for what I do with writing.  Wish I'd had it 20 years ago.

In my opinion writing out an ideal interface (or more accurately: work, process and interaction flows) are worth doing, if only to clarify for self what is being sought. I've found it valuable for myself at any rate. It's a good way of making the not-so-well-considered ideas known. If I can't describe it clearly, then I haven't considered it as much or as deeply as I'm in the habit of assuming I have. Of course even after the fuzzy thinking has been given the boot it's still very difficult to get others to invest enough imagining-themselves-in-your-shoes time to appreciate the vision described -- they're busy with their own imagings.

You've been thinking about this for a couple decades, the challenges still have you by the short and curlies, they're not letting you go or you them, so by that evidence alone it's something worth writing down. :-)

-matt

[Thomas Passin]

On Monday, February 3, 2020 at 6:06:33 PM UTC-5, andyjim wrote:

Sure wish I were a programmer.  Sometimes I've thought maybe I should dive into programming just to gain the skills to build this myself, but I think that's likely way too ambitious, especially at my age.

But if/when someone here wants to/has time to give it a look, I would love to have the opportunity to submit a more lengthy 'essay' outlining in some detail what I've evolved in my imagination over a few years of thinking about this.  Naming a few features doesn't get the idea across.  I haven't written it up in one piece as yet.  I need to scramble through all my past notes about it; might take 3-5 pages.  Heck, maybe it's not as good a set of ideas as I think, but what I envision sure appeals to me for what I do with writing.  Wish I'd had it 20 years ago.

 

I have written an initial set of user requirements (attached), and I would appreciate your thoughts on them.  These are very high level requirements, and they don't include any actual user interface ideas.  Instead, they are things that I think any UI would have to honor.  I have tried to abstract from written work on paper zettelkasten systems.  I also tried out several (free) zettel-programs for Windows, none of which worked well at all for me.

One key point for me is a need to prevent lock-in to this - or any - particular system by either keeping the zettelkasten in the form of text note files, or having the ability to export a complete set of such files.  In the worst case, I picture to myself, one could print out the text notes and actually use them as is in a physical zettelkasten.  I think this is so important that I made it the first requirement.

[Thomas Passin]

On Monday, February 3, 2020 at 7:03:04 PM UTC-5, Matt Wilkie wrote:

In my opinion writing out an ideal interface (or more accurately: work, process and interaction flows) are worth doing, if only to clarify for self what is being sought. I've found it valuable for myself at any rate. It's a good way of making the not-so-well-considered ideas known. If I can't describe it clearly, then I haven't considered it as much or as deeply as I'm in the habit of assuming I have. Of course even after the fuzzy thinking has been given the boot it's still very difficult to get others to invest enough imagining-themselves-in-your-shoes time to appreciate the vision described -- they're busy with their own imagings.

You've been thinking about this for a couple decades, the challenges still have you by the short and curlies, they're not letting you go or you them, so by that evidence alone it's something worth writing down. :-)

In my experience, this is so very true.  You can't really know what you want until you have tried using it to do real work.   That will help refine and change your ideas pretty quickly (it's sometimes called "dogfooding", for "eating your own dog food").   OTOH, you have to have some conceptual framework to make a start.

In the case of the zettelkasten, the originator of the system wrote that it will take maybe two years to get enough material into the system for it to start to make its benefits obvious.  Another practitioner wrote about having it become helpful in a few months.  So we can't expect to arrive at a good system by quickly hacking away for a little while.  It's going to take a real investment of time working with it and changing things.  That's not a bad thing, but it is reality.

[andyjim]

Thanks much Matt and Thomas.  I have many pages of notes on this, and as I looked at some notes from 2-3 years ago most of them lack clarity, though some are better than others.  One approach I thought I might take is to 'narrate' a work session with my envisioned program. Describe what I am wanting to do, how search and navigation plays out, what does a 'standard zettle' do and not do, etc.  The steps I take and how the software responds, what I see happening.  That might bring me about as close as I can get without a working software.  Might be better than just trying to list desirable features, which I have done a lot of. Some of my past notes are so vague that I hardly understand now what I was trying to say! But I think my ideas have slowly gotten clearer in the past couple of years, but I have yet to spell it out clearly in nouns and verbs.  iow I think it's clearer in my mind, but not yet in text.  I'll see what I can do but it's going to take some time. What should I do once I get something written? Post it in this same thread (which is getting long)?  I'll just do it in a  plain text file, since I don't know any markdown/up anyway.

Thomas, sorry for my ignorance but what do I need to do to view your HTML file rendered?  I can dig out the text as is, but rendering it would make it a lot easier.  I'm not HTML literate.

Thanks for your gentle and patient assistance.

Andy

[Edward K. Ream]

On Mon, Feb 3, 2020 at 5:06 PM andyjim <andy...@gmail.com> wrote:

Sure wish I were a programmer.  Sometimes I've thought maybe I should dive into programming just to gain the skills to build this myself, but I think that's likely way too ambitious, especially at my age.

Nonsense. Anyone over the age of 7 can learn python. The trick is not minding all the mistakes you are going to make :-)

But if/when someone here wants to/has time to give it a look, I would love to have the opportunity to submit a more lengthy 'essay'

Length is not your friend in convincing others.

Edward

[Thomas Passin]

On Monday, February 3, 2020 at 10:36:59 PM UTC-5, andyjim wrote:

Thomas, sorry for my ignorance but what do I need to do to view your HTML file rendered?  I can dig out the text as is, but rendering it would make it a lot easier.  I'm not HTML literate.

Do you see that there is a link under the attachment labeled "Download".  Click that link and notice the directory location it gets saved to.  After it is saved, your browser will have some control or menu item to show you your downloads.  In that listing, click or, for some of them, double click) on the newly saved file and it will open in your browser.

I sent the file as html because it is more readable in a browser than plain text, but I can also send a text file if you still can't view the html one.

As for Markdown, it is very nearly plain text with a few conventions, so even a plain text file will usually display fine in a Markdown viewer, and vice-versa, a Markdown file will be pretty readable in a plain text viewer.

[Thomas Passin]

On Tuesday, February 4, 2020 at 5:25:45 AM UTC-5, Edward K. Ream wrote:

Length is not your friend in convincing others.

Length can be unavoidable, when there are many interacting parts.  But each of those parts is better when compact.  But there's an art here - too terse can be be hard for others to grasp.

A need for a lengthy essay could indicate that the underlying thoughts have not gelled enough for prime time.  Or it could mean that the thoughts are very rich and well worked-out.  But for our purposes here, it will be helpful if they are put simply and clearly.

[Thomas Passin]

Here's something interesting.  Remember the Memex, described by Vannebar Bush in 1945?  It sounded like a mixture of the Web and a zettelkasten, with better media input means than perhaps we have today.  Well, someone is trying to actually build one, or at least something as close as he can get given that the article was only a notional sketch of an idea, and that technology has changed a lot  since then.  Take a look -

http://memexsim.sourceforge.net/index.html

[Thomas Passin]

I have put the HTML file on my server at

http://tompassin.net/pub/zettel/zettel_requirements.html

You can just open it in your browser at that address.

[Thomas Passin]

On Tuesday, February 4, 2020 at 9:43:17 AM UTC-5, Thomas Passin wrote:

Here's something interesting.  Remember the Memex, described by Vannebar Bush in 1945?  It sounded like a mixture of the Web and a zettelkasten, with better media input means than perhaps we have today.  Well, someone is trying to actually build one, or at least something as close as he can get given that the article was only a notional sketch of an idea, and that technology has changed a lot  since then.  Take a look -

http://memexsim.sourceforge.net/index.html

Remember my mentioning my bookmarks application in an earlier post?  Well, it has some zettel-box-like features.  I found the link to the Memex simulator while I was checking to see which Zettelkasten bookmarks I had captured so far.  Apparently I had found the link years ago and completely forgotten about it.  But there it was, waiting to be discovered again.

Here is a screen shot showing the display where I found it.  I had just searched for "zettel":

http://tompassin.net/pub/zettel/zetel_display.png

By clicking one of the "details" links, I saw that there were more bookmarks under a subheading -

http://tompassin.net/pub/zettel/zettel_finding_more_related.png

By clicking on "Related Terms", I can see that there are two:

http://tompassin.net/pub/zettel/zettel_related_headings.png

To give a better idea of how the "related" functionality works, here are the related terms for "Conceptual Graphs":

http://tompassin.net/pub/zettel/zettel_conceptual_graphs_related.png

I can add a note - or other types of annotation - to a bookmark:

http://tompassin.net/pub/zettel/zettel_add_note.png

You can see that I actually have much of the functionality that we are talking about, if we used note files as a target rather than web pages.  The main problem with my prototype is you can't save data directly to the file system.  Browsers don't let you do that. Whenever I have collected some new bookmarks in my browser, I save the bookmarks and run some scripts against the bookmarks file.  That recreates everything including the crosslinks, except for my added annotations.  Those I have to write as text to a browser page (I have a link that runs the javascript to do this), do a View Source, copy the text, and paste it into my separate annotation file.

Anyone would ask why I didn't have the web server do all this. The reason is that I wanted to make it run entirely on a local machine without a server at all.  It all runs on files on the file system with no computation except what's in the web pages.  That was around 2004.

It turns out that nowadays, that won't work because most if not all web servers prohibit my style of on-computer file linking for security purposes. So I finally gave in and put the system on a Tomcat web server on my own computer.  No changes were needed to make this work.  All pages are static files.

Obviously if the app were redesigned today, you could use a Python back end instead of using javascript in the web pages.  The way I wrote the core engine, it's easy to port to Python (I did it for an earlier version).  You could serialize the data with JSON - we didn't have that back then, so my serialization takes the form of a code generator that writes the javascript needed to reconstruct the whole thing.  Or you could put the back end code into a plugin for Leo.

My system even treats files in selected directories on my computer as bookmarks - they could actually be notes if you wanted.  The file name becomes the bookmark title.

You can see I've been thinking about this area for a long time. That's why I got interested when @andyjim started asking questions about zettelkasten.

[Thomas Passin]

Here's another potentially useful paper -

http://people.csail.mit.edu/msbernst/papers/p337-vankleek.pdf

The actual software project is now defunct, but we might get some ideas from it.

[andyjim]

"Nonsense.  Anyone over the age of 7 can learn python."

Love it!  Where do I start?  More politely, could you recommend a handful of what you consider the best resources/approach for a beginning programmer?  I may or may not dig in, but I might as well give myself the opportunity and exposure. Actually I've had a very modest exposure to programming and I have heard that python is one of the easier languages to learn.  How come?  Intuitive?  Simple?  Works the way the mind works? 

My age is the exact minimum age you mentioned...but with another digit following.

Andy

[andyjim]

Thomas, I will respond to your notes, and I'm working on a concise description of my envisioned system.

[Steve Litt]

On Tue, 4 Feb 2020 05:10:01 -0800 (PST)
Thomas Passin <tbp1...@gmail.com> wrote:

> On Tuesday, February 4, 2020 at 5:25:45 AM UTC-5, Edward K. Ream
> wrote:
> >
> >
> > Length is not your friend in convincing others.
> >
>
> Length can be unavoidable, when there are many interacting parts.

That's when you need a diagram.

SteveT

Steve Litt
February 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive

[Thomas Passin]

I'm not up on the current books, but here's a possible starting point -

https://wiki.python.org/moin/BeginnersGuide

One thing to keep in mind.  There are two series of Python - 2.x and 3.x.  They are basically very similar but have a few differences.  Even though 3.xx has been the main release for almost a decade, a lot of the examples and tutorials will be using 2.x.  And they may not say so.

The main differences for a beginner are:

1. Print statements in 2.x  - print 'Hello' - are written as functions in 3.x - print('Hellow').

2. Exceptions in 2.x used to be written like this:

   except Exception, e:

      # your code here ...

In 3.x they are

   except Exception as e:

      # your code here ...

The new style works actually works with 2.7 as well. 2.7 is the latest and last version of Python 2.x.  It won't be maintained after the end of 2019.

3.  There are differences in how strings are handled (called encoding/decoding), but it's too complicated to get into here, and won't affect you at an entrance level anyway.

I recommend installing a 64-bit version of Python 3.8 (the current version).

To learn Python, you will need to get used to using the command line, also known as the "console" on Windows or "terminal" in Linux.  You don't need to know much about them except a few basics.  You also want to get a programmer's editor.  Leo can work well, but if you have trouble with its learning curve, and you are on Windows, you can use Notepad++ (free) or editPlus ($35, but worth every cent).  There are fancier editors, but I don't use any of them so I suggest you don't either.

Oh, yes, you can set up Leo to show line numbers for text files.  They are nearly essential to programming.  It's not obvious how to set them up, but if you can't find out how, or get stuck, just ask.

On Tuesday, February 4, 2020 at 6:21:14 PM UTC-5, andyjim wrote:

"Nonsense.  Anyone over the age of 7 can learn python."

Love it!  Where do I start?  More politely, could you recommend a handful of what you consider the best resources/approach for a beginning programmer?  I may or may not dig in, but I might as well give myself the opportunity and exposure. Actually I've had a very modest exposure to programming and I have heard that python is one of the easier languages to learn.  How come?  Intuitive?  Simple?  Works the way the mind works?

Most of the above for me.

 

My age is the exact minimum age you mentioned...but with another digit following.

Mine too ... I might have you beat, though.

[Thomas Passin]

On Tuesday, February 4, 2020 at 6:41:00 PM UTC-5, stevelitt wrote:

> Length can be unavoidable, when there are many interacting parts.

That's when you need a diagram.

Right.  What a pain that we can't have diagrams in an ordinary text file.  Grrr.  Although the Viewrendered3 plugin will be able to execute a mixed text/code file in either Markdown or RsT.  You can have your diagrams that way, when the file is rendered to HTML.  That's something, anyway.

[Steve Litt]

Can't you set a hotkey to simply execute an arbitrary command, so that
you cans run the diagram alongside the outline?

[Edward K. Ream]

On Tue, Feb 4, 2020 at 7:01 PM Thomas Passin <tbp1...@gmail.com> wrote:

I'm not up on the current books, but here's a possible starting point -

https://wiki.python.org/moin/BeginnersGuide

One thing to keep in mind.  There are two series of Python - 2.x and 3.x.

Python 2 is no longer supported. Stick with 3.

Edward

[Thomas Passin]

Yes, absolutely.  It's just that there is still a lot of material on the web (like tutorials and Stack Exchange) that still use Python 2.x, so a newbie better be prepared to encounter it.

[Matt Wilkie]

 One approach I thought I might take is to 'narrate' a work session with my envisioned program. Describe what I am wanting to do, how search and navigation plays out, what does a 'standard zettle' do and not do, etc.  The steps I take and how the software responds, what I see happening. 

Narration is an excellent idea. Also called "user stories" in some software development circles.

-matt

[andyjim]

Thank you, got it, and will reply. I had been thinking if I just opened your attachment it should display rendered. Didn't realize that for some reason it doesn't do that unless it's downloaded. Don't understand it, but that's ok.  Many things in life I don't understand...

Thomas, tell me if this is an inappropriate suggestion, but I wonder if this thread has pretty much played out its level of pertinence and interest to the Leo community, since it's not directly about Leo and may be on a subject of limited interest here.  Given your own zettelkasten-like program and your interest in knowledge and semantic processing, and your direct questions to me about my ideas (I'm working on it), would it be appropriate for us to continue the discussion by email?  That would be much easier for me, but if not appropriate I'll continue here, though this thread waxes long now and I feel I don't function well in a forum venue. 

Some may ask why then did I post here? Well, I can function, just not well, in my opinion. And I did want help. And I do indeed recognize and appreciate the time, consideration and help given here. No disappointment at all, nor disrespect intended, just wondering if it's time to continue it elsewhere.

Andy

andyjim47-at-gmail-dot-com

[Xavier G. Domingo]

Hi Andy,

I've not made any comment till now because I'm really short on time, but I have to say that I find this thread REALLY fascinating and a source of really good and stimulating ideas! So I would greatly appreciate if you go on with all this conversation in the open, either if it's here or in any other place. I think that all the Leo community will benefit from it.

That being said, maybe the conversation could be "refactored" in several sub-topics which may be better handled via new dedicated threads. Do you think that could make the discussion more "easy to handle"?

And last but not least, using this forum is not opposed to having an email conversation: you can have both! In fact I'm following this conversation entirely by email and I'm sending this answer from my email client... Maybe this helps in solving your dilemma. Let us know if you need help on that.

Best wishes and please keep us informed about your next steps. I will be looking forward to your posts with great interest!

Xavier

[Thomas Passin]

On Wednesday, February 5, 2020 at 10:30:26 PM UTC-5, andyjim wrote:

Thomas, tell me if this is an inappropriate suggestion, but I wonder if this thread has pretty much played out its level of pertinence and interest to the Leo community, since it's not directly about Leo and may be on a subject of limited interest here.  Given your own zettelkasten-like program and your interest in knowledge and semantic processing, and your direct questions to me about my ideas (I'm working on it), would it be appropriate for us to continue the discussion by email?  That would be much easier for me, but if not appropriate I'll continue here, though this thread waxes long now and I feel I don't function well in a forum venue. 

I've been wondering the same thing.  Trouble is, if we use email, it's just us, and we miss out on other people's  thinking.  We could set up a whole new Google group, but I'd like to keep the discussion in the Leo context if we can do so - would you agree?  And it's clear that there is some degree of interest, as we see from @Xavier's post.

What I'm thinking is to open a new thread in the Leo group - and to keep opening new threads when and as one gets too long to work with.  Just now, we're wrestling with what we really want to accomplish and how it ought to work, and it would make sense to open a new thread on requirements and concept of operation (this could include your narratives).  How's this sound to everyone?

I've gone beyond the requirements I posted a few days ago, and tried to come up with a note format that

1. Can be typed and read easily;
2. Can be processed by software easily;
3. Could be used in a paper Zettelkasten if one really had to do that;
4. The system could export note files in this format without too much difficulty;
5. Contains most of the essential information, so that the software could reconstruct the entire zettelkasten just from these notes if need be (possibly with a small amount of information loss);

I think I've gotten most of this.  The main things I haven't worked out so far are links to other notes that might be embodied right in the text of the note (if we really want these). and similarly how links to other non-text media would be captured in the zettel.  There is no end of ways these things could be done, and my interest is in coming up with something that is especially easy to type and read.

Why my emphasis on typing the zettels?  Because the alternative is to use some software system that tries to "help" you.  Now we'll certainly want something like that as an option, but having to use a number of select or drop-down lists or whatnot all the time really interferes with one's flow.  Straight typing is better where possible.

In my concept of operations, one would be able to type into a new zettel - either in a Leo node or even in a separate file - and then the system would hook it up based on the info you typed.  Later, the system would help you change, add to, or update the references;  you could do that when you weren't so involved with the thoughts you were typing.

[John Clark]

Andy,

FWIW I have been following this thread with interest also. Your original post is the first I've ever heard of Zettelkasten and I was immediately drawn to it because I too am on the search for the "Holy Grail" of knowledge repositories. 

I've configured my settings for this group so that I only receive a daily digest of postings, so even if I wasn't particularly interested in this thread it wouldn't be clogging my inbox.

I vote you keep the discussion going.

Cheers

John

[Matt Wilkie]

My 2c: this discussion is interesting and I like watching it unfold, even though my participation is low key so far. Splitting the major ideas into separate threads would be useful. Perhaps preface subject with [zet] to help with filtering.

To subscribe using email client instead of the web forum send a message to leo-editor...@googlegroups.com.

Source: https://webapps.stackexchange.com/questions/13508/how-can-i-subscribe-to-a-google-mailing-list-with-a-non-google-e-mail-address

-matt

[andyjim]

I'm attaching my responses to the requirements you wrote, Thomas  I'm thrilled there is more interest here than I had thought.  I haven't even digested your comment here yet, just wanted to get my responses posted to hold up my end here.  Will gladly consider all thoughts on how we should proceed here.  Thanks much to all.  I never expected this much when I walked in here.  I definitely want to take this as far as it can go.

Andy

[Thomas Passin]

Andy, thanks for your comments.  I will give my reaction to them in a series of posts, one per item.

On Thursday, February 6, 2020 at 9:52:45 PM UTC-5, andyjim wrote:

I'm attaching my responses to the requirements you wrote, Thomas  I'm thrilled there is more interest here than I had thought.  I haven't even digested your comment here yet, just wanted to get my responses posted to hold up my end here.  Will gladly consider all thoughts on how we should proceed here.  Thanks much to all.  I never expected this much when I walked in here.  I definitely want to take this as far as it can go.

 1. No lock-in
@andyjim: "I agree with the principle you stated but not quite understanding the implications. Don't tie data up in a proprietary software system? Or does this refer to the organization of the notes? Don't organize them in such a way that would be a confused mess if you took the notes out of the system? I'm afraid I'm not catching on here."

"Lock-in" is a term often used in connection with so-called open-source software.  It means that if you decide to start using some other software system, you should be able to take your data and use it with the new system.  If there were a standard format for this kind of thing, then it should be our choice.  But there isn't one.  To make this have a hope of being possible, our system should either use a text format, or at least be able to export such a format.

This format should be relatively easy to write software to convert it to some other form, if need be.  IMHO, it should also be possible for a person to read and type easily, so that even without a different system to change to, there would still be value in the zettels.  I picture myself printing it all out and using it as an actual physical zettelkasten - but maybe that's too idealistic!

However, consider that you might have to use a computer that doesn't have our software on it.  You might still want to be able to create new notes, and later import them into our system.  I think that's a realistic scenario.  Maybe you had to take a borrowed laptop to a conference, or something like that, or a tablet that doesn't run Leo.

[andyjim]

attached is my first draft for a zettel format. 

[Thomas Passin]

On Thursday, February 6, 2020 at 10:59:37 PM UTC-5, Thomas Passin wrote:

Andy, thanks for your comments.  I will give my reaction to them in a series of posts, one per item.

Continuing my reactions to your comments -

4. Unique Identification
@andyjim: "I propose YYMMDDHHMMSS as a UID format. I further propose that each section of a zettel use the UID of the zettel, with an added digit as an identifier for that section."

Here I will disagree.  Based on a lot of experience with my bookmarks system and other experiments with topic maps, I prefer identifiers that convey some information.  To the software, they would still be arbitrary.  Suppose you end up with a lot of zettel files but without the software.  You want to find some notes relating to (Zettel Design Notes").  Wouldn't you rather scan the file listings for file names like "zet-design-1", "zet-design-2", and so forth, compared with "2020031412034522"? I would.  And they are much easier to type, too

It's true that the software can display a list of titles no matter what the identifiers are, and it's also true that computer-generated identifiers are easier to guarantee that they are unique (sorry for the awkward sentence structure there!).  But my thinking here is dominated by the desire to have a system that can be transported to other software or, in the last resort, still be useful manually.  After all, we're talking about possibly years of work stored in the zettelkasten.  It *has* to remain usable.

Also, if I were typing a note, I wouldn't want to have to type in identifiers that look like that.  It's too hard and finicky.

My concept at this point is that the user types in an optional ID and an optional title.  If he doesn't include an ID, the system tries to make one from the title.  If there were no title, the system would make an id from the first line of the text of the zettel.  If somehow the zettel had been filed without any text - maybe as a placeholder to be revisited later - then the system would make up an arbitrary ID, possibly exactly what you suggest.

The zettel would still contain the time, just not as the ID.

[Thomas Passin]

On Thursday, February 6, 2020 at 11:18:39 PM UTC-5, Thomas Passin wrote:

On Thursday, February 6, 2020 at 10:59:37 PM UTC-5, Thomas Passin wrote:

Andy, thanks for your comments.  I will give my reaction to them in a series of posts, one per item.

Continuing my reactions to your comments -

 

9. Backlinks
@andyjim" "Yes, bi-directional links is on my wish list.
I agree that backlinks should be in exported files, but not sure what the implications are. I've assumed all code embedded in a zettel should be in any external files. But let's see, if we want to export a file to say, Scrivener to be worked into a document, it seems at that point we're expunging it from the zettelkasten system and it should only need text and perhaps markdown, but will it need any embedded code? Probably I'm not understanding on this one."

My thinking on this one has changed over the last few days.  Backlinks are important for sure.  This means that of you link zettel A to zettel B, then the system knows that zettel B should also be linked to zettel A.  However, keeping all that information in the zettel itself might make for the zettel getting too long.  Remember that part of the zettelkasten system depends on the notes being short and focused.

When the system sets up the links, it certainly can create and keep track of the backlinks.  But maybe, if the data is exported to text, there should be a separate file that only contains these backlinks.  That might fulfill the intention of having all the information available in simple text files while keeping the individual zettels short and relatively clean.

Of course, if we have our system working, it could export just the text of the zettel if that's what we need for say publishing papers.  That's a separate matter from recovering our data.

[Thomas Passin]

On Thursday, February 6, 2020 at 11:18:39 PM UTC-5, Thomas Passin wrote:

On Thursday, February 6, 2020 at 10:59:37 PM UTC-5, Thomas Passin wrote:

Andy, thanks for your comments.  I will give my reaction to them in a series of posts, one per item.

Continuing my reactions to your comments -

10. Display Styles
@andyjin: "Could this be called 'mapping'? e.g. a simple tree is a mapping or 'display style' of relationships.
To me this is one of the most important elements of the system, and it's all about accessibility. I want to be able to find any note or group of notes in the system very quickly and intuitively.
On my wish list is a search/navigation system that will enable me to locate items by tag(s), date, hierarchic relationships, linked relationships, text search terms, any other useful relationships that may be conceived for the system, AND any combination of these, in one search. My (only partially conceived) notion is for search results for such a search involving multiple types be displayed in a mapping or tree, and that that that tree be navigable. This is not well conceived as yet, but hopefully the general concept is understandible."

All things are possible, but it's easy to make a system that's too complicated.  In that case it doesn't get used for very long.  If you think how valuable the original zettelkasten seems to have been, it didn't have any of those capabilities.  In my experience, it's good to start out simple, and slowly extend the capabilities as you find you really need them.  In my bookmark system, I started with maybe half a dozen features that it turns out I almost never use.  Other features I modified after a lot of experience.

For example, I can do a simple text search for a phrase.  What's especially useful is that it returns hits for both web page titles and also for the indexing terms.  These two are displayed separately, mot mixed together.  I have working code to do approximate searches - matches will be found even if a single character is wrong or missing - but so far I haven't  bothered to include it because I find I don't need it much.  It's almost as easy to spot a typing error if I don't get any good search hits, and I don't have to remember the limitations of the approximate search algorithm.  So I haven't bothered to add it so far (I do have it in a different application).

As another example, back around 1990 I wrote a small personal phonebook app.  I still use it.  I can search for a person's full name.  The search is progressive, so that if I get a match before typing the whole thing, I get to the right entry.  However, I have to start with the last name first.  In hindsight, I would like to be able to start with either the first or last name.  But the system I used to create the app (Powerbuilder) is long gone and so I can't change it.  I have never felt that it was worth re-creating the app in a different language, so I live with it.  It's not too big a pain.

My point is that these systems need to start simple, but be designed so that it's not too hard to change or extend them as you learn how to use them.

[Thomas Passin]

On Thursday, February 6, 2020 at 11:04:30 PM UTC-5, andyjim wrote:

attached is my first draft for a zettel format. 

Thanks.  Here's my first cut at a format.  It's designed to be easy to type and easy to read.  All the keyword data items are optional.  I can tell you that it will be almost trivial to write a parser for this format.  It might not take more than ten or 20 lines of code, depending on what data structures you want to parse it into.  There is a minimum of extraneous marks and structure, so as to distract from the text as little as possible.

I use a semi-colon ";" as the preferred comment mark because it is easy to type - being lower case;  and I suggest the alternate "#" because many programmers are used to typing and seeing it even though it's upper case.

Oh, and @andyjim, would you mind adding the extension ".txt" to your plain text files?  It makes life a little easier for other people (and the OS) because we don't have to guess what format they are in.  For example, instead of naming a file "zettel_format_1", name it "zettel_format_1.txt".

[Thomas Passin]

On Friday, February 7, 2020 at 12:00:43 AM UTC-5, Thomas Passin wrote:

On Thursday, February 6, 2020 at 11:04:30 PM UTC-5, andyjim wrote:

attached is my first draft for a zettel format. 

Thanks.  Here's my first cut at a format.

Here's a Markdown version of the same thing.  You can see that it is basically just as readable, and could be parsed by almost the same parser as the plain text version.

[Thomas Passin]

On Friday, February 7, 2020 at 12:00:43 AM UTC-5, Thomas Passin wrote:

On Thursday, February 6, 2020 at 11:04:30 PM UTC-5, andyjim wrote:

attached is my first draft for a zettel format. 

Thanks.  Here's my first cut at a format.

Here is a Restructured Text version that uses RsT syntax features.  I think this is the best I've come up with so far.  Attached is the text file and an HTML file showing how it looks rendered by an RsT processor.

This format is nearly as easy to type and read in plain text as the original plain text version, uses only standard RsT features, and is very readable when rendered to HTML.

[andyjim]

A draft of my 'user's story', in hopes it gives a glimpse of how I see the system playing out.  Much is left out of this draft; I just intend it to give a flavor.

[andyjim]

Seems this issue needs a lot of thought.  Niklas Luhmann's zettels had numerical ID numbers, without textual clues as to their content.  And it was a paper system. And he certainly didn't work by remembering filenames (he had 75,000 zettels). I don't think it could have worked with textual, meaning-based filenames---not for that big a system (and I have the same problem, not on his scale but I will at least be in the 10s of thousands I think). How did he do it?  Well, we know he had an indexing system, though we don't know much about it. And we know that his zettel ID numbering system itself created 'clusters', so the zettel IDs served as a sort of internal indexing system, which was in turn connected with his external indexing system (I'm assuming his indexing was external to the zettelkasten itself. The software zettelkasten systems I've seen simply generate a time-based numerical UID. Fine for the system, but gibberish to the user, so they do not employ Luhmann's type of indexing system.  Maybe we need to figure out how to employ those principles. Maybe some sort of indexing system is what I'm fishing for when I talk about 'mapping'.  I'm going to be thinking about this.

I understand your wanting individual text-based filenames, in order to be forward-compatible with an uncertain future. I get that and agree with the principle.  But it appears to me that while that idea is forward-compatible it's not current-compatible with a software-based zettelkasten.  How do we resolve this?  Well, you suggested an optional, user-entered title as the UID. What if the system could (optionally) generate a separate file using the zettel title as the filename? The reason I say 'optionally' generate that file is that in my case I do intend to use titles, but they won't be unique. I might use the same title for a hundred different zettels, some on entirely different subjects.

Hard to conceive?  Well here's an example for a PIM system: a file called Books of Interest. Now suppose my PIM system covers a number of different categories, in each one of which I want a list of books of interest.  In my system, which is a thoughts system, not a PIM system, there will be thoughts, concepts, ideas, themes that occur in many different contexts, hence the high likelihood of identical zettel titles in many contexts. That's why I need much more than just a simple filename in order to locate any given zettel in its full context, to say nothing of my inability to remember thousands of files. This is the magic of the zettelkasten system. So in my thinking, using a zettel's title for its UID won't work in this kind of system (maybe I should say in my use case of this kind of system).  But, having said that, I certainly can buy into what I'm calling your forward-compatibility principle. 

So how about going with the best of both worlds, and provide an option to generate files by zettel title? They could be loaded into an archive as both a second copy of the files, and as a hedge against an unknown future. Or if you want, an option to use zettel titles as UIDs instead of having the system generate time-based UIDs (Let the system do it: I wouldn't want to type those in either).

[Thomas Passin]

On Saturday, February 8, 2020 at 2:15:42 PM UTC-5, andyjim wrote:

Seems this issue needs a lot of thought.  Niklas Luhmann's zettels had numerical ID numbers, without textual clues as to their content.  And it was a paper system. And he certainly didn't work by remembering filenames (he had 75,000 zettels)....

I understand your wanting individual text-based filenames, in order to be forward-compatible with an uncertain future. I get that and agree with the principle.  But it appears to me that while that idea is forward-compatible it's not current-compatible with a software-based zettelkasten.  How do we resolve this?  Well, you suggested an optional, user-entered title as the UID. What if the system could (optionally) generate a separate file using the zettel title as the filename? The reason I say 'optionally' generate that file is that in my case I do intend to use titles, but they won't be unique. I might use the same title for a hundred different zettels, some on entirely different subjects.

I think we're pretty much on the same page here.  There seem to be three similar but different things in play:

1. Unique IDs for each zettel;
2. Titles;
3. File names for a putative move to to another system or even (temporarily, we hope!) a manual system.
   

 1. IDs are easy. I happen to prefer ids that are more or less readable, but that's not all that important.  They are helpful when debugging, for example.  What I've suggested has worked well for me before:  make an id out of the title, with modifications if that title is already in use.  If a title is missing, make up an arbitrary ID.

Luhmann used unique indexing expressions, mainly so he could find things again, and refer to them from other zettels.  A hierarchical system like the one he devised helps in keeping related zettels - like child notes - quick to find.  As you say, since we expect to keep relationships in the system, we don't need indexing terms to play that role.

2. Titles are good for quick visual recognition, and as a memory aid.  They can also be the basis for all kinds of later analysis, such as generating clusters, or connecting different thoughts because they have something similar in the titles.  The system can check to see if a title is unique, and modify it or just let you know if it's being duplicated.  I suggested making a title out of the first line of the zettel, if the system sees that there is no title.  Titles wouldn't be used by the system to refer to anything, so one could always change a title later.

3. File names.  I do think that for export, it would be a good idea to use the title in the file name - assuming that the export method generated one file per zettel.  That assumption could be revisited.  For example. you could have all the zettels in a single file, separated by some distinctive mark.  But *if* it were to be one file per zettel, then the system could make sure it didn't duplicated any by modifying the filename to avoid a name collision.  E.g., a duplicate "U.S. Navy in WW2.txt" filename  could become "U.S. Navy in WW2_02.txt".

I'm with you that any and all of the metadata, including id and title, should be optional when the zettel is typed in.  Let the system work it out if the information isn't included.  The only item that can't be changed later is the id.

[andyjim]

Speaking for myself, with my use case, where the system is for thoughts, I want as little clutter and distraction as possible, which is the main reason I’ve never even used markdown. When I’m thinking and writing my thoughts, I don’t want to have to think about anything at all but writing nouns and verbs; not formatting code or anything else.  I don’t know how many of my silly breed are thus afflicted, but I know some are. I’m having to work at accepting that I probably have to learn some markdown, but I won’t be messing with it until after I’m done writing my nouns and verbs.

Likewise when I make a gathering of a cluster of zettels to work with, I just want to see the text ("Just the text, ma'am").  Don’t want to see meta data or any other sort of informational or system stuff. Just the text, please, so I can focus on the meat. I’ll be thinking and writing further notes then as well, so keep the dogs quiet and tell that silly parrot to just shut up.

Ok well, enough drama.  But this strongly felt need of mine is one reason I suggested (in my zettel template file attached to another post) a sub-divided zettel instead of a monolithic zettel. Let the system be able to address each sub-element independently. Bind the elements together by adding one more digit to the zettel’s UID  and let that extra digit differentiate the individual elements. Now, let the system permit displaying only the body element, and now I have my distraction free thinking/writing environment. If all the link stuff is in one sub-zettel then the system need only look at that sub-element and not have to scan everything else to find what it’s looking for. Distraction free environment for the system as well. The links blocks from all the zettels are all the system needs to form the entire zettel web. Neat and clean, hopefully easier on the programmer (speaking as a non-programmer).

If the body (including title) comprises a separate element, then we can easily export only the body (if that’s what we want to do), free of all the system stuff. Or, if we wanted to export some but not all the specialized blocks. We can do whatever we want with ease.

Too, if the title is a sub-block of the body block, then we can view title only, or many titles, stacked up so we can scan them undistracted by everything else in the zettel.  But maybe it’s only my use case that would benefit from such a capability.

If the links block is a separate element, containing only links (using ’links’ broadly) then the system only has to directly address that block, and everything in it is code that the system understands. It could even contain the addresses of the other blocks.

All of which brings me to another reason I’m suggesting this, and you are free to tell me I’m crazy. This is a jealously guarded secret so don’t tell a soul:

If the zettel is modular, then a user can design his own zettels and his own system…

Suppose the user wants a GTD system, specialized for his own use case. Now I realize the zettelkasten system can be used as is for a GTD, a PIM or most anything else. But, a GTD system would probably benefit from specialized templates for GTD. Likewise a PIM would better suit with specialized templates (fields for data, etc). You yourself designed a specialized ‘zettel’ for your URL management system.  If this system has the capability to allow the user to ‘roll his own’ for specialized purposes, then I think we’ve got something pretty special. Heck you or I might want to redesign the zettel for our own use case. It looks already as if we have slightly different preferences in some ways each to suit his own use case.  I’d like to be able to see first lines only, but you may have little or no interest in such a feature.  But if my custom modified zettel template allows the first line to be a separate zet (cute name for a sub-element?), then I can have my wish, and you can have yours. Too, we could combine multiple systems in one: Notes, GTD, PIM, URL manager, project manager, … all in one integrated system.

Many researchers and writers want citations. If there’s a separate block for them, they can be hidden unless wanted (keep the dogs quiet). Or the user can easily view or form a list of all zettels’ citations. Or titles. Or links. Or header info.  With such a system maybe the header block would contain the descriptor for the zettel.  A list of the 'zets', their types, address of each. The system will need all that, and that and making a template for each sub element may be about all it takes.

I know---wild idea. And, I know too that it’s not as simple as just enabling the user to custom build his own zettel. The rest of the system has to accommodate this concept.  But my non-programmers mind naively thinks: how difficult could that be, really? Well, maybe way too difficult, for all I know. So tell me I’m crazy and I’ll return it back under my hat where it belongs, and you don’t have to ever tell anyone, even your mother.

Cheers

[Thomas Passin]

On Saturday, February 8, 2020 at 11:41:38 PM UTC-5, andyjim wrote:

Speaking for myself, with my use case, where the system is for thoughts, I want as little clutter and distraction as possible, which is the main reason I’ve never even used markdown. When I’m thinking and writing my thoughts, I don’t want to have to think about anything at all but writing nouns and verbs; not formatting code or anything else.  I don’t know how many of my silly breed are thus afflicted, but I know some are. I’m having to work at accepting that I probably have to learn some markdown, but I won’t be messing with it until after I’m done writing my nouns and verbs.

That's why I put in that every item would be optional.  You could omit them all, and the system will create values for them.  OTOH, if you care about, say, the title, you could still type one in easily.  So I think my suggestion covers you here,

 

Likewise when I make a gathering of a cluster of zettels to work with, I just want to see the text ("Just the text, ma'am").  Don’t want to see meta data or any other sort of informational or system stuff. Just the text, please, so I can focus on the meat. I’ll be thinking and writing further notes then as well, so keep the dogs quiet and tell that silly parrot to just shut up.

Once the system knows what the various data items are, no problem in just displaying and editing the text.

 

Ok well, enough drama.  But this strongly felt need of mine is one reason I suggested (in my zettel template file attached to another post) a sub-divided zettel instead of a monolithic zettel. Let the system be able to address each sub-element independently. Bind the elements together by adding one more digit to the zettel’s UID  and let that extra digit differentiate the individual elements. Now, let the system permit displaying only the body element, and now I have my distraction free thinking/writing environment. If all the link stuff is in one sub-zettel then the system need only look at that sub-element and not have to scan everything else to find what it’s looking for. Distraction free environment for the system as well. The links blocks from all the zettels are all the system needs to form the entire zettel web. Neat and clean, hopefully easier on the programmer (speaking as a non-programmer).

If you want to type something like a link to another zettel, and expect the system to know it's a link, you are going to have to mark it in some way.  The system won't be able to read your mind about it.  You could mark a link line by line - one way is the method I suggested - or you could collect them all in a block, as you are visualizing here.  But you will still have to delineate that block in some way.  So there will have to be some marking syntax to internalize somehow.  The alternative is to add links after the zettel is in the system, using some kind of data entry boxes.  That's certainly possible, but I would like to be able to type them in if I want to, and to be able to export them in some readable way if export becomes necessary.

I think we're basically compatible on this, even if we still need to get the concepts worked out a little better.

 

If the body (including title) comprises a separate element, then we can easily export only the body (if that’s what we want to do), free of all the system stuff. Or, if we wanted to export some but not all the specialized blocks. We can do whatever we want with ease.

[snip]

All of which brings me to another reason I’m suggesting this, and you are free to tell me I’m crazy. This is a jealously guarded secret so don’t tell a soul:

If the zettel is modular, then a user can design his own zettels and his own system…

Suppose the user wants a GTD system, specialized for his own use case. Now I realize the zettelkasten system can be used as is for a GTD, a PIM or most anything else. But, a GTD system would probably benefit from specialized templates for GTD. Likewise a PIM would better suit with specialized templates (fields for data, etc). You yourself designed a specialized ‘zettel’ for your URL management system.  If this system has the capability to allow the user to ‘roll his own’ for specialized purposes, then I think we’ve got something pretty special. Heck you or I might want to redesign the zettel for our own use case. It looks already as if we have slightly different preferences in some ways each to suit his own use case.  I’d like to be able to see first lines only, but you may have little or no interest in such a feature.  But if my custom modified zettel template allows the first line to be a separate zet (cute name for a sub-element?), then I can have my wish, and you can have yours. Too, we could combine multiple systems in one: Notes, GTD, PIM, URL manager, project manager, … all in one integrated system.

Considering that each of these project types uses data very differently, this might be a tall order.  To the extent that the underlying model uses blocks and connecting links, you could probably generalize.  That's what we are talking about doing with Leo right now, after all.  And that's what databases are all about, too.

But too much complexity at the beginning is likely to sink a project.  Just keep that in mind.

 

Many researchers and writers want citations. If there’s a separate block for them, they can be hidden unless wanted (keep the dogs quiet). Or the user can easily view or form a list of all zettels’ citations. Or titles. Or links. Or header info.  With such a system maybe the header block would contain the descriptor for the zettel.  A list of the 'zets', their types, address of each. The system will need all that, and that and making a template for each sub element may be about all it takes.

Just like links blocks, display of only certain elements is not hard once the data is in the system.  The harder part is to arrive at a user interface that is not obtrusive to use.

In the interest of writing multiple thoughts (to become multiple zettels) in a flow with minimal interference from the system, here's what I  suggest.  Accept just one delimiter to denote the boundary between one zettel and the next.  I happen to like a row of "=" - easy to type and read, and (at least for me), visually it looks like a boundary.

==========================================

The system would split your text into separate zettels, linked together in order, when it processes a new zettel.  I think there is very little chance that one would like to type that kind of line into text for any other reason, and if one did, we could accommodate that in various ways, like starting a line with a space before the row of "======".

I know that this works well, because I have used it before.

[andyjim]

Thanks for being patient with this non-programmer.  And I'm glad I stumbled in here and stumbled upon the right person who has a personal interest in Zettelkasten. Are we more or less caught up now? Have I answered all questions where you wanted my responses?  What's next step? Any other questions we need to be thinking about? Oh, I know of one:

I think for myself I would like the system to generate date-time based UIDs for new zettels (so I don't have to type them in), but to have the option to type in title as UID or default the first line to title per your suggestion. have the option which way to do it.  BUT, what about parsing my archive files?  I will want those zettels dated from origin. They start around 1990 and go up to the present. I would like to be able to call up zettels by date or date range as well as other keys.  Hopefully the system can do that.

Maybe it's as simple as entering my UID manually when I prep a file for the parser, though in that case I would not be using the full YYMMDDHHMMSS format, probably just YYMMDDxx, since date will be the finest granularity available to me. I'll just increment the last two digits after DD for the zettels written on that day.  Another point on that: I won't be consigning the entire content of these files to zettels; just the points I'm interested in. There will be a lot of verbal cruft that I don't need, and this is my opportunity to clean up my mess.  I expect the parser will just keep parsing line by line until it finds another zettel code that I've set?

Anybody know how to recover old MS Word 2003 files where I've lost the password?

OK, one more item: I'm on board with the notion of making zettels short, keeping the thought atomic. I see the value of that, but I won't always be able to do it. I have a goodly number of non-atomic thoughts, even essays, book chapters... But I want them in my ThoughtBase nonetheless. Also, I will be drawing on groups of zettels to write longer pieces, possibly someday a book or two (Luhmann wrote 60 books from his zettelkasten). I realize that at some point you need to take it elsewhere (Scrivener or whatever) to finish it, but I can imagine doing most everything up to rough draft in Zettelkasten.  IOW I feel I need to have no limit on zettel size.

Earlier you suggested starting a new thread. Are we coming to a good point to do that? I lean upon your best judgement; no strong opinion either way.

[Thomas Passin]

On Monday, February 10, 2020 at 9:54:53 PM UTC-5, andyjim wrote:

Anybody know how to recover old MS Word 2003 files where I've lost the password?

Maybe ... There are some solutions out there to be found through an internet query.  A few of them look relatively simple. How practical it will be, even if they work, will depend on how many files you've got.  If you would like to post one example, I'll see what I can do - just attach it to your reply.

Now, about automatically ingesting these old files.  It depends on how they are structured.  If they are just text, and you haven't done anything depending on formatting or tables or other word processing features, then it can be done easily, at least if they are text files.  If they are old Word files, even if not password protected, it remains to be seen (maybe some else reading this will know).  The thing is that converting documents one at a time can be stultifying and time consuming if there are a lot of them.  So I would be looking for a way to automate it.  LibreOffice can read old Word files, I believe, and it can be scripted.  That might be a route.  And there are other possibilities.

OTOH, if you have a lot of password protected files from long ago, you probably haven't looked at them for many years.  So maybe they aren't too important after all!

 

OK, one more item: I'm on board with the notion of making zettels short, keeping the thought atomic. I see the value of that, but I won't always be able to do it. I have a goodly number of non-atomic thoughts, even essays, book chapters... But I want them in my ThoughtBase nonetheless. Also, I will be drawing on groups of zettels to write longer pieces, possibly someday a book or two (Luhmann wrote 60 books from his zettelkasten). I realize that at some point you need to take it elsewhere (Scrivener or whatever) to finish it, but I can imagine doing most everything up to rough draft in Zettelkasten.  IOW I feel I need to have no limit on zettel size

I don't see any technical problem with having long notes.  As long as a paragraph break isn't considered to be a block marker, the number of paragraphs shouldn't matter.

 

Earlier you suggested starting a new thread. Are we coming to a good point to do that? I lean upon your best judgement; no strong opinion either way.

You're probably right.  Let me think on it.

[Steve Litt]

On Sat, 18 Jan 2020 15:36:36 -0800 (PST)
andyjim <andy...@gmail.com> wrote:


> My thought is to arrange all this in external plain text files
> initially, with the outline organization being in Leo, leaving the
> files external

Hi andyjim,

The thread you started long ago moved away from the preceding desire.
Your preceding desire should be very easy to accomplish using the same
method VimOutliner accomplished it: Use executable lines. Somewhere on a
headline, or as a direct child of a headline, have a command to view
the external file, so that if you hotkey the headline, it runs the
command and pulls up the file.

So you could have a hotkey with the command "inkscape myimage.svg",
another one "libreoffice mybook.odt", and another one "leo
my_trip_plan.leo" **.

There are a million ways to do this. The way it's done in VimOutliner
is to have a line with the following format:

[Name] _exe_ command_with_args

The brackets mean the name is optional. If you place the cursor
anywhere on that line and type ",,e" then that command is run, with the
result that a window with the desired document appears.

I don't think there's a facility for comma comma commands in Leo, but
whatever the native hotkey system is will handle it nicely. The
function run by the hotkey is basically the following:

def execute_line:
arr = thisline.split("_exe_", 3)
if len(arr) > 2:
os.system(arr[2])

Don't shoot me if I got the preceding commands wrong: I've been doing
Tcl the past month and have confused my Python. But you know what I
mean: Split it around _exe_ with a maximum of 3 elements, and if it has
3 or more elements, execute the 3rd (and final) element of the split.

When the external file is a Leo file, I'm pretty sure you can copy and
paste into the main file, if you want. But I'm a big fan of having a
"single tree of knowledge" such that I can drill down to any knowledge
I have by just doing executable lines.

[**] VimOutliner has a separate command for .otl files that brings the
external file into the *current instance* of VimOutliner, but I don't
think this is necessary in Leo.

> One reason I'm looking at Leo for this is that I think I'm going to
> have to just start bringing material into an outline system, note by
> note, and evolve the classing and relationships 'as she goes'.

I think the preceding is an excellent plan, although I could make a
case for keeping some of the files separate forever.

[Edward K. Ream]

On Tuesday, February 11, 2020 at 10:55:38 AM UTC-6, stevelitt wrote:

So you could have a hotkey with the command "inkscape myimage.svg",
another one "libreoffice mybook.odt", and another one "leo
my_trip_plan.leo" **.

There are a million ways to do this.

The Leonine way is:

headline: @command command-name @key=whatever

body: The command to be executed

Or, for one-offs, just use Ctrl-B in the body text of any node:

g.execute_shell_commands("inkscape myimage.svg")

Edward

[Thomas Passin]

On Tuesday, February 11, 2020 at 11:55:38 AM UTC-5, stevelitt wrote:

On Sat, 18 Jan 2020 15:36:36 -0800 (PST)
andyjim <andy...@gmail.com> wrote:


> My thought is to arrange all this in external plain text files
> initially, with the outline organization being in Leo, leaving the
> files external

Hi andyjim,

The thread you started long ago moved away from the preceding desire.
Your preceding desire should be very easy to accomplish using the same
method VimOutliner accomplished it: Use executable lines. Somewhere on a
headline, or as a direct child of a headline, have a command to view
the external file, so that if you hotkey the headline, it runs the
command and pulls up the file.

@stevelitt, I agree that there are many ways a system might be implemented.  One of the things we (or I, anyway) are keeping in mind is a strong desire to be able to extract the data from the system in case it has to be used in some other system (or even manually, in the worst case).  So at this point, we're trying to get clear on the concept of operations (use the use cases, if you like that terminology better), and then see how we can fit that into Leo.  Bear in mind that we're thinking about a substantial body of work here - potentially years or decades of research and thinking.   The primary objectives are to be able to preserve that work, to be able to add to it with the least amount of friction, and to use have the system help us use it in a way that promotes creativity and productivity.

An additional constraint is that both @andyjim and myself want to be able to get these notes and their meta data into the system with the least hindrance possible - a stream of plain typing being the most desirable.

After that, I expect we'll be getting into user interfaces, and what compromises might be forced on us - let's hope they will be minimal!  That's where suggestions like your could fit in well.

[Thomas Passin]

On Wednesday, February 12, 2020 at 7:56:31 AM UTC-5, Edward K. Ream wrote:

On Tuesday, February 11, 2020 at 10:55:38 AM UTC-6, stevelitt wrote:

So you could have a hotkey with the command "inkscape myimage.svg",
another one "libreoffice mybook.odt", and another one "leo
my_trip_plan.leo" **.

There are a million ways to do this.

The Leonine way is:

headline: @command command-name @key=whatever

@ekr, are the identifiers for Leo nodes globally unique, or only within an outline?  And how do you get a node's identifier programatically?

[Edward K. Ream]

On Wed, Feb 12, 2020 at 3:24 PM Thomas Passin <tbp1...@gmail.com> wrote:

> @ekr, are the identifiers for Leo nodes globally unique, or only within an outline? 

gnx's (global node indices) are supposed to be truly unique. They will be unique unless you are doing something very odd, say by running multiple copies of the Leo bridge simultaneously.

> And how do you get a node's identifier programatically?

p.gnx or v.gnx.

Edward

[Steve Litt]

On Wed, 12 Feb 2020 13:21:10 -0800 (PST)
Thomas Passin <tbp1...@gmail.com> wrote:

> On Tuesday, February 11, 2020 at 11:55:38 AM UTC-5, stevelitt wrote:
> >
> > On Sat, 18 Jan 2020 15:36:36 -0800 (PST)
> > andyjim <andy...@gmail.com <javascript:>> wrote:
> >
> >
> > > My thought is to arrange all this in external plain text files
> > > initially, with the outline organization being in Leo, leaving
> > > the files external
> >
> > Hi andyjim,
> >
> > The thread you started long ago moved away from the preceding
> > desire. Your preceding desire should be very easy to accomplish
> > using the same method VimOutliner accomplished it: Use executable
> > lines. Somewhere on a headline, or as a direct child of a headline,
> > have a command to view the external file, so that if you hotkey the
> > headline, it runs the command and pulls up the file.
> >
>
> @stevelitt, I agree that there are many ways a system might be
> implemented. One of the things we (or I, anyway) are keeping in mind
> is a strong desire to be able to extract the data from the system in
> case it has to be used in some other system (or even manually, in the
> worst case).

From the preceding, I assume all the information is not within the same
directory tree, so you can't just roll it into a tarball. And if it
isn't already in Leo, it sounds like you don't yet have an inventory of
all this information. If this is indeed the situation, you have a
challenge: A very interesting one. Please feel free to contact me
offlist for the parts of the situation not involving Leo: If the
situation is what I think it is, it's very interesting and common
situation whose solution isn't trivial.

> So at this point, we're trying to get clear on the
> concept of operations (use the use cases, if you like that
> terminology better), and then see how we can fit that into Leo. Bear
> in mind that we're thinking about a substantial body of work here -
> potentially years or decades of research and thinking. The primary
> objectives are to be able to preserve that work,

Sounds to me like you need to identify each file to preserve the work.
Perhaps you can then put a hard link, of the same name but different
directory, to each file within a directory tree meant only for this body
of work. Then you can back it up with tar.

> to be able to add to
> it with the least amount of friction, and to use have the system help
> us use it in a way that promotes creativity and productivity.

Sounds like Leo to me. Probably write a small, possibly recursive
program, to turn them all into a .leo file, and then put the headlines
from that .leo file in the appropriate parts of your master Leo file.

>
> An additional constraint is that both @andyjim and myself want to be
> able to get these notes and their meta data into the system with the
> least hindrance possible - a stream of plain typing being the most
> desirable.

I'd use a little program, and if doesn't give you the exact desired
format, edit it with Vim until it does.

>
> After that, I expect we'll be getting into user interfaces, and what
> compromises might be forced on us - let's hope they will be minimal!

> That's where your ideas could fit in.
>

Sounds good!

[Thomas Passin]

Thanks.  And - maybe this is weird - would there be any problem adding properties to a node?  If course, the Leo serializer wouldn't know about them, but a custom serializer could.  Extra properties on a node wouldn't interfere with anything else, would they?  I'm speculating about keeping the various meta data items for a zettel (note) as properties on the note's node itself.

[Thomas Passin]

On Monday, February 10, 2020 at 9:54:53 PM UTC-5, andyjim wrote:

Maybe it's as simple as entering my UID manually when I prep a file for the parser, though in that case I would not be using the full YYMMDDHHMMSS format, probably just YYMMDDxx, since date will be the finest granularity available to me.

Using Leo, and making each note be a separate node, we can get just that kind of ID for free.  Each Leo node get created with a unique ID that includes the date/time, and is fairly easy to read (and you could write one by hand if you needed to)..

[andyjim]

A node for each zettel? Thousands of them?

[Thomas Passin]

On Thursday, February 13, 2020 at 10:58:01 PM UTC-5, andyjim wrote:

A node for each zettel? Thousands of them?

Well, yes, that's what I've been been envisioning.  Having thousands of them - whether they are represented as Leo nodes or some other way  - will require us to be smart at coming up with ways to work with them, and to find interesting related ones as well as the ones we've been working on recently.  That would be true for the old paper system, too.  With a computerized system, at least searches will be much faster.

My experience with my bookmark management system makes me think that the zettels should be collected under headings that relate to the reason the zettel was written in the first place.  The headings can be informal and changeable, and I found there is very little cognitive overhead in "filing" under one or another heading.  In Leo, the headings could be implemented by creating organizer nodes.  This does not commit you to a particular view of the world, but only gives you some mnemonic help in finding related thoughts.

Leo itself has something like 300 or 400 files of code, most of them contained in one Leo file.  Each code file would be equivalent to maybe dozens if not hundreds of individual "notes", if you wanted to think about them that way.  That might in total be several tens of thousands - in the rough ballpark of the number of zettels we are imagining . It's not too unwieldy to work with them.

Come to think of it, my bookmark management system, which I've mentioned before, has some 25,000 web pages, with more than a hundred top-level headings, not including all the subheadings.  The cross-links are all between headings, though, not between individual pages.  So the size and complexity of the bookmark collection is also in the ballpark of what we are looking at for the zettelkasten.

What the Leo code doesn't have is the extensive system of cross links that we expect to have in our zettelkasten.  That will be one of the key things we have to work out - not how to accomplish linking technically, but how to make it easy to work with. Just to make this seem a little more real, one thing you can do with Leo right now, without adding anything new, is this:  you can "mark" any number of nodes, and then activate a single Leo command that makes clones of all of them and puts them under a single organizing node. So you could do a search, and then scan through the search results, mark the ones you want, and automatically collect clones of all of them in one place. I see this capability as a way to collect various thoughts into a project to work on.

In addition to finding the notes to work on together, another challenging user interface issue will be to display a number of them at once, and in a readable (and maybe editable) way.  That's never been easy on a computer. Leo does have the ability to open multiple editors, but the way that works won't, I think, be quite right for what we need to do.  I've read that with the old paper system, people used to physically remove a number of zettels from their filing case (the kasten) and spread them out on a desk. When they were done, they'd have to get them all (with any new ones) back in the right place or they would never be able to find them again.  We can do better than that, anyway.

One approach that I think will be useful in finding zettels related to the ones you are thinking about is sometimes called a Concise Bounded Description.  Basically, given a node, this collects all references of a chosen depth of links in one subset.  See

https://www.w3.org/Submission/CBD/

I think this is likely to lead to the other zettels one is most interested in. I'm fairly sure that a CBD won't be hard to implement.  I've done it before.   One way to display them would be be with a mind map - I'm very fond of mind maps, myself.  Making a mind map that can interact with the rest of our zettelkasten system would be challenging.  So a read-only mind map would be what we could expect for quite a while.

Well, there I go getting into details of the user interface when we are still working on the requirements at a higher level.  Fun and useful, but we shouldn't get carried away too soon!

[Edward K. Ream]

On Thu, Feb 13, 2020 at 6:28 PM Thomas Passin <tbp1...@gmail.com> wrote:

And - maybe this is weird - would there be any problem adding properties to a node? 

Not weird at all. Custom properties are called uA's (user attributes). See this page.

Edward

[Edward K. Ream]

On Thu, Feb 13, 2020 at 9:58 PM andyjim <andy...@gmail.com> wrote:

A node for each zettel? Thousands of them?

Yes. This is perfectly possible. LeoPyRef.leo contains thousands of nodes, each containing source code.

Look, I can't stress this enough. Leo is the ultimate filing cabinet. "Boxes" can contain other boxes as well as notes. Really, you have to start by getting how powerful clones are.

Leo's unl's already likely suffice for zettel links. Nodes already have unique id's.  Etc. etc. etc.

Edward

[Edward K. Ream]

On Thu, Feb 13, 2020 at 7:08 PM Thomas Passin <tbp1...@gmail.com> wrote:

> Using Leo, and making each note be a separate node, we can get just that kind of ID for free. 

Not "kinda" for free. It's completely free for users. It's one of Leo's essential features.

This didn't happen for free behind the scenes :-) A lot of tricky work is involved. Don't even think of duplicating that work. It might take you years.

Edward

[Thomas Passin]

On Friday, February 14, 2020 at 7:50:56 AM UTC-5, Edward K. Ream wrote:

On Thu, Feb 13, 2020 at 7:08 PM Thomas Passin <tbp1...@gmail.com> wrote:

> Using Leo, and making each note be a separate node, we can get just that kind of ID for free. 

Not "kinda" for free. It's completely free for users. It's one of Leo's essential features.

I meant "that sort of ID" - timestamped - not "kind of for free".  Sorry to be unclear!

 

This didn't happen for free behind the scenes :-) A lot of tricky work is involved. Don't even think of duplicating that work. It might take you years.

Don't I know it!  Way better to make use of it than to duplicate it.

[Thomas Passin]

Ha!  After seeing references to uAs over and over, I finally learn what they are.

[andyjim]

Well, this gives me a lot to think about. I've been more or less assuming the idea of one zettel/one node as being a limiting one, but perhaps it's the opposite, given all the capabilities of a node, hardly any of which I am familiar with.  And that's what I need to do: dig in and get familiar with the organizational/accessing capabilities of Leo.

@EKR says Leo is the ultimate filing cabinet and I must dig into that instead of sitting here on the sidelines waiting for something to happen. 

I expect there are one or more tutorials somewhere dealing particularly with those aspects while leaving aside the programmer's aspects. I'll look around but if someone can point me ...

One thing I wish I understood better is the acyclic graph model, how that plays out in Leo and what it accomplishes for us in organization/linking.

And Thomas, perhaps I need to read your papers on semantic processing (haven't done so yet), as it seems that's more or less what the zettelkasten model offers (maybe the Leo model, in fact), and it appears you are bringing the body of your work to bear on this project.  Which probably makes you nearly the perfect person to be working on this.

[andyjim]

> On Tuesday, February 11, 2020 at 11:55:38 AM UTC-5, stevelitt wrote:

> > The thread you started long ago moved away from the preceding
> > desire. Your preceding desire should be very easy to accomplish
> > using the same method VimOutliner accomplished it: Use executable
> > lines. Somewhere on a headline, or as a direct child of a headline,
> > have a command to view the external file, so that if you hotkey the
> > headline, it runs the command and pulls up the file.

I've actually gotten some text files into Leo, whole folders full (365 per folder), by multi-select, drag/drop. Each forms a node, which I think is probably going to turn out best.

From the preceding, I assume all the information is not within the same
directory tree, so you can't just roll it into a tarball. And if it
isn't already in Leo, it sounds like you don't yet have an inventory of
all this information. If this is indeed the situation, you have a
challenge: A very interesting one. Please feel free to contact me
offlist for the parts of the situation not involving Leo: If the
situation is what I think it is, it's very interesting and common
situation whose solution isn't trivial.

I PM'd you Steve, but it does not seem to go through. I'd be happy to be in touch with you for your suggestions. 

andyjim47-at-gmail-dot-com

 

[Thomas Passin]

On Monday, February 3, 2020 at 9:28:32 PM UTC-5, Thomas Passin wrote:

I have written an initial set of user requirements (attached), and I would appreciate your thoughts on them.  These are very high level requirements, and they don't include any actual user interface ideas.  Instead, they are things that I think any UI would have to honor.  I have tried to abstract from written work on paper zettelkasten systems.  I also tried out several (free) zettel-programs for Windows, none of which worked well at all for me.

One key point for me is a need to prevent lock-in to this - or any - particular system by either keeping the zettelkasten in the form of text note files, or having the ability to export a complete set of such files.  In the worst case, I picture to myself, one could print out the text notes and actually use them as is in a physical zettelkasten.  I think this is so important that I made it the first requirement.

After minor revisions to these basic user requirements, I have worked on an assessment of how much of them we can achieve with Leo's current capabilities, or at least slight enhanced capabilities.  It seems that Leo as is can meet most of them.  So that's encouraging.  Actually, I hadn't thought  that Leo would come this close to meeting them - turns out that there are several plugins I'd never used will that help a lot.

I have attached the requirements with commentary to this post.  The assessments follow each requirement, with the assessment having an italicized heading.  Let me know what you think!  Just open the file with your browser.  BTW, I wrote the assessments in a separate tree in Leo, and moved them as clones into the main requirements tree so that they can be shown together.

Aside to @ekr - this file was generated by my VR3 alpha in RsT mode.

[Thomas Passin]

On Friday, February 14, 2020 at 12:27:31 PM UTC-5, andyjim wrote:

One thing I wish I understood better is the acyclic graph model, how that plays out in Leo and what it accomplishes for us in organization/linking.

It's not too hard to grasp the basics, @andyjim.  A graph is a set of nodes connected by edges.  Sometimes the edges connect back to a starting node, in a kind of circle.  The circular set of nodes and connections is called a "cycle".  A tree has nodes that don't connect back - they only grow "downwards", like displays of file system directories, or a collection of Leo nodes.  With no cycles, it's called "acyclic".  It's easier to work with acyclic graphs because you don't have to take special care to make sure you don't keep going around a cycle over and over.

The little joke here is that you may have a (acyclic) tree of nodes in Leo, but once we get through overlaying our links and backlinks, who knows how many cycles might be formed when you follow all the links.

 

[Thomas Passin]

On Friday, February 14, 2020 at 12:27:31 PM UTC-5, andyjim wrote:

And Thomas, perhaps I need to read your papers on semantic processing (haven't done so yet), as it seems that's more or less what the zettelkasten model offers (maybe the Leo model, in fact), and it appears you are bringing the body of your work to bear on this project.  Which probably makes you nearly the perfect person to be working on this.

I actually have three semantic-related papers on my web site, though the one on bookmarks is much the closest to what we are talking about here -

http://www.tompassin.net/

[Edward K. Ream]

On Fri, Feb 14, 2020 at 10:08 PM Thomas Passin <tbp1...@gmail.com> wrote:

> I have attached the requirements with commentary to this post. 

I'll take a look.

Edward

[Edward K. Ream]

On Fri, Feb 14, 2020 at 11:27 AM andyjim <andy...@gmail.com> wrote:

> One thing I wish I understood better is the acyclic graph model, how that plays out in Leo and what it accomplishes for us in organization/linking.

In an acyclic graph, a node may have multiple parents.

In Leo, all such nodes are clones. They have the little red circular arrow in their icon box.

Therefore, clones are children of multiple nodes (their parents).

Any Leo node (cloned or not) can be thought of (used as) as a drawer. The contents of the drawer are all the drawer's children. The children (contents) of the drawer can be clones, or plain nodes.

Therefore, a single outline may contain arbitrarily many views of the same data.

That's all. Please play with it. It's a powerful model.

Edward