Further problem with recent changes to custom-magic-alist.

Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

I have a further problem with the recent changes to custom-magic-alist:

You have set this %c and saved it through Customize in your init file.

This is too long.  It produces lots of ugly continuation lines.
It also is inaccurate if custom-file is non-nil.

What about just:

You have set and saved this %c through Customize.

Sincerely,

Luc.

Re: Further problem with recent changes to custom-magic-alist.

[Richard Stallman]

    You have set this %c and saved it through Customize in your init file.

    This is too long.  It produces lots of ugly continuation lines.
    It also is inaccurate if custom-file is non-nil.

Telling the user the value has been saved in the init file may help
users understand what is going on.  That is useful.  As for the case
where custom-file is non-nil, that is comparatively unimportant.
Being helpful in the usual case is a higher priority than being
accurate when the user has changed things.

I thought about replacing "init file" with some other term such as
"custom file", so as to be accurate in all cases, but that just
isn't common Emacs terminology and it won't be as clear.

So I think the best way to shorten this is to delete "through
Customize".  That too is unfortunate to lose, but better than
the other alternatives.

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

We are talking about:

You have set this %c and saved it through Customize in your init file.

Richard Stallman wrote:

   So I think the best way to shorten this is to delete "through Customize".

That would be very misleading.  There are two ways a user can set an
option permanently:  through Custom and by writing code in his init
file.  Once "through Customize" is deleted, the message seems to say
that the user did the latter:

You have set this %c and saved it in your init file.

   Telling the user the value has been saved in the init file may help
   users understand what is going on.

But the State message is not the place to try to explain how Custom is
implemented.  The user is already reminded that things are written in
his init file each time he saves an option.

Sincerely,

Luc.

Re: Further problem with recent changes to custom-magic-alist.

[Robert J. Chassell]

   That would be very misleading.  There are two ways a user can set an
   option permanently:  through Custom and by writing code in his init
   file.  

Your statement is confusing.  Custom automatically writes code that is
saved in an init file.  It is a code generating tool that saves in a
particular place.

   You have set this %c and saved it in your init file.

This wording is correct.  In this case, you did not write the code
yourself, but had a library do it.  You set %c and saved it in your
init file.

Richard's suggestion for saving some characters makes sense.  His
wording is both accurate and good.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

Robert Chassell wrote:

      You have set this %c and saved it in your init file.

   This wording is correct.  In this case, you did not write the code
   yourself, but had a library do it.

But nothing in the sentence tells the latter.  Therefore, the sentence
is very misleading.

_The_ most important thing one needs to know when trying to save a
previously saved option to a new value or reset it to standard, is
whether it was saved _by Custom_, because that affects whether trying
to save a new value or resetting to standard is guaranteed to work.

A State message tries to identify which of nine possible states an
option is in.  A list of them can be found in the initial comment to
cus-edit.el.  That is _all_ a State message should try to do.  Telling
that it was saved in the init file does not help clarifying which of
the nine state the option is in.  On the contrary, it tends to suggest
that the state is "Modified" (set outside Custom) instead of "Saved"
(saved through Custom).  Hence, it does not belong in the State message.

If it _has_ to be told somewhere it would be in the general
documentation at the top of the Custom-buffer, for instance:

===File ~/cus-edit.el-newdiff===============================
*** cus-edit.el	22 Feb 2005 16:55:41 -0600	1.213
--- cus-edit.el	22 Feb 2005 18:32:23 -0600	
***************
*** 1377,1384 ****
  	(widget-insert (format ".
  %s show active fields; type RET or click mouse-1
  on an active field to invoke its action.  Editing an option value
! changes the text in the buffer; invoke the State button and
  choose the Set operation to set the option value.
  Invoke " (if custom-raised-buttons
  	     "`Raised' buttons"
  	     "Square brackets")))
--- 1377,1388 ----
  	(widget-insert (format ".
  %s show active fields; type RET or click mouse-1
  on an active field to invoke its action.  Editing an option value
! changes the text in the buffer.  Invoke the State button and
  choose the Set operation to set the option value.
+ Choose the Save operation to save it.  Saving an option writes a
+ `custom-set-variables' and a `custom-set-faces' form in your
+ `custom-file' (usually .emacs) if they are not yet present and
+ edits these forms otherwise.
  Invoke " (if custom-raised-buttons
  	     "`Raised' buttons"
  	     "Square brackets")))
