Looking for others' experience with "plain text files" applications

Best Practices
1

I’m unfamiliar with apps like Roam, Obsidian or Logseq. I have the impression that these applications are a kind of file-management layer over a collection of separate, individual text files, which affords some linking and graphical organization functionality. That may be an oversimplification.

But I’m wondering about the experience of using that kind of application, specifically in the context of naming the individual text files. Is there a custom, or a practice with some broad application across those sorts of applications with regard to naming the individual files, and does it vary in some way by the application?

I ask because, in some ways, Tinderbox’s $Name/$Text maps to filename/contents in apps that prioritizes separate individual text files, and I’m curious about that approach to naming. Is there something there that’s worth knowing?

I hasten to add that Tinderbox seems to have a far richer suite of signifiers to add context to $Name than perhaps that afforded by an OS’s file system. (Badges, colors, subtitles, hover expressions, display name, etc.) Am I wrong about that? Do these “plain text files” apps also offer something of a contextual layer within the app that expands their ability to convey context or significance beyond that afforded by the OS’s file management system, or the mere filename?

I’m not looking to specifically make a direct comparison between the Tinderbox approach and that of the other apps, I’m just wondering about names, and if there’s something there worth thinking about with regard to considering $Name in a Tinderbox document.

I’m fairly certain I’m over-thinking this, but I have to scratch this itch to make it go away.

Thanks.

2 Likes
2

TL:DR; Yes, they are. I realise they work orthagonally to Tinderbox, in that they create lots of files rather than single monolothic one. Here I detail a system I’ve assembled to use Tinderbox in this way, but it depends on the auto-import feature integrating DEVONthink and Tinderbox. While the DT/TB integration uses internal UUIDs to allow records to move and be renamed, the process relies on storing files on disk, which breaks this benefit. Apologies for the following typing:

I’m writing my thesis as an outline in Tinderbox: however, this limits me to sitting in front of my computer to write (rather than giving me the flexibility of using a Pomera or my iPad). What I do is consider Tinderbox as the structural manager of the system - I move parts around in an outline, but don’t actually write in it. I instead store everything on disk as plain text (or really, markdown) files. I use DEVONthink to bind the two - DEVONthink can ‘index’ a directory on disk, where I keep the files (and can edit with any tool I feel like, or sync to an iPad, or SD card). DEVONthink notices changes in those ‘indexed’ directories, and imports them automatically (or removes them if taken from disk!). Most importantly, it gives each file a unique ID and URL, which is consistent across devices (a devonthink link on iPad will point to the same file as on my Mac).

I have some (shonky) AppleScript what I wrote which connects the two things; in my Tinderbox outline, I have a ‘writing’ prototype which exposes the URL and AutoUpdate attributes, and I can trigger one script to take the Tinderbox text and note title, create a record in DEVONthink with those properties, and link the record in each programme back to the other (I also have an even flakier script to update Tinderbox from DEVONthink, In case I get carried away and forget my workflow).

There’s a couple of caveats; I have to avoid updating in Tinderbox, as if ‘autoupdate’ is set on a note, it will happily clobber the changes I make in Tinderbox with the DEVONthink version, which I have to consider as the reference copy (though the on-disk version trumps all others, it being the version DT actually uses).

I have another flaky script which takes the note in Tinderbox, looks at the DT reference version, and opens it for editing in whatever external editor I’m using (I’m enjoing MultiMarkdown Composer at the moment). Once I’ve settles into a flow, it’s quite nice - as long as I remember to use the on-disk versions of files, I can edit them and they will magically replicate over DT and Tinderbox, plus I can make changes on my iPad and they get propagated back.

It gets messy if I undertake a big restructure and rename files - I deciced to use a hierarchical numbering system (and wrote prototypes to support and automate this) as part of the filename, but while it helps preserve a directory sorting order, it imposes it’s own rigidity if I need to restructure.

