2:04 p.m.
[ Redirecting to xemacs-betaļ¼ ]
Stephen J. Turnbull wrote:
Didier Verna writes:
> I'm certainly open to alternatives. I'm not very satisfied with
> "flush" either. "justify" doesn't sound quite right though
because it
> means both sides and also suggests that the actual text layout is
> involved, which is not the case.
Ah, I see now, having taken time to actually look at the blog :-P.
You're right, it's not "justify" since text layout isn't involved.
Actually, I think any time the background of a face is different from
default, 'flush should be on by default.
Yeah, the idea crossed my mind, but I was hesitating because it would
be a somewhat radical change to the way things look right now. Also,
maybe there are still some situations in which flushing would be
undesirable. For instance, imagine just one line of text, with the right
part (including the newline) using a different background. I think it
would look strange to have this background extend to the right end of
the window, on this single line only.
How hard would it be to implement a dimension? I can see
applications
for (say) a flush-to-column-65 face, which I'd apply to a whole
paragraph, and anything hanging into the margin would end up in the
default face (or more precisely, the face of a containing region).
That's an interesting idea. I don't think this would be very hard to
implement with one problem though: what about variable width fonts (the
notion of column number doesn't always make sense visually)? Which
brings the question of unit of measure: columns, pixels, percentage of
the window's width?
Flushright doesn't work for me, it refers to the text layout and
implies ragged left. Why not just "block"? Other not very satisfactory
terms that come to mind are "brick" (as in "bricktext"),
"div" (from
HTML but not terribly evocative), "spill" or "flood" or the more
explicit "spill-to-margin" or "flood-to-margin". Something that
refers
to "lines" or "rows", maybe. "band-oriented" or
"band-fill" or
"full-band" maybe?
I guess it can stay "flush" for now, since I don't have a good
alternative suggestion, all the above are pretty awkward. I'm pretty
sure something will occur to me someday soon, but it's just not coming
now. :-/
OK so let's wait until tomorrow morning :-)
Doesn't GNU have something like this by now? We should steal
their
name.
I've just downloaded 23.3 for Mac, and from what I can see, all faces
behave like this (I don't see any face property that would allow one to
turn the "flush" effect off). In that case, maybe we don't even need a
specific property for this...
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:02 p.m.
New subject: [Q] New "flush" face property
Didier Verna writes:
Stephen J. Turnbull wrote:
> Actually, I think any time the background of a face is different
from
> default, 'flush should be on by default.
Yeah, the idea crossed my mind, but I was hesitating because it would
be a somewhat radical change to the way things look right now.
Er, right now we're many moons from a release. Let's get radical,
especially if there's a way to turn it off. In particular, this is a
good excuse for somebody (FVO "somebody" including "me" unless
somebody beats me to it) to figure out and document Ben's behavior
concept.
maybe there are still some situations in which flushing would be
undesirable.
If so, let's find out.
> How hard would it be to implement a dimension? I can see
applications
> for (say) a flush-to-column-65 face, which I'd apply to a whole
> paragraph, and anything hanging into the margin would end up in the
> default face (or more precisely, the face of a containing region).
That's an interesting idea. I don't think this would be very hard to
implement with one problem though: what about variable width fonts (the
notion of column number doesn't always make sense visually)? Which
brings the question of unit of measure: columns, pixels, percentage of
the window's width?
We need to get away from columns anyway. I think that XEmacs should
move in the direction of CSS dimensions. For monospace characters 1
en = 1 em = 1 column. Otherwise, columns don't make a huge amount of
sense.
> Doesn't GNU have something like this by now? We should
steal their
> name.
I've just downloaded 23.3 for Mac, and from what I can see, all faces
behave like this (I don't see any face property that would allow one to
turn the "flush" effect off). In that case, maybe we don't even need a
specific property for this...
No, I can see uses for no-flush (or bounded flush), such as
e.e.cummings poetry and block quotes (eg, of programs).
Or maybe we should just move to the HTML box model. hmmmm...
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:48 p.m.
New subject: [Q] New "flush" face property
Stephen J. Turnbull wrote:
Er, right now we're many moons from a release. Let's get
radical,
especially if there's a way to turn it off. In particular, this is a
good excuse for somebody (FVO "somebody" including "me" unless
somebody beats me to it) to figure out and document Ben's behavior
concept.
No, I can see uses for no-flush (or bounded flush), such as
e.e.cummings poetry and block quotes (eg, of programs).
OK, so here's what I'm gonna do: turn the flush behavior on by default
but keep it a face property so that it can still be turned off
explicitely. Then we'll see...
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4717
days inactive
4717
days old
2 comments
2 participants
participants (2)
-
Didier Verna -
Stephen J. Turnbull