Zettlr: Feature: Code Folding

Created on 18 Oct 2018  Â·  7Comments  Â·  Source: Zettlr/Zettlr

I've recently discovered Zettlr, and I'm trying to use it to organize multiple, dispersed files I have into an academic book, i.e. to use Zettlr rather like Scrivener. I love the concept and what has been achieved so far with your project. One issue I've encountered at the outset: I need to rework articles and book chapters that have endnotes, and I want to work on different sections of these documents as different markdown files in a project folder, while keeping the references in a separate file in the same folder. This currently works when compiling the project to a PDF (although the endnotes all become footnotes) but of course the tooltip is empty, and it's not possible to export just a section, say, to Word with its endnotes/footnotes.

Regarding the tooltip, I'm guessing it would be relatively simple -- a case of adding some code at https://github.com/Zettlr/Zettlr/blob/develop/source/renderer/zettlr-editor.js#L545 to search the contents of a specified file for the reference note. The filename pattern would ideally need to be user-specified, as it is language dependent (e.g., I might want a filename matching /#\d+.?references/i in English, but /#\d+.?referencias/i in Spanish, or I might want /\d+.endnotes/i).

Regarding exporting a document section with notes from the references file, I imagine it's a little more complicated and would be a separate but related issue.

By the way, as an academic working in the arts (with some knowledge of JS coding), the subtle reference to Rancière on the Zettlr home page brought a smile to my face :-) .

feature

Most helpful comment

Next version has code folding!

All 7 comments

Hey @Jaifroid,

I had to search a little bit where I've put the Rancière reference =D

However, to your idea: I see the benefits of this, yet, unfortunately, it wouldn't be as simple as adding some code in the ZettlrEditor-class, b/c referencing footnotes (and, of course, editing them) would require communication with the main process, always opening the file, searching for the reference text and, in case, update it.

It may work with ZettlrProjects (otherwise there would be a lot of contingency which Zettlr would've to account for), but I'm not quite sure.

The recommended way is still to leave the footnotes inside the chapter-file you've been working on, because then you'd have the following benefits:

  1. It's easy to create and edit footnotes, because the code wouldn't need to be changed.
  2. If you export all files into one big PDF using the Project feature, the footnotes would be combined and one could choose to create footnotes, endnotes per section or endnotes for the whole book. (This selection is currently hard-coded to the internal LaTeX-template, but it should be easy to add an option to this)
  3. You could still export a single chapter and have the notes with it.

The only thing that needed to change in the code (and this is something I have to do pretty quick) is to correctly number the footnotes on export (otherwise you'd have a footnote number 1 for each file, which would confuse Pandoc). This is not done currently, because I've had massive problems reordering the footnotes in the past.

Would this be a feasible approach? Or are there other benefits to a separate references file that I do not see?

Cheers!

OK, thanks for the reply :-) The main reason I felt I needed something like this is that I'm trying to divide already written markdown articles with endnotes into sections based on the ## marker, without having to sort out which endnotes belong to which chunk (which will slow me down considerably). However, I can see now that there are larger issues than I had considered surrounding reference management.

I think what I really need is some sort of virtual splitting of a chapter-length document at a predefined header depth. Under the hood, the document remains whole, but what I see are the chunks that I can re-arrange and rewrite by dragging and dropping them around, inserting new ones, etc., with endnotes being dynamically renumbered across the document. In the meantime I'll follow your approach, for which many thanks.

Feel free to close this issue or change its title to reflect any valid issues. Alternatively, I'd be happy to make separate issues for: a) dynamic reference numbering; b) the concept of virtually splitting a document, or having different "views" of a document (whole, split by second-level-header, etc.).

I think what I really need is some sort of virtual splitting of a chapter-length document at a predefined header depth.

Maybe, what you might need is Code Folding, see a demo here: https://codemirror.net/demo/folding.html

I've wanted to implement it when I have time, so it'll come. This way you could keep your documents together. Also, to _actually_ split the document, I've also planned to introduce batch editing, which would allow for exactly what you want to do.

Therefore I'll rename the issue to code folding! Hope that's also in your interest :)

That definitely sounds like a good idea and an interesting solution. Code folding does make it easy to move whole sections around in code editors.

Batch editing sounds great. I'm sure you're aware of Scrivener's "corkboard" solution, which allows a very intuitive re-arranging of chunks of written text -- anything that can be as intuitive for re-arranging "chunks" would be great. Zettlr would somehow need to keep track of the intended order for chunks. It currently uses the filesystem ordering, which is alphabetical, so requires a rigid numbering of file "chunks" or batches.

With both solutions there still may be an issue around dynamic renumbering of footnotes/endnotes, but I guess that's now a separate but related issue.

I'm sure you're aware of Scrivener's "corkboard" solution […]

Actually not, I was always more of a Ulysses type. I never got the way scrivener did things …

Zettlr would somehow need to keep track of the intended order for chunks. It currently uses the filesystem ordering, which is alphabetical, so requires a rigid numbering of file "chunks" or batches.

I think here we're touching on one of the basic design decisions of Zettlr :S When I stopped using Ulysses, I found out that there were _a lot_ of files made by Ulysses that cluttered all my folders, because these were the files needed for stuff like manual arranging, etc. As I intend Zettlr to be as unintrusive as possible, even the small .ztr-project and .ztr-virtual-directory-files sometimes feel unwelcoming. On the other hand, using a database for this is also not a good idea because then you'd directly run into the problem of how to sync this between computers.

Therefore I'd say that while the idea is definitely great, it comes at a cost of portability between different systems and would be intrusive into your files. And I don't think Zettlr should be that intrusive.

Besides, when you say:

It currently uses the filesystem ordering, which is alphabetical, so requires a rigid numbering of file "chunks" or batches.

This is actually by purpose, because this way you are forced to keep a rigid numbering of these files (a.k.a. chunks/batches). This may be inconvenient at first, but once you get a grip upon what is possible and what not, you won't notice anymore that you are actually paying attention to how you name files. Additionally, this way you can not only be sure that Zettlr shows the files correctly ordered, but that your filesystem, and any other you may be using, as well.

This way, the "immersive" element of Zettlr is not so much about moving files individually, but that it integrates with your operating system, and, if you are using a smartphone to browse your files while you're on the road, you can immediately tell where a file is because all of these apps filter the files using the same ruleset!

It is in this way that I would propose that I do not introduce manual arranging, as this would mean to further pollute your file system and would prevent you from using all the apps you want to view all your files where you want, and instead stick with the code folding, which is a good compromise, I think.

OK, thanks, I'm new to Zettlr, so only just learning its philosophy. I see the advantage of using the filesystem for ordering. It does mean some self-discipline... ;-)

Next version has code folding!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

grst picture grst  Â·  4Comments

volt4ire picture volt4ire  Â·  4Comments

klaus7 picture klaus7  Â·  4Comments

tupio picture tupio  Â·  3Comments

Alopex4 picture Alopex4  Â·  4Comments