# Whither Zettlr

## Introduction
Zettlr is facing an identity crisis. It is a powerful tool with many features but, like [the proverbial elephant](https://en.wikipedia.org/wiki/Blind_men_and_an_elephant), it appears differently to different people. This would not be a problem if the design were static or "finished", but the Zettlr project is ongoing, and the different views of the purpose of the application are causing tension when considering improvements, implementing new features and prioritising bug fixes.

## Aspects of Zettlr
For the purposes of discussion I have identified a few different aspects of the nature of Zettlr. In each of the following subsections, I attempt to explain what I mean by each aspect, and evaluate the strengths, weaknesses, and possibilities for Zettlr in this role.

### A Markdown Editor
If you first find Zettlr via the https://zettlr.com/ website, then it is natural to assume that this is the main purpose of the application. Right there at the top of the front page it is described as "A MARKDOWN EDITOR FOR THE 21ST CENTURY". Markdown is a plain text format for describing rich text documents, and a Markdown Editor is a text editor which has understanding of the Markdown syntax.

While Zettlr certainly fulfils this role, as it is able to edit markdown documents, it also offers more. The most obvious addition to the Markdown Editor role is the ability to manage one or more "workspaces", each of which contain many markdown documents. Zettlr also supports the addition of "yaml frontmatter" as a means of adding non-printable metadata to markdown documents.

Competitors in this area include markdown-specific local editors such as [Markdown Pad](http://markdownpad.com/) and online services such as [Hack MD](https://hackmd.io/) as well as general-purpose editing environments which have plugins or extensions to support markdown, such as [Visual Studio Code](https://code.visualstudio.com/)

Most competitors support some form of "real time" rendering of the rich-text equivalent of the markdown "source code", whereas Zettlr attempts a simpler in-line rendering. If a Zettlr user views Zettlr though the lens of a Markdown Editor, the lack of such a preview seems a strange omission.

Priorities for improving this aspect of Zettlr could include:
* a preview panel
* more solid handling of markdown rendering and eliminating quirks such as lines which start with `#` appearing as headings even in "back-tick" code blocks.
* a "quick edit" option. As a simple Markdown Editor, Zettlr takes a long time to load and manage workspaces of files, even if you only wish to edit a single file.

### A Personal Knowledge Manager
Another major aspect of Zettlr is as a [Personal Knowledge Management](https://en.wikipedia.org/wiki/Personal_knowledge_management) tool. This is a broad category of applications with a range of approaches, but the common features seem to be the ability to capture and interlink "nuggets" of information, knowledge, or opinion so that they may be found and used later. Some such tools support the addition of almost any type of data object (images, videos, captured web pages, rich and plain text documents, etc.), whereas some are more specific The specific variants usually limit themselves to textual information and include some way to connect the "nuggets", either using special text sequences within the information, or by associating external metadata.

Zettlr fulfils this role in that markdown files within a Zettlr workspace can be used to hold textual "nuggets" and the Zettr variant of Markdown includes a syntax for linking between files. Zettlr also adds the ability to link to external URLs and to academic literature outside the workspace, with the help of a separate reference manager such as [Zotero](https://www.zotero.org/)

Competitors in this area range from the simple, such as [the many Wiki variants](https://www.wikimatrix.org/) to the complex [Notion](https://www.notion.so/), [Obsidian](https://obsidian.md/), [Evernote](https://evernote.com/) etc.

This kind of application has several key attributes. One of them is a lack of "friction". Going form waking up in the middle of the night with an idea, or finding inspiration on a random web page or academic paper, to a useful representation in your knowledge management tool should be as smooth and direct as possible. Some competitors provide browser plugins or "bookmarklets" to grab information and add it to the repository. Most make basic operations such as creating a new "nugget", or extracting something to a new "nugget" of its own, following links between "nuggets", or getting back to what you were working on before a distraction, as simple as possible, ideally just a single click or command. If such basic operations take too many steps or too much thinking, they risk [losing the spark of knowledge which prompted the activity in the first place](https://en.wikipedia.org/wiki/Person_from_Porlock).

Priorities for improving this aspect of Zettlr could include:
* reducing friction and confusion for common knowledge-management activities, such as a button to create a new file, and the ability to set a default "snippet" for a new file
* supporting per-folder configuration for snippets (including the default), variables, etc. so that placing a file in a folder can have a _meaning_ beyond mere location on a disc.
* additions to help surface unexpected connections, such as allowing a user to find all kinds of related files
* better navigation while editing, such as browser-style back and forward buttons
* and generally anything which will help keep a user in the creative "zone" while working.

As well as general-purpose knowledge management tools which attempt to solve the whole knowledge management problem, there are also some special types of knowledge manager which deserve discussion here

#### A Reference Manager

A reference manager is a specialist tool used primarily in academic writing. It's job is to collect information about academic papers, books, journals, magazine articles, web pages, and various primary sources, so that they may be correctly referenced in further academic documents. generally such tools are responsible for managing bibliographic information such as authors, titles, dates, publications and so on. They may also support the keeping of copies of electronic documents, but this is not a fundamental requirement, as many such sources are outside the electronic realm.

Although the general knowledge management features of Zettlr can be used for this purpose, it is not particularly well suited, and this responsibility is usually delegated to another tool such as Zotero, EndNote, Mendeley, or JabRef.

#### A Digital Zettelkasten

A [Zettelkasten](https://zettelkasten.de/posts/overview/) is a knowledge management tool originally conceived as a collection of physical index cards before electronic equivalents were available. It has specific characteristics tailored to its original form:
* each note is limited to the size of a physical card, so can only contain a relatively small amount of information
* linking between notes is accomplished by unique numeric codes. Following such a link is a matter of locating the card with the referenced code. Finding "back links" (other notes which reference this one) is a laborious process potentially involving checking all the other cards in the system

As a pre-computer knowledge management approach, a Zettelkasten is very clever and surprisingly powerful, but the limitations don't always sit well with computerised tools. When the knowledge is represented as electronic data, following both forward and backward links should be instant, and there are many other things a computer can do to find unexpected connections between notes. Despite that, there are a few things which physical cards do well, which are often not so easy in a computerised solution.
* WIth physical cards it is easy to select a subset of notes to work with for a particular project, this can speed up and simplify many common operations. When the project is complete, the subset of cards can easily be merged back into the main collection
* With physical cards it is easy (and even fun) to shuffle, select, layout, move, group and order concepts to help plan a project and understand a domain. Despite several decades of computer-assisted writing tools, this approach remains extremely popular among writers of all sorts including [fiction, non-fiction, and screenwriting](https://www.google.com/search?q=save+the+cat+board&tbm=isch)

There is evidence from the name that Zettlr was conceived as a Digital Zettelkasten tool. Each Zettlr file is roughly equivalent to a Zettelkasten note, and just like the original, links between notes are accomplished using numeric codes (athough there are also alternative forms of linking). Zettlr mostly does the same job as a physical Zettelkasten, but in common with many computer implementations it lacks some of the ease of working with the cards.

Priorities for improving this aspect of Zettlr could include:
* improving the display and navigation of internal links
* the ability to select or filter one or more subsets or "views" of the full collection to simplify and speed up working on any particular project
* improving the ability to shuffle, select, layout, move, group and order files in the manner of physical cards, and display options to show, read, and work with more than one file at a time (see, for example [the Scrivener "corkboard"](http://www.simplyscrivener.com/wp-content/uploads/2014/05/Corkboard-with-Keyword-Chips.jpg))

### An Academic Writing Tool
One of the aspects of Zettlr which often surprises new users is its use as an academic writing tool. Hidden behind menu options are a variety of settings and actions which can be used to convert a set of markdown files to a document in a different form, such as PDF, LaTeX, or Microsoft Word. This aspect of the tool is one which is obviously used a lot by the originator of the software, Hendrik Erz, but it is not always apparent to anyone who has come to the application looking for a Markdown Editor, Personal Knowledge Manager, or Digital Zettelkasten.

Competitors in this area include [Scrivener](https://www.literatureandlatte.com/scrivener/overview) which is a writing tool which also prides itself on including some knowledge management features and [Overleaf](https://www.overleaf.com/) which deals with the complexities of LaTeX but does not include knowledge management.

I will say up front that academic writing is not an aspect of the software that I currently use (my own PhD thesis lives in Overleaf) so I can't comment on its strengths or weaknesses. The nearest I have come to this is an experiment with adding some of the chapters of a fiction project so I could count the total words.

Priorities for improving this aspect of Zettlr could include:
* inheritable, per-folder (or per-project) configurations for things such as dictionaries, language settings, etc.
* the ability to have multiple output profiles associated with a project so that one set of files can produce (for example) a LaTeX document and an EPUB.
* anything which makes writing smoother and turn-round times shorter between trying something and seeing the result.

#### Some suggestions for improving Zettlr as an academic writing tool

> [name=Arthur Perret] I use Zettlr primarily as an academic writing tool. I think it does a great job. For long texts, I occasionally jump to either BBEdit for power user functionality, or iA Writer for focus. I have two suggestions inspired by these tools.
>
> **1/ Improve support for writing long texts:**
> - add ways to see/write in different places simultaneously (e.g. independent windows in addition to tabs, split view of the current file, scratchpad to dump text in…);
> - add shortcuts to navigate between sections (e.g. press a key to jump to the Table of contents, then navigate it with arrows, which moves the cursor to the corresponding sections).
>
> **2/ Improve Zettlr’s Distraction-Free Mode:**
> - hide all the window elements, including the top area ("window chrome" with the Zettlr name), leave only the text;
> - add a "typewriter" mode (in which the insertion point stays in the middle of the screen);
> - let the user define line length;
> - make it so the shortcuts to show/hide the left and right-side panels don’t turn off Distraction-Free Mode.
>
> These may be difficult to implement. BBEdit and iA Writer are both industry-leading tools in their respective areas in my opinion. There are probably be other ways of improving these aspects too.
>
> I also have one suggestion that’s not related to other tools but a feature introduced in Zettlr 2.0:
>
> - **Add connections based on common citations in Related files.** I really like that Zettlr suggests connections based on common tags. For academic writing, this could be extended to references. I currently use tags for this: if I use a citation key like `@goody1979` somewhere in a file, I add `tags: goody1979` to its frontmatter; then Zettlr can suggest related files based on it, and I can also leverage this in Cosma. But this is labour-intensive and error-prone, so adding these suggestions to the Related files panel would be a great improvement. Frank also suggests extending the scope of the Related files features in [the Linking Conclusions section](#Linking-Conclusions).

### Other Uses

#### 'To Do List' and Project Management
Markdown supports checkboxes, and some examples make use of these as a kind of basic "to do" list. While this is just about functional in Zettlr, it is a long way from mature project management tools which typically allow searching, sorting, filtering and grouping items by completion status. An example of this might be a "Kanban" tool such as [Trello](https://trello.com/), a "to do" based tool such as [Asana](https://asana.com/), a "bug tracker" tool such as [GitHub Issues](https://github.com/features/issues) or a generalised project management tool such as [Jira](https://jira.atlassian.com/). Zettlr would need significant extra features to compete with these kinds of systems, but there is the possibility of integrating more with one or more existing systems in the way that it already does with reference managers

#### Ebook Generator
Although the emphasis of the academic writing abilities of Zettlr have largely been focused on integrating Markdown with LaTeX, it is also possible to use the same approach to generate other forms of output documents. Several people have experimented with generating _HTML-ish_ ebooks such as the EPUB format, but really it is only suited to producing a single type of output from a particular project, as it needs significant changes to configuration and support files to produce a different form of output.

#### Static Website Generator

As well as combining all the files in a project into a single document, there is also the possibility of preserving the hierarchical nature of the files within a Zettlr project and using them instead to generate true HTML files in the form of a "static" website which can then be published on a web server or even served directly from Zettlr for testing. The capability is not quite there for Zettlr as it does not yet have the templating flexibility, or the "hooks" needed to generate additional derived pages (for example index pages, sitemaps, error pages, etc.) which are needed for any modern website beyond a few pages in size. With a few such additions, Zettlr could potentially become a usable way to manage one or more simple websites or blogs directly from the knowledge base in the same way that it is currently possible to generate academic documents.

#### Uses I don't know about
It is entirely possible that that there are people who use Zettlr for uses different to any of the uses above. I would love to learn about them!

## Ways of Working
Even for Zettlr users who are aware of the full range of features, there are many ways of working. Zettlr has several features which overlap in capability, and therefore can be used to approximate some of the attributes of others.

### Grouping and Separating Content
Zettlr has workspaces, folders (a.k.a. directories) and tags. All three of these can be used to separate and group content. These features are different from each other in the way they can be used, though.

**Workspaces** are considered as a "top level"grouping, and can contain folders for further subdividing. The unique feature of a workspace is that it can be added to or removed from the current working context. If a workspace is removed from the current context, none of its folders and files participate in the session, which also means that any tags which only exist within that workspace will not appear in tag lists, any links to files in that workspace will not work, and any backlinks from files in that workspace will not appear in the list of backlinks. The selection of workspaces active in Zettlr is a persistent configuration, however, so if you remove an important workspace, you will need to manually re-add it later.

**Folders** are a structural indication within a workspace used mostly to show to a user that some files belong together. A file can only exist in a single folder at a time, so workspaces, folders, and further subfolders beneath them, form a hierarchical structure.

Some folders, however, are _special_, in that they are marked as being "projects". In some sense the idea of a project "hijacks" the structural use of folders, applying its own rules. All files within a project are considered to be part of a larger text, and Zettlr provides convenience features to, for example, count the words in a project, or process the project into a single generated document. Any auxiliary files not intended to be included in the final document need to be located outside the project folder, though, which can weaken the connection between the resource and the writing.

**Tags** are a non-hierarchical way of grouping and separating files. Each file can have many tags and each tag can be attached to many files. Selecting a particular tag from a "Tag Cloud" acts like a kind of "canned search" and shows all files with that tag in the search results

#### Grouping Conclusions

None of these ways of grouping and separating content allow for the creation of arbitrary or transient "views" which focus on one set of files and allow the user to work on them with the full set of Zettlr tools. The closest to this goal is workspaces, but workspaces (like folders) are hierarchical and exclusive, so it is impossible _(at least without messing with non-portable operating system file links)_ for one file to be included in multiple workspaces. Workspaces are also too permanent. They have obviously been envisaged for very coarse-grained switching between very different contexts.

### Identifying Content

Zettlr has several ways of identifying content which can, if you are not entirely clear about them, overlap and interact in surprising ways. Each file in Zettlr has some subset of the following:
* **Filename**.All files have a filename, but not all filenames are unique. In some domains and ways of working it is common for several files to have the same name, perhaps such as "index" or "Chapter 1". While it is true that no two files _in the same folder_ can have the same name, that same filename can happily appear in many folders. Note that at present, Zettlr does not have a way of disambiguating such file names, for example by using the folder name in references.
* **ID** This is a sequence of numbers which can appear both as the first few characters of the filename, and in a field named `id` in the yaml frontmatter. If the file has an `id` frontmatter field, that is used as the id, regardless of the filename. If the file has no `id` frontmatter field, then the number in the filename is used. If there is no number in the filename, then the file has no usable ID.
* **Title** Each file can also have a title which is used when showing the file in the file manager and in the tab bar at the top of the editor. The default title is based on the filename, but this can be overridden by adding a `title` field to the frontmatter, or, even more confusingly by enabling an option setting and specifying some H1 text by starting a line with `#` in the file.

#### Identification Conclusions
Although all these values can be used to identify a file in one way or another, they are not interchangeable, particularly when it comes to linking (see below) and displaying labels on a chart

### Linking Content

Before any discussion of linking, it is important to explain the several different types of links supported by Zettlr. I tend to think of these as splitting into two groups: _explicit_ links, and _implicit_ links. Explicit Links are links which a Zettlr user manually creates. Implicit Links are links which are (or could be) derived either from other links, or from context.

#### Explicit Links
* **Internal Links** are what is usually meant when people discuss links in Zettlr. An internal link is a reference from one Zettlr file to another. Internal links are denoted by enclosing either an ID or a name between `[[` and `]]`.
* **Tags** are links from Zettlr files to an abstract concept without a file or other physical presence. In most cases tags are used for grouping and finding rather than to express a specific relationship. Tags are denoted by adding a word prefixed by `#` somewhere in a file.
* **URL Links** are links from a Zettlr file to a URL, usually somewhere else on the internet. URL links are created automatically by entering a `http` or `https` URL, but can also be enclosed in parentheses for clarity and disambiguation, and can be given some text enclosed in `[` and `]` as anchor text. When the cursor moves away from the link, the text of the link is overlayed with the anchor text. _Note that other forms of URL links are also available including "absolute" and "relative" file links on the local machine, but these must be used with care as they may not be portable._
* **Citation Links** are links to a paper or other citable resource. Citation links are created semi-automatically by typing `@` and enough characters to identify a citation key in an associated bibliography file. When the cursor moves away from the link, the text of the link is overlayed with a traditional citation.

#### Implicit Links
* **Backlinks** are the most obvious form of implicit links. Whenever one Zettlr document is linked to another, there is an implicit relationship from the linked item back to the linker. This form of implicit link is considered significant enough to appear in the "Related Files" sidebar
* **Tag Peers** are other files which share one or more tags with a particular file. Tag peers also appear in the "Related Files" sidebar, but in my opinion these are much more common and usually less informative than backlinks, particularly when tags are used for broad-brush groupings such as projects, page status values, page types etc. In such situations it is easy for the list of tag peers to be far too long to comfortably examine. Tags also have their own "Tag Cloud" filtering panel in the left sidebar, so their apprearance in the "Related Files" list is somewhat redundant.
* **URL Peers** are other files which share a link to the same URL. These are arguably rarer and therefore more interesting than tag peers, but at the moment Zettlr has no way of displaying the URL peers for a file
* **Citation Peers** are other files which share a link to the same citation. These are arguably rarer and therefore more interesting than tag peers, but at the moment Zettlr has no way of displaying the citation peers for a file
* **Folder Peers** are other files in the same folder. These are shown implicitly in the file manager, but not in the "Related Files" sidebar. There is currently no equivalent _explicit_ way to link to a folder from a file other than placing the file in the folder.
* **Frontmatter Peers** are other files which share similar frontmatter fields. The YAML fontmatter in Zettlr is very powerful but, as far as I can tell, is not used for linking except by using the _special_ `id` and `title` fields. This seems like an omission, as arguably frontmatter fields are at least as flexible as tags, even though they may be a bit pickier to enter. As far as I can tell, frontmatter fields are also not included when searching, either.
* **Similar Files** are files which are similar in some other way, such as similar (but perhaps not identical) titles or contents. At the moment, Zettlr has no way to find or display these other than by manually searching, Some other Personal Knowledge Management tools do attempt this, though.

#### Use of Internal Links
The history of Zettlr as a Digital Zettelkasten has led to a reliance on internal linking by ID. Although it is possible to also link by title, this can be confusing, as it is not immediately clear which of the various interpretations of _title_ will be used, and changes to those titles can break links. In normal usage a link to a file is created by typing `[[` followed by enough of the desired page title to identify it. When the title is clicked, it is replaced by the semantically meaningless ID of the file which has been selected., with the file title placed beside it as an afterthought.

Unfortunately, this approach, while it is in the spirit of the original Zettelkasten, has some problems. The reliance on finding a file by matching the title means that if there is more than one page with a similar or identical title, then it will be impossible to tell between them while selecting. The whole handling of internal links is disappointing compared to the handling of citation links and URL links, both of which are more sophisticated and can provide a much more readable document by overlaying the equivalent of the destination file title when not actively editing the link.

#### Tags vs Backlinks for Concept Groups
One of the most iportant parts of a Personal Knowledge Manager is the relationship between a note and the concepts it references or embodies. There seem to be two main ways this relationship is expressed in practice. _Tags_ and _Backlinks_.

With the _Tags_ approach, when a new concept is encountered, a tag name is chosen, and the new tag is added to the note being edited. This has the function of "tagging" this note with the concept, and by use of the "Tag Cloud" in the left sidebar a user can filter by particular tags to investigate which notes have those tags. When a new note wishes to refer to an existing concept, all that is needed is to mention the tag in the new note.

This approach has the advantage that it is easy and quick, but it also has some disadvantages:
* tags have no semantic content other than their name. This makes it difficult to elaborate on a concept by adding throughts, questions, references and so on.
* each tag must be unique and, for practicality, short. As the number of tags grows it can become increasingly difficult to choose a new tag name which both adequately expresses a concept and is sufficiently distinct from other tags. If tag names become too similar, there is a distinct chance of accidentally mis-tagging a note.
* tags apply to a whole note, regardless of where in the text they appear. While this is useful for finding the set of all notes which contain the tag, it still requires a user to search within the text for the one or more instances of the tag. Some Personal Knowledge Management tools allow internal linking to specific blocks of text.

With the _Backlinks_ aproach, when a new concept is encountered, a new note is created. This note is free to use the full range of ID, title, filename, and folder for identification and can contain arbitrary text, including further links and tags, and its own frontmatter. An internal link to the new note can then be added to the note being edited. When a new note wishes to refer to an existing concept, all that is needed is to create an internal link to the concept in the new note.

This has the function of showing a relationship between the note and the new "concept" note which may be navigated in either direction through the use of forward and backward links. This approach has the advantages that it can be deep and expressive, and there is less chance of name clashes than with tags, but it also has some disadvantages:
* the process for creating such a "concept note" is not as smooth as it could be, and it is significantly more cumbersome than simply adding a tag. In particular, there is a small but noticeable wait between creating a new note and being able to link to it.
* As with all internal links there is apossibility of name clashes when linking to similarly named files in different folders and the continuing debate about whether to link by ID or by title.
* Navigating backlinks uses the "Related Files" sidebar and lacks the potential power of the "Tag Cloud" for filtering based on combinations of such concept links.
* just like tags, backlinks apply to a whole note, regardless of where in the text they appear. While this is useful for finding the set of all notes which contain the link, it still requires a user to search within the text for the one or more instances of the link. Some Personal Knowledge Management tools allow internal linking to specific blocks of text.

#### Linking Conclusions
Linking is a vital concept in Zettlr but it is inconsistently implemented, with different forms of linking being capable of different things. It seems that the features and uses of the different types of links has grown up without strategic thought. There are gaps and inefficiencies which could be addressed.

Linking, its ease of use, and the readability of the results strongly affect the use of Zettlr as a Personal Knowledge Manager. If this is a priority area there is certainly room to:
* improve internal links by including some of the sophistication of URL and citation links
* include a much broader range of peers and potentially similar files in the "Related Files" sidebar
* improve the navigation of backlinks to provide equivalent power to the tag cloud when looking for combinations of concept links
* link to locations within files in addition to the whole file
* include a way of disambiguating links to similarly named files in different folders
* allow explicit linking to folders
* provide the user with more control in selecting which kinds of implicit links are visible in the "Related Files" sidebar
* make creating a new concept note (almost?) as simple as adding a tag

### Searching, Finding and Filtering
Zettlr provides a range of facilities for searching, finding and filtering, but as with other parts of the application, they have been inconsistently implemented, and not all features are available in all situations.

#### Finding files
On the left of the application there is a panel which usually contains a File Manager. By default, this displays all workspaces, folders and (markdown) files in the application. Workspaces and folders can be expanded or contracted to get them out of the way when navigating visually.

Finding a file using just the file manager is not always easy, as it relies on knowing which workspace and folder the file "lives in" and scanning the list of files in that folder for the file. The name shown for a file is not always easy to work out, though. Depending on Zettlr settings and the choice at the time the file was created the file manager might show a numeric ID, a combination numeric and textual filename, or a title derived from the content of the file. In an attempt to make this process easier, Zettlr also provides a filter box at the top of the file manager. Entering text into this box filters the file manager display to show only those files which match the filter. While this approach largely works, it also has some problems:
* file filtering is also not particularly intuitive. From rough experimentation, it seems to include both the raw filename and the displayed title in its filter so, for example when I was looking for a file titled `2020 To Do` and entered `2020` into the filter box it showed a lot more files than I was expecting. It turned out that it was also showing all files which I had created in 2020, and which therefore had a filename ID which started with those digits
* because this operation is a _filter_ rather than a _find_, it hides all non-matching files and their folders, so it is difficult to see the matched file in context. Many equivalent tools provide a _find_ operation which leaves the file manager as it is, but highlights matching files

#### Searching for files
Zettlr also provides a more powerful find operation (accessible by clicking a magnifying glass icon) which replaces the file manager with a search form allowing a user to search for a specified pattern either across the whole set of currently open workspaces, or limited to a particular folder. This is useful, but it also has its issues:
* the removal of the file manager means that the file is not shown in the context of its workspace and folder, so this search is useless for finding _where_ a file is.
* This search also matches against numeric ids found in files, so searches for numeric years have the same problem as the filename filter above
* The usability of the results is inconsistent. For example, if a _filename_ contains a match for the specified pattern, then a link is provided which can be clicked to open that file, however, if the match or matches are in the _content_, then there is no link to just open the file, you have to choose one of the matches, and click to go to that match, even if you want to (for example) edit the yaml metadata at the top of the file.
* As far as I can tell, this search is plain text only, with no option to search for regular expressions or other complex patters

#### Searching within files
While editing a file, Zettlr also provides yer another find tool. Ctrl/Cmd-F brings up a find/replace box in the corner of the editing panel. This behaves much more like a familiar search tool, and highlights matches within the current document (note: not _file_ as the search appears to be in memory and will find matches which may not have been saved back to disk yet). This tool _does_ include the ability to search for regular expressions, and also to replace matches either individually or all at once.

#### Searching, finding and filtering conclusions
Filtering, searching and finding in Zettlr is functional at a basic level but is inconsistent. If improving "findability" is important, then changes could include:
* extend the file manager to support _finding_ as well as _filtering_
* support regular expression matching across all the find and filter operations
* be smarter about matching numeric file ids to avoid unwanted clutter in results
* always provide a way to just open a file from the magnifying glass search

## Conclusions and Future Possibilities
Zettlr is a powerful piece of software which has a range of features and appears to be a different tool to different people. All of the different aspects of the system could benefit from further work, but prioritising and deciding on what to do is a significant challenge The future direction of the tool will be shaped by the relative priorities given to the different aspects of the software. Future directions could include:

### "Double Down" on one aspect and way of working
This approach would be relatively simple to do, as it would mainly involve deprecating or removing features which do not support the main use case, then concentrating on making that the best it can be. However, this would be very hard on existing users, particularly those who enjoy working with the software in a way which is not supported by the new vision. Deciding which aspect to prioritise would be a huge exercise in itself.

### Provide more visibility of the different aspects
This approach is somewhat safer than the others, but also less significant an improvement. It would involve analysing how actual users perceive and use the software, and enhancing the user interface (and adding operations where necessary) to make it more obvious, smooth, and useful for all the use cases. The challenge, much as it is now, would be the prioritisation of features in order to provide the maximum benefit for minimum effort, cost and time.

### Split the application into separate tools
This approach is similar in some ways to "double down".Fork the existing code base and set off separate projects to "double down" on different use cases, progressively diverging from the original vision. While superficially attractive, this would have all the problems known form attempts to fork software in the past such as incompatibilities and inconsistent bug fixes across variants.

### Split the application into "core" and "extension" components
In this model, the core of the application would include file and data management, relationships between objects with operations to find, filter, group, sort, organise and so on. The core of the system would by necessity be somewhat abstract, without the flavour of any particular usage, as it would need to support all the more specific use cases. Extension components would make use of the core facilities to implement the specific needs of particular ways of working. This could allow a broadening of the development effort by reducing the need to understand the whole application in order to make any changes, but it would be a significant (and possibly prohibitive) change to the existing application structure.

Note that this option does not necessarily imply a "plugin" style of architecture. The set of extension compoments could by open, allowing external plugins, or closed, limited to only the extension components supported by the original codebase.