From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: bind faces?
Date: Sun, 14 May 2006 09:13:15 -0700 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICOEAODGAA.drew.adams@oracle.com> (raw)
In-Reply-To: <fc339e4a0605140746x341f8cfcm433b13d6ef7bd1f7@mail.gmail.com>
The example I gave causes the given face's display to change _during
the binding_ -- I used a call to read-string in my example because
that causes redisplay and user interaction within the binding; the
display of the given face changes back again after the binding ceases
to be active
That's what I was saying also: the user (programmer) can do something
(read-string is one possibility) to force redisplay within the scope of the
binding. And the "face changes back again after the binding ceases to be
active". The example I gave used `force-mode-line-update' to cause
redisplay. I also mentioned (sit-for 0). You used `read-string'. There are
many ways to cause redisplay, I believe.
We seem to be saying the same thing about this aspect - you about what your
feature does and I about what my requested feature would do.
If I understand Stefan's point, it is that redisplay does not automatically
occur just because you've made a face binding and changed some text
properties. The user would be responsible for doing something to cause
redisplay, or else the face change wouldn't be manifested visually.
I have no problem with the user taking responsibility for redisplay. Unless
I misunderstand, that is no different from what happens now when you assign
(not bind) new properties to a face and then put that face on some text.
Without redisplay the change is not seen. Again, I'm no expert on faces and
the display process - correct me if I'm wrong on this.
I'm not saying that your implementation wouldn't satisfy my request. If it
does, and if it's the best implementation for such a feature, then I'm all
for it. I am not proposing any particular implementation, and I am not
saying anything about your implementation. I didn't follow the thread about
face remapping. If my request is nothing new, and this question has already
been decided, then ignore my request.
next prev parent reply other threads:[~2006-05-14 16:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-13 17:54 bind faces? Drew Adams
2006-05-13 18:07 ` Chong Yidong
2006-05-13 19:40 ` Drew Adams
2006-05-14 2:39 ` Richard Stallman
2006-05-14 0:52 ` Miles Bader
2006-05-14 1:02 ` Drew Adams
2006-05-14 2:16 ` Miles Bader
2006-05-14 3:13 ` Drew Adams
2006-05-14 4:10 ` David Kastrup
2006-05-14 2:33 ` Miles Bader
2006-05-14 13:17 ` Stefan Monnier
2006-05-14 14:32 ` Drew Adams
2006-05-14 14:46 ` Miles Bader
2006-05-14 16:13 ` Drew Adams [this message]
2006-05-14 17:49 ` Stefan Monnier
2006-05-14 18:43 ` Drew Adams
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DNEMKBNJBGPAOPIJOOICOEAODGAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).