unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Wedler, Christoph" <christoph.wedler@sap.com>
Cc: emacs-devel@gnu.org
Subject: RE: [Feature request] face property `raise'
Date: Tue, 13 May 2003 19:17:53 +0200	[thread overview]
Message-ID: <67B8CED503F3D511BB9F0008C75DAD66054855FF@dewdfx17> (raw)

Richard Stallman wrote:

 > 	 iii. :null (or some other value) = not specified.  In this case
 > 	      `get-text-property' and friends must return that value if a
 > 	      properties is not specified

 > In the current design, the value :unspecified means aface attribute is
 > unspecified.  I think that is essentially your option 3.

That's true then for face properties.  If this is generally true, this
would mean:

  - overlay A from S to E with high prio, mouse-face: nil
  - overlay B from S to E with low prio, mouse-face: some-face

 => there is no highlighting when the mouse is in the region S to E

Is this the case?  Or is there highlighting (nil would be the null value for
mouse-face).

 >     I see two possibilities for a naming convention for built-in properties
 >     (I do not discuss the individual names of the properties in this mail):

 >     [...] b. prop-name, i.e., another symbol

 > I would suggest to use b:

I agree.

 > I agree; the backward-compatibility issue is decisive.
 > However, we could recognize the existing face attribute
 > keywords as properties too.

 >      a. The display property.  The options:

 > 	  i. obsolete, ignore it

 > I think that is ok.  The display property is not used in very much
 > code.

Stefan is probably right that this is might not be true anymore...

 >      b. direct face attributes in the face property:

 > 	iii. obsolete, use it (with prio as it is now)

 > That would be necessary.

Sure, if backward-compatibility is an important issue...

 >      c. category attribute

 > 	 ii. obsolete, use the symbol as an additional face (with lowest
 > 	     prio)

 > That would be necessary.

Same as above (backward-compatibility).

 > Meanwhile, there is an important implementation efficiency issue here.
 > The display code currently checks for just a few properties, and that
 > makes it efficient.

It depends -- let's look at an example with overlays both defining
the display property:

  - overlay A from S to E with high prio, display: (D1 a1 D2 a2)
  - overlay B from S to E with low prio,  display: (D1 b1 D3 b3)

What's the "combined" display property?

  a. (D1 a1 D2 a2) ?

  b. (D1 a1 D2 a2 D3 b3)

I assume the answer is a.  But, if we see the properties Dx as
independent properties, b would be the correct answer.  (A similar
example could be constructed with face attributes in the property
`face' -- what's the answer there?)

 > Clean though this new design is, we may need to stay with the old
 > design if we cannot make the new one efficient.

Without extra checks for backward-compatibility properties ('category'
etc) and if the above answer is b, there don't need to be a difference
with the efficiency.  Otherwise, there might be...

- Christoph

             reply	other threads:[~2003-05-13 17:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-13 17:17 Wedler, Christoph [this message]
2003-05-13 21:23 ` [Feature request] face property `raise' Miles Bader
2003-05-14 21:04 ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2003-05-14 17:45 Wedler, Christoph
2003-05-14 20:57 ` Miles Bader
2003-05-15 15:42 ` Richard Stallman
2003-04-29 18:19 Wedler, Christoph
2003-05-13  1:47 ` Richard Stallman
2003-05-13  2:22   ` Miles Bader
2003-05-14 21:05     ` Richard Stallman
2003-05-13 14:13   ` Stefan Monnier
2003-05-14 21:04     ` Richard Stallman
2003-04-11 19:34 Wedler, Christoph
2003-04-13 11:22 ` Richard Stallman
2003-04-10 18:48 Wedler, Christoph
2003-04-10 23:14 ` Kevin Rodgers
2003-04-09 18:06 Wedler, Christoph
2003-04-09 18:50 ` Kai Großjohann
2003-04-10  6:23 ` Richard Stallman
2003-04-08 17:52 Wedler, Christoph
2003-04-08 18:54 ` Kai Großjohann
2003-04-07 17:33 Wedler, Christoph
2003-04-08  6:45 ` 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

  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=67B8CED503F3D511BB9F0008C75DAD66054855FF@dewdfx17 \
    --to=christoph.wedler@sap.com \
    --cc=emacs-devel@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 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).