Should Emacs have an upgrade procedure?

Should Emacs have an upgrade procedure?

[joakim]

Should Emacs have an upgrade procedure?

Here's a user story:

- The user has just installed Emacs 24, previously having running
  Emacs23
- The Emacs splash screen shows a message: "A number of defaults have
  been changed between Emacs 23 and 24. Would you like to go through the
  changes, or just enable them?". This message is NOT shown if the user
  previously had expressed an opinion about these particular defaults.

OK, you get the picture I suppose. Good or bad? There are elisp
libraries out there that already implements this of course.
  
-- 
Joakim Verona

RE: Should Emacs have an upgrade procedure?

[Drew Adams]

> Should Emacs have an upgrade procedure?
> 
> Here's a user story:
> - The user has just installed Emacs 24, previously having running
>   Emacs23
> - The Emacs splash screen shows a message: "A number of defaults have
>   been changed between Emacs 23 and 24. Would you like to go 
>   through the changes, or just enable them?". This message is NOT
>   shown if the user previously had expressed an opinion about
>   these particular defaults.
> 
> OK, you get the picture I suppose. Good or bad? There are elisp
> libraries out there that already implements this of course.

Good or bad? Good.

That is, some additional, better way to do these two things would be welcome:

1. Let users know about such changes (including also new features, not just
changes in defaults).

NEWS is what it is - necessary, probably, but not ideal as a user aid. An
additional way to present the change info would be welcome. NEWS is somewhat
implementation-centric or development-centric. A top-level user-centric view
would be a helpful addition.

2. Let users make at least an initial decision about acceptance of such changes.
On a group basis and on an individual-change basis.


Dunno about particular ways to do #1 and #2 (including the scenario you
suggest), but I agree about the basic idea. In general terms, these would help,
IMO:

1. Some kind of tour of the changes and their impact for users. This is an
education thing, a means to give users an idea whether they might want to
accept/enable such-and-such change or not. This could be Web-based, esp. if
local resources are a problem.

2. Some kind of easy dialog to let them opt in/out for individual changes, and
for large groups of changes at once, and even for all changes.

#2 could be done using an organized dialog box (groups of check boxes, for
example). Or something else could be devised. (A "wizard-like" long sequence of
"Do you want X?" is a no-no, IMO.)

3. Each change demo'd or illustrated in #1 should be a choice in #2, and vice
versa. The choice dialog of #2 could even have individual links to the
corresponding illustrations in #1 - education is also about reminding. And vice
versa: in the tour presentation of a particular change, there could be a link to
the part of #2 that lets you choose.

4. It should be easy to (a) skip #2 altogether and (b) do #2 later, at any time
(including redoing it, changing one's mind). Obviously, it should also be easy
to skip #1. Users should not have to hunt later to find how to (re)do #1 and #2.
Two places we could provide quick links to #1 and #2: the Help menu and the
splash page.

5. It would be good for a user to be able to do #1 and #2 for past releases as
well.

This would require, at the least, having a way to identify internally each
user-visible change for a given release (or at least those deemed important
enough to figure in #1 and #2).


Do I expect that this will really happen anytime soon, given our limited dev
resources (not to mention our difficulties to agree, especially about UI)? No.
But identifying and agreeing on the goal is one step, and some baby steps toward
realizing it could perhaps be accomplished.

So yes, I think the question you raise is a good one, and your proposal is a
reasonable one to consider.

(I wouldn't characterize this as being about an "upgrade procedure", however.
It's more about (a) educating users about changes and (b) facilitating their
control over those changes.)

Re: Should Emacs have an upgrade procedure?

[joakim]

"Drew Adams" <drew.adams@oracle.com> writes:

>> Should Emacs have an upgrade procedure?
>> 
>> Here's a user story:
>> - The user has just installed Emacs 24, previously having running
>>   Emacs23
>> - The Emacs splash screen shows a message: "A number of defaults have
>>   been changed between Emacs 23 and 24. Would you like to go 
>>   through the changes, or just enable them?". This message is NOT
>>   shown if the user previously had expressed an opinion about
>>   these particular defaults.
>> 
>> OK, you get the picture I suppose. Good or bad? There are elisp
>> libraries out there that already implements this of course.
>
> Good or bad? Good.

Good!

>
> That is, some additional, better way to do these two things would be welcome:

I try to adress your concerns below from the perspective of the subject
"Should Emacs have an upgrade procedure?". This doesnt mean I reject
your thoughts. 

> 1. Let users know about such changes (including also new features, not just
> changes in defaults).
>
> NEWS is what it is - necessary, probably, but not ideal as a user aid. An
> additional way to present the change info would be welcome. NEWS is somewhat
> implementation-centric or development-centric. A top-level user-centric view
> would be a helpful addition.

This isnt within the scope of the proposal.

> 2. Let users make at least an initial decision about acceptance of such changes.
> On a group basis and on an individual-change basis.

This is handled well by an upgrade procedure I think.

>
> Dunno about particular ways to do #1 and #2 (including the scenario you
> suggest), but I agree about the basic idea. In general terms, these would help,
> IMO:
>
> 1. Some kind of tour of the changes and their impact for users. This is an
> education thing, a means to give users an idea whether they might want to
> accept/enable such-and-such change or not. This could be Web-based, esp. if
> local resources are a problem.

The "upgrade process" proposal doesnt try to cover this.

> 2. Some kind of easy dialog to let them opt in/out for individual changes, and
> for large groups of changes at once, and even for all changes.

Yes.

> #2 could be done using an organized dialog box (groups of check boxes, for
> example). Or something else could be devised. (A "wizard-like" long sequence of
> "Do you want X?" is a no-no, IMO.)

