How to customize an option to a dynamic value (computed by lisp form)

How to customize an option to a dynamic value (computed by lisp form)

[Jorge]

Hi.  I set three options to a dynamic value, using the value of the option
`org-directory'.  Now my custom-set-variables call in init.el includes the
following:

   '(org-agenda-files
     (list
      (concat org-directory "/agenda/")
      "~/Dropbox/wanessa_e_jorge/administração_clínica/derma-prime.org"))
   [...]
   '(org-icalendar-combined-agenda-file (concat org-directory "/org.ics"))
   [...]
   '(org-mobile-inbox-for-pull (concat org-directory "/agenda/from-mobile.org"))

The problem is that when I try to customize one of these three options, the
customize buffer does not know that the value was computed dynamically.  For
example, the customize buffer for org-mobile-inbox-for-pull shows the value as
simply "~/org/agenda/from-mobile.org".  This means that if I edit the value to
"~/org/agenda/from-mobile42.org" and save the customization, it will be written
to init.el as a string literal, no longer respecting org-directory.  Then if I
later change org-directory I will have problems.

Previously I worked around this problem by setting these options manually
(editing org-init.el, which is called by init.el), but I think the ideal would
be to use customize, so I decided to ask here.  I have already searched Google
and the list archives.

Thank you for your attention.
-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: How to customize an option to a dynamic value (computed by lisp form)

[Pascal J. Bourguignon]

Jorge <jorge13515@gmail.com> writes:

> Hi.  I set three options to a dynamic value, using the value of the option
> `org-directory'.  Now my custom-set-variables call in init.el includes the
> following:
>
>    '(org-agenda-files
>      (list
>       (concat org-directory "/agenda/")
>       "~/Dropbox/wanessa_e_jorge/administração_clínica/derma-prime.org"))
>    [...]
>    '(org-icalendar-combined-agenda-file (concat org-directory "/org.ics"))
>    [...]
>    '(org-mobile-inbox-for-pull (concat org-directory "/agenda/from-mobile.org"))
>
> The problem is that when I try to customize one of these three options, the
> customize buffer does not know that the value was computed dynamically.  For
> example, the customize buffer for org-mobile-inbox-for-pull shows the value as
> simply "~/org/agenda/from-mobile.org".  This means that if I edit the value to
> "~/org/agenda/from-mobile42.org" and save the customization, it will be written
> to init.el as a string literal, no longer respecting org-directory.  Then if I
> later change org-directory I will have problems.
>
> Previously I worked around this problem by setting these options manually
> (editing org-init.el, which is called by init.el), but I think the ideal would
> be to use customize, so I decided to ask here.  I have already searched Google
> and the list archives.
>
> Thank you for your attention.


Since the customization system updates the source form
customize-variables in your init file (actually, in the file indicated by
the custom-file customization variable), and when it saves this source
form, it saves the values of the variables, not the dynamic expressions
you would use to compute them, you won't have much choice if you want to
keep it simple.

Just set the customization variables to your expressions after the
customize-variables form.


Of course, you can alway extend the customization system to take an optional
expression (to be evaluated in what environment?) for each customization
variable, and to generate the customize-variables form using those
expressions instead of the customization variables values.

Is it worth the trouble?
Customization variables are designed for people who can't type a lisp
expression.
As a lisper it's easier to just set the variables yourself.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: How to customize an option to a dynamic value (computed by lisp form)

[Jorge]

On 24 August 2016 at 14:50, Pascal J. Bourguignon <pjb@informatimago.com> wrote:

> Since the customization system updates the source form
> customize-variables in your init file (actually, in the file indicated by
> the custom-file customization variable), and when it saves this source
> form, it saves the values of the variables, not the dynamic expressions
> you would use to compute them, you won't have much choice if you want to
> keep it simple.
>
> Just set the customization variables to your expressions after the
> customize-variables form.
OK.  I have moved the customization of these three options to my
org-init.el.  Instead of the simple setq, I used
customize-set-variable, because it respects the respective custom-set
property (if it exists).

There remain two problems:
1.  customize-set-variable does not do type checking.  I have just
tested it by setting org-agenda-files to 42 (an integer).
set-variable does type checking, but does not respect any custom-set
property.  How can I elegantly combine both?  And shouldn't elisp
provide a convenient command for this?
2.  If I forget that these options are changed manually (Emacs does
not warn), and configure them via customize, then the new value will
be added to the custom-set-variables form with static values.  This
has two problems:
      1. It will have static values.
      2. Since org-init.el is called after the custom-set-variables
