>
> 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,
> flymake--diag-backend.
>
> 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.
>

Thank you for your helpful comment.
I've made a function (just for my flymake-tip package) using your comment.

--- code:
(defun flymake-tip-get-diag-text-on-line ()
    "Return list of string of error/warning info on the current line."
    (cl-loop for ov in (flymake--overlays :beg (point-at-bol) :end
(point-at-eol))
             collect (flymake--diag-text (overlay-get ov
'flymake--diagnostic))))
---

As you can see, I used 1 (flymake--overlays), 2 (flymake--diag-text), 3
(flymake--diagnostic).
So, I hope those functions/symbol become public API. (i mean "-" instead of
"--")

Also, after implementing my stuff, I popped up a question:
is there public API to check whether error/warning exists on the buffer?
The reason is I would make a command like flymake-next-error, but if there
is no error
I would invoke other things. (maybe using flymake--overlays to check?)


Thanks,
Yuta Yamada


On Mon, Oct 16, 2017 at 11:23 AM, João Távora <joaotavora@gmail.com> wrote:

> Yuta Yamada <sleepboy.zzz@gmail.com> 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,
> flymake--diag-backend.
>
> 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
> etc...
>
> > because I don't feel the fear of devel's change.
>
> :-)
>
> João
>