I agree.

>
> 3. Each change demo'd or illustrated in #1 should be a choice in #2, and vice
> versa. The choice dialog of #2 could even have individual links to the
> corresponding illustrations in #1 - education is also about reminding. And vice
> versa: in the tour presentation of a particular change, there could be a link to
> the part of #2 that lets you choose.
>
> 4. It should be easy to (a) skip #2 altogether and (b) do #2 later, at any time
> (including redoing it, changing one's mind). Obviously, it should also be easy
> to skip #1. Users should not have to hunt later to find how to (re)do #1 and #2.
> Two places we could provide quick links to #1 and #2: the Help menu and the
> splash page.
>
> 5. It would be good for a user to be able to do #1 and #2 for past releases as
> well.

Rollback is within the scope of upgrade handling I think.

>
> This would require, at the least, having a way to identify internally each
> user-visible change for a given release (or at least those deemed important
> enough to figure in #1 and #2).

Maybe this could be realized as flags to defcustom?

>
> Do I expect that this will really happen anytime soon, given our limited dev
> resources (not to mention our difficulties to agree, especially about UI)? No.
> But identifying and agreeing on the goal is one step, and some baby steps toward
> realizing it could perhaps be accomplished.
>
> So yes, I think the question you raise is a good one, and your proposal is a
> reasonable one to consider.
>
> (I wouldn't characterize this as being about an "upgrade procedure", however.
> It's more about (a) educating users about changes and (b) facilitating their
> control over those changes.)

This particular thread was about finding out if a strictly scoped
upgrade process could maybe help with solving, lets say, 80% of the
concerns you rise.

-- 
Joakim Verona

Re: Should Emacs have an upgrade procedure?

[Juri Linkov]

>> 2. Some kind of easy dialog to let them opt in/out for individual changes, and
>> for large groups of changes at once, and even for all changes.
>
> Yes.
>
>> #2 could be done using an organized dialog box (groups of check boxes, for
>> example). Or something else could be devised. (A "wizard-like" long sequence of
>> "Do you want X?" is a no-no, IMO.)
>
> I agree.

I think this could be better done with the Customization UI.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Should Emacs have an upgrade procedure?

[Lennart Borgman]

On Mon, Mar 22, 2010 at 12:55 AM, Juri Linkov <juri@jurta.org> wrote:
>>> 2. Some kind of easy dialog to let them opt in/out for individual changes, and
>>> for large groups of changes at once, and even for all changes.
>>
>> Yes.
>>
>>> #2 could be done using an organized dialog box (groups of check boxes, for
>>> example). Or something else could be devised. (A "wizard-like" long sequence of
>>> "Do you want X?" is a no-no, IMO.)
>>
>> I agree.
>
> I think this could be better done with the Customization UI.


Yes, but a special customization buffer with the relevant options and
with new/old settings button too.

