emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [RFC] Org linting library


From: Rainer M Krug
Subject: Re: [O] [RFC] Org linting library
Date: Wed, 20 May 2015 23:15:08 +0200


Envoyé de mon iPhone

> Le 20 mai 2015 à 22:42, Andreas Leha <address@hidden> a écrit :
> 
> Hi Rainer,
> 
> Rainer M Krug <address@hidden> writes:
>> Rainer M Krug <address@hidden> writes:
>> 
>>> Rainer M Krug <address@hidden> writes:
>>> 
>>>> Andreas Leha <address@hidden> writes:
>>>> 
>>>>> Hi Rainer,
>>>>> 
>>>>> Rainer M Krug <address@hidden> writes:
>>>>>> Nicolas Goaziou <address@hidden> 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
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]