But, generally, I rolled a version of those roam/obsidian tools some time back with TB and DT, and as ever with these things, I’m constantly tweaking and fixing it. Happy to share some parts (after cleaning out data), but some of the conventions may be idiotsyncratic (it’s also neat for storing in git)

3 Likes
3

This is a question that might fall under the umbrella of communication and information science, but that’s not my field. Regarding using Obsidian alongside Tinderbox, I’d say that with the “Basics” feature—Obsidian’s latest innovation (another name for attributes)—it’s possible to get an overview of certain characteristics of your folders within Obsidian. The major difference, in my experience with this tool, is that unless you use plugins that I haven’t tried, you can’t export folders from Obsidian the way you export notes from Tinderbox, grouping them by attributes, by creation date, for example. The name given to what corresponds to a note in Tinderbox corresponds to a text file in Obsidian.

1 Like
4

Replying here to both @dominiquerenauld and @DaveM, and thank you both for your replies.

What I’m curious about is any kind of “philosophical” difference with regard to naming, notes in the case of Tinderbox, files in the case of the other apps.

Is there no difference? Is it the case that at least some of the text files are created within the apps, and naming them is little different in terms of thought process than note naming in Tinderbox?

I’ve watched much of this video by Joel Chan, working in Roam with an extension he developed, and I confess I find it unfathomable. It does seem clear that many of the items appear to be files within the Sources topic or container. And there does appear to be a facility for appending a variety badges, icons, labels, checkboxes to those file names for additional context. It isn’t clear if “Sources” and its child “household secondary attack rate study” are folders within the OS’s file system rendered within Roam, or some part of a Roam “document” that overlays and links to the actual files, which affords the badges, icons, etc.

Obviously the “source” files aren’t created within Roam, but imported in some fashion. Joel seems to have adopted a prefix notation of some kind pre-pending “@” to the names of these studies or source documents. Does that renaming take place within Roam, or in preparatory work within the file system before importing into Roam? That’s not really an important question, I realize, but I don’t know so I’m just mentioning it.

What I was really wondering is if there is some clear difference in the way the user approaches “names” because of the different user interfaces and structural underpinnings? (Separate “files” versus a single file of “notes”.)

The impression I’ve received is that if there is a difference, it is probably subtle, and of little interest in terms of thinking about naming Tinderbox notes.

Secondarily, I also have the impression that names themselves are not given a great deal of consideration or thought in either approach. That indeed as someone, I believe @echuck, mentioned in the meetup, a note’s (file’s) name is little more than a convenient handle, and as little thought is invested as necessary to meet this minimal level of functionality.

It seems that there is little in the way of meaning to be conveyed or expected from a note’s title, it’s merely a means of referring to it, and some amount of idiomatic speech is more advantageous for human beings than an arbitrary “ABC.123” system that is equally practical as a label distinguishing one note from another. To be sure, names with words might convey some hint as to what the note contains, but little more.

All of which makes me wonder if we’re not taking the best advantage of “name” given its priority in terms of the user interface. I think it’s the single attribute that appears virtually everywhere with the document and the application user interface.

I don’t know, but I feel as though I’m getting to the end of my curiosity.

I think in terms of The Hitchhiker’s Guide, I will make some reference to this, with perhaps the recommendation that one be thoughtful or intentional when giving names to notes, because there just may be some value there, which is as of yet unexplored or unexploited.

All of which came about because of my own casual disregard for the value or utility of $Name, mostly regarding it as just a field I had to fill in before I could work on the thing I really wanted to do. The passion that people expressed with regard to certain practices regarding prefixes raised the question in my mind, and, for now at least, I think I’m satisfied.

If there is some value or utility to “good” names, we haven’t figured out how to exploit it yet.

1 Like
5