***************
*** 1683,1689 ****
  this %c has been changed outside the customize buffer." "\
  something in this group has been changed outside customize.")
      (saved "!" custom-saved-face "\
! You have set this %c and saved it through Customize in your init file." "\
  something in this group has been set and saved.")
      (rogue "@" custom-rogue-face "\
  this %c has not been changed with customize." "\
--- 1687,1693 ----
  this %c has been changed outside the customize buffer." "\
  something in this group has been changed outside customize.")
      (saved "!" custom-saved-face "\
! You have set and saved this %c through Customize." "\
  something in this group has been set and saved.")
      (rogue "@" custom-rogue-face "\
  this %c has not been changed with customize." "\
============================================================

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

>From my previous message:

   + Choose the Save operation to save it.  Saving an option writes a
   + `custom-set-variables' and a `custom-set-faces' form in your
   + `custom-file' (usually .emacs) if they are not yet present and
   + edits these forms otherwise.

This also would take care of objections from people who said that
`custom-file' should be mentioned in Custom buffers.

Sincerely,

Luc.

Re: Further problem with recent changes to custom-magic-alist.

[Robert J. Chassell]

         You have set this %c and saved it in your init file.

   _The_ most important thing one needs to know when trying to save a
   previously saved option to a new value or reset it to standard, is
   whether it was saved _by Custom_, because that affects whether trying
   to save a new value or resetting to standard is guaranteed to work.

Hmmm ... I am confused.  When I look at my .emacs file I see

    (custom-set-faces
      ;; ... 
     '(Buffer-menu-buffer-face ((t (:weight normal))))
     '(Info-title-1-face ((t (:background "DodgerBlue4" :foreground "white" :overline nil :underline nil :slant normal :weight normal :height 193 :width normal))))
      ;; ... )

[[The poor pretty printing is not mine.  The automatically written code
should have incorporated a pretty printer with a fill column of 70.
On looking at it, emacs/lisp/emacs-lisp/pp.el lacks a variable for
`fill-column' with a default value of 70; its addition should go on
the emacs/etc/TODO list.]]

When I want to change the background color from "DodgerBlue4" to
"mediumblue" (as I did once) I simply change the expression and
re-evaluate it.  If I like the new color (I didn't) I save it.  If I
do not like the new color I revert it and save.

As far as I know, when you set and save a value,  you get the 
"last value saved from customize" (to quote emacs/lisp/cus-edit.el).

The other possible states do not really matter.  What matters is that
Emacs evaluates the `custom-set-faces expression and saves it.

It is nice to know about the other possible states.  It is good to
read the source code; but many novices will not.  But some of them
will look at the message.

Hence, it is a good  message.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Further problem with recent changes to custom-magic-alist.

[Richard Stallman]

    We are talking about:

    You have set this %c and saved it through Customize in your init file.

How about

 You've set this %c and Customize saved it in your init file.

Re: Further problem with recent changes to custom-magic-alist.

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

>     We are talking about:
>
>     You have set this %c and saved it through Customize in your init file.
>
> How about
>
>  You've set this %c and Customize saved it in your init file.

I would prefer something like

   You've set and saved this %c.

Put a link to an Info page with information about where the saving is done
in the customize buffer.

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

Lennart Borgman wrote:

   Put a link to an Info page with information about where the saving is done
   in the customize buffer.

I agree.  Moreover, other people have asked for a link explaining
`custom-file'.

I enclose a patch which implements this and also makes the states of
options more recognizable, by using messages starting with a
capitalized keyword.  After installing the patch in my own private
Emacs, I found that it indeed made it a lot easier for me to quickly
recognize states.  It goes part of the way in the direction of a
change suggested by Drew.  I could install in CVS, if desired.

Motivation for new link to Emacs manual node on `custom-file':

I believe that more people use `custom-file' than Richard believes.
There are two unrelated reasons to use it.  The first is because
trying to use the same file (.emacs) for different Emacs versions might
not work because of incompatibilities.  (That is why I _need_ to have
several Custom files.)  The second is because people do not like two
huge blurbs to be written in their .emacs.

Putting the fact that saving writes into `custom-file' in the State
message does not work very well, because there is no place there to do
it appropriately and because it is told after the fact.  If people did
not like Custom to write into their .emacs, it is already done.

The patch below puts the info on top of the Custom buffer, where
people can see it _before_ they save.  It puts in a link to the node
in the Emacs manual explaining `custom-file', as people have
requested.  It is much shorter than my previous similar proposal.  It
adds only one line, containing the new link.

Motivation for message style change:

   I would prefer something like

      You've set and saved this %c.

I believe that we should shorten the messages as much as possible and
put one capitalized keyword in front, allowing people who already know
the rest of the text by heart to quickly recognize the State.

The State message would become:

SAVED, but not set.

If deemed _really_ necessary, there would be place for things like:

SAVED, but not set.  Code written into `custom-file'.

Or, less accurately, if custom-file is set:

SAVED, but not set.  Code written in your init file.

However, the patch below already puts much more helpful info on top of
the Custom buffer.  I see no reason to repeat it for every single saved
option.

The capitalized keywords I used are essentially the same as the
internal Custom symbols, except that I replaced "MODIFIED" with
"EDITED", which seemed clearer.  I replaced "ROGUE" with "STRAY",
because otherwise there might be confusion with `M-x customize-rogue',
which is actually meant to produce a buffer containing all CHANGED
(outside customize) options.  The "ROGUE"-"STRAY" issue is not very
relevant, because such options normally never occur in Custom buffers.
They can only "stray" into them by very badly written code.

No info present in the current messages was lost (except for the
writing into .emacs, which went to the top of the buffer.)  Space was
saved by using a more compacted style, not by deleting info.  For the
"CHANGED" state, very essential info was added.

===File ~/cus-edit-latest-diff==============================
*** cus-edit.el	22 Feb 2005 16:55:41 -0600	1.213
--- cus-edit.el	24 Feb 2005 13:59:31 -0600	
***************
*** 1377,1392 ****
  	(widget-insert (format ".
  %s show active fields; type RET or click mouse-1
  on an active field to invoke its action.  Editing an option value
! changes the text in the buffer; invoke the State button and
! choose the Set operation to set the option value.
! Invoke " (if custom-raised-buttons
! 	     "`Raised' buttons"
! 	     "Square brackets")))
  	(widget-create 'info-link
  		       :tag "Help"
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for more information.\n\n")
  	(message "Creating customization buttons...")
  	(widget-insert "Operate on everything in this buffer:\n "))
      (widget-insert " "))
