Would someone please fix this, then ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0
tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
To: bug-gnu-emacsgnu.org
From: Joe Wells <jbwmacs.hw.ac.uk>
Date: Sun, 21 Oct 2007 04:14:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Subject: overlay face property not used for after-string
property

BUG:  An overlay's face property is applied to its
before-string
and display properties, but not to its after-string
property.

Reproduce with this expression (see below for definition of
test-in-fresh-buffer-and-window):

  (test-in-fresh-buffer-and-window
   (insert "123")
   (let ((o (make-overlay 2 3)))
     (overlay-put o 'before-string "B")
     (overlay-put o 'after-string "A")
     (overlay-put o 'display "D")
     (overlay-put o 'face 'highlight)))

This displays ?1BDA3?.  The ?BDA? portion should be
displayed
with face ?highlight?, which means that the background
should be
colored ?darkseagreen2?.  However, only the ?BD? portion is
displayed with face ?highlight? and the ?A? portion is
wrongly
not displayed with any special face.

I'm assuming the following macro definition in my
reproduction
code above:

  (defmacro test-in-fresh-buffer-and-window (&rest
body)
    `(progn
       (delete-other-windows)
       (kill-buffer (get-buffer-create "xyzzy"))
       (let ((xyzzy-buf (get-buffer-create
"xyzzy")))
         (set-buffer xyzzy-buf)
         (display-buffer xyzzy-buf)
         ,body
         )))

I hope this bug report is helpful.

Joe

============================================================
==========
In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version
2.8.20)
 of 2007-06-27 on artemis
Windowing system distributor `The X.Org Foundation', version
11.0.70000000
configured using `configure  '--prefix=/home/jbw/local2'
'--enable-debug' '--disable-nls' '--with-x-toolkit=gtk'
'CFLAGS=-O0 -g3 -ggdb''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: jbw
  value of $LANG: nil
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Minor modes in effect:
  TeX-source-specials-mode: t
  outline-minor-mode: t
  desktop-save-mode: t
  url-handler-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  size-indication-mode: t
  line-number-mode: t
  transient-mark-mode: t
------- End of forwarded message -------


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

> Would someone please fix this, then ack?

I don't think I can fix it, but I remember discussion of
something similar
a few years ago where the conclusion was thatit was better
to not apply a
property of the overlay (e.g. `face' although I believe the
discussion was
about `invisible') to the (after|before)-string because it's
easier to add
this property manually to the relevant string than to
"undo" the effect of
the overlay's property from the string.


        Stefan


> ------- Start of forwarded message -------
> X-Spam-Status: No, score=0.0 required=5.0
tests=UNPARSEABLE_RELAY 
> 	autolearn=failed version=3.1.0
> To: bug-gnu-emacsgnu.org
> From: Joe Wells <jbwmacs.hw.ac.uk>
> Date: Sun, 21 Oct 2007 04:14:55 +0100
> MIME-Version: 1.0
> Content-Type: text/plain; charset=utf-8
> Subject: overlay face property not used for
after-string property

> BUG:??An overlay's face property is applied to its
before-string
> and display properties, but not to its after-string
property.

> Reproduce with this expression (see below for
definition of
> test-in-fresh-buffer-and-window):

>   (test-in-fresh-buffer-and-window
>    (insert "123")
>    (let ((o (make-overlay 2 3)))
>      (overlay-put o 'before-string "B")
>      (overlay-put o 'after-string "A")
>      (overlay-put o 'display "D")
>      (overlay-put o 'face 'highlight)))

> This displays ?1BDA3?.  The ?BDA? portion should be
displayed
> with face ?highlight?, which means that the background
should be
> colored ?darkseagreen2?.  However, only the ?BD?
portion is
> displayed with face ?highlight? and the ?A? portion is
wrongly
> not displayed with any special face.

> I'm assuming the following macro definition in my
reproduction
> code above:

>   (defmacro test-in-fresh-buffer-and-window (&rest
body)
>     `(progn
>        (delete-other-windows)
>        (kill-buffer (get-buffer-create
"xyzzy"))
>        (let ((xyzzy-buf (get-buffer-create
"xyzzy")))
>          (set-buffer xyzzy-buf)
>          (display-buffer xyzzy-buf)
>          ,body
>          )))

> I hope this bug report is helpful.

> Joe

>
============================================================
==========
> In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version
2.8.20)
>  of 2007-06-27 on artemis
> Windowing system distributor `The X.Org Foundation',
version 11.0.70000000
> configured using `configure 
'--prefix=/home/jbw/local2' '--enable-debug' '--disable-nls'
'--with-x-toolkit=gtk' 'CFLAGS=-O0 -g3 -ggdb''

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: en_US.UTF-8
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: jbw
>   value of $LANG: nil
>   locale-coding-system: utf-8
>   default-enable-multibyte-characters: t

> Minor modes in effect:
>   TeX-source-specials-mode: t
>   outline-minor-mode: t
>   desktop-save-mode: t
>   url-handler-mode: t
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   unify-8859-on-encoding-mode: t
>   utf-translate-cjk-mode: t
>   auto-compression-mode: t
>   temp-buffer-resize-mode: t
>   size-indication-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
> ------- End of forwarded message -------


> _______________________________________________
> Emacs-devel mailing list
> Emacs-develgnu.org
> htt
p://lists.gnu.org/mailman/listinfo/emacs-devel


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

STEFAN MONNIER WRITES:

>> WOULD SOMEONE PLEASE FIX THIS, THEN ACK?
>
> I DON'T THINK I CAN FIX IT, BUT I REMEMBER DISCUSSION
OF SOMETHING
> SIMILAR A FEW YEARS AGO WHERE THE CONCLUSION WAS THAT
IT WAS BETTER
> TO NOT APPLY A PROPERTY OF THE OVERLAY (E.G. `FACE'
ALTHOUGH I
> BELIEVE THE DISCUSSION WAS ABOUT `INVISIBLE') TO THE
> (AFTER|BEFORE)-STRING BECAUSE IT'S EASIER TO ADD THIS
PROPERTY
> MANUALLY TO THE RELEVANT STRING THAN TO
"UNDO" THE EFFECT OF THE
> OVERLAY'S PROPERTY FROM THE STRING.

FOR WHAT IT IS WORTH, I AGREE THAT IT MIGHT BE BETTER IF THE
FACE
PROPERTY (AND SIMILAR PROPERTIES LIKE INVISIBLE) DID NOT
AFFECT THE
BEFORE-STRING AND AFTER-STRING PROPERTIES.  IN FACT, I THINK
IT MIGHT
BE BETTER IF THE FACE PROPERTY ALSO DID NOT AFFECT THE
DISPLAY
PROPERTY.

HOWEVER, THERE IS CLEARLY A BUG HERE BECAUSE BEFORE-STRING
IS AFFECTED
BY FACE WHILE AFTER-STRING IS NOT.  EITHER BOTH SHOULD BE
AFFECTED OR
NEITHER.

ALSO, IT IS NOT STRAIGHTFORWARD TO ADD THE FACE PROPERTY
MANUALLY TO
THE RELEVANT STRING, BECAUSE THE STRING MAY ALREADY CONTAIN
FACE
PROPERTIES.  DOING

  (PROPERTIZE STRING 'FACE FACE)

WILL BLAST ANY FACE PROPERTIES ALREADY ON STRING.  IF
RECURSIVE
DISPLAY PROPERTIES WERE ALLOWED, DOING

  (PROPERTIZE " " 'FACE FACE DISPLAY STRING)

WOULD DO THE RIGHT THING EVEN IF STRING ALREADY HAD FACE
AND/OR
DISPLAY PROPERTIES.  BUT RECURSIVE DISPLAY PROPERTIES ARE
NOT ALLOWED.
AND GOING THROUGH THE STRING MODIFYING EACH FACE PROPERTY TO
ADD THE
CORRECT ATTRIBUTES IS A REAL PAIN.

IT WOULD MAKE MY LIFE MUCH EASIER IF RECURSIVE DISPLAY
PROPERTIES WERE
ALLOWED.  IT WOULD BE ENOUGH IN PRACTICE TO ALLOW RECURSION
TO SOME
SMALL FIXED LEVEL, LIKE 10 OR SO.

JOE

P.S.  BY THE WAY, WHEN FORWARDING MESSAGES FROM
BUG-GNU-EMACSGNU.ORG,
IT WOULD BE A BIG HELP IF THE ORIGINAL POSTER WAS CC-ED. 
I'M NOT ON
THE EMACS-DEVELGNU.ORG MAILING LIST, AND IT IS A REAL
PAIN TO HAVE TO
SCAN THROUGH THE WEB MAILING LIST ARCHIVES TO SEE IF
ANYTHING IS
HAPPENING WITH MY BUG REPORT.  ALSO, IT IS AN ADDITIONAL
PAIN TO
EXTRACT THE MESSAGE-ID AND REFERENCES HEADERS FOR THE
MESSAGE I AM
REPLYING TO FROM THE WEB MAILING LIST ARCHIVES IN ORDER TO
MAKE A
PROPER REPLY.  IT WOULD HAVE BEEN MUCH EASIER (AND I WOULD
HAVE
REPLIED DAYS AGO) IF I HAD JUST BEEN CC-ED.

P.P.S.  ACTUALLY, THE ISSUE IN THE ABOVE P.S. WOULD BE
HANDLED MUCH
BETTER BY SIMPLY USING A PROPER BUG TRACKER FOR EMACS. 
AREN'T YOU
FOLKS TIRED OF BUGS BEING DROPPED (IN SOME CASES FOR MANY
YEARS)
BECAUSE OF THE LACK OF A BUG TRACKER?

>> ------- START OF FORWARDED MESSAGE -------
>> FROM: JOE WELLS <ADDRESSHIDDEN>
>> DATE: SUN, 21 OCT 2007 04:14:55 +0100
>> SUBJECT: OVERLAY FACE PROPERTY NOT USED FOR
AFTER-STRING PROPERTY
>
>> BUG:  AN OVERLAY'S FACE PROPERTY IS APPLIED TO ITS
BEFORE-STRING
>> AND DISPLAY PROPERTIES, BUT NOT TO ITS AFTER-STRING
PROPERTY.
>
>> REPRODUCE WITH THIS EXPRESSION (SEE BELOW FOR
DEFINITION OF
>> TEST-IN-FRESH-BUFFER-AND-WINDOW):
>
>>   (TEST-IN-FRESH-BUFFER-AND-WINDOW
>>    (INSERT "123")
>>    (LET ((O (MAKE-OVERLAY 2 3)))
>>      (OVERLAY-PUT O 'BEFORE-STRING "B")
>
>>      (OVERLAY-PUT O 'AFTER-STRING "A")
>>      (OVERLAY-PUT O 'DISPLAY "D")
>>      (OVERLAY-PUT O 'FACE 'HIGHLIGHT)))
>
>> THIS DISPLAYS €ś1BDA3€ť.  THE €śBDA?€ť PORTION
SHOULD BE DISPLAYED
>
>> WITH FACE €śHIGHLIGHT€ť, WHICH MEANS THAT THE
BACKGROUND SHOULD BE
>> COLORED €śDARKSEAGREEN2€ť.  HOWEVER, ONLY THE
€śBD€ť PORTION IS
>> DISPLAYED WITH FACE €śHIGHLIGHT€ť AND THE €śA€ť
PORTION IS WRONGLY
>> NOT DISPLAYED WITH ANY SPECIAL FACE.
>
>> I'M ASSUMING THE FOLLOWING MACRO DEFINITION IN MY
REPRODUCTION
>> CODE ABOVE:
>
>>   (DEFMACRO TEST-IN-FRESH-BUFFER-AND-WINDOW
(&AMP;REST BODY)
>>     `(PROGN
>>        (DELETE-OTHER-WINDOWS)
>>        (KILL-BUFFER (GET-BUFFER-CREATE
"XYZZY"))
>>        (LET ((XYZZY-BUF (GET-BUFFER-CREATE
"XYZZY")))
>
>>          (SET-BUFFER XYZZY-BUF)
>>          (DISPLAY-BUFFER XYZZY-BUF)
>>          ,BODY
>>          )))
>
>> I HOPE THIS BUG REPORT IS HELPFUL.
>
>> JOE
>
>>
============================================================
==========
>> IN GNU EMACS 22.1.1 (I686-PC-LINUX-GNU, GTK+
VERSION 2.8.20)
>>  OF 2007-06-27 ON ARTEMIS
>> WINDOWING SYSTEM DISTRIBUTOR `THE X.ORG
FOUNDATION', VERSION 11.0.70000000
>> CONFIGURED USING `CONFIGURE 
'--PREFIX=/HOME/JBW/LOCAL2' '--ENABLE-DEBUG' 
>
>> '--DISABLE-NLS' '--WITH-X-TOOLKIT=GTK' 'CFLAGS=-O0
-G3 -GGDB''
>
>> IMPORTANT SETTINGS:
>>   VALUE OF $LC_ALL: NIL
>>   VALUE OF $LC_COLLATE: NIL
>>   VALUE OF $LC_CTYPE: EN_US.UTF-8
>>   VALUE OF $LC_MESSAGES: NIL
>
>>   VALUE OF $LC_MONETARY: NIL
>>   VALUE OF $LC_NUMERIC: NIL
>>   VALUE OF $LC_TIME: JBW
>>   VALUE OF $LANG: NIL
>>   LOCALE-CODING-SYSTEM: UTF-8
>>   DEFAULT-ENABLE-MULTIBYTE-CHARACTERS: T
>
>> MINOR MODES IN EFFECT:
>>   TEX-SOURCE-SPECIALS-MODE: T
>>   OUTLINE-MINOR-MODE: T
>>   DESKTOP-SAVE-MODE: T
>>   URL-HANDLER-MODE: T
>>   TOOLTIP-MODE: T
>
>>   MOUSE-WHEEL-MODE: T
>>   FILE-NAME-SHADOW-MODE: T
>>   GLOBAL-FONT-LOCK-MODE: T
>>   FONT-LOCK-MODE: T
>>   BLINK-CURSOR-MODE: T
>>   UNIFY-8859-ON-ENCODING-MODE: T
>
>>   UTF-TRANSLATE-CJK-MODE: T
>>   AUTO-COMPRESSION-MODE: T
>>   TEMP-BUFFER-RESIZE-MODE: T
>>   SIZE-INDICATION-MODE: T
>>   LINE-NUMBER-MODE: T
>>   TRANSIENT-MARK-MODE: T
>
>> ------- END OF FORWARDED MESSAGE -------


_______________________________________________
EMACS-DEVEL MAILING LIST
EMACS-DEVELGNU.ORG
HTTP://LISTS.GNU.ORG/MAILMAN/LISTINFO/EMACS-DEVEL

    I agree that it is simple and clear.  However, given the
point you
    made above, I think it would be better if before-string
and
    after-string properties were affected by the face
property of other
    overlays (regardless of whether they should be affected
by the face
    property of the same overlay).

Do you mean ALL other overlays?

So if there are two overlays A and B, A's before-string
shoud be
affected by B's face and vice versa?  That doesn't sound
quite right
to me, but I don't have a feel for just what would be
right.

So I have installed a change that makes available, to the
function to
choose the base face, the overlay from which the overlay
string came.
The function is now called `face_for_overlay_string', and it
is in
xfaces.c.  Given that info, people could implement whatever
policy
seems right.

But I don't want to try implementing a different policy
myself.  I
don't have an actual use for this feature, so I could try
five
different policies with no reason to expect any of them to
be good for
actual use.

I will leave this part for others.


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

    By the way, the concern I raise in the message you quote
above is not
    about text properties in the before-string or
after-string, but about
    text properties in the buffer.

I know.  Can you send a test case for this?


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

Richard Stallman <rmsgnu.org> writes:

>     I agree that it is simple and clear.  However,
given the point
>     you made above, I think it would be better if
before-string and
>     after-string properties were affected by the face
property of
>     other overlays (regardless of whether they should
be affected by
>     the face property of the same overlay).
>
> Do you mean ALL other overlays?
>
> So if there are two overlays A and B, A's before-string
shoud be
> affected by B's face and vice versa?  That doesn't
sound quite right
> to me, but I don't have a feel for just what would be
right.

Neither do I.

I would expect if someone put an overlay that contains the
entire
buffer, this would affect all things displayed in the buffer
from
overlays at lower priority.

I would expect if overlay o2 completely contains overlay o1
and
overlay o2's priority is higher than overlay o1's priority,
then
overlay o2's face would affect all things displayed by
overlay o1.

The above items seem clearly right.  However, a lot of
strange corner
cases arise.

What if overlay o1 and overlay o2 cover the exact same
region and have
the same priority?  Should they affect the display of each
other's
before-string, display, and after-string properties?

What if

  (and (<= (overlay-start o2)         (overlay-start
o1))
       (<= (overlay-start o1)         (overlay-end o2))
       (<  (overlay-end o2)           (overlay-end o1))
       (<  (overlay-get o1 'priority) (overlay-get o2
'priority)))

?  Should overlay o2's face affect overlay o1's
before-string (but not
its after-string)?

And there are other cases to consider.

Comments from people who have implemented stuff using
overlays would
be welcome here.

> So I have installed a change that makes available, to
the function to
> choose the base face, the overlay from which the
overlay string came.
> The function is now called `face_for_overlay_string',
and it is in
> xfaces.c.  Given that info, people could implement
whatever policy
> seems right.

I think this information may not be enough.  I think the
policy would
also need to know which of the overlay properties
before-string,
display, or after-string the string comes from.  (Note that
coming
from an overlay's display string is distinct from coming
from a
display string as a text property on an overlay's
before-string, which
should count as coming from the before-string.)

-- 
Joe

> But I don't want to try implementing a different policy
myself.  I
> don't have an actual use for this feature, so I could
try five
> different policies with no reason to expect any of them
to be good for
> actual use.
>
> I will leave this part for others.


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

Richard Stallman <rmsgnu.org> writes:

>     By the way, the concern I raise in the message you
quote above
>     is not about text properties in the before-string
or
>     after-string, but about text properties in the
buffer.
>
> I know.  Can you send a test case for this?

There is a test case in this message:

  http://www.na
bble.com/anomalies-of-overlays-and-before-string-and-display
-properties-p12777475.html

The message at that URL has a single test case that
demonstrates
several bugs.  Bugs #3 and #4 in that message are the same
as the bug
I am mentioning in the quoted message above.  I haven't had
time to
prepare a test case that isolates this bug all on its own.

By the way, I think bug #2 in the message at the above URL
has been
fixed (or partially fixed), but all the other bugs I think
have been
left untouched.

-- 
Joe


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

    I think this information may not be enough.  I think the
policy would
    also need to know which of the overlay properties
before-string,
    display, or after-string the string comes from.

In most cases you can determine this by looking at the
overlay's
properties and seeing where the string appears.  That will
work except
when the overlay has two properties that contain strings
that are eq.

That is not good enough for the final implementation, but it
is good
enough for experimenting to find the right criteria.  If the
right
criteria really depend on this information, we can add a
mechanism to
provide the information efficiently and reliably.  So I see
no need to
do that until we know whether it is needed.



_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

Richard Stallman <rmsgnu.org> writes:

>     I think this information may not be enough.  I
think the policy would
>     also need to know which of the overlay properties
before-string,
>     display, or after-string the string comes from.
>
> In most cases you can determine this by looking at the
overlay's
> properties and seeing where the string appears.  That
will work except
> when the overlay has two properties that contain
strings that are eq.
>
> That is not good enough for the final implementation,
but it is good
> enough for experimenting to find the right criteria. 
If the right
> criteria really depend on this information, we can add
a mechanism to
> provide the information efficiently and reliably.  So I
see no need to
> do that until we know whether it is needed.

I think that the before-string should, in effect, use
(get-char-property (overlay-start ov) 'face)
to determine the face to use if no fully specified face is
in the
before-string.

Similarly for after-string.  That's simple, clear and
straightforward
for the user to understand.  It also has the "right
thing" feeling to
it, which ignoring surrounding faces doesn't.

-- 
David Kastrup


_______________________________________________
Emacs-devel mailing list
Emacs-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/emacs-devel

DAVID KASTRUP <DAKGNU.ORG> WRITES:

> RICHARD STALLMAN <RMSGNU.ORG> WRITES:
>
>>     I THINK THIS INFORMATION MAY NOT BE ENOUGH.  I
THINK THE POLICY
>>     WOULD ALSO NEED TO KNOW WHICH OF THE OVERLAY
PROPERTIES
>>     BEFORE-STRING, DISPLAY, OR AFTER-STRING THE
STRING COMES FROM.
>>
>> IN MOST CASES YOU CAN DETERMINE THIS BY LOOKING AT
THE OVERLAY'S
>> PROPERTIES AND SEEING WHERE THE STRING APPEARS. 
THAT WILL WORK EXCEPT
>> WHEN THE OVERLAY HAS TWO PROPERTIES THAT CONTAIN
STRINGS THAT ARE EQ.
>>
>> THAT IS NOT GOOD ENOUGH FOR THE FINAL
IMPLEMENTATION, BUT IT IS GOOD
>> ENOUGH FOR EXPERIMENTING TO FIND THE RIGHT
CRITERIA.  IF THE RIGHT
>> CRITERIA REALLY DEPEND ON THIS INFORMATION, WE CAN
ADD A MECHANISM TO
>> PROVIDE THE INFORMATION EFFICIENTLY AND RELIABLY. 
SO I SEE NO NEED TO
>> DO THAT UNTIL WE KNOW WHETHER IT IS NEEDED.
>
> I THINK THAT THE BEFORE-STRING SHOULD, IN EFFECT, USE
> (GET-CHAR-PROPERTY (OVERLAY-START OV) 'FACE)
> TO DETERMINE THE FACE TO USE IF NO FULLY SPECIFIED FACE
IS IN THE
> BEFORE-STRING.

THE BEHAVIOR YOU PROPOSE IS CURRENTLY USED AND CAUSES
PROBLEMS.  I
HAVE COMPLAINED ABOUT IT (IN SEPARATE MESSAGES) AS A BUG.  I
HAVE SEEN
IT CAUSING PROBLEMS FOR LINUM.EL AND TEX-FOLD.EL.

WHEN (EQ (OVERLAY-START O) (OVERLAY-END O)), THE CHARACTER
AFTER
(OVERLAY-START O) IS NOT EVEN INSIDE THE OVERLAY.  IT MAKES
NO LOGICAL
SENSE FOR THE FACE OF A CHARACTER NOT COVERED BY THE OVERLAY
TO AFFECT
THE DISPLAY OF THINGS SPECIFIED BY THE OVERLAY.

REQUIRING THE FACE OF A STRING DISPLAYED BY AN OVERLAY TO BE
FULLY
SPECIFIED MEANS THAT SUCH A FACE CAN NEVER ADJUST
AUTOMATICALLY TO
CHANGES IN OTHER FACES.  YET THIS IS NEEDED.  FOR EXAMPLE,
IF THE
DEFAULT FACE IS CHANGED (E.G., TO CHANGE THE OVERALL SIZE OF
THE TEXT
FOR EASIER VIEWING), IT IS DESIRED THAT ALL FACES WILL
AUTOMATICALLY
ADJUST.  SIMILARLY, IF THE REGION IS ACTIVATED, IT WOULD BE
NICE IF
ALL FACES THAT DO NOT NEED TO SPECIFY A BACKGROUND WOULD GET
THE
BACKGROUND OF FACE €śREGION€ť.  WITH YOUR PROPOSAL (WHICH IS
ALREADY
IMPLEMENTED), AN OVERLAY'S BEFORE-STRING WOULD HAVE TO
SPECIFY A
BACKGROUND COLOR (EVEN IF MERELY WHITE) AND COULD NOT
AUTOMATICALLY
PICK UP THE BACKGROUND OF THE REGION FACE.

I WOULD LIKE TO STRONGLY SUGGEST THAT OVERLAY BEFORE-STRING,
DISPLAY,
AND AFTER-STRING PROPERTIES SHOULD *NOT* BE AFFECTED BY THE
TEXT-PROPERTY FACE PROPERTIES IN THE BUFFER.

> SIMILARLY FOR AFTER-STRING.  THAT'S SIMPLE, CLEAR AND
STRAIGHTFORWARD
> FOR THE USER TO UNDERSTAND.  IT ALSO HAS THE
"RIGHT THING" FEELING TO
> IT, WHICH IGNORING SURROUNDING FACES DOESN'T.

IT DEFINITELY HAS THE €śWRONG THING€ť FEELING TO IT FOR ME.

-- 
JOE


_______________________________________________
EMACS-DEVEL MAILING LIST
EMACS-DEVELGNU.ORG
HTTP://LISTS.GNU.ORG/MAILMAN/LISTINFO/EMACS-DEVEL