[Top][All Lists]

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

Re: feature request: public API to get new flymake's errors/warnings

From: João Távora
Subject: Re: feature request: public API to get new flymake's errors/warnings
Date: Mon, 16 Oct 2017 19:23:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)

Yuta Yamada <address@hidden> writes:

> Hello Emacs devel.
> First of all, thank you to rewritten of flymake!
> I'm an emacs' package maintainer of flycheck-tip and
> flycheck-nimsuggest (nim language's flycheck backend) and I could
> convert to flycheck-nimsuggest.el for flymake very easy.
> But, as for flycheck-tip (which show flycheck/flymake's errors and
> warning on a tooltip), or other flymake related packages, could you
> support public API to get errors and warnings object? (I mean a public
> function for it)
I see. I think you could try to write it with the internal functions
that I mention in the rest of this message and then we can more easily
see which parts are currently "internal" that could be "external":

1) Most important you need an easy way to get the the "diagnostic"
object at point. This is held by the overlays within their
'flymake--diagnostic' property.

2) You'll probably need accessors for the flymake--diag object (text,
type, issuing backend function). I think this is a question of renameing
the existing flymake--diag-text, flymake--diag-type,

3) Perhaps a way to get all the diagnostics in a region. There is
flymake--overlays for this.

4) Maybe check the properties (severity) of a given type? This is
currently done via flymake--lookup-type-property.

My only doubt is if 1 and 3 should work through the overlays API
(flymake--overlays and overlay-get for discrimination) i.e. If so the
API is smaller, but ties Flymake to an overlay overlay-based
implementation. Otherwise we can make flymake-diagnostics-at-point

> because I don't feel the fear of devel's change.



reply via email to

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