From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63896: [PATCH] Support annotating and sorting the project list during completion Date: Fri, 16 Jun 2023 08:43:47 +0300 Message-ID: <83bkhgt10s.fsf@gnu.org> References: <83v8g240g6.fsf@gnu.org> <83legmutrp.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30541"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63896@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 16 07:44:29 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 1qA2G4-0007lW-G3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Jun 2023 07:44:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qA2Fk-0000lG-Pe; Fri, 16 Jun 2023 01:44:08 -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 1qA2Fe-0000kt-PI for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 01:44:03 -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 1qA2Fe-0004bj-G2 for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 01:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qA2Fe-0003rW-Ck for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 01:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Jun 2023 05:44:02 +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.168689421314796 (code B ref 63896); Fri, 16 Jun 2023 05:44:02 +0000 Original-Received: (at 63896) by debbugs.gnu.org; 16 Jun 2023 05:43:33 +0000 Original-Received: from localhost ([127.0.0.1]:48458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA2FB-0003qZ-DM for submit@debbugs.gnu.org; Fri, 16 Jun 2023 01:43:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA2F8-0003qL-K1 for 63896@debbugs.gnu.org; Fri, 16 Jun 2023 01:43:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qA2F2-0004Ts-4B; Fri, 16 Jun 2023 01:43:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GfLSCt+14xaLUTT+a4c3BzpolRhR0WzCpk60OERhMvM=; b=gFjFlr3mPPWl 16kem2gVCJb2xIC4d5me+w1i9SWDsCZuNRuQ2hviZxze6HTxv/431zH+34J5kuwlDe1tbtX5W2DiW bc7xZHwfR3Tex6eOignKfiv8fou1CklaMNJTh0e9C1VftfwwNHUnPQrHFrcrdGorLRgGVQw6YdDQ4 skft8rLADBovkosMJndqQbrG/jegXP5G7XAX+lt/qEjcd4JpM5EEh/aPPtNNZodWivr92IEEAMU23 UFgm3z+fnQpeVR/749qzpMby8u+okebcgHAihY5CPyy0NfJ83Wg9H9gILMcAC5wlmWwcXnL91asQ1 qEpNcc/w3Qo7tYDftH3piQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qA2F1-0003hQ-8g; Fri, 16 Jun 2023 01:43:23 -0400 In-Reply-To: (message from Spencer Baugh on Thu, 15 Jun 2023 15:04:20 -0400) 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:263449 Archived-At: > 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. > >> 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.