Envoyé de mon iPhone
> Le 20 mai 2015 à 22:42, Andreas Leha <andreas.l...@med.uni-goettingen.de> a > écrit : > > Hi Rainer, > > Rainer M Krug <rai...@krugs.de> writes: >> Rainer M Krug <rai...@krugs.de> writes: >> >>> Rainer M Krug <rai...@krugs.de> writes: >>> >>>> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes: >>>> >>>>> Hi Rainer, >>>>> >>>>> Rainer M Krug <rai...@krugs.de> writes: >>>>>> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> The following library implements linting for Org syntax. The sole public >>>>>>> function is `org-lint', which see. >>>>>>> >>>>>>> Internally, the library defines a new structure: `org-lint-checker', >>>>>>> with the following slots: >>>>>>> >>>>>>> - NAME: Unique check identifier, as a symbol. The check is done >>>>>>> calling the function `org-lint-NAME' with one mandatory argument, >>>>>>> the parse tree describing the current Org buffer. Such function >>>>>>> calls are wrapped within a `save-excursion' and point is always at >>>>>>> `point-min'. Its return value has to be an alist (POSITION MESSAGE) >>>>>>> when POSITION refer to the buffer position of the error, as an >>>>>>> integer, and MESSAGE is a strings describing the error. >>>>>>> >>>>>>> - DESCRIPTION: Summary about the check, as a string. >>>>>>> >>>>>>> - CATEGORIES: Categories relative to the check, as a list of symbol. >>>>>>> They are used for filtering when calling `org-lint'. Checkers not >>>>>>> explicitly associated to a category are collected in the `default' >>>>>>> one. >>>>>>> >>>>>>> - TRUST: The trust level one can have in the check. It is either `low' >>>>>>> or `high', depending on the heuristics implemented and the nature of >>>>>>> the check. This has an indicative value only and is displayed along >>>>>>> reports. >>>>>>> >>>>>>> All checks have to be listed in `org-lint--checkers'. >>>>>>> >>>>>>> Results are displayed in a special "*Org Lint*" buffer with a dedicated >>>>>>> major mode, derived from `tabulated-list-mode'. In addition to the usual >>>>>>> key-bindings inherited from it, "C-j" displays problematic line reported >>>>>>> under point and "RET" jumps to it. >>>>>>> >>>>>>> Checks currently implemented are: >>>>>>> >>>>>>> - duplicates CUSTOM_ID properties >>>>>>> - duplicate NAME values >>>>>>> - duplicate targets >>>>>>> - duplicate footnote definitions >>>>>>> - orphaned affiliated keywords >>>>>>> - obsolete affiliated keywords >>>>>>> - missing language in src blocks >>>>>>> - NAME values with a colon >>>>>>> - wrong header arguments in src blocks >>>>>>> - misuse of CATEGORY keyword >>>>>>> - "coderef" links with unknown destination >>>>>>> - "custom-id" links with unknown destination >>>>>>> - "fuzzy" links with unknown destination >>>>>>> - "id" links with unknown destination >>>>>>> - links to non-existent local files >>>>>>> - special properties in properties drawer >>>>>>> - obsolete syntax for PROPERTIES drawers >>>>>>> - missing definition for footnote references >>>>>>> - missing reference for footnote definitions >>>>>>> - non-footnote definitions in footnote section >>>>>>> - probable invalid keywords >>>>>>> - invalid blocks >>>>>>> - probable incomplete drawers >>>>>>> - obsolete QUOTE section >>>>>>> >>>>>>> Since it relies on lexical binding, `pcase' and `string-prefix-p', it >>>>>>> cannot be added to Org 8.3, but can make it into Org 8.4, if deemed >>>>>>> useful enough. >>>>>> >>>>>> This sounds very interesting and I would like to try it out. I >>>>>> understand that it can't be put into master, but could it be put into a >>>>>> branch? >>>>>> >>>>>> This would make testing a bit easier. >>>>> >>>>> It is. The branch is called `wip-lint'. >>>> >>>> Thanks (also to Nicolas) - I found it. Just expected the branch to be >>>> tracked automatically. >>>> >>>> This is really brilliant! >>>> >>>> But I now get a message in one .org file: >>>> >>>> ,---- >>>> | Org linting process starting... >>>> | Search failed: "^[ ]*#\\+NAME: +tab:sensVar" >>>> `---- >>>> >>>> and no results. >>>> >>>> Works in other .org files. >>>> >>>> This one is rather long (11570 lines) and many code blocks. >>>> >>>> Just let me know how I can trace down where this is coming from and what >>>> the message tells me. >>> >>> It seems that the error comes from the fact that ~#+LABEL: sensVar~ was >>> defined twice. >>> >>> Renaming these results in working linting. >> >> OK - please ignore this last comment. >> >> There is an example where I get the error: >> >> * Fitting the kernel to the data >> The parameter which will be fitted can be found in Table [[tab:fitInitial]] >> >> #+CAPTION: Variables used for the initial fit of the wind profile using the >> function and the initial values. >> #+LABEL: tab:fitInitial >> | variable | initial value | remark >> | >> |--------------------+---------------+--------------------------------------------------| >> >> The cause is the link [[tab:initial]] If I remove everything below and >> including the line #+CAPTION the linting works. >> >> ,---- >> | 2 high Unknown fuzzy location "tab:fitInitial" >> `---- > > Untested - but should that not be > #+NAME: tab:fitInitial > rather than #+LABEL? > Yes - that would be correct. But the linting should tell me that instead of failing with this message Cheers, Rainer > Cheers, > Andreas > >
