[[!meta title="(Un)entangling projects and repos"]] [[!meta copyright="Copyright © 2023 Alexey Bochkarev"]] [[!inline pages="internal(2023/info/unentangling-nav)" raw="yes"]] # (Un)entangling projects and repos Alexey Bochkarev (he/him) - , @bochkarev@qoto.org (Mastodon) [[!inline pages="internal(2023/info/unentangling-before)" raw="yes"]] Emacs provides a few excellent tools for working on projects through all their key stages. Orgmode is great for brainstorming, structuring and maintaining TODO lists, tracking time, organizing notes, and writing memos or reports. Many major modes help writing code, magit makes version control almost frictionless, and projectile helps with project management and navigation. However, I found a few situations when I wanted to separate the concepts of "project" and "source storage" (say, having a few version control repositories associated with a single "generalized project"). In this talk, I would like: 1. to describe a specific example of such situation, 2. discuss a workflow aimed at managing such "generalized" projects and present my solution, based on a very simple ELisp "glue" on top of the functionality provided by package projectile. For example, consider a research project (think: applied mathematics with a heavy part of computational experiments). It might consist of: - The ``paper'' draft: some sort of final report source, usually in LaTeX format, or orgmode exported to PDF via LaTeX. Version controlled by git. - Numerical experiments: a separate folder, or even a separate git repo. Contains the source code for numerical experiments and the related technical documentation. Will be published along with the paper. - A collection of intermediate memos (notes) sent to collaborators. - A collection of "raw" notes (lab journal), regarding what did I try and especially what did NOT work and in which ways. This setting raises a few problems that all boil down to the necessity of having an easily accessible private notes file(s) associated with a few repositories at the same time outside of these repos. This way one can: - Maintain more granular project structure and TODOs while still having more concise TODO lists for the colleagues on a per-repository basis. - Maintain (project-specific) private technical notes, and maybe a full lab journal both describing the "big picture" of the project and containing the technical information. - Keep time tracking data private and outside of the source repositories, - Capture thoughts and TODOs to a single place from across a few specific repositories. I propose to solve this problem by associating a single "notes folder" and a main `.org` file to each repository using the standard mechanism of directory-local variables on top of what is already provided by projectile package. # Discussion ## Questions and answers - Q: Do you use these unentangling techniques in a blog or hosting a zettelkasten? - A: Well, I try to keep my "private notes" in something that might qualify as a Zettelkasten, yes. I wouldn't say I 'host' it --- it's not online. But yes, the whole point is that these "private" notes are interconnected in a Zettelkasten-y way (using org-roam package) - Denote notes Silo features might be useful with your workflow - - oh, thanks --- I'll have a look! - Q: What is the biggest unhappiness you haven't figured out for your current workflow? - A: Maybe I am still on the fence re: where do I structure my TODOs and clock time. I tried to play around with the idea that I structure the work in a repo, and then when I "clock in" it saves time to a separate notes file instead... but it seemed a little too complicated, to my taste. - I feel that the time tracking also kind of annoying, especially you forgot to clock on and all the things mess up. So right now I'm just using a Pomodoro technique, 25 minutes, done, rest, 25 minutes, rest, and kind of repeating that. And I'm quite happy with that. - wait, what's that? 'org-pomodoro'?. sounds interesting... - It's not, you know, special for Org Mode. It's kind of a general technique which you focus on a small task for just 25 minutes, but at the time you're super focused, 100% focused, and after that five minutes you rest, and you're kind of repeating these patterns over long sections. You can do four, five, six of those sections, and it helps me to focus over relateive long time. - I also feel this might be something really useful. Just haven't found a way to incorporate it into my workflow - for me it's quite simple is I can just use a simple stopwatch that every 25 minutes stop and reminde me  a rest. I believe there's a lot of fancy clock specialized on this this type of technique it's at the core of this concept is really not a complex idea. - wait, I'm confused. So, that's outside Emacs right? :-) - Yes, the concept is outside of Emacs, but I saw people using this package. Let me search,: <-- yeah, that one. Maybe I'll have a look, thanks! - Yeah, it's, again, if you're familiar with the sports, it's kind of making your long hard working, breaking into a small section, but I feel it's, you have more kind of energy over a long term, yeah. - I like Using a weekly GTD log files for my TODO. That way I can look back at them and not have my GTD to big. I like to pull daily tasks from agenda - and what do you do to transfer stuff between the weeks --- a manual review?  - Q: Do you use project.el features as well, or just projectile.el ones? - A: Ugh. OK, I am at that point where I am not sure any more ;) it is pretty well integrated to my Doom Emacs, so I am not sure which one is that... ## Notes - GNU Hyperbole already supports this with directory-specific quick access button files (which can be Org files).  These can connect to any number and type of document artifacts, including projects, repos, directories, etc.  You don't need to put any code in dir-locals either.  The directory/project-specific tags jumping (automatically selecting appropriate TAGS files) is also built-in. Have a look. - Yes, there's clearly a few ways to achieve this. I have a feeling Hyperbole achieves this, and much more. I wanted to have something simpler, somehow.   (Yes, you seem to have some very efficient techniques down; maybe you could utilize both).  Thanks for the talk, it was good. Thanks for the suggestion, tho! [[!inline pages="internal(2023/info/unentangling-after)" raw="yes"]] [[!inline pages="internal(2023/info/unentangling-nav)" raw="yes"]]