unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: alex <current@protonmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: johnw@gnu.org, bruce.connor.am@gmail.com, emacs-devel@gnu.org
Subject: Re: Option to not automatically customize-save-variable `package-selected-packages'
Date: Fri, 19 Feb 2016 17:55:21 -0500	[thread overview]
Message-ID: <xyE174b6h-SXfD6RA3Pq8PvOLdSUb9ndikP_ajYJ9ATyW-JVcZJO5m_TR_6mSCiYex6n0_B8zPssRD0hj43gbA==@protonmail.com> (raw)
In-Reply-To: <83io1lrq0b.fsf@gnu.org>

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

Eli Zaretskii <eliz@gnu.org> writes:

> What would the prompt say in this case?

Perhaps something along the lines of "Save <package> permanently to package-selected-packages? (y or n)". Then a variable can be introduced to determine whether or not this prompt should be displayed, or if it should even be saved at all. A variable similar to this is `vc-follow-symlinks', which can have the values nil, ask, or t.

> wouldn't that mean Emacs will not know these packages
> weer selected next time it starts?

Yes, so if you relied on its functionality then it could cause issues. This would be something for the user to decide.

>I see no reason yet why this particular customization is different as to
> require a specialized solution just for it. Can you tell why you
> think it is different?

I do write Lisp for almost all of my customizations, but this isn't really a case where I think behaviour should be handed off to the users to manually tune. For instance, I don't want to have custom Lisp in my init file handling all of my abbrevs, yasnippets, or words in my personal Emacs dictionary. All of these have their own files to which they save data to. I think that the list of `selected' packages, if saved, should go to its own file like the above.

Other customized variables are easy to maintain. `package-selected-packages' on the other hand is a bit more dynamic and can become quite large and difficult to maintain.

I can't use the customize interface for this variable since as far as I'm aware the customize file isn't great for conditionally assigning variables depending on other variables at run-time (like system-type), though perhaps I'm wrong.

So customize seems to be out of the picture here. Without a separate save file, I'd have to use my init file for the job. Certainly it's possible to conditionally setq the variable depending on the machine state, but this can become quite unwieldy with a large number of packages, and with more and more different machines with different packages that you want in this list. There could be a lot of work needed to manually change all of these branches for every package installed/removed.

When I save an abbrev or a dictionary word, I don't want to manually edit my init file corresponding to that. Likewise, I'd rather not have to edit this variable every time I add/drop a package. A separate file, that can be made machine-specific, that holds this data would mean that the users don't have to edit it themselves, nor do they have to worry about the variable being overwritten when the same configuration is moved to a different machine and back.

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

  reply	other threads:[~2016-02-19 22:55 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17  9:27 Option to not automatically customize-save-variable `package-selected-packages' Angelo Graziosi
2016-02-17 23:05 ` John Wiegley
2016-02-18  1:04   ` Angelo Graziosi
2016-02-18  1:43   ` Artur Malabarba
2016-02-18 16:49     ` Eli Zaretskii
2016-02-18 17:28       ` Colin Baxter
2016-02-18 17:35         ` Kaushal Modi
2016-02-18 18:06       ` Artur Malabarba
2016-02-18 18:15         ` Eli Zaretskii
2016-02-18 20:34           ` Joost Kremers
2016-02-18 21:00             ` Eli Zaretskii
2016-02-18 21:49               ` Joost Kremers
2016-02-19  9:31                 ` Eli Zaretskii
2016-02-19  9:47                   ` Angelo Graziosi
2016-02-19 13:04                   ` Artur Malabarba
2016-02-19 15:50                     ` Eli Zaretskii
2016-02-19 18:29                       ` Artur Malabarba
2016-02-19 18:50                         ` Eli Zaretskii
2016-02-19 19:05                           ` Kaushal Modi
2016-02-19 20:34                             ` Eli Zaretskii
2016-02-21 23:56                               ` Joost Kremers
2016-02-22  0:10                                 ` John Wiegley
2016-02-22  3:37                                 ` Eli Zaretskii
2016-02-22 21:00                                   ` Bastian Beischer
2016-02-19  4:18           ` alex
2016-02-19  9:48             ` Eli Zaretskii
2016-02-19 21:15               ` alex
2016-02-20  7:53                 ` Eli Zaretskii
2016-02-18 18:25       ` Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages') Clément Pit--Claudel
2016-02-18 18:54         ` Mechanisms to persist information Eli Zaretskii
2016-02-18 19:22           ` Jonathan Leech-Pepin
2016-02-20  2:17         ` Mechanisms to persist information (Re: Option to not automatically customize-save-variable `package-selected-packages') John Wiegley
2016-02-20  4:44           ` Eric Abrahamsen
2016-02-18 18:45       ` Option to not automatically customize-save-variable `package-selected-packages' John Wiegley
2016-02-19  4:17       ` alex
     [not found]       ` <vYxebPyde_BnqKsA6mXLVX-_dj3rDIchNBYl3O1LxNhGCR7etgi0R4ZR7de5PU1TZXk9R4YsCjNxqkoh5lBR3Q==@protonmail.com>
2016-02-19  9:47         ` Eli Zaretskii
2016-02-19 22:55           ` alex [this message]
2016-02-20  8:27             ` Eli Zaretskii
2016-03-05  0:40               ` alex
2016-02-18 16:19   ` raman
2016-02-18 18:55     ` Angelo Graziosi
2016-02-18 19:00       ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2016-02-17  3:39 Option to not automatically customize-save-variable `package-selected-packages'? alex
2016-02-17  4:10 ` John Wiegley
2016-02-17 10:02   ` Artur Malabarba
2016-02-18 16:52     ` Aaron Ecay
2016-02-17 12:43   ` Joost Kremers
2016-02-17 10:14 ` Colin Baxter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='xyE174b6h-SXfD6RA3Pq8PvOLdSUb9ndikP_ajYJ9ATyW-JVcZJO5m_TR_6mSCiYex6n0_B8zPssRD0hj43gbA==@protonmail.com' \
    --to=current@protonmail.com \
    --cc=bruce.connor.am@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=johnw@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).