emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: infloop with :align-to display property


From: Kim F. Storm
Subject: Re: infloop with :align-to display property
Date: 29 Mar 2004 15:33:43 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Stefan Monnier <address@hidden> writes:

> >> >         (+ expr expr ...)
> >> >         (- expr expr ...)
> >> >         (expr . expr)  => multiplies CAR and CDR.
> >>
> >> Why not (* expr expr) ?
> >> The (expr . expr) form seems pretty future-unfriendly.
>
> > Originally, the (.) form is there so you can say e.g (5 . mm) to get a
> > width of 5 mm.
>
> You mean it was there before?  Has it been used somewhere already?

No.  It was there in my "original" work for enhancing space properties
with the sole intention of providing a simple way to specify a unit
for things as in (5 . mm) or (2.6 . in).

It then happens that this can be used in general as a way to multiply two
quantities like (0.5 . left-fringe) or (0.5 . (+ text left-margin))

Since this use is supposedly rare anyway, I didn't want to supply yet
another way of providing multiplication and division (by zero :-).


> How about declaring it obsolete or even just removing it and adding
> the * form instead?

It is not that trivial, as instead of (5 . mm) you would have to write
(* (5) mm), or (/ (+ text left-margin) (2)) -- since a bare "5" or "2"
means "times the default font width" to be backwards compatible.

>
> > Also, I didn't want to give the impression that it is possible to
> > specify arbitrary lisp forms there.
>
> I like the idea of reusing a subset of elisp, so that in case someone feels
> like extending it to full Lisp, it'll still work.

Looking at the examples above, it will not work to extend this to full
lisp with the current syntax -- the (5) and (2) forms are there to be
able to specify absolute pixel widths rather than relative widths.

In any case, we would need some other syntax for specifying pixel
widths then.  Hm, perhaps '5 and '2 would be better, but it would
still not be possible to eval it as normal lisp.

Still another option (for backwards compatibility) would be to say that
        :align-to N
where N is a number is interpreted as relative to default width (that's
how 21.1 works), while
        :align-to (...)
is interpreted in pixels all together.  To get something relative to default
font width, one would use
        :align-to (* (...) width)

But how do you get the proper value for "width" (and "mm", "in", etc)
then?  The default "eval" doesn't know about them anyway (and they
depend on the display characteristics/frame parameters, so they are
not constants either).

So we still cannot use standard eval here.

So I doubt there is a simple way to make this work -- at least I
cannot see it.

But I also doubt that it really matters -- will we really need that
level of flexibility.

After all, you can now use a buffer-local variable to do more complex
things dynamically, e.g. by extending this code:

(progn
  (blink-cursor-mode -1)
  (setq x 0)
  (insert "\n<" (propertize " " 'display '(space :width (x))) ">\n")
  (setq tm
        (run-with-timer 0.1 0.01
          (lambda ()
             (setq x (if (> x 100) 0 (1+ x)))
             (force-window-update)))))

;(cancel-timer tm)


> Extending it to full Lisp could be done by eval'ing those forms at the same
> place where fontification-function is called (i.e. evalling them in advance
> before rendering a chunk and storing the results somewhere so we can
> retrieve them when we need them inside the rendering itself where Lisp is
> not allowed).


--
Kim F. Storm  http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]