[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: before- and after-string issues
From: |
martin rudalics |
Subject: |
Re: before- and after-string issues |
Date: |
Sun, 15 May 2005 10:45:39 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
> Putting `mark' before S and `point' after T highlights the entire
> overlay but not its after-string.
>
> That in itself might be ok.
Agreed. But in this case a before-string should not get highlighted
either when the associated overlay is highlighted. I'd classified such
highlighting intuitive - so far. Moreover, you would have to consider
the case where a before- or after-string is _completely_ embedded in the
highlighted region. Not highlighting the string in that case could be
quite irritating.
> Moreover, A inherits face properties from the character displayed after
> A and not from the last character of the overlay. Counterintuitive too.
>
> I don't see why A inherits any properties from characters either before
> or after it. That seems like a bug.
I believe that a before- or after-string _could_ inherit normal face
(not mouse-face) properties from the face of the associated overlay.
It's a matter of taste whether it should. If it does, however, it
should inherit properties in an intuititve and symmetric fashion with
respect to the associated overlay.
>
> Normally when we speak of inheriting text properties we mean that you
> insert character C and it gets properties from an adjacent character
> D. But that doesn't happen here, does it?
No. But I couldn't - and still can't - think of a better term.
`xfaces.c' calls this "merging".
> Do you actually mean
> that the text of A is displayed in a way controlled by the properties
> of the following character?
That's what this particular point should have been all about.
>
> That seems to be simply a bug. So I think we don't need to look
> for adding some kind of new features, some kind of "barriers".
> We just need to fix the bug.
>
Barriers would have been useful iff "inheritance" were allowed. If you
rule out any such inheritance you won't need them. But note: You will
have to consider before-strings too which did not appear in my report.
Moreover, some strategy will be needed to handle highlighting of before-
and after-strings anyway. Barriers would have done highlighting and
face inheritance in a uniform way. And, I didn't think of barriers as
"some kind of new feature" - just a simple and transparent concept
hidden in the depths of `xdisp.c' and `xfaces.c`'.
- before- and after-string issues, martin rudalics, 2005/05/14
- Re: before- and after-string issues, Richard Stallman, 2005/05/14
- Re: before- and after-string issues,
martin rudalics <=
- Re: before- and after-string issues, Kim F. Storm, 2005/05/16
- Re: before- and after-string issues, Richard Stallman, 2005/05/18
- Re: before- and after-string issues, martin rudalics, 2005/05/18
- Re: before- and after-string issues, Kim F. Storm, 2005/05/18
- Re: before- and after-string issues, Richard Stallman, 2005/05/18
- Re: before- and after-string issues, martin rudalics, 2005/05/19
- Re: before- and after-string issues, Richard Stallman, 2005/05/20
- Re: before- and after-string issues, martin rudalics, 2005/05/23
- Re: before- and after-string issues, Richard Stallman, 2005/05/24
Re: before- and after-string issues, martin rudalics, 2005/05/18