GNU bug report logs - #63536
Function to update Emacs itself (for example 29.1 to 29.2)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63536 in the body.
You can then email your comments to 63536 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Feature Request
Date: Tue, 16 May 2023 11:39:56 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Dear Emacs,
Could we have a "update function" feature to keep emacs current.
Seriously, I would prefer reading a real gnu emacs manual rather than a online version.

--- Andrew Goh

[Message part 2 (text/html, inline)]

Message #8 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
Cc: 63536 <at> debbugs.gnu.org
Subject: Re: bug#63536: Feature Request
Date: Tue, 16 May 2023 18:46:14 +0300

severity 63536 wishlist
thanks

> Date: Tue, 16 May 2023 11:39:56 +0000 (UTC)
> From:  Andrew Goh via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Could we have a "update function" feature to keep emacs current.

Maybe.  But please describe what would such a function do...

> Seriously, I would prefer reading a real gnu emacs manual rather than a online version.

...and how would it be relevant to which version of the manual you
will read.

Thanks.

Message #11 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
Cc: 63536 <at> debbugs.gnu.org
Subject: Re: bug#63536: Feature Request
Date: Wed, 17 May 2023 13:58:51 +0300

> Date: Wed, 17 May 2023 02:36:14 +0000 (UTC)
> From: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
> 
> to check for new updates. many IDEs out there have this feature - such as jgrasp, vs code, vs ide etc.

Updates of what?

(And please use Reply All to reply, so that the bug tracker is CC'ed.)

Message #14 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
Cc: 63536 <at> debbugs.gnu.org
Subject: Re: bug#63536: Feature Request
Date: Wed, 17 May 2023 16:37:24 +0300

[PLEASE use Reply All to have the bug tracker on the CC list.]

> Date: Wed, 17 May 2023 13:17:09 +0000 (UTC)
> From: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
> 
> Updates of GNU Emacs.  Many software tools out in the proprietary world have such a feature.

So you want a command to check whether a newer Emacs is available?
But where should this command look?  Many (most?) people install
precompiled binaries prepared by their distros, and I assume those
distros have their "check for updates" service or something?

We could check on the GNU FTP site, but how many users will want to
download and build Emacs from sources?

What do other people think about this?

Message #17 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Payas Relekar <relekarpayas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63536 <at> debbugs.gnu.org, Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
Subject: Re: bug#63536: Feature Request
Date: Wed, 17 May 2023 19:34:06 +0530

Eli Zaretskii <eliz <at> gnu.org> writes:

> So you want a command to check whether a newer Emacs is available?
> But where should this command look?  Many (most?) people install
> precompiled binaries prepared by their distros, and I assume those
> distros have their "check for updates" service or something?
>
> We could check on the GNU FTP site, but how many users will want to
> download and build Emacs from sources?
>
> What do other people think about this?

The idea itself is valid, as long as the update check happens only at
explicit user action. The command should only compare current version of
Emacs with the latest update and inform user about the difference. Then
the onus is on user to proceed with the update. Command output can point
them to relevant section of the manual, informing of ways to install
(and also update) Emacs.

Optionally, this function can be run at startup for automated update
check, opt-in by default, of course. I believe that will match the
behavior of 'most' proprietary IDEs.

The idea of Emacs setup/startup screen shines with stuff like this,
where these options are selected by user at the very beginning. This can
even be included in current startup screen as simple hyperlink, IMO and
would be a worthy addition.

It can also optionally include updating all the activated *ELPAs.

Perhaps it can be called something like `emacs-check-update`?

--

Message #20 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Andrew Goh <andrewgoh95 <at> yahoo.com.sg>
Cc: 63536 <at> debbugs.gnu.org
Subject: Re: bug#63536: Feature Request
Date: Wed, 17 May 2023 09:53:38 -0700

On 5/17/2023 6:37 AM, Eli Zaretskii wrote:
> So you want a command to check whether a newer Emacs is available?
> But where should this command look?  Many (most?) people install
> precompiled binaries prepared by their distros, and I assume those
> distros have their "check for updates" service or something?
> 
> We could check on the GNU FTP site, but how many users will want to
> download and build Emacs from sources?
> 
> What do other people think about this?

I think we could fairly easily *check* for the existence of a newer 
Emacs release, but the hard part is what to do about it. Is it enough to 
merely tell the user, "Emacs 29.1 is released," and just expect the user 
to figure out how to update?

For users who get their Emacs from their distro, the distro is 
responsible for updates then. We can ignore that case.[1] (Ditto for any 
other package manager: PPAs, Homebrew, etc.)

However, for users who get their Emacs from GNU FTP, the only update 
mechanism right now is 100% manual. It would be interesting to try to 
fix that, but it also seems difficult: if the user downloaded Emacs and 
compiled from source, can we make 100% sure that we can do that 
programmatically for the next release? What if Emacs adds a new library 
dependency? Maybe GNU FTP could also distribute binaries in some fashion 
instead[2], but that's yet another complexity to work out. If we 
distributed binaries, how would we do so?

If someone wanted to spend the time to figure out all the issues with 
this, I think there'd be value in it, but I also think it's more effort 
than it's worth (unless this is literally just a notification, nothing 
more).