Some other precedents:

  • Locke was a big fan of choosing good names for topics. He advocated selecting a single name for each topic, always in Latin to avoid having to remember which language a particular heading used. Topics were to be listed in one’s notebook as they arose, but the heading was to be copied over to an alphabetical list at the front, leaving space before and after each addition for later topics. See especially Hess, J. M. 2022 How romantics and victorians organized information : commonplace books, scrapbooks, and albums. Oxford University Press. (Someone was in touch with Professor Hess; I’d love to have her come to a meetup.) Also Allen, R. 2023 The Notebook: A History of Thinking on Paper. Profile Books.

  • Luhmann and the zettelkasten tradition is a reaction against Locke’s assignment of names and topics, which often forces the notetaker into difficult choices. (Just look at us here!) His alternative: just pick a name, any name! 3317 will do! Engelbart also wound up in this camp, with “purple numbers” used to refer to blocks in NLS.

  • The original Wiki (aka Ward’s Wiki, for Ward Cunningham) wound up as a counter-reformation, establishing a convention that CamelCase words were links. The main purpose for the original wiki was discussion of object oriented design in its early years, during the emergence of patterns. This spurred the creation of memorable slogans as topic names: “YouArentGonnaNeedIt” or “ProgrammingIsArt”.

  • Early tools often split into those that expected notes to be the size of a notecard (NoteCards, Storyspace, NLS) and those that expected notes to be the size of an essay (Intermedia, HyperTIES, Symbolics Document Examiner). The latter group (holy scrollers) inclined to use names as a title that described, summarized, or advertised the text. Names were more problematic for the former group (card sharks) because there were so many of them.

  • I am 90% sure that no one has written about this anywhere in the research literature. That seems odd.

  • I agree that this isn’t likely of great use to Tinderbox beginners, but it’s a fascinating look at how deep questions lie very close to the surface hereabouts.

5 Likes
6

I hesitated to respond to you on a philosophical ground, but since you use yourself the term and @eastgate mentions John Locke, I see little reason not to pursue this line of thought, that of “philosophical” reflection. If you open the collection of texts published under the title Zettel (in German), this preparatory collection for Wittgenstein’s Philosophical Investigations, you will see that he does not use titles for these notes. He numbers them: 1, 2, 3… up to 717.

I’ve often wondered why he didn’t use titles, and I still don’t have an answer. In the Tractatus, he uses numbering—1, 1.1, 1.11, 1.12…—but doesn’t give any titles to his propositions. Should we assume that a title is less essential than the content of a note? Probably not, because who would accept having their notes automatically assigned a title based, for example, on the first sentence of a note? We must therefore assume that choosing a name for a note is a problem. In Tinderbox, this difficulty frequently arises for me in the following form: what name should I give to my note?

The problem is somewhat similar, it seems to me, to the difficulty of choosing titles and subtitles for a book one is working on: what kind of relationship should a title have with its chapter’s content? In Obsidian, two text files cannot have the same name. This forces us, I think, to accept that the choice of a name inevitably involves an element of arbitrariness. The content matters more. For me, the name is comparable to a memory aid. It is not an “engram” of the Logos, a thought etched in the marble of computer silicon. Everything that enters into Tinderbox, on the other hand, if I understand correctly, is data. Does it mean that the system is engrammed within the system?

1 Like
7

A post was merged into an existing topic: Latests Drafts of The Hitchhiker’s Guide to Tinderbox

9

At the risk of adding more lines to a long thread, I’ll weigh in with the following:

