MKDOCS - How to enable hyperlinks based on keywords found in the content? - plugins

I am using MkDocs, question I have is - I understand that within the documentation files I can say:
[My Link Name](My link URL)
But it's such a hustle when I want to change up my navigation or change up my keywords.
Can anyone suggest a plugin - At the point of building the documentation, automatically find keywords that would match up with keywords within the mkdocs.ymlfile and create a hyperlink to them.
Thanks in advance!

What you are describing, seems to be a primitive form of interwiki links. There is a plugin that you could use: markdown extra.
You could define your wikilinks, or wikilinks components in your mkdocs.yamlfile, like so, e.g.:
extra:
interwiki:
stackoverflow: stackoverflow.com/questions/
google: https://www.google.com/search?q=
Then you would use the "mustache" notation:
Please refer to the [question on StackOverflow]({{ interwiki.stackoverflow }}48173267)
Which would be equivalent to:
Please refer to the [question on StackOverflow](stackoverflow.com/questions/48173267)
I haven't tried it, but that would be the gist. Let me know.

Note that if all you want is to make links within a single web domain, MkDocs supports the standards extensions of python-markdown, hence also WikiLinks.
The syntax in the md file is a "double bracket":
Link to this [[full description]]
Which would become => https://your.website.com/foo/bar/full_description.html
According to the documentation, what you would have to do, is to specify in your mkdocs.yml file:
markdown_extensions:
- wikilinks:
- base_url: https://your.website.com/foo/bar/
- end_url: .html
Disclaimer: I haven't tried it yet, so anyone who has is welcome to correct me.

