Let me know if I should put this in an attached file instead, and I'll do it. Pretty long.
1. No Lockin agreed 2. Text Files agreed 3. Simple Section Demarkations For distraction-free creative/productive activity I'd like to be able to optionally see only the text body, or, (and maybe the following belongs under Display) in a collection/stack of zettels, or only the first lines, or only the titles, or only the links, or only the citations or other reference types. Editor: In my ideal world I might add a category to this list: Editor. My idealized editor displays in rendered text, controlled more or less as a word processor does, e.g. Ctl-I for italic (though I don't need and don't want the accompanying bells and whistles of a word processor, 'just the rendered text please'). This, I think, would significantly enhance creativity because with no intervening (and distracting) step I get the immediate benefit of the clarity that enhanced formatting gives, plus it eliminates from the display all distracting markdown/coding, plus it eliminates me having to think in markdown and type in markdown (distractions, distractions). YET, this wonderful interpretive, self-rendering editor stores the file in text/markdown so it's transferable, or forward-compatible (as I have come to like to put it). So when you read the file in a plain text editor (and my ideal editor optionally displays and operates in plain text/markdown as well), the markdown is there. But when rendered in the editor it's in rendered mode and you edit directly in rendered mode with word-processor style key commands. Ok, here is a wild thought: Leo has a real time renderer, right? All we gotta do then, in my ideal world, is rig key commands and allow the user to work directly in the render pane, with the ability to toggle with the regular body pane, either overlaid or side by side. Easy for me to say from my vantage point as a non-programmer. My imagination lives in joyous, unfettered freedom by the simple device of not knowing what can't be done. 4. Unique Identification agreed 5. Hierarchical Navigation The way I see this playing out for me: I will seek a minimal set of 'highest level' or 'encompassing' headings, the least number under which I can class everything. Every zettel must (eventually) class under at least one 'top heading' (maybe the default could be 'unclassed' if I don't class it). But the acyclic graph principles apply. Even the encompassing headings can be anyone's children. Each zettel, then, maps into the whole shebang by means of: . headings attached to it (as parents, children siblings) . zettels attached as parents, children, siblings (Luhman's system does this, right?) . direct links with other zettels . tags, which creates a peculiar, separate but interwoven mapping, which has even fewer restrictions than the acyclic graph. I want to be able to look at all tags 'associated' (through the zettels but not directly) to a given heading or set of headings. . organizing nodes Luhmann used indexes, for one, and I have not explored Leo's concepts on this. I expect there is a lot one can do with organizing nodes . other organizing features not yet mentioned or conceived... It almost seems as though the acyclic node-mapping system should hardly be called hierarchic, as the very word implies binding limitations, which clones and acyclic graph bring escape from. And yet a Leo file is a hierarchical outline (or perhaps I don't yet grasp how clones change the apparently strict hierarchical display of the Leo outline). I guess this is one reason you like mind maps. I do too, even though I've given up on them a couple of times already and don't currently use them. You probably enhance the mindmap idea with semantic processing concepts that would be great to have in zettelkasten. I can visualize opportunistically traversing an integrated mindmap of all the above-listed mappings, just in search of inspiration, no particular purpose or topic in mind. Each node in such a mapping would access all the headings, tags, organizing nodes, etc that intersect it; all the types of handles integrated in one map. Or equally imaginable, traversing such a mapping with a particular purpose very much in mind. It becomes a capable search tool as well as a rich browsing context. Wild, I know, and quite possibly too much mess in practice to be worth anything. Yet the concept is intriguiing to me. Yep, wild. 6. Link Navigation And these links are (or can be) embedded in text, right? Do they, or can they, also link directly to a specific place in the target note, or simply to the note as a unit? Another way to say that: can the target of a link be an embedded marker in the target note? I can easily imagine, e.g. in the case of more developed zettels such as chapters or textually developed outlines, wanting to link to a particular place in the target zettel. I can also imagine wanting to clone selected material from another zettel into my current zettel. 7. Time Stamp agreed generally. I do want date of origin, and I would like modification dates as well. The vast bulk of my zettels will be extracted from archived files, so I will have to manually enter those dates of origin as I prep those files for the parser. And I want to be able to search the zettelkasten by time stamp as well as (and in combination with) other handles. If the system-applied UID is time-based (YYMMDDHHMMSS, since I might create more than one zettel within a minute), then the UID could double as the timestamp. But, for my zettels drawn from archive I would have to append additional identifying characters after the YYMMDD portion of the (user-created) UID, since many of those zettels will have been created on the same day but without HHMMSS data available. But once again I want all this necessary and highly desirable baggage to disappear when I'm writing. Get outta my sight and leave me alone until I want ya! But when I do want ya I want ya right now, with no fuss and bother! I'm hard to get along with. 8. Tags And tags form an interwoven and searchable mapping, as above. 9. Backlinks agreed, and as above can inter-zettel links go from text point to text point? as opposed to from zettel unit to zettel unit? (preferably both types) 10. Display Styles In Leo just as in MacOS Finder (I don't know about others), you can arrow through a file list viewing the files in another pane. I like that a lot and it's way better than not having it, plus with Leo you can toggle right into the file, which you cannot do in Finder. And as you say you can create ephemeral subsets to peruse and play. I don't know how the user's mechanisms by which to discover and make such collections are to play out efficiently. But the enhanced display capabilities you mentioned are highly desirable as well, along with ideas I mention above and in an attached file a few days ago. I need to better understand organizing nodes and how one creates them, how they are used, how they interact with the other organizing/navigational elements we're discussing. For example, can one easily, quickly, intuitively compose an organizing node somewhat as we do a term-based search? And perhaps thus the organizing node itself becomes a sort of search engine? And then one can perhaps reorganize the results as desired? And then how about a mapping of organizing nodes? What would that be like? Blessed ignorance. It allows my imagination to go where none have gone before (not likely, that). I don't know LeoVue at all. Interested in how it could enhance our system. I have sometimes wondered if my ideal system would have use for an on-board server, though I have no knowledge in that area. How much computer does it take? -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/6bfff1eb-edd9-49dd-aefb-1a66f0e220ae%40googlegroups.com.