Consider 3 scenarios:

  1. What is this about - I think we can all agree that generally we want a Note name to encapsulate the contents of a Note, so that (using my paradigm during yesterday’s Meetup of the “periscope” view) we can rapidly scan through multiple Notes and get a general sense of what the Note (and its companions) are about - the REGARDING scenario.

    This scenario also allows for the use of mnemonics that will directly identify the Note’s contents to the owner, while a stranger may have no idea what the heck the owner is referring to (“Last Friday night with Rosa”).

  2. Context - In some cases, we are concerned less with encapsulation than with relation of and between Notes - the RELATING scenario.

    This scenario covers Zettels and, I believe, most other inter-related (hypertext) bodies of Notes.
    Also allows for non-relation - re: Wittgenstein’s use of Numbers rather than Note names - in the Preface, he notes the challenge involved in attempting to organize and direct myriad thoughts and the risk of focusing on organization being counter to the power and purpose of the text.

  3. Shuffle - In some cases it is useful and sometimes entertaining - or creatively refreshing - to intentionally name a Note completely unrelated and even misdirecting to the reader. David Cross, in his “Shut up you fucking baby” CD [https://en.wikipedia.org/wiki/Shut_Up_You_Fucking_Baby!.], has named the chapters with no apparent consideration to logical completion of the actual topic of the comedic bits.

    Your own methods may vary.

    My feeling on the subject is that Tinderbox, through use of Attributes, has enabled us to abstract/connect the Name of a Note from its content.

    Therefore, the user can generate multiple CONTEXTUAL naming conventions ($Name, $Name2, $Name3, $PreviousName, $HoverText,$About…..) - and then over and above that, generate RELATIONAL markers based on physical appearance (Color, Size, etc) and placement (on the Map).

    The beauty herein is that all scenarios can co-exist independently of each other. Another beautiful aspect is that the user can programmatically bring to the fore any convention/s they wish, and express these conventions (through DisplayExpression and so on) which can evolve according to the needs of the user/project/circumstances.

    Thus, the key takeaway to me is that under Tinderbox we are able to continuously vary the “handle” of the note as well as its context within the project - without destructive effect to the content of the Note itself.

3 Likes
10

As an aside - Obsidian, through use of its Attribute-like “Properties” feature, also allows for multiple naming conventions. I use this feature regularly.

1 Like
11

It’s “Bases” (as in database).

Roam is a web-based graph database. The other two are, yes, local bunches of files.

I use Obsidian regularly. File naming is not important in the sense that any file can be aliased either by an “internal link” – for example [[This file has a name|abracadabra]], which shows up as “abracadabra” wherever the file is linked that away. Files can also have an “aliases” property by which the file can be referenced by however many aliases the user wishes to assign. The internal link is usually used as a one-off solution. A nice feature of defining aliases rather than using internal links is that the spelling of an alias can be change and the change ripples to all files that reference the file by that alias.

Aliases property example for a file named Margaret Bentham Paley.md

---
aliases:
  - Maggie
  - Aunt Meg 
  - Grandmother 
  - Aunt Paley
  - Doodie
---
4 Likes
12

I will hrow my two cents in. Are you familiar with the Zettelkasten technique? One key feature is using a number base system aspart of the note naming convention. Notes are linked to other connecting notes.

If you’re not familiar with it, it is an interesting rabbit hole to disappear down. Note linking deemphasizes the need to categorize notes into folders or tags.

How to stark Zettelkasten

I find I cannot use this technique with very specific technical information that has distinct categories, but for an exploration of a topic where one thought leads to another. It is an interesting way of connecting. Especially as claim suggests - having a conversation with notes. One idea begets another idea.

1 Like
13

Yes, I’m somewhat familiar with it. I think it’s a perfectly valid approach to using Tinderbox, though not for me.

Additionally, there are aspects of Tinderbox that are fundamentally different from the applications mentioned above, with the possible exception of Roam, inasmuch as notes may contain code that runs within the document, altering its appearance, or structure in ways that have some utility or meaning, and the names of those notes are effectively part of the code. So there is a dimension of naming within Tinderbox that must account for that.

And there are perhaps taxonomic, for lack of a better word, approaches to naming as described by @satikusala , where a prefix is used to distinguish two notes that might otherwise share the same name, i.e. a company that produces an eponymous product.

There are obviously many ways to make such a distinction through the use of User Attributes, but $Name is a privileged space in the UI, appearing in search results, agent collections, link roadmaps, virtually everywhere in all main Views, and so on; so it’s very useful to be able to distinguish one sort of note from another by glancing at $Name. Some of that might be alleviated by query or search construction, but much of it is just built into the UI so name collisions can be a problem and a prefix is a simple way of mitigating it in those circumstances.

As @eastgate has observed, a rather rich discussion for a seemingly simple topic.

14

In my experience, the Zettelkasten numbering system in Tinderbox adds a lot of confusion to the order in which notes are presented. However, notes organized using this method, that is, by means of a thematic incrementation, when exported from Tinderbox and compiled into LaTeX, produce a very attractive result: in LaTeX, the outline or table of contents is particularly well done. The combination of the two—Outline View in Tinderbox and Table of Contents with LaTex—produces wonders.

1 Like
15

A side question…

Using what document class or package? I’m just asking out of interest, as something has to tell the LaTeX how to typeset the TeX code you give it.

16

I think it’s different from how Dominique Renauld uses it,
As always, I am particular about writing in LaTeX.
I’m currently working on Tinderbox 11.0.1 to write a sequel to Marcel Moyse et Bergson
and a follow-up to Moyse’s book Tone Development through interpretation.
I have a lot of sheet music and related PDFs, and I’m struggling with how to use them as references.
Therefore, Melle 6.6 is also used in this work.

Since last week, I have returned to Emacs30 (Native-compilatio).
From the Spacemacs environment that I had been using (using emacs-plus 28.5),
I’m thinking of going back to plain Emacs and learning it all over again.
One of the reasons (although this is different from the question here) is to prevent aging.
Japanese input using LaTeX seems to be useful for “finger training”.
When compiling to LaTeX, keyboard operations such as “C-c C-t J” are required.
Spread your left pinky and index finger and press down on the “J” with your right middle finger.
The AUCTeX, I was using until the other day is of the “C-c C-c” type.
It won’t help you train your fingertips. For a Japanese environment called YaTeX that I used a long time ago.
The LaTex compilation engine is a contributor.
In Spacemacs, candidates are selected by “press SPC” + “one key” when compiling, so is it far from training your fingers?

Now, back to the opening question.
There is a package called “denote” that can be used in the Emacs environment.
See the site ``denote: Simple notes with an efficient file-naming scheme.‘’
[ Denote (denote.el) | Protesilaos Stavrou ]
Until now, I had been writing notes using org-roam, but
With this denote package, not only .org but also txt pdf are stored in the same folder.
If you have it stored, you can quickly search for links and preview PDF files you have written down with a single click.
This is a filing system that was not possible with org-roam. (Unlike org-roam, memory consumption seems to be quite low.)
I heard that the usability of denote has improved significantly since it was updated to ver.4 in 2025.
(It is unknown whether the level of the previous version is unused)
The reason I continue to use LaTex is because it matches the tastes of musicians.
Changes in tempo, dynamics, and expression of p, f, cersendo, rit. dolce, etc written in the score are placed at appropriate locations in the score.
This is also a reflection of the creator’s intentions. A similar writing style is also reflected in LaTeX.
As a professional musician, I believe it is important to understand the creator’s intentions.
What made me decide to purchase Ulysses 2 when Tinderbox ver.5 was released was that it supported LaTeX export.
(Later, Ulysses is no longer part of the LaTeX environment.)
I purchased NisusWriter and Mellel as well, as they are apps that set up a LaTeX environment.
Yours, WAKAMATSU
P.S.
If the topic is slightly off topic from the beginning, please submit it as a zip file.
Why did I return to Emacs? etc.

others’ experience.txt.zip (3.0 KB)

1 Like
17

This is the very beginning of my preamble:

\documentclass[hidelinks,12pt,twoside,openany,a4paper]{book}

The following section contains more personal specifications:

CleanShot 2026-01-15 at 16.59.40@2x
CleanShot 2026-01-15 at 16.59.40@2x1154×1156 199 KB

1 Like
18

Thanks!

Most of that seems to relate to main and section titles. To my understanding a Table Of Contents is inserted with the LaTeX built-in \tableofcontents macro (here is a nice simple summary). I assume is uses heading styling as per the \section, \subsection, etc. headings. So if the heading style amendments are pleasing to the eye, the ToC inherits that.

19

In my opinion, nothing beats the table of contents generated by a LaTeX text editor when it comes to get a very detailed overview of a document: part, chapter, section, subsection, subsubsection…