Per-buffer and per-window frame-parameters.

[Kim F. Storm]

Alex Schroeder <address@hidden> writes:
 
> Perhaps it would make more sense to make the left and right fringe
> different sizes, so users can have truncation info on the right fringe
> and a zero-width left fringe?
> 
That is exactly what I've already done.

> > But there are many other things which should be per-buffer rather than
> > per-frame, so this should probably wait until we know how to fix this
> > in general.
> 
> Maybe we should just add this feature now.  In XEmacs, for example,
> many functions take a LOCATION argument which may either be a frame, a
> window, or a buffer.  Thus I think it should be easy to add this
> feature piece by piece.  We might as well start with the fringe.  :)

I agree with Eli that we should come up with a general solution for
this before starting to implement it - but it will probably make sense
to implement it step-wise once we have decided what we want.

>From an Elisp point of view, simply modifying all (relevant) functions
which currently have a FRAME argument - and replacing that with a more
generic LOCATION argument sound appealing, especially because it is
backwards compatible.

As an example, the functions frame-parameters and modify-frame-parameters
should be applicable to buffers and windows as well as frames.

Most of the C level changes needed to support this are probably fairly
trivial, but the number of changes will be large.  The main problem
seems to be to make the specific buffer/window available to the
functions and macros which currently are called with a frame argument.

But, there are definitely things which will break once a we don't
have a common frame-parameter for things like the default font.

For example, the default font is currently used to compute the size of
scroll-bars and fringes, so if there is no longer a common default
font, that code will break.  But OTOH, we could still use the frame's
default font (ignoring per-buffer and per-window default font) for 
such computations.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk