GNU bug report logs - #63896
[PATCH] Support annotating and sorting the project list during completion

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63896 <at> debbugs.gnu.org
Subject: bug#63896: [PATCH] Support annotating and sorting the project list during completion
Date: Fri, 16 Jun 2023 10:26:05 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 63896 <at> debbugs.gnu.org
>> Date: Thu, 15 Jun 2023 15:04:20 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.