From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: saving buffer with text properties Date: Sun, 03 Jun 2007 18:43:02 +0200 Message-ID: <87ira50z1l.fsf@ambire.localdomain> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1180889020 544 80.91.229.12 (3 Jun 2007 16:43:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2007 16:43:40 +0000 (UTC) Cc: Emacs-Devel To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 03 18:43:39 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HutB2-0001NE-AD for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2007 18:43:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HutB1-00045g-OM for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2007 12:43:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HutAy-00044f-Ha for emacs-devel@gnu.org; Sun, 03 Jun 2007 12:43:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HutAw-000440-JV for emacs-devel@gnu.org; Sun, 03 Jun 2007 12:43:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HutAw-00043x-Dx for emacs-devel@gnu.org; Sun, 03 Jun 2007 12:43:30 -0400 Original-Received: from smtp-out3.libero.it ([212.52.84.43]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HutAv-0001h7-Tc for emacs-devel@gnu.org; Sun, 03 Jun 2007 12:43:30 -0400 Original-Received: from localhost (172.31.0.42) by smtp-out3.libero.it (7.3.120) id 4611FE5E041F7547; Sun, 3 Jun 2007 18:43:00 +0200 X-Scanned: with antispam and antivirus automated system at libero.it Original-Received: from smtp-out4.libero.it ([172.31.0.40]) by localhost (asav-out2.libero.it [192.168.32.30]) (amavisd-new, port 10024) with ESMTP id wLfC-VDCsMTX; Sun, 3 Jun 2007 18:42:59 +0200 (CEST) Original-Received: from ambire.localdomain (151.21.33.102) by smtp-out4.libero.it (7.3.120) id 4611FEBC04BCDA97; Sun, 3 Jun 2007 18:42:59 +0200 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1HutAU-0006pi-P2; Sun, 03 Jun 2007 18:43:02 +0200 In-Reply-To: (Drew Adams's message of "Sun\, 3 Jun 2007 07\:15\:54 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:72119 Archived-At: () "Drew Adams" () 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. thi