[Texmacs-dev] Customization by hooks

[david]

On Wed, Feb 05, 2003 at 01:34:03PM +0100, Joris van der Hoeven wrote:
> 
> 1052: Rejected
>   This gives me headaiches for the future...

I understand your health is critical to the project, but I would like
a bit more discussion on the issues of hooks.

I do not think that patches introducing hooks should be rejected by
policy. Hooks are essential to an extensible architecture. Without
them many things cannot be done conveniently, and some things cannot
be done at all. I do not regard emacs has a model of easy-to-use
software, but its extension mechanisms make heavy use of hooks. The
GUILE interpreter is also extensible with hooks.

Generally, hooks cause no maintenance cost because all built-in
functionnality can be implemented without using them.

I agree the proposed patch leaves much to be desired. In particular
hooks should be allowed to alter the parameters and return value of
the function they extend.

It might be possible to provide a similar functionnality entirely in
user extensions using something like:

(let ((pass base-function))
  (set! base-function
    (lambda (x y ...)
      ...
      (... (pass z t ...)))))

I am willing to make a patch which makes some operations (like buffer
switching) overloadable in that way. Other operations (reverting and
saving) can already be overloaded by this mechanism.

Anyhow, how would you suggest to implement the functionnality I need
those hooks for?

  -- windows have properties "screen dpi", "antialiasing factor" and
     "reduction factor".

  -- the document property "dpi" and window property "shrinking
     factor" are updated accordingly to the window property whenever
     the buffer associated to a window is changed (that happens on
     loading, buffer switching, and reverting)

  -- documents are saved with a fixed "dpi" value (600) for
     compatibility with the policy and after saving the document
     "dpi" is reset accordingly to the window properties.

I do not request inclusion of this functionnality in the mainstream
since it causes a lot of font-compiling, but I would like to have it
for my own use because having the "antialiasing factor" as a
independent property makes documents more readable. Depending on
various parameters, like the font design and the screen dpi,
readability can be optimal with an antialiasing factor of 2, 3, or 4.

Also this feature is good for demos. You can start a demo with
antialiasing factor set to 1 and say "antialiasing is like salt, it is
what makes screen display ugly when it is not there", then switch to
an antialiasing factor of 3 or 4...

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.