Could bgex patch or similar be added?

Could bgex patch or similar be added?

[Ivan Andrus]

I use emacs from CVS for the sole reason of applying the background  
pixmap patch found at
http://umiushi.org/~wac/bgex/
I was wondering if there are any plans for something like this to be  
integrated into emacs.  Miles Bader's transparent emacs branch may  
have done this, but I could never find it, so I assume it died.  For  
me there are two key features.

First is that that different backgrounds can be assigned to different  
modes and/or buffer names.  This is very useful to me since I can  
instantly see that I am editing my .emacs file and not some other  
elisp file, and certainly not a C++ file.  Perhaps this can be done  
today in vanilla emacs, but I haven't tried too hard.  I would be  
interested in snippets if anyone has some hanging around.

Second is that using a (very muted) picture as a background seems  
easier on my eyes than either solid colors or true transparency  
(though transparency is definitely cool and I use it in Carbon Emacs  
since the patch doesn't work on NS/Carbon).

Unfortunately, I don't speak any Japanese, so I can't help there but,  
time permitting, I might be able to get it to work on NS (though I  
don't really know anything about the emacs internals so it would take  
me quite a bit of time).

-Ivan

Re: Could bgex patch or similar be added?

[Miles Bader]

Ivan Andrus <darthandrus@gmail.com> writes:
> I was wondering if there are any plans for something like this to be
> integrated into emacs.  Miles Bader's transparent emacs branch may  have
> done this, but I could never find it, so I assume it died.

No, it's still alive, in some sense at least.

The debate over whether it should be merged into emacs centered largely
over whether it was a useful feature, i.e., whether its benefits
justified adding more complexity to the Emacs display engine.  That
debate (a few years ago) petered out without any obvious resolution.

Of course if it _is_ worthwhile, I'd rather like to see my patch merged
instead of someone else's, unless their patch is obviously
superior... :)

From my brief look at the bgex patch, it only lets you define window
backgrounds.  The tiling patch uses what I think is a somewhat more
flexible and powerful approach -- it lets you associate images with
_faces_, so e.g., your region can have a different background image than
normal text, etc.  As recent Emacs allows buffer-specific versions of
faces (using face-remapping), this lets you define per-buffer
backgrounds too.  The tiling patch also allows some simple run-time
image filtering so that you can, e.g., make an image "dimmer" without
changing the actual image file (something that's particularly handy when
defining backgrounds for non-default faces -- you can, for instance,
make the `region' face's background image a tweaked version of the
default face's background image).

-Miles

-- 
The key to happiness
 is having dreams.      [from a fortune cookie]

Re: Could bgex patch or similar be added?

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 24 Jun 2009 22:21:59 -0600, Ivan Andrus <darthandrus@gmail.com> said:

> Unfortunately, I don't speak any Japanese, so I can't help there
> but, time permitting, I might be able to get it to work on NS
> (though I don't really know anything about the emacs internals so it
> would take me quite a bit of time).

As I pointed out in
http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00123.html ,
the NS port contains the image background feature code.  I think such
a feature should be added with some platform independent interface,
and the code should be removed if the port becomes a part of the
official release.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Could bgex patch or similar be added?

[Stefan Monnier]

> The debate over whether it should be merged into emacs centered largely
> over whether it was a useful feature, i.e., whether its benefits
> justified adding more complexity to the Emacs display engine.  That
> debate (a few years ago) petered out without any obvious resolution.

I don't think it's tremendously useful, but I'm sure there can be
interesting use cases, so unless its implementation has significant
drawbacks even when not used (e.g. significant code reorganization,
more complexity, runtime costs, ...), I see no reason not to
integrate it.


        Stefan