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: Tue, 13 Jun 2023 17:19:52 -0400 Message-ID: References: <83v8g240g6.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="22035"; 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 Tue Jun 13 23:20:22 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 1q9BR8-0005XJ-FJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Jun 2023 23:20:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q9BQt-0001ZI-JK; Tue, 13 Jun 2023 17:20:07 -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 1q9BQp-0001Yt-9s for bug-gnu-emacs@gnu.org; Tue, 13 Jun 2023 17:20: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 1q9BQp-0003b6-0f for bug-gnu-emacs@gnu.org; Tue, 13 Jun 2023 17:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q9BQo-0006HM-Ax for bug-gnu-emacs@gnu.org; Tue, 13 Jun 2023 17:20: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: Tue, 13 Jun 2023 21:20: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.168669120024124 (code B ref 63896); Tue, 13 Jun 2023 21:20:02 +0000 Original-Received: (at 63896) by debbugs.gnu.org; 13 Jun 2023 21:20:00 +0000 Original-Received: from localhost ([127.0.0.1]:43182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9BQm-0006H2-2e for submit@debbugs.gnu.org; Tue, 13 Jun 2023 17:20:00 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:34201) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9BQk-0006Gl-7C for 63896@debbugs.gnu.org; Tue, 13 Jun 2023 17:19:58 -0400 In-Reply-To: <83v8g240g6.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Jun 2023 14:23:37 +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:263347 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Sun, 04 Jun 2023 17:20:19 -0400 >> >> This patch adds an annotation-function and display-sort-function to the >> completion-table used for project-prompt-project-dir and >> project-prompt-project-name, as well as a user customization variable to >> customize the behavior of the annotation and sorting functions. > > Thanks. A few minor comments. Thanks, fixed. >> + (cons (+ (* 100 compilation-num-errors-found) >> + (* 10 compilation-num-warnings-found) > > Why "encode" these numbers in a single value? why not use a cons or a > vector? 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)) 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. I could make project-annotations a list of tuples of functions, the first being the annotation-generating function, the second being the annotation-comparison function. Then I wouldn't need to encode the numbers into a single value. Does that seem like a reasonable design? I thought that was a bit overly complex. >> + (format-mode-line mode-line-process nil nil buf))) > > Do you really need to call format-mode-line? My advice is to stay > away of that function: it could have unpleasant side effects. Annoyingly if I want to include the exit code of the compilation in the annotation, the only place it's found is as a string in mode-line-process. I could extract that string from mode-line-process and use it, but I thought it would be a bad idea to depend on the exact structure of what compile.el puts in mode-line-process. So I just format-mode-line'd it. 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.