* Re: URGENT - which-key FSF contributor status [not found] ` <87msp6o9o4.fsf@jeremybryant.net> @ 2024-06-15 9:05 ` Philip Kaludercic 2024-06-15 12:30 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Philip Kaludercic @ 2024-06-15 9:05 UTC (permalink / raw) To: Jeremy Bryant; +Cc: Eli Zaretskii, Justin Burkett, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 9:05 ` URGENT - which-key FSF contributor status Philip Kaludercic @ 2024-06-15 12:30 ` Eli Zaretskii 2024-06-15 12:58 ` Philip Kaludercic 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2024-06-15 12:30 UTC (permalink / raw) To: Philip Kaludercic; +Cc: jb, justin, emacs-devel > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 12:30 ` Eli Zaretskii @ 2024-06-15 12:58 ` Philip Kaludercic 2024-06-15 14:36 ` Stefan Kangas ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Philip Kaludercic @ 2024-06-15 12:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: jb, justin, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 12:58 ` Philip Kaludercic @ 2024-06-15 14:36 ` Stefan Kangas 2024-06-18 19:06 ` Stefan Kangas 2024-06-15 15:19 ` Eli Zaretskii 2024-06-16 19:07 ` Jeremy Bryant 2 siblings, 1 reply; 22+ messages in thread From: Stefan Kangas @ 2024-06-15 14:36 UTC (permalink / raw) To: Philip Kaludercic, Eli Zaretskii; +Cc: jb, justin, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 14:36 ` Stefan Kangas @ 2024-06-18 19:06 ` Stefan Kangas 2024-06-18 19:23 ` Philip Kaludercic 0 siblings, 1 reply; 22+ messages in thread From: Stefan Kangas @ 2024-06-18 19:06 UTC (permalink / raw) To: Philip Kaludercic, Eli Zaretskii; +Cc: jb, justin, emacs-devel 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). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-18 19:06 ` Stefan Kangas @ 2024-06-18 19:23 ` Philip Kaludercic 2024-06-18 19:30 ` Stefan Kangas 0 siblings, 1 reply; 22+ messages in thread From: Philip Kaludercic @ 2024-06-18 19:23 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, jb, justin, emacs-devel [-- 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-18 19:23 ` Philip Kaludercic @ 2024-06-18 19:30 ` Stefan Kangas 2024-06-18 19:41 ` Philip Kaludercic 0 siblings, 1 reply; 22+ messages in thread From: Stefan Kangas @ 2024-06-18 19:30 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Eli Zaretskii, jb, justin, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-18 19:30 ` Stefan Kangas @ 2024-06-18 19:41 ` Philip Kaludercic 2024-06-18 19:42 ` Stefan Kangas 0 siblings, 1 reply; 22+ messages in thread From: Philip Kaludercic @ 2024-06-18 19:41 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, jb, justin, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-18 19:41 ` Philip Kaludercic @ 2024-06-18 19:42 ` Stefan Kangas 2024-06-18 21:41 ` Philip Kaludercic 0 siblings, 1 reply; 22+ messages in thread From: Stefan Kangas @ 2024-06-18 19:42 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Eli Zaretskii, jb, justin, emacs-devel Philip Kaludercic <philipk@posteo.net> writes: > Very well, then I'll proceed to merge the branch into master. Great, thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-18 19:42 ` Stefan Kangas @ 2024-06-18 21:41 ` Philip Kaludercic 2024-06-20 14:26 ` Justin Burkett 0 siblings, 1 reply; 22+ messages in thread From: Philip Kaludercic @ 2024-06-18 21:41 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, jb, justin, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-18 21:41 ` Philip Kaludercic @ 2024-06-20 14:26 ` Justin Burkett 2024-06-20 18:25 ` Stefan Kangas 0 siblings, 1 reply; 22+ messages in thread From: Justin Burkett @ 2024-06-20 14:26 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Stefan Kangas, Eli Zaretskii, jb, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-20 14:26 ` Justin Burkett @ 2024-06-20 18:25 ` Stefan Kangas 2024-06-20 19:22 ` Philip Kaludercic 2024-06-20 21:16 ` Justin Burkett 0 siblings, 2 replies; 22+ messages in thread From: Stefan Kangas @ 2024-06-20 18:25 UTC (permalink / raw) To: Justin Burkett, Philip Kaludercic; +Cc: Eli Zaretskii, jb, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-20 18:25 ` Stefan Kangas @ 2024-06-20 19:22 ` Philip Kaludercic 2024-06-20 21:16 ` Justin Burkett 1 sibling, 0 replies; 22+ messages in thread From: Philip Kaludercic @ 2024-06-20 19:22 UTC (permalink / raw) To: Stefan Kangas; +Cc: Justin Burkett, Eli Zaretskii, jb, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-20 18:25 ` Stefan Kangas 2024-06-20 19:22 ` Philip Kaludercic @ 2024-06-20 21:16 ` Justin Burkett 2024-06-20 21:45 ` Stefan Kangas 1 sibling, 1 reply; 22+ messages in thread From: Justin Burkett @ 2024-06-20 21:16 UTC (permalink / raw) To: Stefan Kangas; +Cc: Philip Kaludercic, Eli Zaretskii, jb, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-20 21:16 ` Justin Burkett @ 2024-06-20 21:45 ` Stefan Kangas 0 siblings, 0 replies; 22+ messages in thread From: Stefan Kangas @ 2024-06-20 21:45 UTC (permalink / raw) To: Justin Burkett; +Cc: Philip Kaludercic, Eli Zaretskii, jb, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 12:58 ` Philip Kaludercic 2024-06-15 14:36 ` Stefan Kangas @ 2024-06-15 15:19 ` Eli Zaretskii 2024-06-15 17:09 ` Philip Kaludercic 2024-06-16 19:07 ` Jeremy Bryant 2 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2024-06-15 15:19 UTC (permalink / raw) To: Philip Kaludercic; +Cc: jb, justin, emacs-devel > 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 15:19 ` Eli Zaretskii @ 2024-06-15 17:09 ` Philip Kaludercic 2024-06-15 17:42 ` Justin Burkett 2024-06-18 8:49 ` Philip Kaludercic 0 siblings, 2 replies; 22+ messages in thread From: Philip Kaludercic @ 2024-06-15 17:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: jb, justin, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 17:09 ` Philip Kaludercic @ 2024-06-15 17:42 ` Justin Burkett 2024-06-15 17:50 ` Eli Zaretskii 2024-06-18 8:49 ` Philip Kaludercic 1 sibling, 1 reply; 22+ messages in thread From: Justin Burkett @ 2024-06-15 17:42 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Eli Zaretskii, jb, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 17:42 ` Justin Burkett @ 2024-06-15 17:50 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2024-06-15 17:50 UTC (permalink / raw) To: Justin Burkett; +Cc: philipk, jb, emacs-devel > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 17:09 ` Philip Kaludercic 2024-06-15 17:42 ` Justin Burkett @ 2024-06-18 8:49 ` Philip Kaludercic 2024-06-18 17:37 ` Eli Zaretskii 1 sibling, 1 reply; 22+ messages in thread From: Philip Kaludercic @ 2024-06-18 8:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: jb, justin, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-18 8:49 ` Philip Kaludercic @ 2024-06-18 17:37 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2024-06-18 17:37 UTC (permalink / raw) To: Philip Kaludercic; +Cc: jb, justin, emacs-devel > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: URGENT - which-key FSF contributor status 2024-06-15 12:58 ` Philip Kaludercic 2024-06-15 14:36 ` Stefan Kangas 2024-06-15 15:19 ` Eli Zaretskii @ 2024-06-16 19:07 ` Jeremy Bryant 2 siblings, 0 replies; 22+ messages in thread From: Jeremy Bryant @ 2024-06-16 19:07 UTC (permalink / raw) To: Philip Kaludercic; +Cc: Eli Zaretskii, justin, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2024-06-20 21:45 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87le4r98m9.fsf@jeremybryant.net>
[not found] ` <86le4rjv9p.fsf@gnu.org>
[not found] ` <87a5l78kc0.fsf@posteo.net>
[not found] ` <87msp6o9o4.fsf@jeremybryant.net>
2024-06-15 9:05 ` URGENT - which-key FSF contributor status Philip Kaludercic
2024-06-15 12:30 ` Eli Zaretskii
2024-06-15 12:58 ` Philip Kaludercic
2024-06-15 14:36 ` Stefan Kangas
2024-06-18 19:06 ` Stefan Kangas
2024-06-18 19:23 ` Philip Kaludercic
2024-06-18 19:30 ` Stefan Kangas
2024-06-18 19:41 ` Philip Kaludercic
2024-06-18 19:42 ` Stefan Kangas
2024-06-18 21:41 ` Philip Kaludercic
2024-06-20 14:26 ` Justin Burkett
2024-06-20 18:25 ` Stefan Kangas
2024-06-20 19:22 ` Philip Kaludercic
2024-06-20 21:16 ` Justin Burkett
2024-06-20 21:45 ` Stefan Kangas
2024-06-15 15:19 ` Eli Zaretskii
2024-06-15 17:09 ` Philip Kaludercic
2024-06-15 17:42 ` Justin Burkett
2024-06-15 17:50 ` Eli Zaretskii
2024-06-18 8:49 ` Philip Kaludercic
2024-06-18 17:37 ` Eli Zaretskii
2024-06-16 19:07 ` Jeremy Bryant
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).