* Should Emacs have an upgrade procedure?
@ 2010-03-21 16:41 joakim
2010-03-21 17:21 ` Drew Adams
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: joakim @ 2010-03-21 16:41 UTC (permalink / raw)
To: Emacs development discussions
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
^ permalink raw reply [flat|nested] 17+ messages in thread* RE: Should Emacs have an upgrade procedure? 2010-03-21 16:41 Should Emacs have an upgrade procedure? joakim @ 2010-03-21 17:21 ` Drew Adams 2010-03-21 20:36 ` joakim 2010-03-21 18:55 ` Ted Zlatanov 2010-03-22 2:07 ` Stefan Monnier 2 siblings, 1 reply; 17+ messages in thread From: Drew Adams @ 2010-03-21 17:21 UTC (permalink / raw) To: joakim, 'Emacs development discussions' > 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.) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 17:21 ` Drew Adams @ 2010-03-21 20:36 ` joakim 2010-03-21 23:55 ` Juri Linkov 0 siblings, 1 reply; 17+ messages in thread From: joakim @ 2010-03-21 20:36 UTC (permalink / raw) To: Drew Adams; +Cc: 'Emacs development discussions' "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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 20:36 ` joakim @ 2010-03-21 23:55 ` Juri Linkov 2010-03-22 1:14 ` Lennart Borgman 0 siblings, 1 reply; 17+ messages in thread From: Juri Linkov @ 2010-03-21 23:55 UTC (permalink / raw) To: joakim; +Cc: Drew Adams, 'Emacs development discussions' >> 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/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 23:55 ` Juri Linkov @ 2010-03-22 1:14 ` Lennart Borgman 2010-03-22 1:18 ` Juri Linkov 0 siblings, 1 reply; 17+ messages in thread From: Lennart Borgman @ 2010-03-22 1:14 UTC (permalink / raw) To: Juri Linkov; +Cc: Drew Adams, joakim, Emacs development discussions 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). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-22 1:14 ` Lennart Borgman @ 2010-03-22 1:18 ` Juri Linkov 2010-03-22 1:32 ` Lennart Borgman 0 siblings, 1 reply; 17+ messages in thread From: Juri Linkov @ 2010-03-22 1:18 UTC (permalink / raw) To: Lennart Borgman; +Cc: Drew Adams, joakim, Emacs development discussions >> 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/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-22 1:18 ` Juri Linkov @ 2010-03-22 1:32 ` Lennart Borgman 0 siblings, 0 replies; 17+ messages in thread From: Lennart Borgman @ 2010-03-22 1:32 UTC (permalink / raw) To: Juri Linkov; +Cc: Drew Adams, joakim, Emacs development discussions 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 16:41 Should Emacs have an upgrade procedure? joakim 2010-03-21 17:21 ` Drew Adams @ 2010-03-21 18:55 ` Ted Zlatanov 2010-03-21 19:34 ` joakim 2010-03-21 20:39 ` Lennart Borgman 2010-03-22 2:07 ` Stefan Monnier 2 siblings, 2 replies; 17+ messages in thread From: Ted Zlatanov @ 2010-03-21 18:55 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 18:55 ` Ted Zlatanov @ 2010-03-21 19:34 ` joakim 2010-03-21 20:39 ` Lennart Borgman 1 sibling, 0 replies; 17+ messages in thread From: joakim @ 2010-03-21 19:34 UTC (permalink / raw) To: Ted Zlatanov; +Cc: Emacs development discussions 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 18:55 ` Ted Zlatanov 2010-03-21 19:34 ` joakim @ 2010-03-21 20:39 ` Lennart Borgman 2010-03-21 22:49 ` Ted Zlatanov 1 sibling, 1 reply; 17+ messages in thread From: Lennart Borgman @ 2010-03-21 20:39 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 20:39 ` Lennart Borgman @ 2010-03-21 22:49 ` Ted Zlatanov 2010-03-21 22:53 ` Lennart Borgman 0 siblings, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-03-21 22:49 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 22:49 ` Ted Zlatanov @ 2010-03-21 22:53 ` Lennart Borgman 2010-03-22 1:32 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Lennart Borgman @ 2010-03-21 22:53 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 22:53 ` Lennart Borgman @ 2010-03-22 1:32 ` Ted Zlatanov 2010-03-22 1:36 ` Lennart Borgman 0 siblings, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-03-22 1:32 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-22 1:32 ` Ted Zlatanov @ 2010-03-22 1:36 ` Lennart Borgman 2010-03-22 2:25 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Lennart Borgman @ 2010-03-22 1:36 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-22 1:36 ` Lennart Borgman @ 2010-03-22 2:25 ` Ted Zlatanov 2010-03-22 13:19 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-03-22 2:25 UTC (permalink / raw) To: emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-22 2:25 ` Ted Zlatanov @ 2010-03-22 13:19 ` Ted Zlatanov 0 siblings, 0 replies; 17+ messages in thread From: Ted Zlatanov @ 2010-03-22 13:19 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Should Emacs have an upgrade procedure? 2010-03-21 16:41 Should Emacs have an upgrade procedure? joakim 2010-03-21 17:21 ` Drew Adams 2010-03-21 18:55 ` Ted Zlatanov @ 2010-03-22 2:07 ` Stefan Monnier 2 siblings, 0 replies; 17+ messages in thread From: Stefan Monnier @ 2010-03-22 2:07 UTC (permalink / raw) To: joakim; +Cc: Emacs development discussions > - 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-03-22 13:19 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-03-21 16:41 Should Emacs have an upgrade procedure? joakim 2010-03-21 17:21 ` Drew Adams 2010-03-21 20:36 ` joakim 2010-03-21 23:55 ` Juri Linkov 2010-03-22 1:14 ` Lennart Borgman 2010-03-22 1:18 ` Juri Linkov 2010-03-22 1:32 ` Lennart Borgman 2010-03-21 18:55 ` Ted Zlatanov 2010-03-21 19:34 ` joakim 2010-03-21 20:39 ` Lennart Borgman 2010-03-21 22:49 ` Ted Zlatanov 2010-03-21 22:53 ` Lennart Borgman 2010-03-22 1:32 ` Ted Zlatanov 2010-03-22 1:36 ` Lennart Borgman 2010-03-22 2:25 ` Ted Zlatanov 2010-03-22 13:19 ` Ted Zlatanov 2010-03-22 2:07 ` Stefan Monnier
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).