[1] That's what Firefox does too: if you install Firefox from Mozilla, 
it'll handle updating itself, but if you install it from your distro, 
the distro handles the updates.

[2] There are the MS-Windows binaries, but I don't think we should be 
spending too much effort on something that would only benefit users of a 
nonfree OS.

Message #23 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Payas Relekar <relekarpayas <at> gmail.com>
Cc: 63536 <at> debbugs.gnu.org, andrewgoh95 <at> yahoo.com.sg
Subject: Re: bug#63536: Feature Request
Date: Wed, 17 May 2023 20:16:18 +0300

> From: Payas Relekar <relekarpayas <at> gmail.com>
> Cc: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>,  63536 <at> debbugs.gnu.org
> Date: Wed, 17 May 2023 19:34:06 +0530
> 
> The idea itself is valid, as long as the update check happens only at
> explicit user action. The command should only compare current version of
> Emacs with the latest update and inform user about the difference. Then
> the onus is on user to proceed with the update. Command output can point
> them to relevant section of the manual, informing of ways to install
> (and also update) Emacs.

How will we know where to look?  That's the main technical issue with
this, I think.

Another possible issue is whether just to tell the user "A newer
version XY.Z is available, you can download it at <URL>", or also
offer a possibility of actually downloading the newer version?

Message #26 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Payas Relekar <relekarpayas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63536 <at> debbugs.gnu.org, andrewgoh95 <at> yahoo.com.sg
Subject: Re: bug#63536: Feature Request
Date: Wed, 17 May 2023 21:10:15 +0530

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Payas Relekar <relekarpayas <at> gmail.com>
>> Cc: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>,  63536 <at> debbugs.gnu.org
>> Date: Wed, 17 May 2023 19:34:06 +0530
>>
>> The idea itself is valid, as long as the update check happens only at
>> explicit user action. The command should only compare current version of
>> Emacs with the latest update and inform user about the difference. Then
>> the onus is on user to proceed with the update. Command output can point
>> them to relevant section of the manual, informing of ways to install
>> (and also update) Emacs.
>
> How will we know where to look?  That's the main technical issue with
> this, I think.
>
> Another possible issue is whether just to tell the user "A newer
> version XY.Z is available, you can download it at <URL>", or also
> offer a possibility of actually downloading the newer version?

The former is preferred. Emacs users more often than not use third party
mechanisms (e.g. package managers) to get it installed. Any action for
actually downloading would muddy the waters. Here's the flow that I
imagine:

1. User runs `M-x emacs-check-update`
2. Emacs checks GNU repo and provides somthing like:
   `Update for Emacs 29.1 is now available. Current version is 28.2.

   If you installed Emacs via a package manager like your GNU/linux
   distribution, homebrew, Guix etc, please follow their respective
   instructions.

   If you installed Emacs by compiling from source, follow _link to
   latest Emacs compilation instructions_.

   If you'd like to check for updates for Emacs-Lisp packages, please
   check 'package-upgrade'`
3. User chooses to follow or ignore the instructions.

The wording would play big part, but as long as we make it clear to
follow the path of original installation is preferred, I think most
users can figure it out, just like the rest of the manual.

At any point, Emacs providing built-in mechanism for update, while nice
to have, will be gigantic pain to implement and even bigger pain to
maintain. Something like rustup is well-desired, but Emacs has very
broad scope and dependency tree unlike rust toolchain, so I'd rather
avoid it.
--