form, the values set in the form will be overwritten.

RE: How to customize an option to a dynamic value (computed by lisp form)

[Drew Adams]

> There remain two problems:

> 1.  customize-set-variable does not do type checking.  I have just
> tested it by setting org-agenda-files to 42 (an integer).

This seems like a bug.  Even if it is by design, it seems like
something that should be improved (aka fixed).

But if you mean only interactively, then it _does_ do type-checking.

> set-variable does type checking, but does not respect any custom-set
> property.

`set-variable' does _not_ do type-checking either.

Perhaps you are thinking of the fact that _when used
interactively_ it checks the type.  (set-variable foo 42) does not.

I filed a bug long ago to make `set-variable' respect :set etc.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6578

(The bug report never even got a reply, and was classed as "wishlist")

> How can I elegantly combine both?  And shouldn't elisp
> provide a convenient command for this?

Try to specify the behavior you want (more clearly).  Presumably
you are looking for a way, using Lisp (non-interactively), to set
an option value and get all of the behavior that you get when you
set it using the Customize UI (:set, :type, etc. control).

> 2.  If I forget that these options are changed manually (Emacs does
> not warn), and configure them via customize, then the new value will
> be added to the custom-set-variables form with static values.  This
> has two problems:
>       1. It will have static values.
>       2. Since org-init.el is called after the custom-set-variables
>          form, the values set in the form will be overwritten.

Again, please specify clearly the behavior you want and the behavior
you see instead.

A variable value is always "static", by definition of the word "value".
It's not clear (to me) just what you are looking for.

