A specific community for original shortform and longform writing, stories, worldbuilding, and other stuff of that nature.
Subcommunity of Creative
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
Honestly, I write virtually everything as markdown in Vim. The only time I get out of that is when I have very specific formatting requirements and I don't feel like messing with LaTeX or I need to submit a Word document.
Plain text is superior due to lack of dependencies. π
I have yet to ascend to the plane of full-time CLI editor use, at least for writing natural language I'm still hooked on the GUI for two reasons: one, I'm still faster at using the mouse to seek to where I want to start an edit, and two, I like visually diffing the current section of whatever I'm editing with previous versions. The former I know I could be faster if I practiced at it because I've seen people blaze through edits in vim, the latter I'm not sure how I would accomplish in vim.
You can set git's difftool to vimdiff. That is admittedly outside of the current editing session, though.
You could set up a script to automatically commit changes (if present) every X minutes. That way you would generate automatic document history without having to care the commit comments. Git is mighty versatile, but you don't have to use all of its features.
I like using commit messages as a a little built-in editor's log; I'm hopeful that in time I'll be able to review the history on a particular poem and see something interesting about the types of edits or editorial choices I make over time. I have a really hard time writing good commit messages for poetry as opposed to code, a lot of the times it's "changed word choice in XXX" or something like that but I want to improve on that. Not really sure what a "good" poetry commit message is but I figure I'll know it when I see it. Or maybe I'll just see a natural trend as my writing matures. But now that the poems are in git, git is part of the medium and the commits are part of the art, and I want to be thoughtful about them. I've always wanted to see the commit history for novels I've read and, if I ever publish my own work (and if I'm brave enough) I want to publish my git repo alongside the finished work.
Interesting thoughts. Thanks for sharing them. I assumed that you would want to have file versioning out of the way and focus on the writing. What about keeping a sort of change log (diary, if you want) as part of the document itself, like an appendix? That way you could maybe separate raw document history from the creative process.
Git is a technical tool intended for versioning sharing, manipulating and comparing pieces of code. I'm not sure that you need all those aspects for literary work. I imagine that writing a poem is more linear in the sense that you won't merge a poem branch back to the "main" version of the poem. At least not in the way you would do it with code. You will also probably not submit or accept patches to the poem. So maybe the commit messages are not necessarily the best place to keep "creative metadata" about the content.
Just some random thoughts. I guess that you'll have to try and see what method fits your creative process best (the natural trend you mentioned). Good luck!
For writing i use Obsidian with the git plugin.
I want to give Obsidian a real try. I have seen it around but never used it, because it seems really complicated to operate and I haven't felt like I have the brainpower to really get my head around it, but it looks interesting. Do you use the concept graph and all the other stuff or do you use it more as a plain old editor?
You can start using it as a plain editor, and wait with the plugins until you are more comfortable with the tool. You don't have to go all in at once.
Iβm surprised no one mentioned emacs. Iβve not done much with version control lately but back when I was coding at a day job, emacs was king. All the important version control functions are mapped to key bindings and macros.
Emacs functions graphically with a mouse for novices, which makes it good for starting off. Then as you get more advanced you memorise bindings for frequent functions so the mouse slows you down less and less. The default keybindings in emacs have become ubiquitous so e.g. many of the emacs bindings work in BASH and other apps. So when you learn emacs, your knowledge becomes portable outside of emacs.
A lot of the same can be said for vi variants. But thatβs mostly it. Editors other than emacs and vi are isolated and less powerful -- though Iβve not really looked hard outside of emacs lately so things may have changed.
I am too, now that you mention it. I started using vim early in my career because my team lead used it, and I never really had occasion to switch to emacs as I usually used a graphical IDE for most development work, and vim was mostly for editing individual files. Might have to give it a spin.
My source is reStructuredText, so I've found that Sublime Text is enough.
I haven't used Sublime in years, might give it another go. my source is all .md files even though hardly any of them have any markdown formatting besides the occasional bulleted list, but I like having the option to do some light formatting if I want. I think what I'll most likely do is find (or in the most dire case, make) plugins for whatever editor I land on to make writing easier. The problem I tend to face is that most editors have too many features and options and they are built for a slightly different purpose (writing code vs writing prose) which makes them just different enough to be irritating.
When I write prose I tend to ignore most options. Sublime has a "no distractions" mode but I hardly use it.
@queerlilhayseed At works, documentation is in LaTeX under version control.
The few document I have under version control at home are all LibreOffice flat XML files (fodt etc), which are text and diffable.
Do you use the LibreOffice GUI to edit the documents? if so can you diff in the editor or do you use something else? LO feels heavy for what I'm doing but if it has an easy path to diff the current text with the current commit and/or review the document's git history... that would be cool.