Re: URGENT - which-key FSF contributor status

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Jeremy Bryant <jb@jeremybryant.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Jeremy Bryant <jb@jeremybryant.net>
>>>> CC: Eli Zaretskii <eliz@gnu.org>, Philip Kaludercic <philipk@posteo.net>
>>>> Date: Thu, 02 May 2024 23:01:02 +0100
>>>> 
>>>> Hi Justin,
>>>> 
>>>> Prior to merging which-key and its history into Emacs core we need to
>>>> confirm that the contributors have indeed signed the FSF paperwork.
>>>> While this is a requirement of being ELPA it's up to the maintainer of
>>>> the package to check.
>>>> 
>>>> Can you confirm?
>>>
>>> I can easily check who has an assignment on file and who doesn't.  See
>>> below.  Where I need help is with the contribution of those who do NOT
>>> have assignments.  For each one of those, we need the total line count
>>> of non-trivial code changes they contributed, so we can decide whether
>>> their contributions present a copyright problem.
>>>
>>> Here's the list of contributors to which-key for whom I found no
>>> copyright assignment on file:
>>>
>>>>      16 Author: Bar Magal <barmagal@gmail.com>
>>>>       1 Author: Yunhao Zhao <yunhaozhaots@gmail.com>
>>>>       1 Author: Uros Perisic <uros.m.perisic@gmail.com>
>>>>       1 Author: N V <44036031+progfolio@users.noreply.github.com>
>>>>       1 Author: Hariharan R <hariharanrangasamy@gmail.com>
>>>>       1 Author: Frank Terbeck <ft@bewatermyfriend.org>
>>>>       1 Author: Duncan Burke <duncankburke@gmail.com>
>>>>       1 Author: D.K <beerandhot@gmail.com>
>>>>       1 Author: Colin Yates <colin@colinyates.co.uk>
>>>>       1 Author: Chris Perkins <chrisperkins99@gmail.com>
>>>>       1 Author: Celestial Nebula <41875671+CelestialNebula@users.noreply.github.com>
>>>>       1 Author: BlaCk_Void <alstjr7375@daum.net>
>>>>       1 Author: anis-semmar <78486514+anis-semmar@users.noreply.github.com>
>>>>       1 Author: Amory Meltzer <Amorymeltzer@gmail.com>
>>>
>>> If the notion of "line count of non-trivial code changes" presents a
>>> problem, feel free to email the diffs, and I will make the call.
>>
>> To my estimation, the above git log is suggestive and there are no
>> significant contributors besides Bar Magal (the others have 1-5 lines of
>> changes in the current code base).
>>
>> Here is an Occur buffer of the whitespace-insensitive vc-annotate buffer
>> with Bar's attributed lines:
>>
>> 111 matches for "Bar Magal" in buffer: *Annotate which-key.el (rev 1e89fa0)*
>>      57:2df42e2d (Bar Magal          2015-07-10   57) (defcustom which-key-idle-delay 1.0
>>     267:2df42e2d (Bar Magal          2015-07-10  267)   :type '(radio (const :tag "Show in minibuffer" minibuffer)
>>     268:2df42e2d (Bar Magal          2015-07-10  268)                 (const :tag "Show in side window" side-window)
>>     290:2df42e2d (Bar Magal          2015-07-10  290)   :type '(radio (const right)
>>     291:2df42e2d (Bar Magal          2015-07-10  291)                 (const bottom)
>>     292:2df42e2d (Bar Magal          2015-07-10  292)                 (const left)
>>     321:d9a9bd5a (Bar Magal          2015-07-09  321) This variable can also be a number between 0 and 1. In that case, it denotes
>>     687:02140265 (Bar Magal          2015-07-06  687) (defvar which-key--frame nil
>>    1122:688ba7ee (Bar Magal          2015-07-09 1122) 
>>    1131:688ba7ee (Bar Magal          2015-07-09 1131)   (let ((char-width (frame-char-width)))
>>    1132:688ba7ee (Bar Magal          2015-07-09 1132)     (+ text-width
>>    1133:688ba7ee (Bar Magal          2015-07-09 1133)        (/ (frame-fringe-width) char-width)
>>    1134:688ba7ee (Bar Magal          2015-07-09 1134)        (/ (frame-scroll-bar-width) char-width)
>>    1136:315eeca5 (Bar Magal          2015-07-09 1136)        ;; add padding to account for possible wide (unicode) characters
>>    1137:315eeca5 (Bar Magal          2015-07-09 1137)        3)))
>>    1138:688ba7ee (Bar Magal          2015-07-09 1138) 
>>    1141:688ba7ee (Bar Magal          2015-07-09 1141) TOTAL-WIDTH is the desired total width of the window.  The function calculates
>>    1142:688ba7ee (Bar Magal          2015-07-09 1142) what text width fits such a window.  The calculation considers possible fringes
>>    1143:688ba7ee (Bar Magal          2015-07-09 1143) and scroll bars.  This function assumes that the desired window has the same
>>    1144:688ba7ee (Bar Magal          2015-07-09 1144) character width as the frame."
>>    1145:688ba7ee (Bar Magal          2015-07-09 1145)   (let ((char-width (frame-char-width)))
>>    1146:688ba7ee (Bar Magal          2015-07-09 1146)     (- total-width
>>    1147:688ba7ee (Bar Magal          2015-07-09 1147)        (/ (frame-fringe-width) char-width)
>>    1148:688ba7ee (Bar Magal          2015-07-09 1148)        (/ (frame-scroll-bar-width) char-width)
>>    1150:315eeca5 (Bar Magal          2015-07-09 1150)        ;; add padding to account for possible wide (unicode) characters
>>    1151:315eeca5 (Bar Magal          2015-07-09 1151)        3)))
>>    1152:688ba7ee (Bar Magal          2015-07-09 1152) 
>>    1156:688ba7ee (Bar Magal          2015-07-09 1156) 
>>    1160:688ba7ee (Bar Magal          2015-07-09 1160) 
>>    1164:688ba7ee (Bar Magal          2015-07-09 1164) 
>>    1166:d9a9bd5a (Bar Magal          2015-07-09 1166)   "Return window total width.
>>    1167:d9a9bd5a (Bar Magal          2015-07-09 1167) If WIDTH-OR-PERCENTAGE is a whole number, return it unchanged.  Otherwise, it
>>    1168:d9a9bd5a (Bar Magal          2015-07-09 1168) should be a percentage (a number between 0 and 1) out of the frame's width.
>>    1169:d9a9bd5a (Bar Magal          2015-07-09 1169) More precisely, it should be a percentage out of the frame's root window's
>>    1170:d9a9bd5a (Bar Magal          2015-07-09 1170) total width."
>>    1172:d9a9bd5a (Bar Magal          2015-07-09 1172)       width-or-percentage
>>    1173:d9a9bd5a (Bar Magal          2015-07-09 1173)     (round (* width-or-percentage (window-total-width (frame-root-window))))))
>>    1174:d9a9bd5a (Bar Magal          2015-07-09 1174) 
>>    1176:d9a9bd5a (Bar Magal          2015-07-09 1176)   "Return window total height.
>>    1177:d9a9bd5a (Bar Magal          2015-07-09 1177) If HEIGHT-OR-PERCENTAGE is a whole number, return it unchanged.  Otherwise, it
>>    1178:d9a9bd5a (Bar Magal          2015-07-09 1178) should be a percentage (a number between 0 and 1) out of the frame's height.
>>    1179:d9a9bd5a (Bar Magal          2015-07-09 1179) More precisely, it should be a percentage out of the frame's root window's
>>    1180:d9a9bd5a (Bar Magal          2015-07-09 1180) total height."
>>    1182:d9a9bd5a (Bar Magal          2015-07-09 1182)       height-or-percentage
>>    1183:d9a9bd5a (Bar Magal          2015-07-09 1183)     (round (* height-or-percentage (window-total-height (frame-root-window))))))
>>    1184:d9a9bd5a (Bar Magal          2015-07-09 1184) 
>>    1195:67065197 (Bar Magal          2015-07-05 1195) 
>>    1208:02140265 (Bar Magal          2015-07-06 1208) 
>>    1225:67065197 (Bar Magal          2015-07-05 1225)   (when (buffer-live-p which-key--buffer)
>>    1226:02140265 (Bar Magal          2015-07-06 1226)     ;; in case which-key buffer was shown in an existing window, `quit-window'
>>    1227:02140265 (Bar Magal          2015-07-06 1227)     ;; will re-show the previous buffer, instead of closing the window
>>    1233:02140265 (Bar Magal          2015-07-06 1233) 
>>    1236:02140265 (Bar Magal          2015-07-06 1236)   (when (frame-live-p which-key--frame)
>>    1237:02140265 (Bar Magal          2015-07-06 1237)     (delete-frame which-key--frame)))
>>    1259:67065197 (Bar Magal          2015-07-05 1259) 
>>    1267:315eeca5 (Bar Magal          2015-07-09 1267)     (apply #'fit-window-to-buffer window params)))
>>    1268:315eeca5 (Bar Magal          2015-07-09 1268) 
>>    1302:02140265 (Bar Magal          2015-07-06 1302) 
>>    1306:35a171ef (Bar Magal          2015-07-06 1306)          (frame-height (+ (car act-popup-dim)
>>    1307:35a171ef (Bar Magal          2015-07-06 1307)                           (if (with-current-buffer which-key--buffer
>>    1308:35a171ef (Bar Magal          2015-07-06 1308)                                 mode-line-format)
>>    1309:35a171ef (Bar Magal          2015-07-06 1309)                               1
>>    1310:35a171ef (Bar Magal          2015-07-06 1310)                             0)))
>>    1311:35a171ef (Bar Magal          2015-07-06 1311)          ;; without adding 2, frame sometimes isn't wide enough for the buffer.
>>    1312:35a171ef (Bar Magal          2015-07-06 1312)          ;; this is probably because of the fringes. however, setting fringes
>>    1313:35a171ef (Bar Magal          2015-07-06 1313)          ;; sizes to 0 (instead of adding 2) didn't always make the frame wide
>>    1314:35a171ef (Bar Magal          2015-07-06 1314)          ;; enough. don't know why it is so.
>>    1315:35a171ef (Bar Magal          2015-07-06 1315)          (frame-width (+ (cdr act-popup-dim) 2))
>>    1316:02140265 (Bar Magal          2015-07-06 1316)          (new-window (if (and (frame-live-p which-key--frame)
>>    1317:02140265 (Bar Magal          2015-07-06 1317)                               (eq which-key--buffer
>>    1324:35a171ef (Bar Magal          2015-07-06 1324)     (when new-window
>>    1325:35a171ef (Bar Magal          2015-07-06 1325)       ;; display successful
>>    1326:02140265 (Bar Magal          2015-07-06 1326)       (setq which-key--frame (window-frame new-window))
>>    1327:35a171ef (Bar Magal          2015-07-06 1327)       new-window)))
>>    1328:02140265 (Bar Magal          2015-07-06 1328) 
>>    1331:35a171ef (Bar Magal          2015-07-06 1331)   (let* ((frame-params `((height . ,frame-height)
>>    1332:35a171ef (Bar Magal          2015-07-06 1332)                          (width . ,frame-width)
>>    1333:35a171ef (Bar Magal          2015-07-06 1333)                          ;; tell the window manager to respect the given sizes
>>    1334:35a171ef (Bar Magal          2015-07-06 1334)                          (user-size . t)
>>    1335:35a171ef (Bar Magal          2015-07-06 1335)                          ;; which-key frame doesn't need a minibuffer
>>    1336:35a171ef (Bar Magal          2015-07-06 1336)                          (minibuffer . nil)
>>    1337:35a171ef (Bar Magal          2015-07-06 1337)                          (name . "which-key")
>>    1338:35a171ef (Bar Magal          2015-07-06 1338)                          ;; no need for scroll bars in which-key frame
>>    1339:35a171ef (Bar Magal          2015-07-06 1339)                          (vertical-scroll-bars . nil)
>>    1340:35a171ef (Bar Magal          2015-07-06 1340)                          ;; (left-fringe . 0)
>>    1341:35a171ef (Bar Magal          2015-07-06 1341)                          ;; (right-fringe . 0)
>>    1342:35a171ef (Bar Magal          2015-07-06 1342)                          ;; (right-divider-width . 0)
>>    1343:35a171ef (Bar Magal          2015-07-06 1343)                          ;; make sure frame is visible
>>    1344:35a171ef (Bar Magal          2015-07-06 1344)                          (visibility . t)))
>>    1345:35a171ef (Bar Magal          2015-07-06 1345)          (alist `((pop-up-frame-parameters . ,frame-params)))
>>    1346:35a171ef (Bar Magal          2015-07-06 1346)          (orig-frame (selected-frame))
>>    1347:35a171ef (Bar Magal          2015-07-06 1347)          (new-window (display-buffer-pop-up-frame which-key--buffer alist)))
>>    1348:35a171ef (Bar Magal          2015-07-06 1348)     (when new-window
>>    1349:35a171ef (Bar Magal          2015-07-06 1349)       ;; display successful
>>    1350:35a171ef (Bar Magal          2015-07-06 1350)       (redirect-frame-focus (window-frame new-window) orig-frame)
>>    1351:35a171ef (Bar Magal          2015-07-06 1351)       new-window)))
>>    1352:02140265 (Bar Magal          2015-07-06 1352) 
>>    1355:35a171ef (Bar Magal          2015-07-06 1355)   (let ((window
>>    1358:35a171ef (Bar Magal          2015-07-06 1358)     (when window
>>    1359:35a171ef (Bar Magal          2015-07-06 1359)       ;; display successful
>>    1360:35a171ef (Bar Magal          2015-07-06 1360)       (set-frame-size (window-frame window) frame-width frame-height)
>>    1361:35a171ef (Bar Magal          2015-07-06 1361)       window)))
>>    1362:67065197 (Bar Magal          2015-07-05 1362) 
>>    1383:67065197 (Bar Magal          2015-07-05 1383)    (if (floatp max-mini-window-height)
>>    1384:67065197 (Bar Magal          2015-07-05 1384)        (floor (* (frame-text-lines)
>>    1385:67065197 (Bar Magal          2015-07-05 1385)                  max-mini-window-height))
>>    1409:d9a9bd5a (Bar Magal          2015-07-09 1409)                  which-key-side-window-max-width))
>>    1419:02140265 (Bar Magal          2015-07-06 1419)   (cons which-key-frame-max-height which-key-frame-max-width))
>>    1420:02140265 (Bar Magal          2015-07-06 1420) 
>>    2313:67065197 (Bar Magal          2015-07-05 2313)           (with-current-buffer which-key--buffer
>>    2314:02140265 (Bar Magal          2015-07-06 2314)             (erase-buffer)
>>
>>
>> What concerns me is that at least according to his GitHub profile[0],
>> there has been no activity since 2022, and almost no regular activity
>> since 2016-2017, so I cannot estimate how reliably we can contact him.
>>
>> Setting aside the issue of adding this to Emacs, the package should not
>> be in GNU ELPA if this is the case.
>>
>> [0] https://github.com/bmag
>>
>>> But please let's do this ASAP, as I don't want to delay the release
>>> branch creation, if possible.
>>>
>>> Thanks.
>
> Philip, thanks for checking - yes it appears to be a problem, I'll try and chase
> this 1 contributor.

(Adding emacs-devel)

We have found out that Bar has completed the CA.  That means we can
proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?

I think the best thing right now would be to collect all the patches in
a single message for a final review.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Justin Burkett <justin@burkett.cc>,
>  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 09:05:52 +0000
> 
> We have found out that Bar has completed the CA.  That means we can
> proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?

Yes.  If you do this _very_ quickly.

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Justin Burkett <justin@burkett.cc>,
>>  emacs-devel@gnu.org
>> Date: Sat, 15 Jun 2024 09:05:52 +0000
>> 
>> We have found out that Bar has completed the CA.  That means we can
>> proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?
>
> Yes.  If you do this _very_ quickly.

I have pushed a working branch under "feature/which-key-in-core".
Please take a look to see if I missed something obvious, and if it seems
fine I can merge it into master right away.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> I have pushed a working branch under "feature/which-key-in-core".
> Please take a look to see if I missed something obvious, and if it seems
> fine I can merge it into master right away.

LGTM.

Note these two warnings from package-lint when run on which-key.el:

806:0: error: "evil-state" doesn't start with package's prefix "which-key".
2334:10: error: `next-event' was removed in Emacs version 28.1.

Re: URGENT - which-key FSF contributor status

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> Note these two warnings from package-lint when run on which-key.el:
>
> 806:0: error: "evil-state" doesn't start with package's prefix "which-key".
> 2334:10: error: `next-event' was removed in Emacs version 28.1.

Did you have a chance to look into these warnings?

The first one seems cosmetic, but we might want to fix the second one
(assuming that it's a valid warning).

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Stefan Kangas <stefankangas@gmail.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Note these two warnings from package-lint when run on which-key.el:
>>
>> 806:0: error: "evil-state" doesn't start with package's prefix "which-key".
>> 2334:10: error: `next-event' was removed in Emacs version 28.1.
>
> Did you have a chance to look into these warnings?

Sorry, I forgot to respond to your message.

> The first one seems cosmetic, but we might want to fix the second one
> (assuming that it's a valid warning).

The first one is related to evil-support  I am not familiar with the
issue to find a better solution.

The second one is not a valid warning, apparently package-lint doesn't
distinguish between function calls and variable bindings.  If we really
wanted to fix it, then


[-- Attachment #2: Type: text/plain, Size: 698 bytes --]

diff --git a/lisp/which-key.el b/lisp/which-key.el
index 1de599e5497..8a61dd0edce 100644
--- a/lisp/which-key.el
+++ b/lisp/which-key.el
@@ -2336,9 +2336,9 @@ which-key-reload-key-sequence
 `which-key--current-key-list'.  Any prefix arguments that were
 used are reapplied to the new key sequence."
   (let* ((key-seq (or key-seq (which-key--current-key-list)))
-         (next-event (mapcar (lambda (ev) (cons t ev)) key-seq)))
+         (next-evt (mapcar (lambda (ev) (cons t ev)) key-seq)))
     (setq prefix-arg current-prefix-arg
-          unread-command-events next-event)))
+          unread-command-events next-evt)))
 
 (defun which-key-turn-page (delta)
   "Show the next page of keys."

[-- Attachment #3: Type: text/plain, Size: 51 bytes --]


would do it.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

>> Did you have a chance to look into these warnings?
>
> The first one is related to evil-support  I am not familiar with the
> issue to find a better solution.
>
> The second one is not a valid warning, apparently package-lint doesn't
> distinguish between function calls and variable bindings.

OK, thanks.  It seems like it's not worth our time to fix either of them.

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> Did you have a chance to look into these warnings?
>>
>> The first one is related to evil-support  I am not familiar with the
>> issue to find a better solution.
>>
>> The second one is not a valid warning, apparently package-lint doesn't
>> distinguish between function calls and variable bindings.
>
> OK, thanks.  It seems like it's not worth our time to fix either of them.

Very well, then I'll proceed to merge the branch into master.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> Very well, then I'll proceed to merge the branch into master.

Great, thanks.

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Very well, then I'll proceed to merge the branch into master.
>
> Great, thanks.

Was the plan then to proceed and have the ELPA package use the file from
the core?

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Justin Burkett]

On Tue, Jun 18, 2024 at 5:41 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > Philip Kaludercic <philipk@posteo.net> writes:
> >
> >> Very well, then I'll proceed to merge the branch into master.
> >
> > Great, thanks.
>
> Was the plan then to proceed and have the ELPA package use the file from
> the core?
>

I'd like to echo this question. Up until now, I have managed which-key
through a github repo which then gets synced to elpa. I'm now not sure
what to do with github and specifically contributions I get through
there. I can archive that repo if bugs and contributions should now go
through standard emacs channels.

> --
>         Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Stefan Kangas]

Justin Burkett <justin@burkett.cc> writes:

> I'd like to echo this question. Up until now, I have managed which-key
> through a github repo which then gets synced to elpa. I'm now not sure
> what to do with github and specifically contributions I get through
> there. I can archive that repo if bugs and contributions should now go
> through standard emacs channels.

It's basically your decision as the maintainer of which-key.

Org mode, CC mode, and others, have external repositories and merge code
back and forth.  This would require you to periodically do these merges,
for example when you release a new version.  This means checking for
changes in emacs.git and merging them into your tree, and then merging
the released version into our tree.

Some other packages, for example Gnus and eglot, are now developed fully
in emacs.git and have abandoned their external repositories.  Bugs for
those packages are now also always reported on our bug mailing list.
(We are also okay with preferring bug reports to go elsewhere, but we
will usually always accept bugs through our regular channels too, and
then simply forward them to you.)

From the Emacs maintainer point of view, the latter option is always
going to be the easiest, but again: it's your decision.  So please let
us know what you prefer.  I'd suggest to document the parts that are
different from any other package in emacs.git in the "Commentary" of
which-key.el.

I hope that helps, and please let us know if you have any questions.

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Justin Burkett <justin@burkett.cc> writes:
>
>> I'd like to echo this question. Up until now, I have managed which-key
>> through a github repo which then gets synced to elpa. I'm now not sure
>> what to do with github and specifically contributions I get through
>> there. I can archive that repo if bugs and contributions should now go
>> through standard emacs channels.

That would certainly be one option, and one of the simpler ones.  You
could also ask for access to emacs.git, if you think you'll be needing it.

> It's basically your decision as the maintainer of which-key.
>
> Org mode, CC mode, and others, have external repositories and merge code
> back and forth.  This would require you to periodically do these merges,
> for example when you release a new version.  This means checking for
> changes in emacs.git and merging them into your tree, and then merging
> the released version into our tree.
>
> Some other packages, for example Gnus and eglot, are now developed fully
> in emacs.git and have abandoned their external repositories.  Bugs for
> those packages are now also always reported on our bug mailing list.
> (We are also okay with preferring bug reports to go elsewhere, but we
> will usually always accept bugs through our regular channels too, and
> then simply forward them to you.)

IIRC Eglot bugs are still sometimes reported on the old bug tracker, but
that is being sunset.

> From the Emacs maintainer point of view, the latter option is always
> going to be the easiest, but again: it's your decision.  So please let
> us know what you prefer.  I'd suggest to document the parts that are
> different from any other package in emacs.git in the "Commentary" of
> which-key.el.
>
> I hope that helps, and please let us know if you have any questions.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Justin Burkett]

On Thu, Jun 20, 2024 at 2:25 PM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Justin Burkett <justin@burkett.cc> writes:
>
> > I'd like to echo this question. Up until now, I have managed which-key
> > through a github repo which then gets synced to elpa. I'm now not sure
> > what to do with github and specifically contributions I get through
> > there. I can archive that repo if bugs and contributions should now go
> > through standard emacs channels.
>
> It's basically your decision as the maintainer of which-key.
>
> Org mode, CC mode, and others, have external repositories and merge code
> back and forth.  This would require you to periodically do these merges,
> for example when you release a new version.  This means checking for
> changes in emacs.git and merging them into your tree, and then merging
> the released version into our tree.
>
> Some other packages, for example Gnus and eglot, are now developed fully
> in emacs.git and have abandoned their external repositories.  Bugs for
> those packages are now also always reported on our bug mailing list.
> (We are also okay with preferring bug reports to go elsewhere, but we
> will usually always accept bugs through our regular channels too, and
> then simply forward them to you.)
>
> From the Emacs maintainer point of view, the latter option is always
> going to be the easiest, but again: it's your decision.  So please let
> us know what you prefer.  I'd suggest to document the parts that are
> different from any other package in emacs.git in the "Commentary" of
> which-key.el.
>
> I hope that helps, and please let us know if you have any questions.

Thank you. Yes, that's very helpful. I prefer the latter option, too.
I don't foresee many significant changes to which-key, and would
rather have the process be as simple as possible. I will write up a
notice in the readme on github and archive the project.  There are one
or two pending contributions, but I can send them through the emacs
channels to learn about the process if that's alright.

Best,
Justin

Re: URGENT - which-key FSF contributor status

[Stefan Kangas]

Justin Burkett <justin@burkett.cc> writes:

> Thank you. Yes, that's very helpful. I prefer the latter option, too.
> I don't foresee many significant changes to which-key, and would
> rather have the process be as simple as possible. I will write up a
> notice in the readme on github and archive the project.  There are one
> or two pending contributions, but I can send them through the emacs
> channels to learn about the process if that's alright.

That sounds good, thank you.

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Justin Burkett <justin@burkett.cc> writes:
>
>> Thank you. Yes, that's very helpful. I prefer the latter option, too.
>> I don't foresee many significant changes to which-key, and would
>> rather have the process be as simple as possible. I will write up a
>> notice in the readme on github and archive the project.  There are one
>> or two pending contributions, but I can send them through the emacs
>> channels to learn about the process if that's alright.
>
> That sounds good, thank you.

One point I just noticed, we haven't bumped the version tag.  I just
updated elpa.git to follow the core package, but it won't work for now
until we release a new version.  Are there any specific preferences as
to how to proceed here?  I would have just changed 3.6.0 to 3.6.1.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Justin Burkett]

On Wed, Jul 17, 2024 at 6:17 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > Justin Burkett <justin@burkett.cc> writes:
> >
> >> Thank you. Yes, that's very helpful. I prefer the latter option, too.
> >> I don't foresee many significant changes to which-key, and would
> >> rather have the process be as simple as possible. I will write up a
> >> notice in the readme on github and archive the project.  There are one
> >> or two pending contributions, but I can send them through the emacs
> >> channels to learn about the process if that's alright.
> >
> > That sounds good, thank you.
>
> One point I just noticed, we haven't bumped the version tag.  I just
> updated elpa.git to follow the core package, but it won't work for now
> until we release a new version.  Are there any specific preferences as
> to how to proceed here?  I would have just changed 3.6.0 to 3.6.1.
>

That seems fine to me.

Justin

> --
>         Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Justin Burkett <justin@burkett.cc> writes:

> On Wed, Jul 17, 2024 at 6:17 PM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>> > Justin Burkett <justin@burkett.cc> writes:
>> >
>> >> Thank you. Yes, that's very helpful. I prefer the latter option, too.
>> >> I don't foresee many significant changes to which-key, and would
>> >> rather have the process be as simple as possible. I will write up a
>> >> notice in the readme on github and archive the project.  There are one
>> >> or two pending contributions, but I can send them through the emacs
>> >> channels to learn about the process if that's alright.
>> >
>> > That sounds good, thank you.
>>
>> One point I just noticed, we haven't bumped the version tag.  I just
>> updated elpa.git to follow the core package, but it won't work for now
>> until we release a new version.  Are there any specific preferences as
>> to how to proceed here?  I would have just changed 3.6.0 to 3.6.1.
>>
>
> That seems fine to me.

OK, I'll update this on the master branch.

> Justin
>
>> --
>>         Philip Kaludercic on peregrine
>
>

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: jb@jeremybryant.net,  justin@burkett.cc,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 12:58:00 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  Justin Burkett <justin@burkett.cc>,
> >>  emacs-devel@gnu.org
> >> Date: Sat, 15 Jun 2024 09:05:52 +0000
> >> 
> >> We have found out that Bar has completed the CA.  That means we can
> >> proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?
> >
> > Yes.  If you do this _very_ quickly.
> 
> I have pushed a working branch under "feature/which-key-in-core".
> Please take a look to see if I missed something obvious, and if it seems
> fine I can merge it into master right away.

Thanks.  A couple of comments:

The :version tags of the defcustoms and deffaces will need to change.

Some faces use attributes such as underline or bold without testing
for their availability first and without offering any fallbacks if
they aren't.  Is it okay to have those displayed using the default
face?

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: jb@jeremybryant.net,  justin@burkett.cc,  emacs-devel@gnu.org
>> Date: Sat, 15 Jun 2024 12:58:00 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Cc: Eli Zaretskii <eliz@gnu.org>,  Justin Burkett <justin@burkett.cc>,
>> >>  emacs-devel@gnu.org
>> >> Date: Sat, 15 Jun 2024 09:05:52 +0000
>> >> 
>> >> We have found out that Bar has completed the CA.  That means we can
>> >> proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?
>> >
>> > Yes.  If you do this _very_ quickly.
>> 
>> I have pushed a working branch under "feature/which-key-in-core".
>> Please take a look to see if I missed something obvious, and if it seems
>> fine I can merge it into master right away.
>
> Thanks.  A couple of comments:
>
> The :version tags of the defcustoms and deffaces will need to change.

I can change the current tags to :package-version and also add :version
"30.1" tags.

> Some faces use attributes such as underline or bold without testing
> for their availability first and without offering any fallbacks if
> they aren't.  Is it okay to have those displayed using the default
> face?

My guess is that this is just decoration, but someone who actually uses
which-key should comment on that.  Specifically it appears to involve
the

- which-key-special-key-face
- which-key-highlighted-command-face

faces.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Justin Burkett]

On Sat, Jun 15, 2024 at 1:09 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: jb@jeremybryant.net,  justin@burkett.cc,  emacs-devel@gnu.org
> >> Date: Sat, 15 Jun 2024 12:58:00 +0000
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> From: Philip Kaludercic <philipk@posteo.net>
> >> >> Cc: Eli Zaretskii <eliz@gnu.org>,  Justin Burkett <justin@burkett.cc>,
> >> >>  emacs-devel@gnu.org
> >> >> Date: Sat, 15 Jun 2024 09:05:52 +0000
> >> >>
> >> >> We have found out that Bar has completed the CA.  That means we can
> >> >> proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?
> >> >
> >> > Yes.  If you do this _very_ quickly.
> >>
> >> I have pushed a working branch under "feature/which-key-in-core".
> >> Please take a look to see if I missed something obvious, and if it seems
> >> fine I can merge it into master right away.
> >
> > Thanks.  A couple of comments:
> >
> > The :version tags of the defcustoms and deffaces will need to change.
>
> I can change the current tags to :package-version and also add :version
> "30.1" tags.
>
> > Some faces use attributes such as underline or bold without testing
> > for their availability first and without offering any fallbacks if
> > they aren't.  Is it okay to have those displayed using the default
> > face?
>
> My guess is that this is just decoration, but someone who actually uses
> which-key should comment on that.  Specifically it appears to involve
> the
>
> - which-key-special-key-face
> - which-key-highlighted-command-face
>
> faces.

That's right. These faces are there to optionally highlight some of
the bindings. If a font does not support underlining or bold face, I'm
guessing these faces would just ignore that property. Is that right?
If so, these faces will just fall back to the unhighlighted version.

I'm wondering if there is a recommended way to handle the circumstance
where you want to highlight an entry with say bold face and have a
fallback in place in case bold is not available. I suppose we could
just pick a different fallback color.

Justin

>
> --
>         Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Eli Zaretskii]

> From: Justin Burkett <justin@burkett.cc>
> Date: Sat, 15 Jun 2024 13:42:40 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, jb@jeremybryant.net, emacs-devel@gnu.org
> 
> I'm wondering if there is a recommended way to handle the circumstance
> where you want to highlight an entry with say bold face and have a
> fallback in place in case bold is not available. I suppose we could
> just pick a different fallback color.

I think you can find examples in our sources.  In general, you could
use a different attribute (e.g., underline instead of bold), or you
could use a special color.

Re: URGENT - which-key FSF contributor status

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Philip Kaludercic <philipk@posteo.net>
>>> Cc: jb@jeremybryant.net,  justin@burkett.cc,  emacs-devel@gnu.org
>>> Date: Sat, 15 Jun 2024 12:58:00 +0000
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> >> From: Philip Kaludercic <philipk@posteo.net>
>>> >> Cc: Eli Zaretskii <eliz@gnu.org>,  Justin Burkett <justin@burkett.cc>,
>>> >>  emacs-devel@gnu.org
>>> >> Date: Sat, 15 Jun 2024 09:05:52 +0000
>>> >> 
>>> >> We have found out that Bar has completed the CA.  That means we can
>>> >> proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?
>>> >
>>> > Yes.  If you do this _very_ quickly.
>>> 
>>> I have pushed a working branch under "feature/which-key-in-core".
>>> Please take a look to see if I missed something obvious, and if it seems
>>> fine I can merge it into master right away.
>>
>> Thanks.  A couple of comments:
>>
>> The :version tags of the defcustoms and deffaces will need to change.
>
> I can change the current tags to :package-version and also add :version
> "30.1" tags.

This has been done.

>> Some faces use attributes such as underline or bold without testing
>> for their availability first and without offering any fallbacks if
>> they aren't.  Is it okay to have those displayed using the default
>> face?
>
> My guess is that this is just decoration, but someone who actually uses
> which-key should comment on that.  Specifically it appears to involve
> the
>
> - which-key-special-key-face
> - which-key-highlighted-command-face

I think that it should be OK for 'which-key-special-key-face' to use
:bold, because it is accompanied by :inverse-video that carries most of
the visual effect.

As for 'which-key-highlighted-command-face', I have removed the
:underline and instead let it inherit from 'highlight'.  I hope nobody
objects to that.  By default it doesn't make any difference, as it only
affects people who have customised 'which-key-highlighted-command-list'.

IMO we could merge the branch into master.

> faces.

-- 
	Philip Kaludercic on peregrine

Re: URGENT - which-key FSF contributor status

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: jb@jeremybryant.net,  justin@burkett.cc,  emacs-devel@gnu.org
> Date: Tue, 18 Jun 2024 08:49:47 +0000
> 
> >> The :version tags of the defcustoms and deffaces will need to change.
> >
> > I can change the current tags to :package-version and also add :version
> > "30.1" tags.
> 
> This has been done.
> 
> >> Some faces use attributes such as underline or bold without testing
> >> for their availability first and without offering any fallbacks if
> >> they aren't.  Is it okay to have those displayed using the default
> >> face?
> >
> > My guess is that this is just decoration, but someone who actually uses
> > which-key should comment on that.  Specifically it appears to involve
> > the
> >
> > - which-key-special-key-face
> > - which-key-highlighted-command-face
> 
> I think that it should be OK for 'which-key-special-key-face' to use
> :bold, because it is accompanied by :inverse-video that carries most of
> the visual effect.
> 
> As for 'which-key-highlighted-command-face', I have removed the
> :underline and instead let it inherit from 'highlight'.  I hope nobody
> objects to that.  By default it doesn't make any difference, as it only
> affects people who have customised 'which-key-highlighted-command-list'.
> 
> IMO we could merge the branch into master.

Thanks, I think it's okay to land this on master.

Re: URGENT - which-key FSF contributor status

[Jeremy Bryant]

Philip Kaludercic <philipk@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Philip Kaludercic <philipk@posteo.net>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  Justin Burkett <justin@burkett.cc>,
>>>  emacs-devel@gnu.org
>>> Date: Sat, 15 Jun 2024 09:05:52 +0000
>>> 
>>> We have found out that Bar has completed the CA.  That means we can
>>> proceed with adding which-key, perhaps even by Emacs 30 (Eli?)?
>>
>> Yes.  If you do this _very_ quickly.
>
> I have pushed a working branch under "feature/which-key-in-core".

Thanks, this is based on the latest upstream, LGTM

> Please take a look to see if I missed something obvious, and if it seems
> fine I can merge it into master right away.