-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhancement] Filename as title #156
Comments
I want to add that this very much is in the spirit of cosma which seems to support keeping things simple by using plain text formats and a simple CLI interface. If I keep my notes simple I am able to integrate them very easily into the rest of my system. I don't have to parse yaml, I just read the file names |
@adam-devel This goes against the design of the program. It's the same reason Cosma requires a YAML header and File names are mostly read and written by machines. We want to keep file names from becoming a problem for people like me, who may move their files through a lot of different programs/devices in their work and over the years, and who don't have programming skills. The probability of encountering a problem is low, but if you can't solve it, it's a big risk. One solution to reduce the risk is to design file names for maximum data portability and interoperability, with a very restrictive encoding scheme, e.g. lowercase ASCII without spaces. It's low-tech, effective, mostly future-proof. On the other hand, the contents of those files are meant to be read and written mostly by humans. This includes titles. Note titles are the primary interface to our thoughts. (Andy Matuschak says they are like APIs.) If you're building a personal knowledge base, which is the core use case for Cosma, you're constantly interacting with titles. So they should be designed for human readability and ease of use first. A very restrictive encoding scheme would be a hindrance. Unicode / UTF-8 makes more sense because of its expressiveness. If you want to address both of these concerns at the same time, you need separate titles. Hence the YAML header in Cosma, with the required title. I'm always curious of other perspectives, so I'm open to discuss this further. If you want to share examples of notes for instance, that would be great. |
@infologie I acknowledge the need of a separate title property for "advanced" use cases, such as support for more symbols and different languages. my proposal doesn't prevent that, however. it just allows for those of us that use simple sentences for titles to use filenames directly instead of duplicating the file name then having to deal with keeping both in sync. it's just unnecessary additional work when you don't need it. I disagree that filenames are meant to be a low level thing manage by the machine, that would be the inode. the file and directory names have always been left to the user to choose and are the direct user interfacing part of the filesystem. it's what you see when you do I see your perspective however, I understand why you say it's a machine interface. just like we use filenames and paths to locate things, so do programs (such as yours which uses the file name config.yaml). this medium is actually shared by both humans and machines (that's why windows by default hides file extensions). it's limitations also make it less suitable for humans. given all of that. I understand the desire to build an abstraction over it. I see the use case. what I am asking for however doesn't clash with that usecase. An analogy here is the fact that you can write an html document without any JavaScript or CSS, you can easily add them later. and the ones that already start with JavaScript and CSS are unaffected by the allowance to not use them. there's no reason to demand that the user include a JavaScript file regardless of whether they want to use one or not. Allow the user to choose their level of abstraction and walk up the abstraction chain if they feel like it. This is your project at the end of the day. If you aren't convinced you don't have to listen to me |
@adam-devel Verbose, not-perfectly-formatted answers are fine! I agree that ideally Cosma should adapt to different practices. And there's always the documentation to explain things. We've already done this for titles vs. identifiers. It's just that it takes time to think things through and change them, even simple things. Ok, let's look at this possible feature. Can you show us one example of a file name you use, and one of a link to a file in a note? |
To be precise, what I am really advocating for here is progressive adoption of features. I shouldn't be forced to use a feature I don't need just because it maybe useful for those who need it. |
@adam-devel Yes, I agree. Can you share an example of a file name and a link to a file in your system? This will help me work the specifics. (For instance, do you include extensions when linking to files: |
@infologie I follow different approaches to naming things on sufficiently different topics. I maintain a personal thesaurus of words in English and other languages. I maintain a directory of lists of services (similar to the "Awesome" lists in many girhub repos). I maintain a sort of academic/technical knowledge base mixed with personal thoughts. and I maintain documentation relating to my computer setup. None of this is static. I may decide to merge or split those if I observe too much similarly or too much separation. The thesaurus
Sadly meanings are private, only accessible within one's consciousness. one may initially think that a word maps to a specific meaning. so we should use words for note ! but words may have multiple different meanings. for the example I used, I have three relevant notes:
The first note links to the second and the third notes as the two possible sense of the word "Sound". the links do not include the extension. I found out later that the WordNet project uses a similar structure. This is also great because I can search for "Sound" and I will immediately see all the possible senses of the word, I can then jump to the note with the sense i am looking for. The more technical/academic knowledgeI have a note named "Language and communication" it serves as a category. it just lists highlights of important notes related to language and communication. within said note I link to a note called "dictionaries are circular" and "language doesn't transfer meaning; it points to it", and "words come to being before their definition" and others. this isn't the only note that serves as a category, I have other notes that serve as just listings of relevant notes. these listings may evolve to a more narrative format later on. for the time being they are just listings. Another example is a note named GLX, it links to [[Opengl]], [[X.org server]], and [[XCB]]. I don't have a note named XCB.md yet. Context for the reader: GLX is an extension to OpenGL that allows it to communicate with the windowing system of an operating system. The windowing system has a client/server architecture. The X.Org Serve is the server side implementation and XCB is a library used by the clients to communicate with the server. Feel free to ask questions, Maybe you want to see the actual content of the files instead of just description ? maybe you want to see the local graph of some files ? |
@adam-devel That's great, thanks. We don't need to go into more detail for now. Let's recap this idea for a possible enhancement:
Does that sound right? @Myllaume do you see any edge cases I don't? |
@infologie that sounds perfect ! just decide if you are going to make it implicit or make it an explicit configuration option. don't feel pressured to implement this feature if you have more important ones. this isn't an urgent issue |
@adam-devel I think implicit is appropriate, like using titles or identifiers in links: you use one or the other and Cosma works with it. A config option would be needed if you want to create notes with Cosma but suppress the generation of the YAML header. Just as we have |
I'm adding it to our long roadmap. Depending on the complexity of the task, we may be able to slip it in an upcoming round of development, because we have some funding for 2025. Also, right now, we're working on facilitating external contributions, by refactoring the code and writing developer documentation. This could potentially lead some people to look at this issue and attempt a pull request. In any case, it's probably wise to be patient and have moderate expectations! |
that sounds great, I may contribute at some point
I agree, I share your sentiment in regard to this type of work. there's no settled science of knowledge management and note taking as far as I know. we are building the plane as we fly it. it's good to be careful and to demand good reasons for things |
@infologie how do you want to deal with case sensitivity ? in my opinion, the file matching must be case insensitive |
@adam-devel I agree, and it's already the case (pun intended!) for links based on |
Which part of Cosma is your request about?
Describe your request:
TLDR: Allow linking to notes by their filename or path
I write my notes as a simple graph of files linked to each other. I avoid indirection whenever possible:
title
property because the file names are already present, no need for duplication.cosma seems to require either an id or a title, if one is missing I get an error ("Le fichier note.md n'a pas d'identifiant"). this is where cosma fall short for me.
It would be nice if cosma supported simpler approaches to note taking by default. if there's no id or title, fall back to file names. or provide a configuration option for doing so.
this doesn't compromise the current approach of cosma in any way. people who want to use a
title
instead of the file name won't notice a thing.The text was updated successfully, but these errors were encountered: