[IPython-user] hard-to-read highlight colors in ipython mode w/ XEmacs

Alexander Schmolck a.schmolck@gmx....
Sat Apr 12 16:57:28 CDT 2008

skip@pobox.com writes:

>     Pete> Colors are set by a command line option to ipython.  I used
>     Pete> customize to set `py-python-command-args':
>     Pete> Value: ("-pylab" "-colors" "LightBG")
>     Pete> I think that the options for -colors are NoColor, Linux, and LightBG.
> My last input on this (maybe this is mostly for the XEmacs folks and
> Alexander Schmolck - author of ipython.el - but I don't have an email for
> him handy).  I looked at the color-option-setting code in ipython.el and
> found this:
>       (setq py-python-command-args 
>             (nconc py-python-command-args 
>                    (list "-colors"
>                          (cond  
>                            ((eq frame-background-mode 'dark)
>                             "Linux")
>                            ((eq frame-background-mode 'light)
>                             "LightBG")
>                            (t ; default (backg-mode isn't always set by XEmacs)
>                             "LightBG"))))))
> Then I ran "xemacs -rv" and evaluated frame-background-mode.  It was still
> 'light.  I don't know what the right variable to test is, but on XEmacs it
> doesn't appear that the -rv command line flag causes frame-background-mode
> to be set differently (this is in 21.5b28).

On first sight this seems to be a design flaw in emacs -- I don't see a sane
way to query if the background is light or dark. What you see is, I think,
just that you configure the background to be "light" yourself. At least in FSF
emacs you have the ability to set this variable to 'light 'dark or nil (nil
being auto-detect), and the code that sets up the right faces for a frame
figures out whether the frame is dark or light by using this variable and
using some kludges in the NIL case (but this isn't factored into a function,
so there seems no sane way to find out). I assume your setting just overrides

I just looked very briefly, so I might be wrong -- if someone wants to dig
deeper or post to a relevant group/list such as comp.emacs, I'm certainly
happy to incorporate a better solution provided it is clean and not some
horrible roundabout kludge, because nothing better exists.


More information about the IPython-user mailing list