Difficulties with `purecopy' discarding text properties from strings

Difficulties with `purecopy' discarding text properties from strings

[Alan Mackenzie]

Hello, Emacs.

The context is my implementing of new mode-line %-constructs.  I want a
customisable user option whose values will be things like ("%o"), with
text properties on the string (for things like help strings and mouse
action key bindings).

I naively constructed such a defcustom, with text properties on the
value option strings.  After some debugging, I discover that defcustom
strips those text properties off the strings.  It does this by using
`purecopy' on these strings (in the function `custom-declare-variable').

(Yes, the variable I'm trying to declare is in bindings.el along with
all the other mode-line stuff, and this is preloaded stuff.)

So, I'm a little bit stuck.

Presumably there are good reasons for discarding text properties when
purecopying strings.  Or, maybe, there was just no particular reason to
amend the workings of `purecopy' when text properties came into
existence.

How does this sound for a solution to the problem?  In `defcustom',
introduce a new keyword `impure:' which, when placed early enough in the
defcustom would inhibit the `purecopy' action.

Or should I work at amending `purecopy' also to copy text properties?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulties with `purecopy' discarding text properties from strings

[Daniel Colascione]

On 05/19/2017 11:55 AM, Alan Mackenzie wrote:
> Hello, Emacs.
>
> The context is my implementing of new mode-line %-constructs.  I want a
> customisable user option whose values will be things like ("%o"), with
> text properties on the string (for things like help strings and mouse
> action key bindings).
>
> I naively constructed such a defcustom, with text properties on the
> value option strings.  After some debugging, I discover that defcustom
> strips those text properties off the strings.  It does this by using
> `purecopy' on these strings (in the function `custom-declare-variable').
>
> (Yes, the variable I'm trying to declare is in bindings.el along with
> all the other mode-line stuff, and this is preloaded stuff.)
>
> So, I'm a little bit stuck.
>
> Presumably there are good reasons for discarding text properties when
> purecopying strings.  Or, maybe, there was just no particular reason to
> amend the workings of `purecopy' when text properties came into
> existence.
>
> How does this sound for a solution to the problem?  In `defcustom',
> introduce a new keyword `impure:' which, when placed early enough in the
> defcustom would inhibit the `purecopy' action.
>
> Or should I work at amending `purecopy' also to copy text properties?

When we move to the new dumper (whatever it is), I don't think we'll 
have a conventional purespace at all anymore. In my system, text 
properties are just automatically preserved along with everything else 
and don't get special treatment.

Re: Difficulties with `purecopy' discarding text properties from strings

[Stefan Monnier]

> Presumably there are good reasons for discarding text properties when
> purecopying strings.

I don't think so.

