Just discovered 'presenterm' and have to try it out. I like #terminal and #Rust, so I might need it sometime. The nice thing about this #RustLang solution is that it uses #markdown and I also like this a lot to create #documentation and #presentation.
When you sit down to write, it's all too common to become distracted. While we can't disable notification center and sounds from other applications, DEVONthink can provide a more minimalistic view in which to write. #devonthink#workflow#markdown#writing#focushttps://buff.ly/4c7w4LI
1/2 Speaking of writing articles, this from Paul Scanlon (one of the folks I edit at @TheNewStack) is a good conversation starter: "why a CMS over a file based markdown solution for long form content?"
Paul and I have been emailing back and forth about this. I use #Markdown for my Eleventy site and am fine with it; I usually enter my posts into the Bear app and then copy the MD file over to VS Code to finalize the images, etc. But most content people need and want a WYSIWYG #CMS.
Anyone can recommend personal #wiki engine / notetaking with sync that has first-class #markdown support and can be easily edited on PC (#linux, #windows) and #iphone ? I don't really want #obsidian as it requires subscription that is comparable to e.g. #notion
I love #presenter by @ia, but I think the documentation for creating custom themes could be improved. So I went ahead and did just that, hoping that it'll help someone to get started:
OCR, autobackup, text color, evernote links -- all's new in Joplin 2.14
🔤 Autodetect text in pics and pdfs (#ocr) + search
🖌️ Text color in Rich text editor
💾 Rotating auto #backup - now bundled out of the box
🔗 Auto restoration of #evernote note links
📂 Import a directory of #ENEX files
💪 #Markdown editor upgrade
Short codes in #Hugo make your #MarkDown files much cleaner, but you are essentially locking yourself in a specific static site generator.
If you use a lot of them and in the future you decide to migrate your content to something else (like I recently did from #Pelican ) good luck with that.
Hugo uses Markdown to create the content, which is then parsed into static HTML. One of the features of Markdown are quotes. Multiline quotes (block quotes) are possible, but they are not very intuitive.
Make API documentation comments easier to write and easier to read in source form by introducing the ability to use Markdown syntax in documentation comments, alongside HTML elements and JavaDoc tags.
Do not adversely affect the interpretation of existing documentation comments.
Extend the Compiler Tree API to enable other tools that analyze documentation comments to handle Markdown content in those comments.
Non-Goals:
It is not a goal to enable automated conversion of existing documentation comments to Markdown syntax."
Tiny reminder of my small blog engine serving Markdown files that has all the "no-AI" tags possible to protect your writings from exploitation for shareholders profits :Blobhaj_Ani_Hearts:
Mac users who write files in Markdown format: a lot of people know this already, but FYI, there's a free and very useful Quick Look plugin for the Finder that will display previews of Markdown files. It's handy when looking at folders in the Finder – just move the cursor to the file and press the space key to pop-up a formatted preview.
#TechnicalWriting#DITA#Markdown#SoftwareDocumentation: "Moving from DITA (Darwin Information Typing Architecture) to Markdown for technical documentation involves weighing several benefits and risks, which are pertinent to the specific needs and workflow of technical writers
While Markdown offers notable advantages in terms of productivity, collaboration, and alignment with modern development workflows, it also presents significant challenges in content structure, scalability, and feature richness.
Technical writers must be prepared to navigate the less-structured environment of Markdown and may need to employ additional tools and practices to compensate for the loss of certain key capabilities inherent in DITA’s more complex system.
The decision to transition should therefore be made with a thorough understanding of these trade-offs and an assessment of the specific needs of the documentation project.
@weirdwriter@pixelate@halisonjl@weirdwriter, that article is a fantastic resource! Please do continue to keep it up to date with your discoveries. If I had found it earlier it could have saved me work discovering things on my own - then again, I do like figuring things out so I might have done the same anyway, just with a better start point.
When I was considering my options for tools to (re)learn to use after my vision loss my primary focus was on regaining my ability to write code instead of documents as that was more central to the type of work I did at the time. While I found learning to use #VSCode effectively with a screen reader to be a very frustrating and time-consuming process, it made sense at the time, and proved well worth it to me in the long run. After (re)learning to use it to code, discovering I could use it for #markdown as well was a very nice bonus. It is very web app like and can be very difficult to use with a screen reader without learning a library worth of hotkeys/key-binding/keyboard-shortcuts. If I had not already needed to learn them for coding, I don't know that I would have tried for writing documents alone. I have been consider switching to #vscodium. Less telemetry definitely appeals to me.
Thanks again for referencing that article! I'll definitely be giving it a follow.