-
Notifications
You must be signed in to change notification settings - Fork 1
GitHub wiki is a pain
It hurts me that I find it a pain to use the GitHub wiki.
- I've been a wiki user and evangelist since 1996 - the first public wiki was March 1995 https://en.wikipedia.org/wiki/Ward_Cunningham
- I think that the wiki approach can solve many problems, with suitable extensions
- I have evangelized wikis at every company I've ever worked for, inside every project. I have used far too many different wiki engines.
- ...
But try as I might, whenever I try to use it I get frustrated and then give up for a few months.
This page to try to figure out why I find the GitHub wiki so frustrating.
Probably most of these things I complain about about the GitHub wiki are generic to many other wikis. Nevertheless, some value in collecting them here, as I bang my head against them. If nothing else, shows me what my current hot buttons are, and helps prioritize if I ever have enough copious free time to fix these issues.
Overall: Github wiki is such a good example of bad wiki behavior that it is almost unfair
It is possible that a large part of my frustration with the GitHub wiki arises because now, in 2022, I am using speech recognition as much as possible, whereas in the past, certainly 1996, I was a classic UNIX emacs keyboard X Windows maven. of course, such excessive keyboard pounding, stretching for modifier keys, and reaching for mouse is a large part of why I have bad computeritis and am now attempting to emphasize speech recognition more and more to reduce the physical pain.
Editing wiki pages in a typical web browser interface to the GitHub wiki is not very speech friendly. In large part because most web browsers are not very speech friendly - neither Chrome, nor Edge, nor Firefox ... and it is not so much the web browser per say, as the text editor inside the GitHub wiki used to edit pages online. ideally a speech recognition system such as Dragon would control the computer by sending commands, but failing that most applications are controlled by emulating keyboard and mouse events. And the GitHub wiki web page editor does not really have many keyboard shortcuts. it seems mostly to be designed to be used by mouse clicking, and mouse clicking leads to very unreliable speech control.
I don't think it is just a question of me not having written appropriate speech commands for the GitHub wiki. The usual ways that I write speech commands for applications do not seem to be available. Poor keyboard control ==> hard to automate.
TBD: Maybe JavaScript? But Firefox security models have been breaking many extensions.
TBD: it may be better to try to edit the GitHub wiki online using a web browser inside emacs, which has a real command system and a real programming language.
More and more I paste bitmap screenshots. I do not want to have to create a separate page and then link the image.
In this I have been spoiled by Atlassian Confluence and Microsoft OneNote
Much of what I post to the wiki refers to other pages. usually I want pretty links, nice display text hiding the ugly URL.
Microsoft OneNote has spoiled me, because it automatically attaches a link to text copied from one webpage and pasted into OneNote. Much faster than 1st copying the text, then copying the link, then updating the display...
TBD: This might be something that I can just automate myself. TBD: paste with auto-linking
- Write a speech command (or other automation such as AutoHotKey) that looks at the metadata in the clipboard, and automatically creates the appropriate links when pasting.
- This would be generic, not just for the GitHub wiki and any particular web browser.
Again, spoiled by Confluence and OneNote:
while it is nice to be able to have a strictly textual representation of table that can be easily generated by scripts
it is also nice to just be able to do something like WYSIWYG editing for table in rows and columns
...
Again, I'm spoiled by OneNote and Confluence.
It sucks that when you rename a page in the GitHub wiki all the referrers need to be updated
TBD: less painful when I do it off-line inside emacs
Note: renaming when off-line disconnect or partitioned is IMHO now an almost solved problem. but of course, almost nobody solves it, although Confluence comes closest AFAIK.
Auto linking URLs, hiding the ugly parts: http://ugly.net/blah-blah/nice-part --> [nice-part]
Auto linking case sensitive or not: The [capitalization] inside text is often not the capitalization you want when that phrase becomes a page name --> [Capitalization].
Auto linking plural or not [Foobars] --> [Foobar]
TBD: while it might be nice to have a link [Foobars] automatically linked to [Foobar], it may not be necessary 1. if there is support at link creation time to suggest links 2. and renaming support
---
Home - top of HFIM-BS wiki, including Topics. • Incoming, Catch All, not yet Organized Content.