all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: 67916@debbugs.gnu.org,
	"Mattias Engdegård" <mattias.engdegard@gmail.com>,
	"Stefan Monnier" <monnier@iro.umontreal.ca>
Subject: bug#67916: 30.0.50; No lexical-binding directive warning in -pkg.el files
Date: Wed, 20 Dec 2023 18:54:49 +0000	[thread overview]
Message-ID: <87sf3wbt6u.fsf@posteo.net> (raw)
In-Reply-To: <8734vwkaqi.fsf@epfl.ch> (Basil L. Contovounesios's message of "Wed, 20 Dec 2023 19:08:37 +0100")

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Philip Kaludercic [2023-12-20 15:14 +0000] wrote:
>
>> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>>
>>> package-vc--generate-description-file currently passes:
>>>   :kind 'vc
>>> unquoted to define-package, which results in the -pkg.el contents:
>>>   (define-package ... :kind vc ... :keywords '(...) ...)
>>> Note the difference in quoting between :kind and :keywords.  Is this
>>> intentional?  Or can/should :kind pass through macroexp-quote as well?
>>
>> This is not intentional, if anything a lucky oversight.
>
> Lucky in the sense that it's preferable this way, or just an accident? ;)

The latter.

>>> Questions for Stefan:
>>>
>>> - Which version of Emacs can/does elpa-admin.el assume?
>>
>> All I can say is that the ELPA build server, the main user of
>> elpa-admin.el, has Emacs 28.2 installed.
>
> I'm wondering because elpa-admin.el seems to contain some compatibility
> code for Emacs 26 (elpaa--select-revision, elpaa--write-pkg-file) and
> Emacs versions <28 (elpaa--get-section, elpaa--html-build-doc).

My guess is that it was just not removed, but I'll just let Stefan
explain that.

>>>  (defgroup package nil
>>>    "Manager for Emacs Lisp packages."
>>>    :group 'applications
>>> -  :version "24.1")
>>> +  :group 'tools
>>> +  :version "30.1")
>>
>> I am not sure if bumping :version is necessary (here and above).
>
> I think it's unnecessary in the sense that I don't know of any place
> where this information is displayed, but otherwise I thought it was good
> form to do this since any change in :groups is user-visible.

My understanding was that this information is supposed to indicate when
the group was added, while each member of a group that has since been
changed would have a newer :version tag.

>>>  (define-inline package-vc-p (pkg-desc)
>>>    "Return non-nil if PKG-DESC is a VC package."
>>> -  (inline-letevals (pkg-desc)
>>> -    (inline-quote (eq (package-desc-kind ,pkg-desc) 'vc))))
>>> +  (inline-quote (eq (package-desc-kind ,pkg-desc) 'vc)))
>>> +
>>> +(define-inline package--unquote (arg)
>>> +  "Return ARG without its surrounding `quote', if any."
>>> +  (inline-letevals (arg)
>>> +    (inline-quote (if (eq (car-safe ,arg) 'quote) (cadr ,arg) ,arg))))
>>
>> Honestly, the usage of define-inline was probably a premature
>> optimisation on my part, I don't think we really need it here either.
>
> You mean, you prefer package--unquote being a plain function?

Yes.

> [ To be honest, I'm slightly inclined to add this to macroexp.el
>   instead, since it's a somewhat common operation. ]

My only concern is that this would slightly complicate the initiative of
adding package.el to GNU ELPA, if that is to proceed at all.

>> You removed (require 'inline) anyway, or is it now preloaded?
>
> define-inline is autoloaded, and there are no other in-tree occurrences
> of (require 'inline).

Nevermind then.

>>> +;; Potentially also used in elpa.git.
>>> +(defun package--write-description-file ( file name version doc reqs extras
>>> +                                         &optional extra-props verbose)
>>> +  "Write a `define-package' declaration to FILE.
>>> +Absolute FILE names the -pkg.el description file.
>>> +NAME, VERSION, and DOC are the leading, and EXTRA-PROPS the
>>> +trailing, arguments of `define-package'.
>>> +REQS and EXTRAS are the eponymous `package-desc' slots.
>>> +Non-nil VERBOSE means display \"Wrote file\" message."
>>> +  (let* ((src (replace-regexp-in-string (rx "-pkg.el" eos) ".el"
>>> +                                        (file-name-nondirectory file) t t))
>>> +         (def `(define-package ,name ,version ,doc
>>> +                 ,(macroexp-quote
>>> +                   ;; Turn requirement version lists into string form.
>>> +                   (mapcar (lambda (elt)
>>> +                             (list (car elt)
>>> +                                   (package-version-join (cadr elt))))
>>> +                           reqs))
>>> +                 ,@extra-props
>>> +                 ,@(package--alist-to-plist-args extras)))
>>> +         (print-cfg '((length . nil)
>>> +                      (level . nil)
>>> +                      (quoted . t)))
>>> +         (str (concat ";;; Generated package description from " src
>>> +                      "  -*- no-byte-compile: t; lexical-binding: t -*-\n"
>>> +                      (prin1-to-string def nil print-cfg)
>>> +                      "\n")))
>>> +    (write-region str nil file nil (unless verbose 'silent))))
>>
>> I like this, but we should really make sure that there are no hidden
>> edge-cases that might cause problems.
>
> How do we find them if they're hidden? ;)
> Did you have something specific in mind?

IIRC there were some bugs related to the generation of -pkg.el files,
but I can't find them right now.  I'll ping you if I find anything.

> Thanks,





  reply	other threads:[~2023-12-20 18:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-19 21:49 bug#67916: 30.0.50; No lexical-binding directive warning in -pkg.el files Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-19 22:15 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-20 15:14   ` Philip Kaludercic
2023-12-20 18:08     ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-20 18:54       ` Philip Kaludercic [this message]
2023-12-20 20:43       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sf3wbt6u.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=67916@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=mattias.engdegard@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.