Message #29 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Payas Relekar <relekarpayas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63536 <at> debbugs.gnu.org, andrewgoh95 <at> yahoo.com.sg
Subject: Re: bug#63536: Feature Request
Date: Wed, 17 May 2023 21:21:48 +0530

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Payas Relekar <relekarpayas <at> gmail.com>
>> Cc: Andrew Goh <andrewgoh95 <at> yahoo.com.sg>,  63536 <at> debbugs.gnu.org
>> Date: Wed, 17 May 2023 19:34:06 +0530
>>
>> The idea itself is valid, as long as the update check happens only at
>> explicit user action. The command should only compare current version of
>> Emacs with the latest update and inform user about the difference. Then
>> the onus is on user to proceed with the update. Command output can point
>> them to relevant section of the manual, informing of ways to install
>> (and also update) Emacs.
>
> How will we know where to look?  That's the main technical issue with
> this, I think.
>

Sorry, I missed this in previous mail. Where do we look? GNU Emacs
stable release URL, of course. As long as the latest version available
upstream (FTP or the git branch directly) is higher than user's version,
we are good to report.

If the users see their package manager does not have the latest version,
that's a good motivation for reporting it there. But the wording should
be clear for the same.

--

Message #32 received at 63536 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: 63536 <at> debbugs.gnu.org
Subject: Re: bug#63536: Feature Request
Date: Fri, 19 May 2023 15:36:10 +0200

Hi Eli,

Eli Zaretskii writes:
> So you want a command to check whether a newer Emacs is available?
> But where should this command look?  Many (most?) people install
> precompiled binaries prepared by their distros, and I assume those
> distros have their "check for updates" service or something?
>
> We could check on the GNU FTP site, but how many users will want to
> download and build Emacs from sources?
>
> What do other people think about this?

Since you asked for it ;-):

I dislike it when programs annoy me with dialog boxes like that at
startup.  I start a program because I want to do something that uses it,
not to maintain the program.

I use Debian and I like working with its package management.  It is
especially bad when programs tell me they have a new version, but the
package manager doesn't actually have it.

I also do not always want the latest version of any program in the first
place, as long as the current version still does what I want.

Regards, benny

Message #41 received at 63536-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrew Goh <andrewgoh95 <at> yahoo.com.sg>,
 63536-done <at> debbugs.gnu.org
Subject: Re: bug#63536: Function to update Emacs itself (for example 29.1 to
 29.2)
Date: Sat, 15 Feb 2025 03:18:13 +0000

close 63536
tags 63536 + wontfix
thanks

Jim Porter <jporterbugs <at> gmail.com> writes:

> On 5/17/2023 6:37 AM, Eli Zaretskii wrote:
>> So you want a command to check whether a newer Emacs is available?
>> But where should this command look?  Many (most?) people install
>> precompiled binaries prepared by their distros, and I assume those
>> distros have their "check for updates" service or something?
>> We could check on the GNU FTP site, but how many users will want to
>> download and build Emacs from sources?
>> What do other people think about this?
>
> I think we could fairly easily *check* for the existence of a newer Emacs
> release, but the hard part is what to do about it. Is it enough to merely tell
> the user, "Emacs 29.1 is released," and just expect the user to figure out how
> to update?
>
> For users who get their Emacs from their distro, the distro is responsible for
> updates then. We can ignore that case.[1] (Ditto for any other package manager:
> PPAs, Homebrew, etc.)
>
> However, for users who get their Emacs from GNU FTP, the only update mechanism
> right now is 100% manual. It would be interesting to try to fix that, but it
> also seems difficult: if the user downloaded Emacs and compiled from source, can
> we make 100% sure that we can do that programmatically for the next release?
> What if Emacs adds a new library dependency? Maybe GNU FTP could also distribute
> binaries in some fashion instead[2], but that's yet another complexity to work
> out. If we distributed binaries, how would we do so?
>
> If someone wanted to spend the time to figure out all the issues with this, I
> think there'd be value in it, but I also think it's more effort than it's worth
> (unless this is literally just a notification, nothing more).

I tend to agree, so I'm closing this as wontfix.  I just don't see it
happening with all the complications it would entail.  Sorry.

If someone were to present a full-blown working patch, the situation
might be different, but even then I'd be slightly reluctant to merge it
due to the difficulty in maintaining it.  This should properly be
handled by distros on GNU/Linux, on macOS there's Homebrew, on
MS-Windows I have no idea but I assume whatever you do there applies.

Thanks for the feature proposal, nevertheless.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.