Maybe it can be combined with assistant.el (but I have no idea since I
have not been able to find it yet).

Re: Should Emacs have an upgrade procedure?

[Juri Linkov]

>> I think this could be better done with the Customization UI.
>
> Yes, but a special customization buffer with the relevant options and
> with new/old settings button too.

What I meant is the existing command `customize-changed-options'
where you specify the version number, and it displays all settings
that were added or redefined since that version.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Should Emacs have an upgrade procedure?

[Lennart Borgman]

On Mon, Mar 22, 2010 at 2:18 AM, Juri Linkov <juri@jurta.org> wrote:
>>> I think this could be better done with the Customization UI.
>>
>> Yes, but a special customization buffer with the relevant options and
>> with new/old settings button too.
>
> What I meant is the existing command `customize-changed-options'
> where you specify the version number, and it displays all settings
> that were added or redefined since that version.


Thanks, I had forgotten that.

It is very good command - but still not good enough for the purpose. I
think it needs info about what is new and what is changed and links to
explanations.

Re: Should Emacs have an upgrade procedure?

[Ted Zlatanov]

On Sun, 21 Mar 2010 17:41:52 +0100 joakim@verona.se wrote: 

j> Should Emacs have an upgrade procedure?
j> Here's a user story:

j> - The user has just installed Emacs 24, previously having running
j>   Emacs23
j> - The Emacs splash screen shows a message: "A number of defaults have
j>   been changed between Emacs 23 and 24. Would you like to go through the
j>   changes, or just enable them?". This message is NOT shown if the user
j>   previously had expressed an opinion about these particular defaults.

I think assistant.el (in Gnus) could be used to automate this.

j> OK, you get the picture I suppose. Good or bad? There are elisp
j> libraries out there that already implements this of course.

Any specifics?  I didn't know of such libraries.

Ted

Re: Should Emacs have an upgrade procedure?