--- 1377,1399 ----
  	(widget-insert (format ".
  %s show active fields; type RET or click mouse-1
  on an active field to invoke its action.  Editing an option value
! changes only the text in the buffer.  Invoke the State button to set or
! save the option value.  Saving an option normally edits your init file.
! Invoke "
! 			       (if custom-raised-buttons
! 				   "`Raised' buttons"
! 				 "Square brackets")))
! 	(widget-create 'info-link
! 		       :tag "Custom file"
! 		       "(emacs)Saving Customizations")
! 	(widget-insert
! 	 " for information on how to save in a different file.
! Invoke ")
  	(widget-create 'info-link
  		       :tag "Help"
  		       :help-echo "Read the online help."
  		       "(emacs)Easy Customization")
! 	(widget-insert " for general information.\n\n")
  	(message "Creating customization buttons...")
  	(widget-insert "Operate on everything in this buffer:\n "))
      (widget-insert " "))
***************
*** 1665,1695 ****
  
  (defconst custom-magic-alist
    '((nil "#" underline "\
! uninitialized, you should not see this.")
      (unknown "?" italic "\
! unknown, you should not see this.")
      (hidden "-" default "\
! hidden, invoke \"Show\" in the previous line to show." "\
  group now hidden, invoke \"Show\", above, to show contents.")
      (invalid "x" custom-invalid-face "\
! the value displayed for this %c is invalid and cannot be set.")
      (modified "*" custom-modified-face "\
! you have edited the value as text, but you have not set the %c." "\
  you have edited something in this group, but not set anything yet.")
      (set "+" custom-set-face "\
! you have set this %c, but not saved it for future sessions." "\
  you have set something in this group, but not saved anything yet.")
      (changed ":" custom-changed-face "\
! this %c has been changed outside the customize buffer." "\
  something in this group has been changed outside customize.")
      (saved "!" custom-saved-face "\
! You have set this %c and saved it through Customize in your init file." "\
  something in this group has been set and saved.")
      (rogue "@" custom-rogue-face "\
! this %c has not been changed with customize." "\
  something in this group is not prepared for customization.")
      (standard " " nil "\
! this %c is unchanged from its standard setting." "\
  visible group members are all at standard settings."))
    "Alist of customize option states.
  Each entry is of the form (STATE MAGIC FACE ITEM-DESC [ GROUP-DESC ]), where
