bug#63536: Feature Request

bug#63536: Feature Request

[Andrew Goh via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 891 bytes --]

bug#63536: Feature Request

[Eli Zaretskii]

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

bug#63536: Feature Request

[Eli Zaretskii]

> Date: Wed, 17 May 2023 02:36:14 +0000 (UTC)
> From: Andrew Goh <andrewgoh95@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.)

bug#63536: Feature Request

[Eli Zaretskii]

[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@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?

bug#63536: Feature Request

[Payas Relekar]

Eli Zaretskii <eliz@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`?

--

bug#63536: Feature Request

[Payas Relekar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Payas Relekar <relekarpayas@gmail.com>
>> Cc: Andrew Goh <andrewgoh95@yahoo.com.sg>,  63536@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.
--

bug#63536: Feature Request

[Payas Relekar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Payas Relekar <relekarpayas@gmail.com>
>> Cc: Andrew Goh <andrewgoh95@yahoo.com.sg>,  63536@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.

--

bug#63536: Feature Request

[Jim Porter]

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.

bug#63536: Feature Request

[Eli Zaretskii]

> From: Payas Relekar <relekarpayas@gmail.com>
> Cc: Andrew Goh <andrewgoh95@yahoo.com.sg>,  63536@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?

bug#63536: Feature Request

[Benjamin Riefenstahl]

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