From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Yuta Yamada Newsgroups: gmane.emacs.devel Subject: Re: feature request: public API to get new flymake's errors/warnings Date: Tue, 17 Oct 2017 07:32:48 -0700 Message-ID: References: <87inffhrzq.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1144ac20541349055bbeff79" X-Trace: blaine.gmane.org 1508251120 30022 195.159.176.226 (17 Oct 2017 14:38:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 14:38:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 17 16:38:31 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4T0k-0005rq-CJ for ged-emacs-devel@m.gmane.org; Tue, 17 Oct 2017 16:38:26 +0200 Original-Received: from localhost ([::1]:39868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4T0q-0000BQ-3Q for ged-emacs-devel@m.gmane.org; Tue, 17 Oct 2017 10:38:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4SvU-0007gr-3N for emacs-devel@gnu.org; Tue, 17 Oct 2017 10:33:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e4SvK-0002Ol-3A for emacs-devel@gnu.org; Tue, 17 Oct 2017 10:33:00 -0400 Original-Received: from mail-qk0-x234.google.com ([2607:f8b0:400d:c09::234]:44405) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e4SvJ-0002OX-RP for emacs-devel@gnu.org; Tue, 17 Oct 2017 10:32:50 -0400 Original-Received: by mail-qk0-x234.google.com with SMTP id r64so2273495qkc.1 for ; Tue, 17 Oct 2017 07:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G7tBH3Nea22tCDdhVOFcO7A3Ilu/dCV+x02KFLt9Weo=; b=oIPjMYddhCIHpy7IbVpYvuSFJI2kQRuK8InT/3Eb/8E8kW2jmjR6HFEj9145a7WTra K0VUtJCNXU3nuS7PC8cPjLORdyfnyMkhAr4jXi7+LlpBdJW6ErgULArHOWdL8dyDfjeg Q4Tef1nzpWpm3NUyfC67GR1aaeWbGL78o5gMZfvxcKyEVCMlOQCBeGSF8sZSh4Js1r2t Kb2INh4zydFPEvL7iJ74mYy0ZHmo+o/z5TdNH54RsbwIcBDTkNPTnP2iuk5eetxiRjLd 7ZZhWKlGeRKhk/fiHqPIeph/IuL8BRj1xIdxDjQbN3RHLp3xcHAXLjSsgIRBJeHUPlOb KYwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G7tBH3Nea22tCDdhVOFcO7A3Ilu/dCV+x02KFLt9Weo=; b=IAS3S4xa5eHqpa3N28xmjFk13l/K4RU2TsB7LmazA+tnivI9N4oBjy1vpL1h72EV15 6H6b+fENGaI+WTdxnBOizwql3jXV6QgDieMuQ5joZnuXU9/J0OI2vZZJu1CVWm84xs3T UTwULdPYsfPOVShHga9WF30ETKroLQxryv47qmjvl5BmKmy/Xx/dqciOBgQA5aj4O+zM g8MfkNMHxaDezxZ+46lymsdenMFveiZYgFN1hsE6OdTDdHqpsIbY5/l9nZQqJnLKpWqs h8kUrnr+pChGrLglWYFOpoGD5IJ89Ea9RAdIhrhjtSBa0heWzLKC8Pe/aqDolj2rZ67f 3Fxg== X-Gm-Message-State: AMCzsaWCHsRfid+a5Bzi3zo9R4FQPVGfynJIjAY+3STumqfevVlA9luR ijZRz+bm/6mi3LxREy5PaxW8UcP1nnCU85e1ihweVA== X-Google-Smtp-Source: AOwi7QAEboVy0Jux7KcBm7KlvsxuyjJXsqyfZzB4NtKnILWMZQahi2o+vbws4IbqODnVkkcQoJhNB32RpzVvViaZSWU= X-Received: by 10.55.203.5 with SMTP id d5mr16950951qkj.189.1508250769165; Tue, 17 Oct 2017 07:32:49 -0700 (PDT) Original-Received: by 10.140.101.52 with HTTP; Tue, 17 Oct 2017 07:32:48 -0700 (PDT) In-Reply-To: <87inffhrzq.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::234 X-Mailman-Approved-At: Tue, 17 Oct 2017 10:37:30 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:219605 Archived-At: --001a1144ac20541349055bbeff79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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=C3=A3o T=C3=A1vora wrote: > Yuta Yamada 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=C3=A3o > --001a1144ac20541349055bbeff79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 "exte= rnal":

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.
<= div>=C2=A0
--- code:
(defun flymake-tip-get-diag-text-on-line ()
=C2=A0=C2=A0=C2=A0 "Ret= urn list of string of error/warning info on the current line."
=C2= =A0=C2=A0=C2=A0 (cl-loop for ov in (flymake--overlays :beg (point-at-bol) := end (point-at-eol))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 collect (flymake--diag-text (overlay-get ov 'flym= ake--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 "-" inste= ad of "--")

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


Thanks,
Yuta Yamada

On Mon, Oct 16, 2017 at 11:23 AM, Jo=C3=A3o T=C3=A1vora <joaotav= ora@gmail.com> wrote:
Yuta Yamada <sleep= boy.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<= br> > 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 "exte= rnal":

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=C3=A3o

--001a1144ac20541349055bbeff79--