On 21/11/2021 17:01, Ihor Radchenko wrote:
Max Nikulin writes:
My draft version is attached. Ihor, thank you for inspiration. Feel free
to improve it. I hope, it makes problem more apparent to user who tries
to customize markers. Have I missed some undesired side effects?
Unfortunately with "set" type in defcustom "catch inappropriate" item is
not hidden for valid configuration.
>
I am not very familiar with :set customisation. Could you elaborate what
you mean? I do not understand what "catch inappropriate" refers to.
I am afraid of confusion of ":set" defcustom parameter and "set" type in
":type" parameter.
I mean "set" instead of "repeat" (or "list" in your patch). It is
collection of *unique* items. Other variants allow to add several
entries for the same marker, e.g. "*". Set does not allow users to add
duplicated entries. I started from your description of allowed entries
and changed rigid "list" type to "set" and added (approximately)
(list :tag "Unsupported ignored"
(string :tag "Marker")
(choice :tag "Font"
(face :tag "Face")
(plist :tag "Property list"))
(option (const verbatim))
to notify user that some part of configuration does not work, it is
always shown in `customize-variable' interface, even as a disabled
option for default configuration.
With repeat, "Unsupported" options are not present in customization
buffer, unless user has something like
(custom-set-variables
'(org-emphasis-alist
(quote
(
("*" bold)
("_" underline)
("=" org-verbatim verbatim)
("/" italic)
("~" org-code verbatim)
("!" org-todo) ;; does not work
("+" (:strike-through t)))))
)
It is possible to add "seq" entry to catch list entries having
completely invalid structure, but I decided that it is redundant.
So with "repeat" type user may notice "Unsupported ignored" option in
customization interface. I think, it is not enough, so I added ":set"
function that issues a warning during load time. Invalid configuration
may still remain hidden in the case of `setq' instead of
`custom-set-variables' in the init file or `eval-after-load' hook. I am
afraid, nothing could be done to reliably detect the last case.
+ ... It is possible to customize
+~org-emphasis-alist~ variable, but it will be deprecated.
We probably do not need to mention to-be-deprecated variables in manual.
It will only confuse users.
I do not insist. My intention is to inform users that wide spread
recipes should be avoided.
Maybe we should also take a chance and deprecate org-emphasis-alist now?
We can introduce org-bold/italics/... faces and use them in
org-emphasis-alist default value.
I do not mind. I have never experimented with themes, so I would leave
this part of work to someone else.
