From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Christopher Done Newsgroups: gmane.emacs.devel Subject: Support for bringing package change logs to the user's attention Date: Fri, 25 May 2018 12:47:49 +0100 Message-ID: Reply-To: chrisdone@googlemail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008b092e056d0657dc" X-Trace: blaine.gmane.org 1527248772 17210 195.159.176.226 (25 May 2018 11:46:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 25 May 2018 11:46:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 25 13:46:08 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fMBAd-0004Lj-9M for ged-emacs-devel@m.gmane.org; Fri, 25 May 2018 13:46:07 +0200 Original-Received: from localhost ([::1]:43184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fMBCk-0006pu-Gf for ged-emacs-devel@m.gmane.org; Fri, 25 May 2018 07:48:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fMBCe-0006pk-2g for emacs-devel@gnu.org; Fri, 25 May 2018 07:48:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fMBCc-00069p-PE for emacs-devel@gnu.org; Fri, 25 May 2018 07:48:12 -0400 Original-Received: from mail-qt0-x22f.google.com ([2607:f8b0:400d:c0d::22f]:46747) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fMBCc-00069U-K6 for emacs-devel@gnu.org; Fri, 25 May 2018 07:48:10 -0400 Original-Received: by mail-qt0-x22f.google.com with SMTP id 32-v6so6118250qtr.13 for ; Fri, 25 May 2018 04:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=RzEMZQ3ZmITGPbTZ5sKl361ZrwkHt0O30HpRiKjmjWY=; b=bri/KGw0wUdgUxWyk92LTbIF9uzCCc8BQa3M7A4yme96fwhg/wafXwpy/iNi7mTvRb Rf/sbc1yPZ1aOELWZmDNrluWUCog34x7OPr1oP5O5YIGmTn8fdCi+v1o0mhvC+5cAVWG 19MBDb4e5IIvce8SKSQDRVsZL1gaV5PvFW4p9cbJzqdpSEAEiJbea0XTJFi0CWPYdq0/ AFvGz5/+NTI3L9FVC5nnNzmKP69Q+GORyO5BXpoAGHIFBERldLX4XcmUst8Vkvt8dgm8 ksyIvDS03nxvOMHPV0VyeB26CLTIsBqWCOSyIWV4R0VmYRV+XvPjjkKZa9wObZ0eJsHi uv+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=RzEMZQ3ZmITGPbTZ5sKl361ZrwkHt0O30HpRiKjmjWY=; b=L3TDYXOw4gjIMu0k7wWyA7iSEkaxd0ykXGemmol4/kS7Mnc/iSiU7jTt95ActzSZmc dFP5l8F1MBHVV7mSH91ZOaoWc1wkRm/B5aSi1D+VRnZaAsmh+pLlHzqHb+rudHjtPhFj KuhsUgJALcLH7Ad9uy+yEMjzoYvcg6uVvcO3PfHKA5QRWIbDG+CnNTS7UbVKlcfwvwqE 3oQRi4fVVfdp9JW3Zeshs4lEVYuHp6fVOPFB8szv45k7bCf5aWDr2gKzqS6Z3g/RrRaJ pws7u7U+dfao7ab1Sc5J49ow9bgmJDGvEfQgSARUxcrdXLG1vu+alp7k2c4vfxQ2wMf/ l6Aw== X-Gm-Message-State: ALKqPweD1jHu6X1S/z/wPU0fJ//SzrOqMPnVD8kaquc7GbSxCjBhybts isEL+leYJ7OPjz0jKEbDWv8LDTYqBa6KQeDGmfBTPElA X-Google-Smtp-Source: ADUXVKLzdXDOl4q58yFzsiCkVlvpbUT93cB4M5Eafa1trjNWg3tMDGiSqM/fxid+luiTiyTN4ZHjJsfC/cH3m6xGzVo= X-Received: by 2002:ac8:2447:: with SMTP id d7-v6mr1833960qtd.50.1527248889512; Fri, 25 May 2018 04:48:09 -0700 (PDT) Original-Received: by 2002:ac8:2a06:0:0:0:0:0 with HTTP; Fri, 25 May 2018 04:47:49 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225706 Archived-At: --0000000000008b092e056d0657dc Content-Type: text/plain; charset="UTF-8" Hi all, As the author and maintainer of several Emacs Lisp packages, I'd like to discuss how change logs are brought to the user's attention. The simple problem for me is that users never know what cool new things have been added, or what bugs have been fixed, unless they're really keeping an eye out for it. People often seem just update all their packages. New things aren't obviously discoverable. There are three main kinds of Emacs package users that I'm aware of: 1. People who have a ~/.emacs.d with the packages/.el files that they've downloaded and made a copy of locally. 2. People who put their ~/.emacs.d under version control and pull packages down via that. 3. People who install Emacs packages via the package system in Emacs. (Personally, I am in the (2) set of people. I searched through the Emacs manual about packages and didn't find anything about change logs... tell me if I missed something!) I would like that there be explicit support for: A. When I load an Emacs package that is newer than last time, that Emacs automatically brings up to my attention a buffer with "what's new" in the package. B. Once I've acknowledged by a button or key press that I've really read the changes, then I never see the buffer again unless I explicitly ask to see it again. For example: To handle the (3) type of person, you could put such support into package-install, by simply writing to some kind of ~/.emacs.d/seen.el file with (("package" . version) ...) inside that lets Emacs know that I've seen the changelog, and I don't need to be bothered about it again. Alternatively it could be put in a customization variable and written to .emacs. I'm not sure about the implementation, but the UX is the important part. For people who do the (1) and (2) method, there isn't explicitly an "install" step. A bunch of Elisp files are loaded up and that's all. I'm not sure what we can do for them. Perhaps not much and that's OK. I'm open to ideas, though. We could have the package system look for a CHANGELOG file, or a ;;; Changes section in the file. It would parse up the latest entries since the last seen version and open a buffer to show the user, e.g. 0.1.31: * C-c C-p now massages your feet while gcc is compiling * The bug with overlays being slow is now fixed. Parsing isn't always a nice solution, but that's already done to some extent anyway. The alternative would be having the author write some Elisp with the changelog, but that seems like duplication of work to me. It would of course have an option to turn it off if people don't care what changed in any of their packages. What do you think? I'm asking here because I think it'd be a valuable addition to Emacs and would be best if it had buy-in from general package writers and the Emacs maintainers. Chris --0000000000008b092e056d0657dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

