From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [NonGNU ELPA] 11 new packages! Date: Sun, 27 Nov 2022 08:11:27 +0000 Message-ID: <8735a46cls.fsf@posteo.net> References: <87r0y6ug9z.fsf@disroot.org> <87y1sct2hp.fsf@posteo.net> <87k03vf5m8.fsf@disroot.org> <87edu2narn.fsf@posteo.net> <8735aieqtr.fsf@disroot.org> <87cz9mlq3o.fsf@posteo.net> <875yfdd5ad.fsf@disroot.org> <87v8n2zwc6.fsf@posteo.net> <87cz9arw7t.fsf@disroot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30058"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs Developer List To: Akib Azmain Turja Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 27 09:12:25 2022 Return-path: Envelope-to: ged-emacs-devel@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 1ozCm0-0007ek-AG for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Nov 2022 09:12:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozClC-0001ZF-NW; Sun, 27 Nov 2022 03:11:34 -0500 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 1ozClB-0001Z7-IC for emacs-devel@gnu.org; Sun, 27 Nov 2022 03:11:33 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozCl8-0007lN-1l for emacs-devel@gnu.org; Sun, 27 Nov 2022 03:11:32 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 08CF1240026 for ; Sun, 27 Nov 2022 09:11:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1669536688; bh=RNbIpdsm66FjzBaAFjJuiGsQl1iktEQ9pOiyJONBXTQ=; h=From:To:Cc:Subject:Date:From; b=O//9o/UUVwGmbm3SNiInD8DVyz9fyejgZZq3OCMwEBOm+AFylYYrf8yYo4ssFPZEb LVyviJlh7NEWrjj5Ylo733+H7cZS8WuMNjuvxXKUUeW3WpQ4Piena64WAOk6tc8+dx MO5Je5QTk7CcveGMAxB5IJZG8gj6XfcMsbROnaOvZmJPXmAwq7HnEcw/2U873C3TKP ZrVnXia+himafGeAmS3dStgmB319W9k5wjItjpItJz9dNiqqmmGV2GYnaQD6kdEb1n KsvAZZJGo16hlUNF614UAzZTqgSNvnoYN/lpDRLBVpMcqqDs++Rg4WtF1apnIetezC +/s1MQS7L0LDQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NKhBk3qS7z9rxM; Sun, 27 Nov 2022 09:11:25 +0100 (CET) In-Reply-To: <87cz9arw7t.fsf@disroot.org> (Akib Azmain Turja's message of "Sat, 26 Nov 2022 13:49:58 +0600") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300619 Archived-At: Akib Azmain Turja writes: >> ;;;###autoload >> (defun gnu-indent-region (beg end) >> @@ -88,14 +87,15 @@ When called non-interactively, indent text between B= EG and END." >> (send-region process beg end) >> (process-send-eof process) >> (redisplay) >> - (while (process-live-p process) >> - (sleep-for 0.01)) >> + (while (accept-process-output process nil 10)) > > MILLISEC argument is obsolete, I used SECONDS instead. Actually, this change might have been pointless. I misremembed the warning from (elisp) Accepting Output, that said you shouldn't combine `accept-process-output' and `process-live-p', but what you were doing was probably harmless. I guess the real question is why you don't use a synchronous process? indent usually isn't that slow. >> (error "GNU Indent exited with non-zero status")) >> (save-restriction >> (let ((inhibit-read-only t)) >> (narrow-to-region beg end) >> + ;; Perhaps something should be done to try an preserve >> + ;; the point after indentation? >> (insert-file-contents temp-file nil nil nil >> t)))) > > On my computer, the point doesn't move relative to text, because the > fifth argument to insert-file-contents is t. My bad then. >> (delete-file temp-file))) >> @@ -108,11 +108,24 @@ When called non-interactively, indent text between= BEG and END." >> (interactive) >> (gnu-indent-region (point-min) (point-max))) >> >> +;; A little suggestion >> +;;;###autoload >> +(defun gnu-indent-defun-or-fill (arg) >> + "Indent current function with GNU Indent. >> +If point is in a comment, call `fill-paragraph' instead. A >> +prefix argument ARG is passed to `fill-paragraph'." >> + (interactive "P") >> + (if (nth 8 (syntax-ppss)) ;if in a comment >> + (fill-paragraph arg) >> + (let ((bounds (bounds-of-thing-at-point 'defun))) >> + (if (consp bounds) >> + (gnu-indent-region (car bounds) (cdr bounds)) >> + (user-error "No defun at point"))))) >> + > > Great idea. But would it cause problem to assign copyright if I take > your change? (AFAIK you've completed paperwork, but in this case you're > not contributing to FSF-copyrighted code, so is this change covered by > your paperwork? Right now, no, you're the copyright holder. (According > to Section 2 of copyright assignment agreement sent to me.)) I don't think there should be an issue, as we want to add the package to NonGNU ELPA. If the package is later moved to GNU ELPA, then my CA should cover it. >> devhelp: >> >> diff --git a/devhelp.el b/devhelp.el >> index 6b3d9a1ce9..05aeb1e18e 100644 >> --- a/devhelp.el >> +++ b/devhelp.el >> @@ -48,6 +48,10 @@ >> ;; "~/.guix-profile/share/doc/" >> ;; "~/.guix-profile/share/gtk-doc/html/")) >> >> +;; Do you think it makes sense to automatically detect this (if the >> +;; user has a ~/.guix-profile directory) and make the changes to the >> +;; default value? >> + > > Yes, it makes sense. But I didn't find any way to detected the > directories, except heuristics. What would the problem be with checking the existence of these specific (or other well known directories)? (append [default value] (and (file-exists-p "~/.guix-profile/share/doc/" (list "~/.guix-profile/share/doc/"))) (and (file-exists-p "~/.guix-profile/share/gtk-doc/html/") (list "~/.guix-profile/share/gtk-doc/html/")))) >> @@ -219,6 +224,7 @@ If a single file was opened, only show that book's t= able of contents." >> See `devhelp-toc' for more details." >> (let ((inhibit-read-only t)) >> (erase-buffer) >> + ;; Why not prepare the document in SXML and then use `dom-print'? >> (insert >> "Table of contents
    " >> (let ((book-tocs > > Hmm, that would be a cleaner approach. Now I need to research the > format of SXML. This gives a brief demonstration: (dom-print '(tag ((key . "value")) (sub-tag () "body"))) ;; Output: body >> (defgroup why-this nil >> "Show why the current line contains this." >> :group 'tools >> @@ -64,6 +68,7 @@ the first argument is the command (which is a symbol): >> `:author' Name of the author. >> `:time' Time of change (local). >> `:desc' Single line description of change." >> + ;; Would it make sense to use a `cl-defstruct'? >> :type 'hook >> :options (list #'why-this-git >> #'why-this-hg) > > Maybe. But I think the plist approach is simpler and good enough. My fear is that it is less robust, but my fear is probably unreasonable. >> @@ -364,6 +370,7 @@ TIME-FORMAT is used to format data." >> 'solaire-region-face >> 'region)) >> ('line >> + ;; Looks like a `cond' to me >> (if (bound-and-true-p hl-line-mode) >> (if (bound-and-true-p solaire-mode) >> 'solaire-hl-line-face > > Yes, but I think its more efficient. (IIUC cond would test hl-line-mode > before returning why-this-face.) I don't think there would be a big difference. The transformation I had in mind was something along these lines: (if foo (if bar (if baz 0 1) 2) 3) =E2=87=9D (cond ((not foo) 3) ((not bar) 2) ((not baz) 1) (t 0)) >> @@ -537,6 +544,11 @@ Actually the supported backend is returned." >> (* (- (nth i b-color) >> (nth i a-color)) >> ratio))))) >> + ;; Note that RGB interpolation doesn't always behave the way you >> + ;; think it does. You'd have to convert it into some other color >> + ;; space like CIELAB to get perceptual mixing right (but even that >> + ;; is trying because it requires some kind of a white-reference >> + ;; point). >> (color-rgb-to-hex (funcall mix 0) >> (funcall mix 1) >> (funcall mix 2) > > Any edge case of my code? Not an edge-case, just a mathematical/physical problem. Maybe https://www.alanzucconi.com/2016/01/06/colour-interpolation/ can help explain what I had in mind (it also indicates that interpolation in the HSV color space might be good enough of a fix).