From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: variable or function for list of known text properties? Date: Mon, 2 Apr 2007 15:33:53 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1175553362 4168 80.91.229.12 (2 Apr 2007 22:36:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 2 Apr 2007 22:36:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 03 00:35:56 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 1HYV7z-0007JI-6Y for ged-emacs-devel@m.gmane.org; Tue, 03 Apr 2007 00:35:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HYVB3-0000ai-OQ for ged-emacs-devel@m.gmane.org; Mon, 02 Apr 2007 18:39:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HYVAz-0000ad-UJ for emacs-devel@gnu.org; Mon, 02 Apr 2007 18:39:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HYVAy-0000aR-2e for emacs-devel@gnu.org; Mon, 02 Apr 2007 18:39:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HYVAx-0000aO-Vp for emacs-devel@gnu.org; Mon, 02 Apr 2007 18:39:00 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HYV7r-0001fS-Bz; Mon, 02 Apr 2007 18:35:47 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l32MZgE3023227; Mon, 2 Apr 2007 16:35:42 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l32M35l7029132; Mon, 2 Apr 2007 16:35:41 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt351.oracle.com with ESMTP id 2581889011175553235; Mon, 02 Apr 2007 15:33:55 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= 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:68946 Archived-At: > An Elisp function might want to use a list of such known text > properties in some way (e.g. as TABLE arg to `completing-read' > or in a defcustom :type expression). The list of predefined > properties depends on the Emacs release used. > > I do not see why this would be useful. In any given place, each standard > property probably is or is not appropriate, so you need your own > list anyway. Short answer: be able to do general things with text areas that have some text property - for example, search among and within such areas. Longer answer: 1. If you think in terms only of the particular context where a property was originally introduced, then you are right, at least for many properties: in such a context, it is likely that only certain properties and certin property values are appropriate. Even in such a restricted context, however, it would be useful to be able (able, not required) to declare the permitted values for a property. Hence, the defcustom-like suggestion I made: define a property as having these possible (i.e. known) values: x, y, z. 2. Other properties, such as `field', `face', `mouse-face', `font-lock-face', `display', `invisible', `intangible', `category', `keymap', and `syntax-table' are quite general - they can be used in many different contexts. Any program that lets users use text properties in a _general_ way could make use of the suggested feature (list of defined properties). Consider a command that lets a user apply any property to an area of text easily. We already have commands (e.g. `C-u x =') that let a user check properties and their values. And we have ways (e.g. facemenu) for users to interactively set some properties (e.g. `face'). I can see a possible use for users to be able to set other properties as well. 3. Here's how I currently use such a list of properties: I have a command that lets you search a buffer (or buffers) for areas of text that have a given property with a given value. That is, the search domain is effectively limited to those areas. You can easily navigate among those areas, and you can enter minibuffer text to filter the set of candidates (matching text areas with the given property value). If you change your minibuffer text, then the set of search areas is updated on the fly. For example, you enter a) property `face' (using completion against the list of properties) and then b) value `font-lock-function-name-face' (using completion against the list of faces). The text areas that have that face are then highlighted. You can navigate among those hits, or narrow the set of candidate areas by typing some text - e.g. part of a function name. At that point, the highlighted text areas are those with the given face value that match your input (part of a function name). You navigate among the search hits using various keys defined in the minibuffer completion maps and `completion-list-mode-map'. One such key is `C-mouse-2' in *Completions*, to move to that search hit. You can do the same thing with any text property - navigate among fields, invisible-text areas, links, whatever. Even just for debugging Emacs Lisp that deals with text properties, this can be useful for any property and values - it lets you "see" properties that normally have no visible effect. I haven't yet done the same thing (search) for overlay text, but that too would be useful. If you want to try this, to get an idea of what is involved: http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Search_Enhancements. The particular search command for this is `icicle-search-text-property'. (Of course, if you try, for instance, a font-lock face, then search candidates will be limited to the portion of the buffer that has been fontified so far.) 4. I'd like to perhaps do the same thing for other character properties, besides text properties. That is, other kinds of information that you get from `C-u C-x =' could perhaps be used in a similar way. I'm not very familiar with that stuff, but a priori I imagine that character syntax, charsets, and so on could be used similarly to define zones of text that you might want to search for and search within. 5. Beyond my particular search tool, I don't have any other examples ready-to-mind, but I'm convinced this would be useful generally. A text property can be thought of as a particular kind of text. Whatever users do to or with text, users might want to do to or with only text of a certain kind (text with certain properties). There is quite a bit on the other side of that door... It thus would help to make properties and their permitted values (if those are limited) "known" to Emacs, so that programs can, for example, check "valid" properties and values before applying them. I'm not saying that it would be _required_ to declare a new text property before it can be used, but it would be useful to be able to see if a property has been so defined (e.g. `text-property-p').