There's a simple way to add wikilinks to mkdocs by using the mkdocs-ezlinks-plugin.
Install the plugin:
pip3 install mkdocs-ezlinks-plugin
note that your OS may prefer pip instead of pip3
Add the following to mkdocs.yml:
plugins:
- search
- ezlinks:
wikilinks: true
The plugin does some really nice translation of links and searches the document tree for matching titles.
Link
Translation
[[Page Name]]
[Page Name](../folder2/page-name.md)
![[Puppy]]
![Puppy](../images/puppy.png)
[[Page Name|Link Text]]
[Link Text](../folder2/page-name.md)
[[Page Name#Section Heading|Link Text]]
[Link Text](../folder2/page-name.md#section-heading)

Related

How to make a Pod link from a module to a script within the same distribution?

Consider this module App::TimeTracker. If you click on the tracker link in the SYNOPSIS section you end up here whereas you should have ended up here. The Pod source code responsible for the behavior is given here, which shows that the following Pod formatting code was used:
L<tracker>
I can fix the problem by providing an absolute link instead:
L<tracker|https://metacpan.org/pod/release/DOMM/App-TimeTracker-3.000/bin/tracker>
but this fixes the link to version 3.000 which may change in the future.
So how should this be done in general?
Use the full path without the version number: https://metacpan.org/pod/distribution/App-TimeTracker/bin/tracker.
The problem is that tracker_bash_autocomplete is not being indexed correctly as documentation by MetaCPAN. The NAME section has a very specific format based on manpages which must be adhered to for MetaCPAN to know how to link to your documentation. Putting tracker bash autocomplete before the hyphen makes MetaCPAN index it as tracker.
=head1 NAME
tracker_bash_autocomplete - whatever

Use equivalent of InterWiki links in doxygen documentation markup

Some of my doxygen documentation need to refer to pages in the
company's wiki. I would prefer if these references resulted in working
hypertext links in the generated documentation. I could of course
achieve this by writing:
/// Name of page
or alternatively using Markdown syntax:
/// [Name of wiki page](http://long-URL.com/wiki/index.php?Name-of-page)
Unfortunately I have to give the full URL at every link in both cases,
and when (as has already happened) the base URL of our company/wiki
changes, all the URLs needs updating.
I therefore wonder if Doxygen has some support to avoid having to
hardcode the entire URL at every link?
For comparison, wikis use "InterMap" or "InterWiki", to define
prefixes that allow a shorthand notation for quickly referring to pages
on another web site. Example:
See WikiPedia:InterWiki_Links for more details.
So if possible I would like to let the Doxygen documentation contain
something like:
// See CompanyWiki:Name_of_wiki_page for bla bla
Some references:
Automatic link generation - http://www.doxygen.nl/manual/autolink.html
InterWiki - https://www.mediawiki.org/wiki/Manual:Interwiki
PmWiki/InterMap - http://www.pmwiki.org/wiki/PmWiki/InterMap
You could define an alias in the config file:
ALIASES += WikiPedia{2}="\2"
and then use it in your comments like so
See \WikiPedia{InterWiki_Links,Interwiki Links} for more details.
See also http://www.doxygen.org/manual/custcmd.html for more info.

Is there a detailed documentation on how to create own jsdoc templates?

Short version:
If I wanted to develop a completely new jsDoc template from scratch, what would I have to read to understand what jsDoc does, what interface my template must provide and what data I get to work with?
Long version:
I've been using jsDoc for a while now and have come across some tags that I would like to add and overview pages that I would like to have generated out of my documentation. Up to now I solved all my "user problems" with usejsdoc.org. I even managed to add a new jsdoc plugin that adds some tags. However, I can't find any developer documentation on how to create templates for jsdoc. I use ink-docstrap so I clicked my way through the template-folder (publish.js, /tmpl, etc.) and somehow got the idea of how everything works. But its very very time consuming.
What should I read to become a jsDoc template pro?
These instructions are the closest I could find:
To create or use your own template:
Create a folder with the same name as your template (for example, mycooltemplate).
Within the template folder, create a file named publish.js. This file must be a CommonJS module that exports a method named publish.
For example:
/** #module publish */
/**
* Generate documentation output.
*
* #param {TAFFY} data - A TaffyDB collection representing
* all the symbols documented in your code.
* #param {object} opts - An object with options information.
*/
exports.publish = function(data, opts) {
// do stuff here to generate your output files
};
To invoke JSDoc 3 with your own template, use the -t command line option, and specify the path to your template folder:
./jsdoc mycode.js -t /path/to/mycooltemplate
Failing that, you can read the source code!
I am running into a similar difficulty with lack of documentation. There is a GitHub issue that has been open for 7 years on this: Provide docs that explain how templates work.
The only example I've found so far of a custom template that doesn't look like just a modified version of the default is Ramda's documentation. It looks like they use a completely custom publish.js script that uses handlebars.js instead of underscore.js templates, constructs a non-hierarchical nav, pulls info from #sig and #category tags, and uses links to github for 'view source' instead of rendering its own html pages for source code.
Some of their code will be difficult to understand unless you are familiar with Ramda and functional programming (they use Ramda itself in their version of publish.js) but dumping out the values of data and docs during execution should help provide insight into what is going on.
It is helpful as well that their template is a single file so you don't have to jump between a lot of partial template files to follow how the doc is constructed.
I've just published my own new jsdoc theme. What I did is I simply copied the default template: https://github.com/jsdoc3/jsdoc/tree/master/templates/default, and worked on that.
I also managed to add grunt with the following features:
* transcompile + minify js files
* parse sass styles and minify them
* refresh the docs when you change something
You can see how it works here: https://github.com/SoftwareBrothers/better-docs
you can customize one of existing templates (default, haruki or silent):
go into node_modules/jsdoc/template and grab on of them into your app directory outside node_modules.
feel free to rename the dir ex: jsdoc-template.
open jsdoc-template update/customize the content as you want. ex: open publish.js find Home and replace My Js App.
update jsdoc.json by adding:
"opts": {
"template": "jsdoc-template"
}
another option to use one of those templates too: jsdoc3 template list examples
Followup to my previous comment about Ramda's JSDoc template. I've since created a customized version of it and published it on GitHub at https://github.com/eluv-io/elv-ramdoc
This is tailored for my company's projects, but it may be helpful as another learning tool. It adds a 'Show private' checkbox, updates Bootstrap to v5.13, replaces Handlebars with Pug, adds JSDoc comments to the publish.js script itself, and supports setting an environment variable to dump data to console during doc generation.

Including reference links in markdown as bullet point list on GitHub

Currently I'm using this markdown text inside the README.md file of a project on GitHub:
See the docs of [testthat][3] on how to write unit tests.
Links
-----
- http://www.rstudio.com/products/rpackages/devtools/
- https://github.com/hadley/testthat
- http://r-pkgs.had.co.nz/tests.html
---
[1]: http://www.rstudio.com/products/rpackages/devtools/
[2]: https://github.com/hadley/testthat
[3]: http://r-pkgs.had.co.nz/tests.html
I don't like this duplication, but I don't see what choice I have. If I remove the explicit bullet point lists, then GitHub won't display the reference links. If I remove the reference links, then GitHub shows the bullet point list (of course), but the embedded links like "testthat" above don't work.
Is there a better way than duplicating? What am I missing?
Inspired by #mb21, I suppose this would be the right way to do it:
See the docs of [testthat][2] on how to write unit tests.
Links
-----
- [RStudio Devtools][1]
- [testthat][2]
- [More unit test examples][3]
[1]: https://stackoverflow.com/users/214446/mb21
[2]: https://github.com/hadley/testthat
[3]: http://r-pkgs.had.co.nz/tests.html
That is, it's not a good practice to include links verbatim and without a meaningful title. I should keep the link URLs only in the reference links section at the bottom, and in the bullet point list use meaningful titles.
When you view this on GitHub, the URLs shouldn't really matter, and if you really want to know you can move the mouse over. When you view this in plain text, now the links have meaningful titles, which is useful additional information about the URLs.
I'd write that as follows:
See the docs of [testthat][1] on how to write unit tests.
Links
-----
- [RStudio Devtools](http://www.rstudio.com/products/rpackages/devtools/)
- [Testthat](https://github.com/hadley/testthat)
- [Tests][1]
[1]: http://r-pkgs.had.co.nz/tests.html
Did that answer your question? If not, you'll have to clarify it.
An answer from 8 years in the future!
The answer to your question will depend on what your Markdown parser supports. Nowadays, most parsers support CommonMark (plus some flavouring). However, don't take this for granted and double check it. If CommonMark is not supported, try using the "vanilla" Markdown syntax as described below. Just be aware that the "vanilla" Markdown specification is flawed and may result in broken links (by design, almost).
Using CommonMark
If you can guarantee that your Markdown parser supports CommonMark, then you can do it in a simple way:
Writing unit tests is explained in the [Unit Testing] website
[Unit Testing]: https://unittesting.somedomain.com
In the Links section of the CommonMark specification (currently at version 0.30) you see that a "link" is composed of a link text, link destination and a title and each one has its own syntax and quirks. For example, if the link destination contains spaces, you need to wrap it in <angled brackets>, or if your link text is some kind of code, you're allowed to write
[`AwesomeClass`](<../docs/awesome class.md>]
Note:
In this section I am using the CommonMark syntax, so you can click the
"Edit" button to see the syntax that I used for a "real" example.
Using vanilla Markdown
The vanilla Markdown specification simply requires an extra set of angled brackets with nothing in between, as described in the links section.
Writing unit tests is explained in the [Unit Testing][] website
[Unit Testing]: https://unittesting.somedomain.com
Note
And in this section I've only used vanilla Markdown syntax. Stack Overflow's Markdown parser supports both CommonMark and vanilla Markdown. This is not by accident, since CommonMark intends to be compatible with the original specification (wherever possible!). Stack Overflow do state that they use the CommonMark spec in their Markdown help page.
Tl;dr
See the docs of [`testthat`] on how to write unit tests.
Links
-----
- [RT Studio dev tools]
- [`testthat`]
- [R Packages]
---
[RT Studio dev tools]: http://www.rstudio.com/products/rpackages/devtools/
[`testthat`]: https://github.com/hadley/testthat
[R Packages]: http://r-pkgs.had.co.nz/tests.html

Replace éàçè... with equivalent "eace" In GWT

I tried
s=Normalizer.normalize(s, Normalizer.Form.NFD).replaceAll("[^\\p{ASCII}]", "");
But it seems that GWT API doesn't provide such fonction.
I tried also :
s=s.replace("é",e);
But it doesn't work either
The scenario is I'am trying to générate token from the clicked Widget's text for the history management
You can take ASCII folding filter from Lucene and add to your project. You can just take foldToASCII() method from ASCIIFoldingFilter (the method does not have any dependencies). There is also a patch in Jira that has a full class for that without any dependencies - see here. It should be compiled by GWT without any problems. License should be also OK, since it is Apache License, but don't quote me on it - you should ask a real lawyer.
#okrasz, the foldToASCII() worked but I found a shorter one Transform a String to URL standard String in Java