Re: Incorporate package macrostep into Emacs core

[Eli Zaretskii]

> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org,  j.j.oddie@gmail.com,
>  stefankangas@gmail.com,  jonas@bernoul.li
> Date: Mon, 18 Mar 2024 22:58:02 +0000
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Jeremy Bryant <jb@jeremybryant.net>
> >> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org,  j.j.oddie@gmail.com,
> >>   stefan@marxist.se,  stefankangas@gmail.com,  jonas@bernoul.li
> >> Date: Sun, 17 Mar 2024 21:48:08 +0000
> >> 
> >> Manual?
> >> Should the documentation for macrostep be included in the Emacs Lisp
> >> manual section Macros?
> >
> > Yes, I think so.
> >
> > Please also provide a suitable entry for NEWS.
> >
> >> Code?
> >> The main file is attached for convenience, from the orphanage upstream
> >> (https://github.com/emacsorphanage/macrostep). 
> >> Are any changes needed before this is merged into Emacs?
> >> I volunteer to write some code towards this, please let me know.
> >
> > Please add :version tags to all the defcustom's and defface's.
> >
> >> (define-obsolete-variable-alias 'macrostep-mode-keymap
> >> 'macrostep-mode-map "2023")
> >> (define-obsolete-variable-alias 'macrostep-keymap 'macrostep-mode-map 
> >> "2022")
> >
> > The years there should be changed to Emacs versions, I think.
> >
> >> (defvar macrostep-mode-map
> >>   (let ((map (make-sparse-keymap)))
> >>     (define-key map (kbd "RET") #'macrostep-expand)
> >>     (define-key map "=" #'macrostep-expand)
> >>     (define-key map "e" #'macrostep-expand)
> >
> > Bonus points for converting this into defvar-keymap.
> >
> >> ;; Local Variables:
> >> ;; indent-tabs-mode: nil
> >> ;; End:
> >
> > I think this should be deleted, as this is now the default in ELisp
> > buffers.
> 
> OK, I'll start working on these.

Thanks.

> For the macrostep commits, is it easier for future integration that this
> is done externally and submitted in one go, or would something like a
> new macrostep branch in the Emacs tree be more appropriate?

A branch is preferable if you want people to be able to use and test
the package before it lands.  If this package is already in use by
enough people, so you can be reasonably sure it doesn't have any grave
problems, a branch is not required, and you can submit everything as a
single patch.