[joakim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sun, 21 Mar 2010 17:41:52 +0100 joakim@verona.se wrote: 
>
> j> Should Emacs have an upgrade procedure?
> j> Here's a user story:
>
> j> - The user has just installed Emacs 24, previously having running
> j>   Emacs23
> j> - The Emacs splash screen shows a message: "A number of defaults have
> j>   been changed between Emacs 23 and 24. Would you like to go through the
> j>   changes, or just enable them?". This message is NOT shown if the user
> j>   previously had expressed an opinion about these particular defaults.
>
> I think assistant.el (in Gnus) could be used to automate this.
>
> j> OK, you get the picture I suppose. Good or bad? There are elisp
> j> libraries out there that already implements this of course.
>
> Any specifics?  I didn't know of such libraries.

I just remembered having seen something. Maybe it was in ECB, maybe in
Gnus. Not sure.

>
> Ted
>
>
-- 
Joakim Verona

Re: Should Emacs have an upgrade procedure?

[Lennart Borgman]

2010/3/21 Ted Zlatanov <tzz@lifelogs.com>:
> On Sun, 21 Mar 2010 17:41:52 +0100 joakim@verona.se wrote:
>
> j> Should Emacs have an upgrade procedure?
> j> Here's a user story:
>
> j> - The user has just installed Emacs 24, previously having running
> j>   Emacs23
> j> - The Emacs splash screen shows a message: "A number of defaults have
> j>   been changed between Emacs 23 and 24. Would you like to go through the
> j>   changes, or just enable them?". This message is NOT shown if the user
> j>   previously had expressed an opinion about these particular defaults.
>
> I think assistant.el (in Gnus) could be used to automate this.

Where is it? What does it do?

Re: Should Emacs have an upgrade procedure?

[Ted Zlatanov]

On Sun, 21 Mar 2010 21:39:52 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> 2010/3/21 Ted Zlatanov <tzz@lifelogs.com>:
>> On Sun, 21 Mar 2010 17:41:52 +0100 joakim@verona.se wrote:
>> 
j> Should Emacs have an upgrade procedure?
j> Here's a user story:
>> 
j> - The user has just installed Emacs 24, previously having running
j>   Emacs23
j> - The Emacs splash screen shows a message: "A number of defaults have
j>   been changed between Emacs 23 and 24. Would you like to go through the
j>   changes, or just enable them?". This message is NOT shown if the user
j>   previously had expressed an opinion about these particular defaults.
>> 
>> I think assistant.el (in Gnus) could be used to automate this.

LB> Where is it? What does it do?

Check out Gnus from CVS or:

http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/lisp/assistant.el

It was written by Lars.  I was going to use it for guided setup for Gnus
users but simply haven't had the time.  It can do almost any dynamic UI
tree with the right setup but needs polish.

See discussions about it here:

http://search.gmane.org/?query=assistant.el&group=gmane.emacs.gnus.general

RMS asked that it be removed from the Emacs trunk but I don't think
there was prejudice in that request, only the reality that the package
is not ready for regular use.  See
http://thread.gmane.org/gmane.emacs.devel/83364/focus=83452

Ted

Re: Should Emacs have an upgrade procedure?

[Lennart Borgman]

2010/3/21 Ted Zlatanov <tzz@lifelogs.com>:
> On Sun, 21 Mar 2010 21:39:52 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> LB> 2010/3/21 Ted Zlatanov <tzz@lifelogs.com>:
>>> On Sun, 21 Mar 2010 17:41:52 +0100 joakim@verona.se wrote:
>>>
> j> Should Emacs have an upgrade procedure?
> j> Here's a user story:
>>>
> j> - The user has just installed Emacs 24, previously having running
> j>   Emacs23
> j> - The Emacs splash screen shows a message: "A number of defaults have
> j>   been changed between Emacs 23 and 24. Would you like to go through the
> j>   changes, or just enable them?". This message is NOT shown if the user
> j>   previously had expressed an opinion about these particular defaults.
>>>
>>> I think assistant.el (in Gnus) could be used to automate this.
>
> LB> Where is it? What does it do?
>
> Check out Gnus from CVS or:
>
> http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/lisp/assistant.el


I can not find it there. When I click on "download" for 1.23 I get an error.

Re: Should Emacs have an upgrade procedure?

[Ted Zlatanov]

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

On Sun, 21 Mar 2010 23:53:22 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> I can not find it there. When I click on "download" for 1.23 I get an error.

You can check out Gnus from CVS to get it.

I'm attaching the latest here since it's a small file.

Ted


[-- Attachment #2: assistant.el --]
[-- Type: application/emacs-lisp, Size: 14966 bytes --]

Re: Should Emacs have an upgrade procedure?

[Lennart Borgman]

2010/3/22 Ted Zlatanov <tzz@lifelogs.com>:
> On Sun, 21 Mar 2010 23:53:22 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> LB> I can not find it there. When I click on "download" for 1.23 I get an error.
>
> You can check out Gnus from CVS to get it.
>
> I'm attaching the latest here since it's a small file.
>
> Ted


Thanks. The comment section is very scarce, perhaps you can explain a bit?

Re: Should Emacs have an upgrade procedure?

[Ted Zlatanov]

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

On Mon, 22 Mar 2010 02:36:47 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> 2010/3/22 Ted Zlatanov <tzz@lifelogs.com>:
>> On Sun, 21 Mar 2010 23:53:22 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> 
LB> I can not find it there. When I click on "download" for 1.23 I get an error.
>> 
>> You can check out Gnus from CVS to get it.
>> 
>> I'm attaching the latest here since it's a small file.

LB> Thanks. The comment section is very scarce, perhaps you can explain a bit?

Hmm, the best way is with some .ast examples.  Now these may not even
work (it's been 3+ years) but you should see the idea.  It's basically
a graph with transition triggers stored in a Texinfo-style documents.

These are in the Gnus CVS, by the way, under etc/gnus/

Ted


[-- Attachment #2: news-server.ast --]
[-- Type: text/plain, Size: 1611 bytes --]

@title Configuring Gnus for reading news


@node Setting up the news server name and port number
@variable server :string (gnus-getenv-nntpserver)
@variable port :number 119
@validate (assistant-validate-connect-to-server server port)
@result gnus-select-method (list 'nntp server (list 'nntp-server port))
@text
Usenet news is usually read from your Internet service prodider's news
server.  If you don't know the name of this server, contact your ISP.

As a guess, the name of the server might be news.yourisp.com.

Server name: @variable{server}
Port number: @variable{port}
@end text
@next t "User name and password"


@node User name and password
@type interstitial
@next 
(if (assistant-password-required-p)
    "Enter user name and password"
  "Want user name and password?")
@end next


@node Want user name and password?
@variable passwordp (:radio ((item "Yes") (item "No"))) "No"
@text
Some news servers require that you enter a user name and a password.
It doesn't look like your news server is one of them.

Do you want to enter user name and password anyway?

@variable{passwordp}

@end text

@next (equal passwordp "No") finish
@next (not (equal passwordp "No")) "Enter user name and password"


@node Enter user name and password
@variable user-name :string (user-login-name)
@variable password :password (or (assistant-authinfo-data server port 'password) "")
@text

It looks like your news server requires you to enter a user name
and a password:

User name: @variable{user-name}
Password: @variable{user-name}

@end text

@c Local variables:
@c mode: texinfo
@c End:

@c arch tag is missing


[-- Attachment #3: gnus-setup.ast --]
[-- Type: text/plain, Size: 1517 bytes --]

@title Configuring Gnus for the first time

@node What do you want to do with Gnus?

@variable outbound (:radio ((item :tag "Send mail via sendmail" "sendmail") (item :tag "Send mail via SMTP" "smtp"))) "sendmail"

@variable backends (:set ((item :tag "Read news via NNTP" "nntp") (item :tag "Read mail, store it locally" "nnml") (item :tag "Read mail and store it on an IMAP server" "nnimap"))) (list "nnml")
@result primary-mail-selections (list backends outbound)

@text
Welcome to Gnus.  You need to tell us what you want to do with Gnus
before we go on to specific configurations.

Choose the tasks you want to set up: 
@variable{backends}

Choose the method Gnus will use to send mail: 
@variable{outbound}

@end text

@next (member "nnml" backends) "Setting up local mail storage (nnml)"
@next (member "nntp" backends) "Setting up a NNTP server"

@node Setting up local mail storage (nnml)
@variable mechanism (:radio ((item :tag "Get mail from your Unix mbox" "mbox") (item :tag "Use POP3 to retrieve mail" "pop3"))) "mbox"
@result nnml-mechanism (list mechanism)
@text
You are setting up local mail storage, using the nnml backend in Gnus terms.

Your mail can be downloaded into Gnus in several ways, choose one:
@variable{mechanism}

@end text

@node Setting up a NNTP server

@text
TODO: this will be a real link.
Run M-x assistant and use the news-server.ast file as input.
@end text

\f
@c Local variables:
@c mode: texinfo
@c End:

@ignore
   arch-tag: 6b7b200b-9169-4b44-8b32-b73773fa71af
@end ignore

Re: Should Emacs have an upgrade procedure?

[Ted Zlatanov]

On Sun, 21 Mar 2010 21:25:39 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Mon, 22 Mar 2010 02:36:47 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote: 
LB> 2010/3/22 Ted Zlatanov <tzz@lifelogs.com>:
>>> On Sun, 21 Mar 2010 23:53:22 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>> 
LB> I can not find it there. When I click on "download" for 1.23 I get an error.
>>> 
>>> You can check out Gnus from CVS to get it.
>>> 
>>> I'm attaching the latest here since it's a small file.

LB> Thanks. The comment section is very scarce, perhaps you can explain a bit?

TZ> Hmm, the best way is with some .ast examples.  Now these may not even
TZ> work (it's been 3+ years) but you should see the idea.  It's basically
TZ> a graph with transition triggers stored in a Texinfo-style documents.

TZ> These are in the Gnus CVS, by the way, under etc/gnus/

I fixed a bug in :string and :number variables but at this point it's
easier to just point you to the Gnus CVS repo than to keep posting
versions.

Ted

Re: Should Emacs have an upgrade procedure?

[Stefan Monnier]

> - The Emacs splash screen shows a message: "A number of defaults have
>   been changed between Emacs 23 and 24. Would you like to go through the
>   changes, or just enable them?".

Sounds OK.  It could also be done just to announce changes, whether
defaults or not.

>   This message is NOT shown if the user previously had expressed an
>   opinion about these particular defaults.

The issue is how to make sure it never becomes annoying.  E.g. for
people who share their .emacs between different machines and/or use
different versions of Emacs, ...


        Stefan