It appears you are casting your net beyond Leo a bit too, in case there is something out there that does almost all of what we want. Brain? MindForge? Let me know what you find. I was unable to install MindForge on my Mac even though there are instructions to build it. Didn't work.
@Thomas I found the command that allows you to break zettels out of an imported file. In the body you select the lines you want, hit shift-Command-D and it splits your selection out into a new node (under the parent heading for the imported file) with the first line as the new heading.So, import file, select lines, make zettels. Can discard unwanted parts in same process. So that's a start on one way to bring a file in and break it up into zettel nodes.
I've been spending some time with my bookmark manager again,
Cool! That's one thing about Leo - it can do so many things, but it can be hard to discover them. Maybe a zettelkasten?
On Thursday, February 20, 2020 at 9:37:43 AM UTC-5, andyjim wrote:On Wednesday, February 19, 2020 at 11:35:05 PM UTC-5, Thomas Passin wrote:3. I *think* that by using Firefox, you can use the manager without running a web server. Most other browsers won't let you do it (they all worked without a server back when I developed it, in the 2003-2004 time frame, but no longer). So if you don't want to use Firefox, we'll have to set you up with a web server on your computer.
Bingo! I had a brainstorm. Now I know how we can use Leo to write text zettels, have them organized in a tree of files on disk - for almost no effort - and then use them in my bookmark manager. We can have - right now, today - enough of zettelkasten functionality to start actually trying it out, so we can learn how best to author zettels and organize them, and have the bookmark manager link them up and provide the GUI. The manager has some limitations, but we can either add functionality to it, or write code for Leo to do some of the additional things we want - as we use the system and find out what we really need. And the zettels are automatically saved as text files, as we said we want.
I look forward to getting into this. So on the Leo side I need to start setting up a heading structure. I also need to learn about Leo tags. And start learning some RsT and write some zettels at least for testing.It's looking interesting.
I will attach my zettelkasten outline in another post as a guide to creating a structure that works on its own and also with the bookmarks manager.
... I also need to learn about Leo tags. And start learning some RsT and write some zettels at least for testing.
I have developed two commands that insert the node id and current timestamp into the zettel. I'm already using them in my little experimental zettelkasten. The results look like this::id: TomP.20200221221759.1
:timestamp: 02/22/2020 08:25:29Since the creation time is included in the node id, we are free to use the timestamp to record the modification time if that's what we want.I should be able to have a command to navigate to a node id soon. The examples of links I gave in my earlier post work, but they won't keep working if the structure of the outline gets changed. That's not desirable. Using the node id, the details of the outline structure won't matter.
I now have a command with keyboard shortcut that works like this:
So I say we're ready to rock and roll!
With the command to add a backlink, I would say that we have a working zettelkasten system that has essentially all the features of the original paper system, with better searching and reorganizing abilities.
Attached is the Leo file for my little zettelkasten. It includes @settings nodes for the commands and keyboard shortcuts for inserting the node id and timestamp.
The structure uses @path nodes to create directories. When you run the rst3 command on the tree, it will create a directory tree in the file system that matches the structure of the Leo outline. The bookmark manager uses this directory structure to build its internal data structures linking different parts of the outline together. This procedure also gives you the ability to export the files if you should ever want to move to some other system.
So the @path directives are only needed if you plan to make use of the bookmark manager (when I get it ready for use). Otherwise, you would still want those nodes, but they wouldn't have to have the @path directives. Ultimately my plan is to use them with a Leo plugin to do the kind of linking I currently do in the bookmark manager. So it would be wise to include the organizing nodes, and to give them meaningful titles. And even without the behind-the-scenes data structures, they will still be useful for searching in the Nav tab.The @rst directives are only needed for using the rst3 command. But I think that's worthwhile.Oh, and here is a command to open Explorer (Windows only) at the directory of the path of the current outline.
Bingo! I had a brainstorm. Now I know how we can use Leo to write text zettels, have them organized in a tree of files on disk - for almost no effort - and then use them in my bookmark manager. We can have - right now, today - enough of zettelkasten functionality to start actually trying it out, so we can learn how best to author zettels and organize them, and have the bookmark manager link them up and provide the GUI. The manager has some limitations, but we can either add functionality to it, or write code for Leo to do some of the additional things we want - as we use the system and find out what we really need. And the zettels are automatically saved as text files, as we said we want.
On Saturday, February 22, 2020 at 9:47:41 PM UTC-6, Thomas Passin wrote:Attached is the Leo file for my little zettelkasten. It includes @settings nodes for the commands and keyboard shortcuts for inserting the node id and timestamp.
Is TM4J your bookmark manager? Is there a web link?
The .leo file has this broken link for .. _Zettels: file:///D:/Tom/devel/zettelkasten/zettel1/zettels.txt
Excellent. Working code (or in this case, a working outline), is worth gazillions of words and requirements :-) Much easier to understand.
I decided to have the link meta-lines have optional labels, because they help you know which links goes where. In the older paper-based system, identifiers generally looked like [...]
Using an optional label seems better.
Granted, you can't easily get a listing of all the tags - until we have a zettelkasten plugin that can create one - but you could maintain a zettel that only contains the tag names. It would be almost as good.
I am unsure, though, whether to allow more than one link per line. One link per line would be easier to write the code for, yet more than one would be easier to author and would reduce the visual clutter.
Is TM4J your bookmark manager? Is there a web link?Yes, that's right. There's only a link to an obsolete version that I wouldn't recommend. I have to do some work on it to package it up so other people can use it. For example, it uses batch files that use absolute paths, and the python parts of the codes are for v2.1 or maybe earlier. It's a unix-like mix of batch files in a processing pipeline that uses batch, python, and xslt templates playing together. We didn't have JSON back when I developed it (2003 - 2004), so there is an xslt template that actually is a code generator that outputs javascript code to build the data structures in the browser. Awkward, but in return I didn't have to invent a syntax and an in-browser parser for it. I'm sure it would have been easier to debug the code generator than to debug a parser.I should work up the changes and packaging .. but not until I finish VR3!
On Saturday, February 22, 2020 at 11:05:32 PM UTC-5, Thomas Passin wrote:Granted, you can't easily get a listing of all the tags - until we have a zettelkasten plugin that can create one - but you could maintain a zettel that only contains the tag names. It would be almost as good.We do need some sort of indexing or search method list for tags and other handles. I'm still wondering exactly how Luhmann's indexing played out. With 90k zettels it must have been efficient and effective indeed, for him to use the system so productively.
Seems like there's a whole layer (maybe more than one layer) of his system that we don't know enough about. It seems like we might need to innovate something here.
I am unsure, though, whether to allow more than one link per line. One link per line would be easier to write the code for, yet more than one would be easier to author and would reduce the visual clutter.Personally I very much favor one link per line.
One of the types of links I'm very interested in is what I've called 'pointers', which is a poor term for what I mean. In addition to links to related zettels the notion of questions or germs of ideas for further thought is, I think, exceedingly creativity inducing. The example in the format we saw I-forget-where appealed to me. The ideas/questions for further work followed after the body text (because the ideas were stimulated by the content of the text) and they would automatically create new zettels, which in turn could be indexed somehow so that, in a spare moment we can be stimulated by 'ideas to pursue'. The term 'pointers' came to mind meaning 'this points to another path to be investigated', but I'm sure there's a better term. In other uses of the system (besides notes), there could be other uses for such links; further work needing done on this part of a project, memos/comments...
I'm still wondering exactly how Luhmann's indexing played out.
With 90k zettels it must have been efficient and effective indeed, for him to use the system so productively.
Seems like there's a whole layer (maybe more than one layer) of his system that we don't know enough about. It seems like we might need to innovate something here.
Note: Luhmann was the inventer of the zettelkasten.
All right; I've not seen the term "zettelkasten" applied to systems before Luhmann's got publicised.
I've been under the impression that his particular way of indexing and linking is what characterizes the term.
And even if I tried to do things exactly as Luhmann seems to have done them, my own note collection would turn out to be very different because - I'm sure - I conceptualize and link things differently from the way he did.
In a sense, Luhmann's zettelkasten was nearly the same as the World Wide Web. He had "resources" - his cards, and "links" - his index strings. He also used backlinks, which can be added to a web page but it's not so easy to know how it could be done automatically, since you wouldn't want to add the URL of just any page that had a hyperlink to your target.
In this case, though, I'm interested in having a system that doesn't need to use someone else's web server. I wouldn't mind using my own server on my own machine, but if it isn't necessary, so much the better.
Yes, for some reasons there is a cargo-cult growing around Luhmann and his knowledge-system.Which is kinda strange, as it's really not that special and we today have many better systems in use.
I must frankly admit that the only reason I am barking up the zettelkasten tree is that I have failed to run across a better system
though of course not a replica of Luhmann's.
you could save us quite a lot of wasted effort reinventing the wheel when the wheel apparently is not that good to begin with.
Am Mittwoch, 26. Februar 2020 23:50:11 UTC+1 schrieb andyjim:
But in general you are not wrong here. Leo Editor can be used that way, even though it's not be the best for this. But it's not the worst either. It depends on how you polish it and yourself. Using Leo in a way to copy Luhmanns Zettelkasten could be done with 2-3 Simple functions. All you need is something to get the reference of node, and something to got from a link in text to the referenced node. First one is quite simple, just add an entry to the context-menu to get the leo-internal id. Second one could be achived by reusing the existing Hyperlink-Click-function and add support for links with leo:// as protocol. Then the rest is up to you to use it and fill your box.
But in general you are not wrong here. Leo Editor can be used that way, even though it's not be the best for this. But it's not the worst either. It depends on how you polish it and yourself. Using Leo in a way to copy Luhmanns Zettelkasten could be done with 2-3 Simple functions. All you need is something to get the reference of node, and something to got from a link in text to the referenced node. First one is quite simple, just add an entry to the context-menu to get the leo-internal id. Second one could be achived by reusing the existing Hyperlink-Click-function and add support for links with leo:// as protocol. Then the rest is up to you to use it and fill your box.Just so. That's what I have worked out in some of the posts on this thread; a small example, with working code for the three functions, is attached to my Feb 25 post on the thread "Comments re the ZettelKasten work". The idea is to have something as minimal and non-obtrusive as possible, yet still be useful.
any workflow must be forged by the user themself over a long time.
Am Donnerstag, 27. Februar 2020 15:46:04 UTC+1 schrieb Thomas Passin:But in general you are not wrong here. Leo Editor can be used that way, even though it's not be the best for this. But it's not the worst either. It depends on how you polish it and yourself. Using Leo in a way to copy Luhmanns Zettelkasten could be done with 2-3 Simple functions. All you need is something to get the reference of node, and something to got from a link in text to the referenced node. First one is quite simple, just add an entry to the context-menu to get the leo-internal id. Second one could be achived by reusing the existing Hyperlink-Click-function and add support for links with leo:// as protocol. Then the rest is up to you to use it and fill your box.Just so. That's what I have worked out in some of the posts on this thread; a small example, with working code for the three functions, is attached to my Feb 25 post on the thread "Comments re the ZettelKasten work". The idea is to have something as minimal and non-obtrusive as possible, yet still be useful.Yes, that's also a way to do it. But I was talking more about a way to insert links in text, and let the choose. So you can have as many links in a node as you want.
After all that's some differences in Luhmanns system. But I guess this is not something that can be done in a @command or plugin.But you could build a search-interface for listing multiple links in a node and choosing a target.
But funny that we both came up with the same colon-based-syntax for embedding metadata in nodes :)BTW Using "created" instead of "timestamp" would be more self-documentating.
That's up in the air for me. Should it represent the creation time or the last-modified time? @AndyJim sounded like he'd like to use a last-modified time, because he likes to see what he was working on at a certain period. I don't want to add yet another piece of metadata if it's not needed. It would be simple to modify the id insertion command to also insert a time the command was run, so it's doable if people think it would be important. Yet the Leo id does actually include a timestamp for the creation time. It's just not formatted to be as readable. So by inserting the id, we automatically have it anyway.
I'd like to settle on one specific name for that timestamp, though, and finalize it soon before I have too many nodes the other way.
I think the capabilities of the Nav tab will go a long way.
BTW Using "created" instead of "timestamp" would be more self-documentating.
That's up in the air for me. Should it represent the creation time or the last-modified time?
I don't want to add yet another piece of metadata if it's not needed.
Yet the Leo id does actually include a timestamp for the creation time.
I'd like to settle on one specific name for that timestamp, though, and finalize it soon before I have too many nodes the other way.
Another ugly and inconvenient question: Are you contemplating a command to automate starting a new zettel (is it ok to use that term for the time being? I gather you plan to find a new term.)? Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing.
I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel,
Another ugly and inconvenient question: Are you contemplating a command to automate starting a new zettel (is it ok to use that term for the time being? I gather you plan to find a new term.)? Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing. I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel, that I might end up not using the system. Currently all I do to start a new thought is skip a line and write. I never have to shift attention to accomplishing a mechanical process before I can start writing the new thought. For my very peculiar (and inconvenient) profile of creative thought process I need it to be very nearly that simple, quick and non-distracting.
. Personally, though American, I have gotten used to the European date format: YYMMDD and have come to prefer it. I've used it in filenames as well as internally in files for about five years now (actually I hyphenate it: YY-MM-DD).
Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing. I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel, that I might end up not using the system. Currently all I do to start a new thought is skip a line and write.
On Thursday, February 27, 2020 at 10:51:42 PM UTC-5, andyjim wrote:Sorry to bring it up again, but one of the key things for me is to be able to launch a new zettel in an instant, without required steps before I can start writing. I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel, that I might end up not using the system. Currently all I do to start a new thought is skip a line and write.
Am Freitag, 28. Februar 2020 02:11:20 UTC+1 schrieb Thomas Passin:BTW Using "created" instead of "timestamp" would be more self-documentating.That's up in the air for me. Should it represent the creation time or the last-modified time?Both have value, so add both.I don't want to add yet another piece of metadata if it's not needed.It's always better to collect more than neccessary than to some day miss what's needed. Storage is cheap.
Yet the Leo id does actually include a timestamp for the creation time.It's not expliciet, nor portable. You must be aware of it when you decide to change the ID or software some day.
And this is something which can be easily move out of sight. Ok, that's my habits as a devloper shining.Non-devs probably see it different. But general experience with those things is that they should be clear.I'd like to settle on one specific name for that timestamp, though, and finalize it soon before I have too many nodes the other way.Strictly spoken, the name alone is not much of a problem. One can always write a script for mass-changing this. that is the advantage of structured data.What it can't do is adding missing data. But of course I only speak from perspektive of a developer, so take it with a grain.
It's not about storage, it's about reducing visual clutter in the text.
After all, how likely is it that some other system could used the exact format of the zettels with no change at all?
I revised the command to insert an ID, so that it also inserts the creating date. Here's the new script:
Something you may be interessted for this:
new = c.insertChild()
new.b = f'{id_label}{time_string}'
I'm not sure about about focus on the title in this case, as I removed this. But this should simplify your code and process.It creates a child-node, gives it focus and sets the body-text.
I have a function bind to a key doing that and can confirm, it's very useful to have a new entry generated and focused instantly.I also let it search the proper node in the my prefered leo-file, so it will always created at the same location.I am suspicious that if I have to type in three or four headings, decide upon titles, etc, in order to create a new zettel,Leo has a function to replace text as you type ( http://leoeditor.com/abbreviations.html ), which you could use to create a new entry from template in an empty node.
But what do you mean with title? Leo does not force you to use a title, but for something meaningful you can't automate this, or do you?
Here's what I've been doing, and I find it very unobtrusive. I create a new node where I want it, using the usual <CTRL>-I. Of course, I type in the node's name as usual. Then <ALT>-F8, <ALT>-F7. I hardly notice I'm doing it. It would be easy to combine all three of these commands in a single keystroke, but so far I haven't felt the need.
In Thomas Passin's prototype, which I downloaded, 1st he types a title heading, 2nd a @rst subheading, with title (for Sphinx, which is fine), 3rd a @path heading, with title, 4th a @rst subheading, again with title, and that 4th node is our zettel. Four new nodes, four titles before I start writing. At least that is how I understand it (Thomas correct me). For me that is a lot of overhead and distraction before I can start typing. I don't even want to decide upon a title, because I may not know yet what the best title should be. I just want to hit a hot key and start writing/thinking. Title can come after I've completed the thought.
Also realized I don't have to title it until I'm darn good and ready. And I don't have to ID it and time stamp it before writing either. I can do those later as well.
All of that is a great help, yet my optimum situation would still be: no matter where I am in my system, when a new thought strikes, I just hit a hot key and start typing. I don't have to locate and go to the outline where I want the new zettel, position the focus and the cursor where I want the new zettel.
Probably I don't even know yet where I will want it, but at any rate I don't want to think about any of that. Just hit a hot key and type. Take care of all the overhead later, after I've completed the thought.
With The Archive zettelkasten software, for example, you hit command-N and start typing. That simple. In Mr. Luhmann's case, he pulls a new blank slip from his supply, directly to hand I presume, and starts writing. Does the overhead later.
And people thought this pure genius! Maybe it is.I'm not easy to get along with, am I? And your proper response to me, I would think, will be, "Son, if you want things exactly your way like that, learn python and Leo yourself and learn how to make stuff like that happen!"
From my reading, he immediately numbered it. Then he added links to other likely zettels. And then he got into the writing. He didn't write these slips quickly, but only after mulling over temporary notes he had taken previously. Maybe temporary notes are really what you have in mind here. My own notion for that is to have a top-level node, maybe outside the zettelkasten top-level node but in the same leo file. These temporary notes would all go there.
We could even have the hot-key put the new node into the temporary notes section, if that's what you want. From a programming point of view, there would have to be a node with a fixed name, like "temporary notes". Otherwise the command behind the hot key wouldn't know where to put the new node. If you don't want that, it would just create the new node right where you are in the ZK, and you could move it yourself. We already just about have that, with <CTRL>-I.
No, not necessarily. This kind of back-and-forth is needed to home in on how the thing should work. Well, there's going to be a limit to how much time someone is willing to spend on a feature that you want one way but they don't think it should work that way. As long as we are figuring that out together, to come up with features that could be fairly general, it's all good.
[snip]
On Saturday, February 29, 2020 at 12:28:27 AM UTC-5, Thomas Passin wrote:I think that's the solution for my use case. If, for example, as in The Archive, Command-N (no matter where I am at the moment) creates a new zettel, in the 'temporary notes' node, plants the id, and the 'created' timestamp, and shifts focus to the body, then I have a distraction-free way to immediately capture a new thought bubble. This will cleanly initiate the process of thought capture. I might want a 'back button' to take me back where I was before this event, but that's another matter for another day.
Paste the code above into this new node. The new node has be a child of an @settings node in either your MyLeoSettings.leo file or your ZK leo file, so move it as needed. Then reload the settings. The hot-key will be ALT-F8.
This one is easy to adjust. You would put another setting into MyLeoSettings.py with the time format you want. If you like, myself or someone could write down the string format for your particular format. The name of the setting isbody-time-format-string
On Saturday, February 29, 2020 at 11:30:58 AM UTC-5, Thomas Passin wrote:Paste the code above into this new node. The new node has be a child of an @settings node in either your MyLeoSettings.leo file or your ZK leo file, so move it as needed. Then reload the settings. The hot-key will be ALT-F8.Ok, added it to my current Leo zk file. What it does now:does not create new nodeinserts id line in the body of the selected nodedoes not insert timestampdoes not shift focus to the body
If I hit it again, repeats the id line under the previous one, same id numberAdded it also to myLeoSettings file; same thingRemoved it from the Leo zk file, leaving it in the myLeoSettings file; same thing.Then realized I didn't know what 'reload settings' entails. Did Settings>Reload Settings>Reload-Settings, also Reload-All-Settings.Same thing.
Finally I quit Leo and restarted. Now it does not respond to Alt-F8 at all. Still responds correctly to Alt-F7. Also, for some reason it dropped all tabs except the one I had open when I quite Leo. Before it has reloaded all tabs I had when I shut down.
I don't have a mac, but I installed the commands on a linux version -- I'm running one in a virtual machine. It doesn't work there, either. This is a shock to me - everything in the code should work no matter what the OS. I'll see if I can track down what's going on.
On Saturday, February 29, 2020 at 11:02:07 PM UTC-5, Thomas Passin wrote:I don't have a mac, but I installed the commands on a linux version -- I'm running one in a virtual machine. It doesn't work there, either. This is a shock to me - everything in the code should work no matter what the OS. I'll see if I can track down what's going on.The commands work on linux (and I was able to remove some unnecessary code). The problem seems to be that Linux intercepts Alt-F8 and Alt-F7 for its own purposes (like resizing a window). Presumably it's more or less the same on the Mac. I'm trying to come up with alternate shortcut keys that aren't in use by either the OS or Leo.
--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/0906031d-4c80-4c6e-b0be-9d43fd0e10e1%40googlegroups.com.
The commands work on linux (and I was able to remove some unnecessary code). The problem seems to be that Linux intercepts Alt-F8 and Alt-F7 for its own purposes (like resizing a window). Presumably it's more or less the same on the Mac. I'm trying to come up with alternate shortcut keys that aren't in use by either the OS or Leo.
I changed the hot keys to Ctrl+F8. Ctrl+F7, Ctrl+F6. They don't seem to conflict with either the OS hot keys, or Leo key assignments. According to what @Austin(Xu)Wang wrote above, you might have to edit them to use "Meta" instead of "Ctrl".I also fixed a bug I hadn't known about for the insert new zettel command. I've attached the revised leo file with the commands. Just replace the old version with it. This file with the revised commands works for me on both Windows and Linux.
I think Zettelkasten people tend to say the automated UID system plus the tags system fulfills the purpose of this, but I don't think it does. ... The branched threads represented stepwise, connected thoughts, while the tags represented relationships not based in any way on sequence, but merely shared or related topics. He wanted both, plus he also had headings systems and index systems.
I've begun to use it.And already I see that I could use a command to slap a UID into an already existing zettel that doesn't yet have one. I can do it (and have done it) by making a new zettel and copy-pasting the body of the old one to the new one, then delete the old, but that's a bit cumbersome.Oh boy, this gets complicated quickly. I'll also need to be able to select a section of a file and create a zettel out of it. It can go in a to-be-dealt-with node. Maybe these are actually parser functions.
On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:I think Zettelkasten people tend to say the automated UID system plus the tags system fulfills the purpose of this, but I don't think it does. ... The branched threads represented stepwise, connected thoughts, while the tags represented relationships not based in any way on sequence, but merely shared or related topics. He wanted both, plus he also had headings systems and index systems.I think we're not as far off as I have thought. Luhmann's numbering system provided ordered, two-way connections. We are doing two-way links, though not ordered, just as Luhmann's direct slip-to-slip links were not ordered, afaik. I may need to provide literate/semantic ordering somehow within the system we have, in place of (and possibly better than, if I can do it well) a Luhmann-type numbering system.
[snip]
Eventually I hope, at least my vision hopes, to 'run the show' from inside the zettels. For example, I prep an external (or it can be an already imported file) for the leokasten and turn the parser loose on it. What I want to happen, what happens in my vision, is the prepped zettels in the file are brought in, placed in their proper headings with all the hooks in place. Hooks meaning headings, title, subtitle, abstract, tags, body, links, keywords, sum-next, pointers, references/citations, Most of these optional but all of them supported, is the idea.And they are all written into the zettel, so the system just reads the zettel, does all the behind the scenes work, and I have virtually no overhead because I've done it all right there in the zettel. Plus I can alter or add anything later, which is essential in building up the network of interlaced connections.
I've begun to use it.
This is quite a mind dump, and I am very hard to get along with. Oh well, hopefully some of this is stimulating/amusing at worst and maybe a little of it possibly useful at best.
On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:And already I see that I could use a command to slap a UID into an already existing zettel that doesn't yet have one.
Creating your own unique identifiers can be hard.
My own plan for this kind of thing is to take the text that I want to split up into zettels and go through it a section at a time. For each section, make a new zettel in Leo.
I've attached a screenshot of an example. It shows the Leo view of a zettel and also the Restructured Text rendering. The URL is clickable in both the Leo and the rendered panes.BTW, you may notice that on the id line, after the actual identifier there is a string. The string is optional, but when the hot key command creates a backlink, it looks for that string and adds it to the backlink. If there is none, it adds the node's headline. That way, you have some idea of what that backlink points to, and you get that for no effort on your part.
So you will need to have some degree of consistency in the syntax and planning of what you write and in your working procedures.
On Monday, March 2, 2020 at 8:57:30 AM UTC-5, Thomas Passin wrote:
On Sunday, March 1, 2020 at 10:54:59 PM UTC-5, andyjim wrote:And already I see that I could use a command to slap a UID into an already existing zettel that doesn't yet have one.Creating your own unique identifiers can be hard.Yes, I do not contemplate writing my own UIDs. I realize that UIDs belong to Leo, not to me. I meant that if I have an existing node, OR, a section of a file, that has not yet become a zettel in the system, with UID, I need a direct, quick way to accomplish that.My own plan for this kind of thing is to take the text that I want to split up into zettels and go through it a section at a time. For each section, make a new zettel in Leo.How do you go about making a section of text a zettel? Copy paste it into the body of an already created (with UID) empty (i.e. no body as yet) zettel? That's ok for a few, but I will have large numbers of them.
I used this format to index the file for a full text search engine (Lucene). I like the format because it is easy to type, easy to read, and easy to parse. Note that this is an actual fragment from one of my files - it's not made up for this post.===============================================================================
[Get or find computer-unique computer-specific id identifier] 2007-04-17
Find or get an identifier (hostid or host id) unique to a specific computer.
We've got that by means of the Leo outline structure. The proximity and nesting of the Leo nodes fills exactly the same function.
I've actually been making new organizing nodes contain the IDs, because I know from experience with my bookmarks manager that it can be useful to jump to headings instead of only to specific items.
On Monday, March 2, 2020 at 9:07:09 AM UTC-5, Thomas Passin wrote:We've got that by means of the Leo outline structure. The proximity and nesting of the Leo nodes fills exactly the same function.Somehow I don't see it as quite the same thing. The outline structure is hierarchical while the numbered thread structure, while it does represent ordered sequence, does not necessarily imply hierarchy (although it can). But the other aspect that I see as different (and a necessary difference) is that outline headings are categories or topics, while thought sequences are another sort of thing. A thought may be an observation, a viewpoint, an opinion, a deduction, a question. I might think of it as more of a process than a topic, although it will always have a topic. We will have entire sequences of thoughts on one topic, and topic-wise, we do indeed need the outline structure, which I consider a top-down function.But the sequences of thoughts, and their branches and connections do not, to me, closely resemble a hierarchically arranged set of topics. They can indeed be, and should be, classed within such a structure, but it appears to me that allowing them only a topic-based structure might break the dynamic of the sequenced thread of thought. This forum thread is an example of a sequenced thread of thought that would be difficult, I think, to represent as a hierarchical outline of headings. Sub-topics topics could indeed be identified, and we could build an outline structure of those sub-topics (in fact it would likely be helpful to do so), yet that structure would not, I think, reflect or adequately (though it could to a degree) illuminate the sequential thought processes that develops through this thread. A thought thread or 'train of thought' is a sequential, ordered process, not just an organization of topics. Just my viewpoint for what it's worth.
[snip]
The line of "=" characters marks a section break, the text in brackets becomes the title, and the date speaks for itself. The number of "=" characters in a line doesn't matter as long as 1) the line starts with an "=" and 2) there are at least some minimum number of them.As I see it, when you want to convert one of your text files to zettel-hood, you would go through the file and add these section breaks as you go. Then paste the entire thing into a Leo node (or import the file into a node), hit a hot key, and the system would split out all your zettels, in order, with the titles as the headlines. They'd all be at the same level of indentation. After that, you could move them into the ZK, add organizing zettels, link them, add citations, etc to your heart's delight.Does that sound like it would work for you?
On Monday, March 2, 2020 at 10:07:00 AM UTC-5, Thomas Passin wrote:The line of "=" characters marks a section break, the text in brackets becomes the title, and the date speaks for itself. The number of "=" characters in a line doesn't matter as long as 1) the line starts with an "=" and 2) there are at least some minimum number of them.As I see it, when you want to convert one of your text files to zettel-hood, you would go through the file and add these section breaks as you go. Then paste the entire thing into a Leo node (or import the file into a node), hit a hot key, and the system would split out all your zettels, in order, with the titles as the headlines. They'd all be at the same level of indentation. After that, you could move them into the ZK, add organizing zettels, link them, add citations, etc to your heart's delight.Does that sound like it would work for you?Yes it does.So prepping a file consists of adding the separators, [title in brackets] on first line, a space and then the 'created' date (where I see you used the same YYYY-MM-DD format that is my preference.Will the system then zettel-ize it with a UID? And where will it place the title (within the zettel that is)?
In the example you posted, "Salmon with Whole Lemon Dressing" is the heading, and also the title in the rendered pane. But in the body pane, what follows the id is "Salmon Lemon Dressing", so the rendered title is the same as the heading, but not the same as what is in the body pane.
[snip]
And if the system extracts the title for the heading, perhaps I need to copy the title into the 'body', below. Or it could even differ from the heading if there is any reason to do that. Can you have multiple identical headings in an outline? Actually, yes, I've already discovered that you can.
BTW, with Restructured Text your zettels can have note boxes, sidebars, and tables that render well. See the attached screen shots.
A zettel thought experiment....
So in about five minutes we have wandered from a dinner recipe to paleo history to philosophical questions about the meaning and stability of sensory perceptions. We've actually come up with several possible research projects and a topic for a philosophical essay. All in about five minutes.All this, and there's virtually nothing in my ZK yet! I'm just visualizing how I might use it. This serendipidy, that's one of the main things I'm interested in - that, and helping me and my fallible memory find things again.
On Monday, March 2, 2020 at 3:43:08 PM UTC-5, Thomas Passin wrote:
A zettel thought experiment....So in about five minutes we have wandered from a dinner recipe to paleo history to philosophical questions about the meaning and stability of sensory perceptions. We've actually come up with several possible research projects and a topic for a philosophical essay. All in about five minutes.
All this, and there's virtually nothing in my ZK yet! I'm just visualizing how I might use it. This serendipity, that's one of the main things I'm interested in - that, and helping me and my fallible memory find things again.
Zettelkasten = structured serendipity! A self-organizing thought factory! How to partner creatively with your own brain! An intelligent memory bank that digests what you feed it and provides instant, connected, pre-clustered, organized access to everything you've ever written!