As the author and ma= intainer of several Emacs Lisp packages, I'd like to
discuss = how change logs are brought to the user's attention.

The simple problem for me is that users never know what cool new thi= ngs
have been added, or what bugs have been fixed, unless they= 9;re really
keeping an eye out for it. People often seem just upd= ate all their
packages. New things aren't obviously discovera= ble.

There are three main kinds of Emacs package u= sers that I'm aware of:

1. People who have a ~= /.emacs.d with the packages/.el files that they've
=C2=A0 =C2= =A0downloaded and made a copy of locally.

2. Peopl= e who put their ~/.emacs.d under version control and pull
=C2=A0 = =C2=A0packages down via that.

3. People who instal= l Emacs packages via the package system in Emacs.

= (Personally, I am in the (2) set of people. I searched through the Emacs ma= nual about packages and didn't find anything about change logs... tell = me if I missed something!)

I would like that there= be explicit support for:

A. When I load an Emacs = package that is newer than last time, that Emacs
=C2=A0 =C2=A0aut= omatically brings up to my attention a buffer with "what's new&quo= t; in
=C2=A0 =C2=A0the package.

B. Once = I've acknowledged by a button or key press that I've really read
=C2=A0 =C2=A0the changes, then I never see the buffer again unless = I explicitly
=C2=A0 =C2=A0ask to see it again.

For example: To handle the (3) type of person, you could put such
support into package-install, by simply writing to some kind of
~/.emacs.d/seen.el file with (("package" . version) ...) i= nside that
lets Emacs know that I've seen the changelog, and = I don't need to be
bothered about it again. Alternatively it = could be put in a
customization variable and written to .emacs. I= 'm not sure about the
implementation, but the UX is the impor= tant part.

For people who do the (1) and (2) metho= d, there isn't explicitly an
"install" step. A bunc= h of Elisp files are loaded up and that's all. I'm
not su= re what we can do for them. Perhaps not much and that's OK. I'm
open to ideas, though.

We could have the pa= ckage system look for a CHANGELOG file, or a ;;;
Changes section = in the file. It would parse up the latest entries since the last seen versi= on and open a buffer to show the user, e.g.

0.1.31= :
* C-c C-p now massages = your feet while gcc is compiling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Th= e bug with overlays being slow is now fixed.

Parsi= ng isn't always a nice solution, but that's already done to some
extent anyway. The alternative would be having the author write som= e
Elisp with the changelog, but that seems like duplication of wo= rk to me.

It would of course have an option to tur= n it off if people don't care
what changed in any of their pa= ckages.

What do you think? I'm asking here bec= ause I think it'd be a valuable addition to Emacs and would be best if = it had buy-in from general package writers and the Emacs maintainers.
=

Chris
--0000000000008b092e056d0657dc--