[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: saving buffer with text properties

From: Thien-Thi Nguyen
Subject: Re: saving buffer with text properties
Date: Sun, 03 Jun 2007 18:43:02 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

() "Drew Adams" <address@hidden>
() Sun, 3 Jun 2007 07:15:54 -0700

   If a text property were represented in the saved form by its property
   name as well as its value, why couldn't arbitrary, user-defined
   properties be accomodated too? That's a question, not a claim; I'm no
   expert in this. (`buffer-invisiblity-spec' would also need to be
   saved in the file.)

everything can be accomodated in the current situation (w/ a SMOP).  the
question is not of feasability, it is of design.  consider the property
name: under sane usage it is a symbol or a keyword, but guess what,
emacs has no qualms w/ `(put-text-property 1 2 "foo" "bar")'.  what if
the property name is a circular structure?, a hash?, something tricky to
serialize?  same question goes for the property value, of course.

when serialization is required, ordering comes into play.  ordering
implies priority and thus specific design for specific purposes.  all
the mechanisms to support ordering are in place, hence the pointer:

   > on the trunk, see (info "(elisp) Format Conversion").

   Good to know. IIUC, that explains how one might implement what I'm
   asking for, and it is not specific to text properties.

you are right, but that is irrelevant.  text properties are key/value
object pairs; format conversion is parsing/rendering of such pairs (as
well as other kinds of info) serially, given an ordering.

   I was wondering if there was already a plan to define a saved
   representation that would take text properties into account - similar
   to (or perhaps an extension of) enriched text, for instance.

you are (again) invited to design, codify and characterize a good plan.
probably a first step is to restrict the types of the text property name
and value to avoid the hair mentioned above.  you have already begun:

   My code just uses:

   * a `face' property
   * a `highlight' property with the same value as `face'
   * possibly an `invisible' property

your design should also handle properties your code does NOT use.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]