> Or, maybe, there was just no particular reason to amend the workings
> of `purecopy' when text properties came into existence.

I think that's what happens.

But wait a minute:
> I naively constructed such a defcustom, with text properties on the
> value option strings.

How exactly did you do that?  Using #("..." ...)
or using (propertize "..." ...)?

> After some debugging, I discover that defcustom strips those text
> properties off the strings.  It does this by using `purecopy' on these
> strings (in the function `custom-declare-variable').

But AFAICT custom-declare-variable only applies purecopy to its
`default` argument which is supposed to be an expression (which
evaluates to the intended value) rather than a value.  So if you use the
(propertize "..." ...)  form, the properties should not be stripped.

Or am I missing something?


        Stefan

Re: Difficulties with `purecopy' discarding text properties from strings

[Alan Mackenzie]

Hello, Stefan.

On Fri, May 19, 2017 at 15:22:50 -0400, Stefan Monnier wrote:
> > Presumably there are good reasons for discarding text properties when
> > purecopying strings.

> I don't think so.

> > Or, maybe, there was just no particular reason to amend the workings
> > of `purecopy' when text properties came into existence.

> I think that's what happens.

Yes, that's probably what happened.

> But wait a minute:
> > I naively constructed such a defcustom, with text properties on the
> > value option strings.

> How exactly did you do that?  Using #("..." ...)
> or using (propertize "..." ...)?

By using propertize:

(defun mode-line-%-propertize (str)
  "Add standard mode-line properties to STR, a string.
These enable certain mouse operations when the mouse pointer is
hovering over the display of STR in the mode line."
  (propertize
   str
   'local-map mode-line-column-line-number-mode-map
   'mouse-face 'mode-line-highlight
   ;; XXX needs better description
   'help-echo "Size indication mode\n\
mouse-1: Display Line and Column Mode Menu"))

(defcustom mode-line-percent-position `(,(mode-line-%-propertize "%p"))
  "Type of \"percentage offset\" of window through buffer to display
This option specifies the type of offset displayed in
`mode-line-position',
a component of the default `mode-line-format'."
  :type `(radio
          (const :tag "nil:  No offset is displayed" nil)
          (const :tag "\"%o\": Proportion of \"travel\" of the window through the buffer"
                 (,(mode-line-%-propertize "%o")))
          (const :tag "\"%p\": Offset of top of window through buffer"
                 (,(mode-line-%-propertize "%p")))
          (const :tag "\"%P\": Offset of bottom of window through buffer"
                 (,(mode-line-%-propertize "%P")))
          (const :tag "\"%q\": Offsets of both top and bottom of window"
                 (,(mode-line-%-propertize "%q"))))
  :version "26.1"
  :group 'mode-line)
(put 'mode-line-percent-position 'risky-local-variable t)


> > After some debugging, I discover that defcustom strips those text
> > properties off the strings.  It does this by using `purecopy' on these
> > strings (in the function `custom-declare-variable').

> But AFAICT custom-declare-variable only applies purecopy to its
> `default` argument which is supposed to be an expression (which
> evaluates to the intended value) rather than a value.  So if you use the
> (propertize "..." ...)  form, the properties should not be stripped.

> Or am I missing something?

purecopy is applied to the entire type: argument.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulties with `purecopy' discarding text properties from strings

[Alan Mackenzie]

Hello, Daniel

On Fri, May 19, 2017 at 12:11:58 -0700, Daniel Colascione wrote:
> On 05/19/2017 11:55 AM, Alan Mackenzie wrote:

[ .... ]

> > Presumably there are good reasons for discarding text properties when
> > purecopying strings.  Or, maybe, there was just no particular reason to
> > amend the workings of `purecopy' when text properties came into
> > existence.

> > How does this sound for a solution to the problem?  In `defcustom',
> > introduce a new keyword `impure:' which, when placed early enough in the
> > defcustom would inhibit the `purecopy' action.

> > Or should I work at amending `purecopy' also to copy text properties?

> When we move to the new dumper (whatever it is), I don't think we'll 
> have a conventional purespace at all anymore. In my system, text 
> properties are just automatically preserved along with everything else 
> and don't get special treatment.

OK.  Less (or should that be "fewer"?) data will be shared between Emacs
instances, partly because a machine with < 4 GB RAM now counts as tiny.

It looks like any work I do here will be for the short term only,
assuming either your or the other solution to the death of dumping will
shortly take its place in master.

But I'm impatient, I'm looking for a solution over the weekend.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulties with `purecopy' discarding text properties from strings

[Eli Zaretskii]

> Date: Fri, 19 May 2017 19:54:58 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> > How exactly did you do that?  Using #("..." ...)
> > or using (propertize "..." ...)?
> 
> By using propertize:
> 
> (defun mode-line-%-propertize (str)
>   "Add standard mode-line properties to STR, a string.
> These enable certain mouse operations when the mouse pointer is
> hovering over the display of STR in the mode line."
>   (propertize
>    str
>    'local-map mode-line-column-line-number-mode-map
>    'mouse-face 'mode-line-highlight
>    ;; XXX needs better description
>    'help-echo "Size indication mode\n\
> mouse-1: Display Line and Column Mode Menu"))
> 
> (defcustom mode-line-percent-position `(,(mode-line-%-propertize "%p"))
>   "Type of \"percentage offset\" of window through buffer to display
> This option specifies the type of offset displayed in
> `mode-line-position',
> a component of the default `mode-line-format'."
>   :type `(radio
>           (const :tag "nil:  No offset is displayed" nil)
>           (const :tag "\"%o\": Proportion of \"travel\" of the window through the buffer"
>                  (,(mode-line-%-propertize "%o")))
>           (const :tag "\"%p\": Offset of top of window through buffer"
>                  (,(mode-line-%-propertize "%p")))
>           (const :tag "\"%P\": Offset of bottom of window through buffer"
>                  (,(mode-line-%-propertize "%P")))
>           (const :tag "\"%q\": Offsets of both top and bottom of window"
>                  (,(mode-line-%-propertize "%q"))))
>   :version "26.1"
>   :group 'mode-line)
> (put 'mode-line-percent-position 'risky-local-variable t)

Why can't you do this like mode-line-position already does: it uses a
dispatch on specific modes.  You could add more possibilities to the
dispatch, and have the defcustom control the value by setting some
variable to specific values.  That way, the properties don't need to
be in the defcustom itself.

Re: Difficulties with `purecopy' discarding text properties from strings

[Stefan Monnier]

>           (const :tag "\"%q\": Offsets of both top and bottom of window"
>                  (,(mode-line-%-propertize "%q"))))
[...]
>> Or am I missing something?
> purecopy is applied to the entire type: argument.

I see, the problem I was missing is that the :type part contains values
rather than expressions.

BTW, another option is to use the (:propertize ...) mode-line element.
It could be placed in mode-line-format around the use of
mode-line-percent-position, so that mode-line-percent-position can just
be a non-propertized string.


        Stefan

Re: Difficulties with `purecopy' discarding text properties from strings

[Alan Mackenzie]

Hello, Eli.

On Sat, May 20, 2017 at 00:04:25 +0300, Eli Zaretskii wrote:
> > Date: Fri, 19 May 2017 19:54:58 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > > How exactly did you do that?  Using #("..." ...)
> > > or using (propertize "..." ...)?

> > By using propertize:

> > (defun mode-line-%-propertize (str)
> >   "Add standard mode-line properties to STR, a string.
> > These enable certain mouse operations when the mouse pointer is
> > hovering over the display of STR in the mode line."
> >   (propertize
> >    str
> >    'local-map mode-line-column-line-number-mode-map
> >    'mouse-face 'mode-line-highlight
> >    ;; XXX needs better description
> >    'help-echo "Size indication mode\n\
> > mouse-1: Display Line and Column Mode Menu"))

> > (defcustom mode-line-percent-position `(,(mode-line-%-propertize "%p"))
> >   "Type of \"percentage offset\" of window through buffer to display
> > This option specifies the type of offset displayed in
> > `mode-line-position',
> > a component of the default `mode-line-format'."
> >   :type `(radio
> >           (const :tag "nil:  No offset is displayed" nil)
> >           (const :tag "\"%o\": Proportion of \"travel\" of the window through the buffer"
> >                  (,(mode-line-%-propertize "%o")))
> >           (const :tag "\"%p\": Offset of top of window through buffer"
> >                  (,(mode-line-%-propertize "%p")))
> >           (const :tag "\"%P\": Offset of bottom of window through buffer"
> >                  (,(mode-line-%-propertize "%P")))
> >           (const :tag "\"%q\": Offsets of both top and bottom of window"
> >                  (,(mode-line-%-propertize "%q"))))
> >   :version "26.1"
> >   :group 'mode-line)
> > (put 'mode-line-percent-position 'risky-local-variable t)

> Why can't you do this like mode-line-position already does: it uses a
> dispatch on specific modes.  You could add more possibilities to the
> dispatch, and have the defcustom control the value by setting some
> variable to specific values.  That way, the properties don't need to
> be in the defcustom itself.

I think I was subconsciously worried that redisplay would be reapplying
the text properties at each redisplay.  But either this doesn't happen,
or is no big deal.

I've done not quite what you suggested, but something which I think will
work as well.  The value in mode-line-percent-position is something like
(-3, "%p"), and this gets propertised in mode-line-position.  Please see
my patch in the main thread for this change.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulties with `purecopy' discarding text properties from strings

[Alan Mackenzie]

Hello, Stefan.

On Fri, May 19, 2017 at 22:58:00 -0400, Stefan Monnier wrote:
> >           (const :tag "\"%q\": Offsets of both top and bottom of window"
> >                  (,(mode-line-%-propertize "%q"))))
> [...]
> >> Or am I missing something?
> > purecopy is applied to the entire type: argument.

> I see, the problem I was missing is that the :type part contains values
> rather than expressions.

> BTW, another option is to use the (:propertize ...) mode-line element.
> It could be placed in mode-line-format around the use of
> mode-line-percent-position, so that mode-line-percent-position can just
> be a non-propertized string.

Thank you indeed.  That is what I have now done.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).