| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
* Keep track of ordered list indexes and render them
* Rename some identifiers to clarify
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Catch Markdown links at beginning of line within paragraph
Per Issue #774, Markdown links were being parsed as ordinary text when
they occurred at the beginning of a line other than the first line of
the paragraph. This occurred because the parser was not interpreting a
left square bracket as a special character that could delimit special
markup. A space character was considered a special character, so, if a
space occurred at the beginning of the new line, then the parser would
interpret the space by itself and then continue parsing, thereby
catching the Markdown link. '\n' was not treated as a special character,
so the parser did not catch a Markdown link that may have followed.
Note that this will allow for Markdown links that are not surrounded by
spaces. For example, the following text includes a Markdown link that
will be parsed:
Hello, world[label](url)
This is consistent with how the parser handles other types of markup.
* Remove obsolete documentation hint
Commit 6b9aeafddf20efc65d3725c16e3fc43a20aac343 should eliminate the
need for the workaround suggested in the documentation.
|
| |
|
|
|
|
|
|
|
|
| |
Support a markdown-style way of annotating module references. For instance
-- | [label]("Module.Name#anchor")
will create a link that points to the same place as the module
reference "Module.Name#anchor" but the text displayed on the link will
be "label".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix multiple typos and inconsistencies in doc/markup.rst
Note: I noticed some overlap with #1112 from @wygulmage and #1081 from
@parsonsmatt after creating these proposed changes - mea culpa for not
looking at the open PRs sooner.
* Fix #1113 If no Signatures, no section of index.html
* Change the formatting of missing link destinations
The current formatting of the missing link destination does not really
help user to understand the reasons of the missing link.
To address this, I've changed the formatting in two ways:
- the missing link symbol name is now fully qualified. This way you
immediately know which haskell module cannot be linked. It is then easier
to understand why this module does not have documentation (hidden module
or broken documentation).
- one line per missing link, that's more readable now that symbol name
can be longer due to qualification.
For example, before haddock was listing missing symbol such as:
```
could not find link destinations for:
Word8 Word16 mapMaybe
```
Now it is listed as:
```
could not find link destinations for:
- Data.Word.Word8
- Data.Word.Word16
- Data.Maybe.mapMaybe
```
* Add `--ignore-link-symbol` command line argument
This argument can be used multiples time. A missing link to a symbol
listed by `--ignore-link-symbol` won't trigger "missing link" warning.
* Forbid spaces in anchors (#1148)
* Improve error messages with context information (#1060)
Co-authored-by: Matt Audesse <matt@mattaudesse.com>
Co-authored-by: Mike Pilgrem <mpilgrem@users.noreply.github.com>
Co-authored-by: Guillaume Bouchard <guillaume.bouchard@tweag.io>
Co-authored-by: Pepe Iborra <pepeiborra@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Our quickcheck tests for `haddock-library` stumbled across an edge case
input that was causing Haddock to crash: it was a unicode space
character.
The root cause of the crash is that we were implicitly assuming that
if a space character was not " \t\f\v\r", it would have to be "\n".
We fix this by instead defining horizontal space as: any space character
that is not '\n'.
Fixes #1142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* '(<|>)' and '`elem`' now get parsed and rendered properly as links
* 'DbModule'/'DbUnitId' now properly get split apart into two links
* tuple names now get parsed properly
* some more small niceties...
The identifier parsing code is more precise and more efficient (although to be
fair: it is also longer and in its own module). On the rendering side, we need
to pipe through information about backticks/parens/neither all the way through
from renaming to the backends.
In terms of impact: a total of 35 modules in the entirety of the bootlib + ghc
lib docs change. The only "regression" is things like '\0'. These should be
changed to @\\0@ (the path by which this previously worked seems accidental).
|
| |
|
|
|
|
|
|
|
|
|
| |
Identifier links can be prefixed with a 'v' or 't' to indicate the value or
type namespace of the desired identifier. For example:
-- | Some link to a value: v'Data.Functor.Identity'
--
-- Some link to a type: t'Data.Functor.Identity'
The default is still the type (with a warning about the ambiguity)
|
| | |
|
| |
|
|
|
|
|
|
| |
* Add tests for the identifier parser
* docs: Clarify how to delimit identifiers
(cherry picked from commit 0861affeca4d72938f05a2eceddfae2c19199071)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Metadoc stores a package name
This means that '@since' annotations can be package aware.
* Get the package name the right way
This should extract the package name for `@since` annotations the
right way. I had to move `modulePackageInfo` around to do this and,
in the process, I took the liberty to update it.
Since it appears that finding the package name is something that can
fail, I added a warning for this case.
* Silence warnings
* Hide package for local 'since' annotations
As discussed, this is still the usual case (and we should avoid being
noisy for it).
Although this commit is large, it is basically only about threading a
'Maybe Package' from 'Haddock.render' all the way to
'Haddock.Backends.Xhtml.DocMarkup.renderMeta'.
* Bump binary interface version
* Add a '--since-qual' option
This controls when to qualify since annotations with the package they
come from. The default is always, but I've left an 'external' variant
where only those annotations coming from outside of the current
package are qualified.
* Make ParserSpec work
* Make Fixtures work
* Use package name even if package version is not available
The @since stuff needs only the package name passed in, so it
makes sense to not be forced to pass in a version too.
|
| | |
|
| |
|
|
| |
otherwise we can't test w/ e.g. GHC 7.4.2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change notation and add support for inline math.
Allow newlines in display math.
Add a command line option for the mathjax url (you might want to use a
locally installed version).
Rebase tests because of extra url and version change.
Respond to (some of the) comments.
Fix warnings in InterfaceFile.hs
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we only use it only for ‘since’ annotations but with these
patches it should be fairly simple to add new attributes if we wish to.
Closes #26. It seems to work fine but due to 7.10 rush I don't have the
chance to do more exhaustive testing right now. The way the meta is
output (emphasis at the end of the whole comment) is fairly arbitrary
and subject to bikeshedding.
Note that this makes test for Bug310 fail due to interface version bump:
it can't find the docs for base with this interface version so it fails.
There is not much we can do to help this because it tests for ’built-in’
identifier, not something we can provide ourselves.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is to disambiguate them from markdown links and will be require
with a future release.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I get rid of the Monoid instance because we weren't satisfying the laws.
Convenience of having <> didn't outweigh the shock-factor of having it
behave badly.
|
| | |
|
| |
|
|
|
|
|
|
| |
The benefit of this is that the ‘top-level’ element of such lists is
properly wrapped in <p> tags so any CSS working with these will be
applied properly. It also just makes more sense.
Pointed out at jgm/pandoc#1346.
|
| |
|
|
|
| |
I can not remember why they were wrapped in paragraphs to begin with and
it seems unnecessary now that I test it. Closes #307.
|
| | |
|
| |
|
|
| |
They are much more useful to the users here.
|
|
|
We move some types out that are necessary as well and then
re-export and specialise them in the core Haddock.
Reason for moving out spec tests is that if we're working on the parser,
we can simply work on that and we can ignore the rest of Haddock. The
downside is that it's a little inconvenient if at the end of the day we
want to see that everything passes.
|
