all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: variable or function for list of known text properties?
Date: Mon, 2 Apr 2007 15:33:53 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMCEGCDAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <E1HYLfQ-0008Ri-3J@fencepost.gnu.org>

>     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').

  reply	other threads:[~2007-04-02 22:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-01 23:10 variable or function for list of known text properties? Drew Adams
2007-04-02 12:29 ` Richard Stallman
2007-04-02 22:33   ` Drew Adams [this message]
2007-04-02 22:49     ` Drew Adams
2007-04-03 21:40     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EIENLHALHGIMHGDOLMIMCEGCDAAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.