unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
@ 2021-10-06 10:14 Lars Ingebrigtsen
  2021-10-06 14:01 ` Stephen Gildea
  0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-06 10:14 UTC (permalink / raw)
  To: 51056; +Cc: Stephen Gildea


Emacs 29 has grown a new function to define keymaps, `define-keymap'
somewhat inspired by the more than two-decades-old macro
`gnus-define-keys'.

So I've now replaced all the usages of `gnus-define-keys' in Emacs 29
with `define-keymap' and was about to make `gnus-define-keys' obsolete,
but that macro is used by mh-e, too.  mh-e is also distributed outside
Emacs, if I understand correctly, so this code can't be converted.

Stephen, would it make sense to copy the Gnus macro into mh-e, and
rename it mh-define-keys?  That way `gnus-define-keys' could be
obsoleted.

A different solution would be to write a new mh-define-keymap that more
closely mimics the new `define-keymap' function, and then use it instead
in mh-e -- that's probably a better long-term solution, because you
could then remove the mh-define-keymap function at some later date (when
you shift the mh-e target to Emacs 29+).


In GNU Emacs 29.0.50 (build 36, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-10-06 built on elva
Repository revision: 8e37466efc36dab153a9c784ce1ff41c5a663318
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no






^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
  2021-10-06 10:14 bug#51056: 29.0.50; Making `gnus-define-keys' obsolete Lars Ingebrigtsen
@ 2021-10-06 14:01 ` Stephen Gildea
  2021-10-06 21:09   ` Stefan Kangas
                     ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Stephen Gildea @ 2021-10-06 14:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 51056, mh-e-devel

+mh-e-devel

Lars Ingebrigtsen <larsi@gnus.org> wrote to me:

>   Emacs 29 has grown a new function to define keymaps, `define-keymap'
>   somewhat inspired by the more than two-decades-old macro
>   `gnus-define-keys'.
>   
>   So I've now replaced all the usages of `gnus-define-keys' in Emacs 29
>   with `define-keymap' and was about to make `gnus-define-keys' obsolete,
>   but that macro is used by mh-e, too.  mh-e is also distributed outside
>   Emacs, if I understand correctly, so this code can't be converted.
>   
>   Stephen, would it make sense to copy the Gnus macro into mh-e, and
>   rename it mh-define-keys?  That way `gnus-define-keys' could be
>   obsoleted.
>   
>   A different solution would be to write a new mh-define-keymap that more
>   closely mimics the new `define-keymap' function, and then use it instead
>   in mh-e -- that's probably a better long-term solution, because you
>   could then remove the mh-define-keymap function at some later date (when
>   you shift the mh-e target to Emacs 29+).

MH-E is no longer developed nor distributed separately from GNU Emacs,
since maybe 2015.

You can update the MH-E part of the Emacs source tree to use Emacs 29
features.  No compatibility is needed.

Thanks for checking,

 < Stephen





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
  2021-10-06 14:01 ` Stephen Gildea
@ 2021-10-06 21:09   ` Stefan Kangas
  2021-10-07  2:48     ` Stephen Gildea
  2021-10-07  7:46   ` bug#51070: " Lars Ingebrigtsen
  2021-10-07 16:46   ` bug#51056: " Lars Ingebrigtsen
  2 siblings, 1 reply; 10+ messages in thread
From: Stefan Kangas @ 2021-10-06 21:09 UTC (permalink / raw)
  To: Stephen Gildea; +Cc: 51056, Lars Ingebrigtsen, mh-e-devel

Stephen Gildea <stepheng+emacs@gildea.com> writes:

> MH-E is no longer developed nor distributed separately from GNU Emacs,
> since maybe 2015.

Does that mean that the XEmacs compatibility code in MH-E could also be
removed?





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
  2021-10-06 21:09   ` Stefan Kangas
@ 2021-10-07  2:48     ` Stephen Gildea
  2021-10-11 19:00       ` Bill Wohler
       [not found]       ` <1178966.1633978812@olgas.newt.com>
  0 siblings, 2 replies; 10+ messages in thread
From: Stephen Gildea @ 2021-10-07  2:48 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 51056, Lars Ingebrigtsen, mh-e-devel

Stefan Kangas <stefan@marxist.se> wrote:

>   Stephen Gildea <stepheng+emacs@gildea.com> writes:
>   
>   > MH-E is no longer developed nor distributed separately from GNU Emacs,
>   > since maybe 2015.
>   
>   Does that mean that the XEmacs compatibility code in MH-E could also be
>   removed?

Yes.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51070: 29.0.50; Making `gnus-define-keys' obsolete
  2021-10-06 14:01 ` Stephen Gildea
  2021-10-06 21:09   ` Stefan Kangas
@ 2021-10-07  7:46   ` Lars Ingebrigtsen
  2021-10-07 16:46   ` bug#51056: " Lars Ingebrigtsen
  2 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-07  7:46 UTC (permalink / raw)
  To: Stephen Gildea; +Cc: 51070, mh-e-devel

Stephen Gildea <stepheng+emacs@gildea.com> writes:

> MH-E is no longer developed nor distributed separately from GNU Emacs,
> since maybe 2015.

Ah, I see.

> You can update the MH-E part of the Emacs source tree to use Emacs 29
> features.  No compatibility is needed.

OK, will do.  Give a shout if I break something.  :-)






