[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Incorporate package macrostep into Emacs core
From: |
Eli Zaretskii |
Subject: |
Re: Incorporate package macrostep into Emacs core |
Date: |
Tue, 19 Mar 2024 14:26:40 +0200 |
> 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.
- Re: Incorporate package macrostep into Emacs core, (continued)
- Re: Incorporate package macrostep into Emacs core, Gerd Möllmann, 2024/03/19
- Re: Incorporate package macrostep into Emacs core, Philip Kaludercic, 2024/03/19
- Re: Incorporate package macrostep into Emacs core, Gerd Möllmann, 2024/03/19
- Re: Incorporate package macrostep into Emacs core, Philip Kaludercic, 2024/03/19
- Re: Incorporate package macrostep into Emacs core, Gerd Möllmann, 2024/03/19
- Re: Incorporate package macrostep into Emacs core, Jonathan Oddie, 2024/03/19
- Re: Incorporate package macrostep into Emacs core, Jeremy Bryant, 2024/03/19
- Re: Incorporate package macrostep into Emacs core, Eli Zaretskii, 2024/03/18
- Re: Incorporate package macrostep into Emacs core, Stefan Monnier, 2024/03/18
- Re: Incorporate package macrostep into Emacs core, Jeremy Bryant, 2024/03/18
- Re: Incorporate package macrostep into Emacs core,
Eli Zaretskii <=