Logseq seems to be in a unique position here. On the one hand, it is connected to the local file system and helps organise pretty much anything going on in our digital lives, and on the other hand, Logseq can be connected to the rest of the Web via APIs, plugins, and separating the private from public.
Nowadays, I’m trying to integrate Warp (command line , more and more with Logseq as Warp treats Unix commands as blocks, which maps nicely to Logseq blocks.
I agree that supporting directories adds complexity to Logseq but these are complexities that have already been solved. It’s a bit comparable to virtual machines in the world of programming languages. JVM was adopted and continues to shine because for the first time, we had a large-scale virtual machine that enabled developers to write code in Java, Groovy, Clojure, etc. and then run that code across any OS. Logseq should be able to provide a layer of abstraction that also hides the OS-specific complexities.
Solved yes, but still not free to implement, debug, maintain. And in a way Logseq already hides the OS-specific complexities by not showing a folder structure. This part I also like, because with alias I can add the same document in multiple structures. For example I have Energy in Topic/Health/Energy and Topic/Productivity/Energy.
I totally agree. It’s a question of perspectives. One perspective is to go from something logical and potentially find file system contexts related to that high level topic.
Another perspective is to start from the file system context and end up linked to the logical structure you maintain in Logseq.
I’m thinking of something like Warp command line, which already does treat commands as blocks. One would think that it would marry nicely with Logseq. But the link from file system to Logseq context is lost at the moment.
And if you look at my proposal, we can have a separate namespace in Logseq for anything file system e.g. a filesystem path that starts with ~/
One use case I have for this is to have Logseq be my personal middleware. I have file system contexts that contain executable scripts or a set of commands, simply that need to be run in a specific directory on the filesystem (filesystem context). I could have Logseq be an executable README (an experience maybe similar to Jupyter Notebook) for certain directories that are linked to the topics I manage in Logseq.
This is exactly me need. I mean I want to be able to have several folders that I can merge and then open in Logseq (for maintenance, archiving or better history/version management, but also for privacy reason). I organise all my files and assets in in structure like yyyy/mm/dd (time path). Each time I modify a file, it is copied in the current time path. As it’s not possible in Logseq right now (basically, for md files, two files of the same name cannot coexists whereas the “last” version could be used), I need to read and parse everything to change file paths… I also cannot change file name of course (one solution would be to use properties for that purpose). Not that easy ! Moreover, I’d like to be able to record also ressources that are read (not only written)… If people understand me and are interested in such usage, we could join forces (ie. have to preprocess/merge directories before opening Logseq) .
Hi @brsma, I’m really struggling with your idea that using filesystem hierarchy is an utter waste of time as in my experience it’s exactly the opposite.
Especially with the current state of logseq, promoting the use of namespaces as an answer to this problem and the current implementation in logseq - discarding any fs related structure - as well as the team’s vision towards handling fs hierarchy in general. I wrote an elaborate reply on a related feature request and a similar confusion arises with your standpoint here, hence my direct question. - link to post
I’m obviously a software developer and just struggling with your words, stating that fs hierarchy is a waste of time - I really fail to understand: it’s just unthinkable to me to run a reasonably complex software project without fs hierarchy… I’m fine with being labeled an OCD sensitive person as I consider this a compliment instead of a blame: more often than not my “OCD like features” have saved me from massive disasters and huge setbacks so I’m obviously proudly defending fs hierarchy, or as @Gary_O already put it so eloquently: “they’re in my blood and in my fingers”
I get that to cover all kinds of hierarchy is way more complicated than a file system can handle, but classifying a fs driven tree based structure as a waste of time is just a bridge too far in my humble opinion. Since you have experience as an architect I’d really value your feedback as I’m growing into a similar position myself and I’m always eager to learn, so pretty please? Can you share your experience here on how you got to these statements, I’m pretty sure I’m not the only one being confused by them…
Replying to myself here as I can’t seem to edit anymore…
Given my reply on the related topic linked below, I guess any attempts to have a sensible fs integration are stillborn by now. Really sad to see this go, especially after seeing parts of such an impressive discussion like the one above. Wonder how the database thing is going…
Just to reiterate: for me logseq has now become an example of how a project can loose track of it’s core values and what makes it loveable by users. At least I tried, but seeing the age and all of the last reactions…
Original message of my first reaction on this thread:
Can you share your experience here on how you got to these statements, I’m pretty sure I’m not the only one being confused by them…