From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#63896: [PATCH] Support annotating and sorting the project list during completion Date: Fri, 16 Jun 2023 10:26:05 -0400 Message-ID: References: <83v8g240g6.fsf@gnu.org> <83legmutrp.fsf@gnu.org> <83bkhgt10s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18178"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 63896@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 16 16:27:11 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qAAPv-0004Wa-4s for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Jun 2023 16:27:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qAAPn-0002BN-5P; Fri, 16 Jun 2023 10:27:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAAPm-0002B1-D1 for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 10:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qAAPm-0005J2-4S for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 10:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qAAPm-0002at-07 for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 10:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Jun 2023 14:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63896 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 63896-submit@debbugs.gnu.org id=B63896.16869255739906 (code B ref 63896); Fri, 16 Jun 2023 14:27:01 +0000 Original-Received: (at 63896) by debbugs.gnu.org; 16 Jun 2023 14:26:13 +0000 Original-Received: from localhost ([127.0.0.1]:50125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAAOz-0002Zi-4T for submit@debbugs.gnu.org; Fri, 16 Jun 2023 10:26:13 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:47311) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAAOx-0002ZR-BU for 63896@debbugs.gnu.org; Fri, 16 Jun 2023 10:26:11 -0400 In-Reply-To: <83bkhgt10s.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Jun 2023 08:43:47 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263472 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: 63896@debbugs.gnu.org >> Date: Thu, 15 Jun 2023 15:04:20 -0400 >> >> Eli Zaretskii writes: >> >> >> I'd be happy to use a cons or a vector, or even a more complicated >> >> structure, but I didn't see an easy way to do comparison of >> >> complicated structures, for the sorting of projects based on their >> >> annotation. For example, if I have values of the form >> >> (num . (num num num)) >> > >> > You'd need to write a custom comparison function, but why is that a >> > problem? >> >> Yes, but how does that get configured? >> >> >> there's no way to know what sorting predicate to use for such values - I >> >> need to be able to know which value should sort sort first, when I have >> >> a pair of them. >> > >> > But the encoding scheme above provides the answer: you want errors to >> > sort before the warnings. So it sounds like you already decided how >> > to sort those, no? >> >> Yes, but I mean that *this function* doesn't know, given some opaque >> value returned by a user-provided annotation function, how to sort. > > You'd need to include the comparison function in the annotation data, > I guess. Yes, I'm just not sure the right approach. It would be wasteful to return the comparison function from the annotation function every time it's called, since it's the same for every call. >> >> Would it be OK to make compile.el store the exit code as a number in a >> >> variable and then use that? Then I wouldn't need to touch >> >> mode-line-process at all. >> > >> > I don't see why you'd need that. Doesn't process-exit-status give you >> > that value? mode-line-process is not some magic, it just accesses >> > process information exposed via the different primitives. >> >> For sure, process-exit-status gives me that value. But how do I get the >> process to call it on? The process is dead at this point, so >> (get-buffer-process "*compilation*") returns nil. Is there a way to get >> the process associated with the buffer even though it's killed? > > If project.el wants to access data from an exited compilation, it > needs to record that when the compilation exits (via the > compilation-finish-functions hook, for example). Calling > format-mode-line will not help you, because if the process doesn't > exist, its data cannot be accessed, and relying on what's displayed on > the mode line is a bad idea: it could be outdated or even irrelevant. > So please don't use such kludges, even though they might look > convenient at first sight. Would it be OK for compile.el to start storing this data in a variable? The number of errors/warnings/infos is already stored; also storing the exit status would probably be useful for all kinds of things.