Links to Nim methods include the name of the method, as well as the type of all
arguments:
This is needed to disambiguate methods that have the same name, but different
sets of arguments. However I find the result pretty verbose. Compare with D
language:
Compare with D language:
That's a terrible style of generating links IMO. Tomorrow if a new replace is documented above the first one, the original first replace will now have #1 link instead of #0 now.
The links will keep on moving with such changes.
That issue is averted by how Nim linkifies things.
and if two types have same first letter?
I could work up an algorithm if people are open to it.
What's the benefit of shorter links?
I like the readable types in the links as we have right now. With the type acronyms, the links will get a bit shorter but then they will look gibberish.
Also, I believe it would need some maintenance to keep the algorithm always working to meet some signature that we haven't seen yet. And then when the algorithm is updated to support that, there's a risk that the links generated by the previous algorithm are now all changed.
I'm saying so because I heavily use the Nim doc links in my notes: https://scripter.co/notes/nim/
@kaushalmodi what about middle ground, something like this:
~
http://nim-lang.github.io/Nim/strutils#split-str-str-int
http://nim-lang.github.io/Nim/strutils#split-str-set-int
~
done like this:
change commas to dashes
I prefer dashes to commas.
But I don't understand the problem statement here? Now the docs have hyperlinked procs, so you just right click and copy, and paste anywhere you like.
This change is going against my personal preference that "if it ain't broke, don't fix it" :)
Note that I am not in any power to accept or deny your proposal, just giving my opinion.
As an aside the docs have few open issues, where we can use your help.
I recognize you from an earlier issue where you helped me fix the link issue on IE, I believe. So your experience with web dev will be useful in those doc site issues.
Who will replace/fix all the manually created links in the documentation? (in See also sections)
This gets thumb down from me, I don't see the benefits.
Sorry, rejected. We would never find all old links and update them. Links must be stable, stability is FAR more important than conciseness.
To any interested, here is a Hugo shortcode that
solves this:
~html
{{ $href := .Get 0 }}
{{ $a1 := split $href "," }}
{{ $text := index $a1 0 }}
{{ $text }}
~
Input:
~
{{< nim "tables#toTable,openArray[]" >}}
~
Output:
~html
tables#toTable
~
Most helpful comment
Who will replace/fix all the manually created links in the documentation? (in
See alsosections)This gets thumb down from me, I don't see the benefits.