^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
  2021-10-06 14:01 ` Stephen Gildea
  2021-10-06 21:09   ` Stefan Kangas
  2021-10-07  7:46   ` bug#51070: " Lars Ingebrigtsen
@ 2021-10-07 16:46   ` Lars Ingebrigtsen
  2 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-07 16:46 UTC (permalink / raw)
  To: Stephen Gildea; +Cc: 51056, mh-e-devel

Stephen Gildea <stepheng+emacs@gildea.com> writes:

> You can update the MH-E part of the Emacs source tree to use Emacs 29
> features.  No compatibility is needed.

I've now converted the calls and done some extremely light testing, but
I don't see any obvious breakages (but I don't have mh set up properly
on my system).  Can you check whether I broke anything?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
  2021-10-07  2:48     ` Stephen Gildea
@ 2021-10-11 19:00       ` Bill Wohler
       [not found]       ` <1178966.1633978812@olgas.newt.com>
  1 sibling, 0 replies; 10+ messages in thread
From: Bill Wohler @ 2021-10-11 19:00 UTC (permalink / raw)
  To: Stephen Gildea; +Cc: 51056, Lars Ingebrigtsen, Stefan Kangas, mh-e-devel

Stephen Gildea <stepheng+emacs@gildea.com> wrote:

> Stefan Kangas <stefan@marxist.se> wrote:
> 
> >   Stephen Gildea <stepheng+emacs@gildea.com> writes:
> >   
> >   > MH-E is no longer developed nor distributed separately from GNU Emacs,
> >   > since maybe 2015.
> >   
> >   Does that mean that the XEmacs compatibility code in MH-E could also be
> >   removed?
> 
> Yes.

Stefan and Lars,

Thanks so much for the MH-E clean-ups! They are very much appreciated.
So far, I haven't noticed any issues with your updates.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
       [not found]       ` <1178966.1633978812@olgas.newt.com>