--- 1672,1702 ----
  
  (defconst custom-magic-alist
    '((nil "#" underline "\
! UNINITIALIZED, you should not see this.")
      (unknown "?" italic "\
! UNKNOWN, you should not see this.")
      (hidden "-" default "\
! HIDDEN, invoke \"Show\" in the previous line to show." "\
  group now hidden, invoke \"Show\", above, to show contents.")
      (invalid "x" custom-invalid-face "\
! INVALID, the displayed value cannot be set.")
      (modified "*" custom-modified-face "\
! EDITED, but not set." "\
  you have edited something in this group, but not set anything yet.")
      (set "+" custom-set-face "\
! SET, but not saved." "\
  you have set something in this group, but not saved anything yet.")
      (changed ":" custom-changed-face "\
! CHANGED outside Customize; operating on it here may be unreliable." "\
  something in this group has been changed outside customize.")
      (saved "!" custom-saved-face "\
! SAVED and set." "\
  something in this group has been set and saved.")
      (rogue "@" custom-rogue-face "\
! STRAY, you should not see this." "\
  something in this group is not prepared for customization.")
      (standard " " nil "\
! STANDARD." "\
  visible group members are all at standard settings."))
    "Alist of customize option states.
  Each entry is of the form (STATE MAGIC FACE ITEM-DESC [ GROUP-DESC ]), where
***************
*** 1709,1715 ****
  `set'
     This item has been set but not saved.
  `changed'
!    The current value of this item has been changed temporarily.
  `saved'
     This item is marked for saving.
  `rogue'
--- 1716,1722 ----
  `set'
     This item has been set but not saved.
  `changed'
!    The current value of this item has been changed outside Customize.
  `saved'
     This item is marked for saving.
  `rogue'
============================================================

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

>From my previous reply:

   If deemed _really_ necessary, there would be place for things like:

   SAVED, but not set.  Code written into `custom-file'.

   Or, less accurately, if custom-file is set:

   SAVED, but not set.  Code written in your init file.

That could be somewhat confusing again.  Better:

SAVED, but not set.  Custom wrote code into `custom-file'.

or:

SAVED, but not set.  Custom wrote code in your init file.

But I really find both redundant, given the proposed text on top of
the buffer.  So I prefer:

SAVED, but not set.

which is the present version of my patch.

Sincerely,

Luc.

Re: Further problem with recent changes to custom-magic-alist.

[Richard Stallman]

The idea of using capitalized keywords is good, but you've shortened
some of the messages too much.  I don't like these:

    ! EDITED, but not set." "\
      you have edited something in this group, but not set anything yet.")
	  (set "+" custom-set-face "\
    ! SET, but not saved." "\

And this is quite confusing:

    ! STRAY, you should not see this." "\

Aside from that aspect, it is good.

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

   The idea of using capitalized keywords is good, but you've shortened
   some of the messages too much.  I don't like these:

       ! EDITED, but not set." "\

What about:

EDITED, shown value does not take effect until you set or save it.

   ! SET, but not saved." "\

What about:

SET for current session only.

   And this is quite confusing:

       ! STRAY, you should not see this." "\

What about:

UNCUSTOMIZABLE, you should not see this.

The "you should not see this" is the same sentence that occurs in:

UNINITIALIZED, you should not see this.

and

UNKNOWN, you should not see this.

All three should really not occur in an actual Custom buffer.

Sincerely,

Luc.

Re: Further problem with recent changes to custom-magic-alist.

[Richard Stallman]

    EDITED, shown value does not take effect until you set or save it.

That is good.

    SET for current session only.

That is good.

    UNCUSTOMIZABLE, you should not see this.

How about

   NO CUSTOMIZATION DATA; you should not see this.

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

Richard Stallman wrote:

       UNCUSTOMIZABLE, you should not see this.

   How about

      NO CUSTOMIZATION DATA; you should not see this.

I installed the latter.  It really does not matter that much, since
those variables really should not find their way into Custom buffers.

Sincerely,

Luc.

Re: Further problem with recent changes to custom-magic-alist.

[Luc Teirlinck]

Richard Stallman wrote:

   You've set this %c and Customize saved it in your init file.

That gets rid of the confusion that the user might have set it by hand
in his init file, which was by far the worst of the two possible
confusions.  So it is a big improvement over your previous suggestion.

It might still confuse people who set custom-file.  (I have the
impression that this concerns much more people than you believe.)  I
still do not understand why one would want to explain the mechanics
of how Custom saves values _in the State message_.  You do not have
enough place there to do it accurately and it has nothing to do with
which state the option is in.

Sincerely,

Luc.