Re: Leo for organizing notes? [Comments Item 9]
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
Re: zombie process generated by g.execute_shell_commands
On Sat, Feb 8, 2020 at 4:41 AM Edward K. Ream wrote: > On Thu, Feb 6, 2020 at 1:08 PM Xu Wang wrote: > >> Dear Leo Developer, >> >> I created one button in Leo, the corresponding script is: >> >> c.save() >> g.execute_shell_commands(['git -C /Users//leodata add austin.leo', >> 'git -C /Users//leodata commit -mupdates', ' -C /Users//leodata >> push']) >> >> >> Basically, it will save the changes and do a git add/commit/push. >> > [...] > Do I need to do something extra in g.execute_shell_commands ? >> > > Good question. Sometimes Leo appears to hang (on Windows) after running > unit tests with g.execute_shell_commands. For me, a fix is to type a > in the console from which Leo is running. > > I'm not sure what else can be done. The guts of g.execute_shell_commands > is just: > > proc = subprocess.Popen(command, shell=True) > if wait: proc.communicate() > > You could try experimenting with shell=False, but I doubt that will work. > Here is a thread from last year on the same topic: https://groups.google.com/d/msg/leo-editor/1VOYPUJrNEM/ItZwstC0AwAJ. In my emails there, I was assuming that running short-lived processes in the background will inevitably lead to zombies and I so I shared a workaround of doing the git commits with a long-running background process. But now I just noticed the subprocess oabjects have a poll method ( https://docs.python.org/3/library/subprocess.html#subprocess.Popen.poll). Maybe if g.execute_shell_commands is called with 'not wait', then leo should save the proc object and at idle time make a call to proc.poll for it (and any other launched background tasks). Then at the next idle call proc.poll again. Keep doing that until proc.poll doesn't return None. Brian -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAO5X8CyapLuNrzoQrtu9fsP-pXzdVuqBF4PmtPjypEBejZMwyQ%40mail.gmail.com.
Re: Leo for organizing notes? [Comments Item 4]
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. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/3a1e53fe-09e7-495b-b20f-a016a16a6233%40googlegroups.com.
Re: Leo for organizing notes? [Comments Item 4]
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). -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/a2a01618-5d6b-48a8-b0a9-a4f830973e77%40googlegroups.com.
Re: Goals for Viewrendered3
On Saturday, February 8, 2020 at 4:35:37 AM UTC-5, Edward K. Ream wrote: > > On Fri, Feb 7, 2020 at 1:56 PM Thomas Passin > wrote: > >> One thing that is still up in the air for me is the relationship between >> *viewrendered >> *and *vr3* >> > > I would prefer that the user choose *either* VR or VR3. That way the VR > pane can be used as is. > I would too. How does Leo send the docstring information to VR? It isn't getting to VR3 at present. Note that I changed all the command names from "vr-xxx" to "vr3-xxx" (only in VR3; I didn't change a thing in VR). Is there one "vr-" command that Leo is using? -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/e2ff9a42-67fa-437f-9bca-0d55d110289b%40googlegroups.com.
Re: where do marks escape?
On Thu, Feb 6, 2020 at 3:27 AM gar wrote: > Another case. When saving outline latest set mark may disappear. > Noted in #1484. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS0A99LR6qz_uddKzkW05tdnJuskkZ8eNMO1WFGQxMZ0WQ%40mail.gmail.com.
Re: Issues using import
On Thu, Feb 6, 2020 at 8:54 PM 'tfer' via leo-editor < leo-editor@googlegroups.com> wrote: > is due to taking a time stamp of the existing file even through I refused to accept the overwrite when saving the .leo file. Therefore, the re-opening of the file doesn't trigger a import [snip] As I implied in my last reply, you don't want to be continually doing imports. Get your file into an @file or @clean (or, if you must, @auto) and then your import troubles are over. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2iWcen17hiMLrZexZG7qRXy_qzCX8jmWjnM5LHZhEyXA%40mail.gmail.com.
Re: Issues using import
On Thu, Feb 6, 2020 at 4:15 PM 'tfer' via leo-editor < leo-editor@googlegroups.com> wrote: > I'm still having issues with various import types: > > 1. doing an import via the "File" menu is under the default @tabwidth > -4, needs to be @tabwidth 2 for these files > ** this has been the only successful import I have been able to make > This is the hard way. After importing a file, either with the File:Import* commands or with the recursive import script, you should have an @auto, @file or @clean tree. After that, restarting Leo, or using refresh-from-disk will re-import the file. After importing, @tabwidth will only affect *new* nodes. If the contextmenu.py plugin is running, right-clicking a node will bring up a context menu. If that node is any kind of @ node, the context menu will have refresh-from-disk. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS04FX0JFQQCVdFJHWzxQe%3DOfaJa8xQutFVQ2ANqhP%3De6w%40mail.gmail.com.
Re: zombie process generated by g.execute_shell_commands
On Thu, Feb 6, 2020 at 1:08 PM Xu Wang wrote: > Dear Leo Developer, > > I created one button in Leo, the corresponding script is: > > c.save() > g.execute_shell_commands(['git -C /Users//leodata add austin.leo', > 'git -C /Users//leodata commit -mupdates', ' -C /Users//leodata > push']) > > > Basically, it will save the changes and do a git add/commit/push. > However, I notice the script will leave zombie process (git). See below ps > output. > > Austin-MacBook-Pro:leodata wangxu$ ps -ef | grep git > 501 88822 20009 0 2:00AM ttys0000:00.00 grep git > 501 88678 88353 0 1:57AM ttys0010:00.00 (git) > 501 88683 88353 0 1:57AM ttys0010:00.00 (git) > > > Do I need to do something extra in g.execute_shell_commands ? > Good question. Sometimes Leo appears to hang (on Windows) after running unit tests with g.execute_shell_commands. For me, a fix is to type a in the console from which Leo is running. I'm not sure what else can be done. The guts of g.execute_shell_commands is just: proc = subprocess.Popen(command, shell=True) if wait: proc.communicate() You could try experimenting with shell=False, but I doubt that will work. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS3a2eY5MB1JVwyOrBZaeKiywfbUui26uTn54vsXv6QW8w%40mail.gmail.com.
Re: Goals for Viewrendered3
On Fri, Feb 7, 2020 at 1:56 PM Thomas Passin wrote: > One thing that is still up in the air for me is the relationship between > *viewrendered > *and *vr3* > I would prefer that the user choose *either* VR or VR3. That way the VR pane can be used as is. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS3H4Vf-d9OJD1622hkZM0jRu3k4y4z7%2Bd5_U8XxxXL3Ug%40mail.gmail.com.