@ 2021-10-11 19:46         ` Stefan Kangas
  2021-10-12 10:43           ` Lars Ingebrigtsen
       [not found]           ` <87o87ufrq8.fsf@gnus.org>
  0 siblings, 2 replies; 10+ messages in thread
From: Stefan Kangas @ 2021-10-11 19:46 UTC (permalink / raw)
  To: Bill Wohler, Stephen Gildea; +Cc: 51056, Lars Ingebrigtsen, mh-e-devel

Bill Wohler <wohler@newt.com> writes:

> Thanks so much for the MH-E clean-ups! They are very much appreciated.
> So far, I haven't noticed any issues with your updates.

Thank you, that is an encouraging report.

If we do break something, we can always back those commits out for
further investigation, as I already had to do in one case.  The culprit
was this change, but I can't say that I understand why:

diff --git a/lisp/mh-e/mh-tool-bar.el b/lisp/mh-e/mh-tool-bar.el
index 805408cfc7..7cc0a1e83c 100644
--- a/lisp/mh-e/mh-tool-bar.el
+++ b/lisp/mh-e/mh-tool-bar.el
@@ -27,8 +27,7 @@
 ;;; Code:

 (require 'mh-e)
-(mh-do-in-gnu-emacs
-  (require 'tool-bar))
+(require 'tool-bar)

 ;;; Tool Bar Commands

So this innocent looking change leads to this:

In mh-tool-bar-define:
mh-e/mh-tool-bar.el:180:62: Warning: reference to free variable ‘folder-docs’
mh-e/mh-tool-bar.el:222:36: Warning: reference to free variable
    ‘folder-button-setter’
mh-e/mh-tool-bar.el:226:36: Warning: reference to free variable
    ‘sequence-button-setter’
mh-e/mh-tool-bar.el:191:34: Warning: reference to free variable ‘show-buttons’
mh-e/mh-tool-bar.el:230:36: Warning: reference to free variable
    ‘show-button-setter’
mh-e/mh-tool-bar.el:234:36: Warning: reference to free variable
    ‘show-seq-button-setter’
mh-e/mh-tool-bar.el:295:41: Warning: reference to free variable
    ‘letter-buttons’
mh-e/mh-tool-bar.el:296:41: Warning: reference to free variable ‘letter-docs’
mh-e/mh-tool-bar.el:245:36: Warning: reference to free variable
    ‘letter-button-setter’
mh-e/mh-tool-bar.el:280:51: Warning: reference to free variable
    ‘folder-defaults’
mh-e/mh-tool-bar.el:291:51: Warning: reference to free variable
    ‘letter-defaults’
mh-e/mh-tool-bar.el:194:36: Warning: reference to free variable
    ‘folder-vectors’
mh-e/mh-tool-bar.el:195:11: Warning: reference to free variable ‘show-vectors’
mh-e/mh-tool-bar.el:196:11: Warning: reference to free variable
    ‘letter-vectors’
mh-e/mh-tool-bar.el:197:14: Warning: assignment to free variable
    ‘folder-defaults’
mh-e/mh-tool-bar.el:199:61: Warning: assignment to free variable
    ‘letter-defaults’
mh-e/mh-tool-bar.el:189:11: Warning: reference to free variable
    ‘folder-buttons’
mh-e/mh-tool-bar.el:189:36: Warning: assignment to free variable
    ‘folder-buttons’
mh-e/mh-tool-bar.el:189:36: Warning: assignment to free variable
    ‘letter-buttons’
mh-e/mh-tool-bar.el:189:36: Warning: assignment to free variable
    ‘show-buttons’
mh-e/mh-tool-bar.el:189:36: Warning: assignment to free variable ‘letter-docs’
mh-e/mh-tool-bar.el:285:41: Warning: assignment to free variable ‘folder-docs’
mh-e/mh-tool-bar.el:285:41: Warning: assignment to free variable
    ‘folder-vectors’
mh-e/mh-tool-bar.el:285:41: Warning: assignment to free variable
    ‘show-vectors’
mh-e/mh-tool-bar.el:285:41: Warning: assignment to free variable
    ‘letter-vectors’
mh-e/mh-tool-bar.el:301:1: Error: Symbol’s value as variable is void:
folder-docs
  ELC      mh-e/mh-xface.elc
make[2]: *** [Makefile:316: mh-e/mh-tool-bar.elc] Error 1

Any ideas here are welcome.





^ permalink raw reply related	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
  2021-10-11 19:46         ` Stefan Kangas
@ 2021-10-12 10:43           ` Lars Ingebrigtsen
       [not found]           ` <87o87ufrq8.fsf@gnus.org>
  1 sibling, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-12 10:43 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 51056, Stephen Gildea, Bill Wohler, mh-e-devel

Stefan Kangas <stefan@marxist.se> writes:

> If we do break something, we can always back those commits out for
> further investigation, as I already had to do in one case.  The culprit
> was this change, but I can't say that I understand why:

[...]

> -(mh-do-in-gnu-emacs
> -  (require 'tool-bar))

It's because mh-do-in-gnu-emacs is autoloaded and pulls in mh-acros,
while mh-dlet* isn't autoloaded, and we're not requiring mh-acros, so it
fails if you remove that macro.

I think the solution is just to require mh-acros (or possibly autoload
mh-dlet*).  (The latter can probably just be rewritten to use dlet,
though.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#51056: 29.0.50; Making `gnus-define-keys' obsolete
       [not found]           ` <87o87ufrq8.fsf@gnus.org>
@ 2021-10-12 11:44             ` Stefan Kangas
  0 siblings, 0 replies; 10+ messages in thread
From: Stefan Kangas @ 2021-10-12 11:44 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 51056, Stephen Gildea, Bill Wohler, mh-e-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think the solution is just to require mh-acros (or possibly autoload
> mh-dlet*).  (The latter can probably just be rewritten to use dlet,
> though.)

Aha!  Thanks, now fixed on master.





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-10-12 11:44 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-06 10:14 bug#51056: 29.0.50; Making `gnus-define-keys' obsolete Lars Ingebrigtsen
2021-10-06 14:01 ` Stephen Gildea
2021-10-06 21:09   ` Stefan Kangas
2021-10-07  2:48     ` Stephen Gildea
2021-10-11 19:00       ` Bill Wohler
     [not found]       ` <1178966.1633978812@olgas.newt.com>
2021-10-11 19:46         ` Stefan Kangas
2021-10-12 10:43           ` Lars Ingebrigtsen
     [not found]           ` <87o87ufrq8.fsf@gnus.org>
2021-10-12 11:44             ` Stefan Kangas
2021-10-07  7:46   ` bug#51070: " Lars Ingebrigtsen
2021-10-07 16:46   ` bug#51056: " Lars Ingebrigtsen

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).