BTW, you can easily check whether an option has been changed outside
Customize, i.e., using something like `setq' and not something like
`customize-set-variable', by invoking code such as this (taken from
`customize-rogue', which lets you open Customize for all such options):

(defun rogue-option-p (symbol)
  (let ((cval  (or (get symbol 'customized-value)
                   (get symbol 'saved-value)
                   (get symbol 'standard-value))))
    (and cval                           ;Declared with defcustom.
         (default-boundp symbol)        ;Has a value.
         (not (equal (eval (car cval))
                     ;; Which does not match customize.
                     (default-value symbol))))))

Re: How to customize an option to a dynamic value (computed by lisp form)

[Jorge]

On 25 August 2016 at 17:54, Drew Adams <drew.adams@oracle.com> wrote:
>> How can I elegantly combine both?  And shouldn't elisp
>> provide a convenient command for this?
>
> Try to specify the behavior you want (more clearly).  Presumably
> you are looking for a way, using Lisp (non-interactively), to set
> an option value and get all of the behavior that you get when you
> set it using the Customize UI (:set, :type, etc. control).
I want one elisp function that, even when called non-interactively,
respects custom-set and does type-checking.

> A variable value is always "static", by definition of the word "value".
> It's not clear (to me) just what you are looking for.
I am sorry.  By "static value" I meant "literal".

>
> BTW, you can easily check whether an option has been changed outside
> Customize, i.e., using something like `setq' and not something like
> `customize-set-variable', by invoking code such as this (taken from
> `customize-rogue', which lets you open Customize for all such options):
>
> (defun rogue-option-p (symbol)
>   (let ((cval  (or (get symbol 'customized-value)
>                    (get symbol 'saved-value)
>                    (get symbol 'standard-value))))
>     (and cval                           ;Declared with defcustom.
>          (default-boundp symbol)        ;Has a value.
>          (not (equal (eval (car cval))
>                      ;; Which does not match customize.
>                      (default-value symbol))))))
Thank you for sharing this.  But for now, I think I will rely on my
memory (I just have to remember that three options are customized on
org-init.el, and I can memorize the fact that options that use the
value of org-directory are configured in org-init.el).
-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: How to customize an option to a dynamic value (computed by lisp form)

[Jorge]

On 26 August 2016 at 09:54, Jorge <jorge13515@gmail.com> wrote:
> Thank you for sharing this.  But for now, I think I will rely on my
> memory (I just have to remember that three options are customized on
> org-init.el, and I can memorize the fact that options that use the
> value of org-directory are configured in org-init.el).

And I intend to ask the Org Mode developers to add the feature that
options which take file paths, and often are configured to paths
inside the org directory, should support relative paths (relative to
org-directory).

Regards
-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

RE: How to customize an option to a dynamic value (computed by lisp form)

[Drew Adams]

> I want one elisp function that, even when called non-interactively,
> respects custom-set and does type-checking.

You might want to `M-x report-emacs-bug'.  It is for enhancement
requests as well as bugs.

> > A variable value is always "static", by definition of the word
> > "value".  It's not clear (to me) just what you are looking for.
>
> I am sorry.  By "static value" I meant "literal".

What does that mean?  A variable has a single, static, literal
value at any time.  That's what a value is.  What you are looking
for is still unclear (to me).  Hopefully it is clearer to others,
and they can help more.

Re: How to customize an option to a dynamic value (computed by lisp form)

[Jorge]

On 26 August 2016 at 11:28, Drew Adams <drew.adams@oracle.com> wrote:
> You might want to `M-x report-emacs-bug'.  It is for enhancement requests as
> well as bugs.
Yes, I may do that, but not now (I have other bugs to report).

> What does that mean?  A variable has a single, static, literal value at any
> time.
https://en.wikipedia.org/wiki/Literal_(computer_programming)

See the following example C code, assuming that read_int is a function that
reads an integer from stdin:
const int answer = 42;  // the answer to life the universe and everything
const int answer_sq = answer*answer;
const int age = read_int();

All three variables defined above are constants. However, only the first two
have values which can be known at compile time, and only the first one is
initialized to a literal (42).

I want to be able to customize the options mentioned in the original email to
values computed from other options, but I cannot.  I can only initialize them
to literals.

-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: How to customize an option to a dynamic value (computed by lisp form)

[Jorge]

On 26 August 2016 at 16:02, Jorge <jorge13515@gmail.com> wrote:
> I want to be able to customize the options mentioned in the original email to
> values computed from other options, but I cannot.  I can only initialize them
> to literals.
I meant: /through Custom/ I can only configure options to literals.  But with
Lisp, of course, I am not limited to literals.



-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

RE: How to customize an option to a dynamic value (computed by lisp form)

[Drew Adams]

> > What does that mean?  A variable has a single, static, literal value at
> > any time.

> https://en.wikipedia.org/wiki/Literal_(computer_programming)

Which says:

"In computer science, a literal is a _notation_ for _representing_
a fixed value in source code."

Whereas here we are not talking about a notation.  We are not
talking about a source-code representation of a value.  We are
talking about a real, live, runtime value.

We are talking about the value of a variable, and a value is not
something particularly "dynamic".  A _variable_ could be considered
dynamic, in that it can change its value over time.

> const int answer = 42;  // the answer to life the universe and everything
> const int answer_sq = answer*answer;
> const int age = read_int();
> 
> All three variables defined above are constants. However, only the first
> two have values which can be known at compile time, and only the first
> one is initialized to a literal (42).

The context of what you requested has nothing to do with compile time,
and it has nothing to do with whether the source code defining the
option value uses a literal (self-evaluating Lisp thingy) or is
computed.

  "the new value will be added to the custom-set-variables form
   with static values.  This has two problems:
      1. It will have static values.
      2. Since org-init.el is called after the custom-set-variables
         form, the values set in the form will be overwritten."

When a variable is assigned a value, regardless of when or how,
the value is a value: essentially static.  (A value can be a mutable
object, such as a cons, but I don't think that's what you intended
by something "dynamic".)

> I want to be able to customize the options mentioned in the original email
> to values computed from other options, but I cannot.  I can only initialize
> them to literals.

Going back to your original message:

  "I set three options to a dynamic value, using the value of the
   option `org-directory'."

And you show code that, in effect, calls `customize-set-variable'
with this as the value argument:
 
(list (concat org-directory "/agenda/")
      "~/Dropbox/wanessa_e_jorge/administração_clínica/derma-prime.org")

The value that is assigned is a list of two strings.  It is not
especially "dynamic".  You did _not_ assign the variable to "a
dynamic value".

And your plaint was that Customize then shows you the value as
that "static" list of two strings, being oblivious to the fact
that you constructed the list and the first string, let alone
how you constructed them.

You say that after customizing the value "it will be written to
init.el as a string literal, no longer respecting org-directory."

You said: "The problem is that when I try to customize one of
these three options, the customize buffer does not know that
the value was computed dynamically."

And that's exactly right.  No matter how you set a variable
value, the value does not tell you how it was constructed.
Customize knows the allowed types for the value, and it
knows the current value and the initial value.  It does not
know or care how the initial or the current value was computed.

It sounds like what you want to use as value is not a list of
strings but a _function_ that, when called, returns a list of
strings, and you want that function to construct the first
string of the list using `org-directory'.  Here is a command
that does that.

(defun foo (subdir file)
  (interactive
    (list (read-directory-name "Agenda subdir: " org-directory nil t)
          (read-file-name "Org file: " nil nil t)))
  (customize-set-variable 'org-agenda-files
    (list (expand-file-name subdir org-directory) file)))

But that won't help you use the Customize UI to set it.
The defcustom defining `org-agenda-files' does not have
a :type that allows a function value.  The value must be
either a list of files and directories or a file name.

(If you really wanted to, you could redefine that defcustom
to accept a function value also, and then redefine the Org
code that uses the option, so that if the value is a function
it invokes it to get the required list of strings.)

What you can do (others might have other suggestions):

M-x foo RET
agenda RET 
/Dropbox/wanessa_e_jorge/administração_clínica/derma-prime.org RET

IOW, use a command to set the value, and have that command
respect `org-directory'.

Re: How to customize an option to a dynamic value (computed by lisp form)

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Aug 26, 2016 at 01:59:00PM -0700, Drew Adams wrote:
> > > What does that mean?  A variable has a single, static, literal value at
> > > any time.
> 
> > https://en.wikipedia.org/wiki/Literal_(computer_programming)
> 
> Which says:
> 
> "In computer science, a literal is a _notation_ for _representing_
> a fixed value in source code."

I think you are talking past each other (i.e. both of you are right,
in a way :)

There are many "dynamic" options, at least in effect, as far as I
understand Jorge.

Of course, the option's *value* itself is expressed as a literal
and is static, but it is "something dynamic", like a function (think
hooks), an expression, a shell command to be called or some form
of "implicit expression" written in a custom mini-language (think
`c-offset-alist'.

The job of interpreting the option as dynamic lies with the "receiver"
of the option, i.e. with the function(s) *using* that option.
Typically wrapped in some function.

Does that help?

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfBfqIACgkQBcgs9XrR2kYfWgCeIdd6mMIZB/LfL7TX3NOnulX6
QRQAnirSlgGtsZM7Pe6s/m9sjeJLeSVm
=LpLJ
-----END PGP SIGNATURE-----

Re: How to customize an option to a dynamic value (computed by lisp form)

[Jorge]

On 26 August 2016 at 17:59, Drew Adams <drew.adams@oracle.com> wrote:
>> https://en.wikipedia.org/wiki/Literal_(computer_programming)
>
> Which says:
>
> "In computer science, a literal is a _notation_ for _representing_
> a fixed value in source code."
>
> Whereas here we are not talking about a notation.  We are not
> talking about a source-code representation of a value.  We are
> talking about a real, live, runtime value.
>
> We are talking about the value of a variable, and a value is not
> something particularly "dynamic".  A _variable_ could be considered
> dynamic, in that it can change its value over time.
>
>> const int answer = 42;  // the answer to life the universe and everything
>> const int answer_sq = answer*answer;
>> const int age = read_int();
>>
>> All three variables defined above are constants. However, only the first
>> two have values which can be known at compile time, and only the first
>> one is initialized to a literal (42).
>
> The context of what you requested has nothing to do with compile time,
> and it has nothing to do with whether the source code defining the
> option value uses a literal (self-evaluating Lisp thingy) or is
> computed.

I mentioned compile time to distinguish compile-time-known constants (which
could be constexpr in C++) from literals.  I gave an example in C – and now I
mentioned C++ – because I know C and C++ better than Lisp.  I apologize if it
led to confusion.  I think that the concept of literals in Lisp is equivalent to
the concept of literals in C. AFAIK, in Lisp `"ab"' and `5' are literals, unlike
`(concat "a" "b")' and `(+ 2 3)'.

My point is that when using Custom, the generated custom-set-variables form
represents the value of org-agenda-files as a list of string literals, which
mean that if I change org-directory, then I have to re-customize
org-agenda-files.  An analogous situation holds for
org-icalendar-combined-agenda-file and org-mobile-inbox-for-pull.

> It sounds like what you want to use as value is not a list of
> strings but a _function_ that, when called, returns a list of
> strings, and you want that function to construct the first
> string of the list using `org-directory'.  Here is a command
> that does that.
>
> (defun foo (subdir file)
>   (interactive
>     (list (read-directory-name "Agenda subdir: " org-directory nil t)
>           (read-file-name "Org file: " nil nil t)))
>   (customize-set-variable 'org-agenda-files
>     (list (expand-file-name subdir org-directory) file)))
Thank you for the suggestion, but I think it would be more fruitful to go along
with my plan of asking the Org Mode developers to allow file paths in these
options to refer to org-directory.

Our conversation may have been obstructed by the fact that English is my second
language, and while I often read English, I rarely speak or write it.

Regards
-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/