I've been updating the cursor code in xemacs-gtk to use cairo instead of
gdk.
It seems that the bar cursor is deliberately not displayed when the frame
doesn't have focus.
Is that a design decision? It seems a bit odd to me.
--
Jeff Sparkes
jsparkes(a)gmail.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi, XEmacs.
When I do "hg commit", I get the error message
abort: no username supplied (see "hg help config")
. hg help config gives a list of possible config files, and when I get
as far as 'man hgrc', my eyes start glazing over.
Would somebody please give me a quick tip on how to fix this error, and
possibly even warn me of other things to come.
Thanks!
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2011-11-08 - 2011-11-15)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
536 open ( +1) / 275 closed ( +1) / 811 total ( +2)
Open issues with patches: 11
Average duration of open issues: 960 days.
Median duration of open issues: 1012 days.
Open Issues Breakdown
new 213 ( +1)
deferred 6 ( +0)
napping 4 ( +0)
verified 54 ( +0)
assigned 150 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 17 ( +0)
Issues Created Or Reopened (2)
______________________________
kp-divide 2011-11-09
http://tracker.xemacs.org/XEmacs/its/issue812 created anonymous
kp-divide 2011-11-09
CLOSED http://tracker.xemacs.org/XEmacs/its/issue813 created ask107
Issues Now Closed (1)
_____________________
kp-divide 2 days
http://tracker.xemacs.org/XEmacs/its/issue813 mike.kupfer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Ar an triú lá déag de mí na Samhain, scríobh Vin Shelton:
> Thanks. I was looking at that very code and should have tried out a
> similar patch on my own. It seems like the existing code represents a
> case of premature optimization; do you think there will be any
> performance implications?
I don’t think there will be, no; each face is only created once, and that’s
when this code is called.
> There's probably a better place to invalidate the cache, somewhere along
> the (set-face-background ...) execution path, don't you think?
Yes. Or don’t cache at all for the custom-face code.
An interesting thing is that since custom was written initially (for GNU
Emacs), GNU have integrated their multi-tty support, which poses the problem
we’ve been addressing in XEmacs-specific code all along, of specifiers with
different values for different devices. It may be that their version of this
code now is worth porting over.
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Greetings -
If I do the following in my .emacs:
(set-face-foreground 'default "LightYellow")
(set-face-background 'default "Black")
The custom-properties of the current frame do not change:
(frame-property (selected-frame) 'custom-properties) ==>
(type x class color background light)
even though the 'background property should be 'dark after the
set-face-background call. The fact that the background is
mis-identified as 'light, confuses font-lock and hyper-apropos (and
probably other libraries) into using the wrong foreground color for
fonts. For instance, font-lock-comment-face (in the current frame)
has a color of blue4 instead of gray80. Here is the definition of
font-lock-comment-face from font-lock.el:
(defface font-lock-comment-face
'((((class color) (background dark)) (:foreground "gray80"))
;; blue4 is hardly different from black on windows.
(((class color) (background light) (type mswindows)) (:foreground "blue"))
(((class color) (background light)) (:foreground "blue4"))
(((class grayscale) (background light))
(:foreground "DimGray" :bold t :italic t))
(((class grayscale) (background dark))
(:foreground "LightGray" :bold t :italic t))
(t (:bold t)))
"Font Lock mode face used to highlight comments."
:group 'font-lock-faces)
You can see that it's matching the (background light) specifier
instead of (background dark).
Subsequent frames get the right interpretation of background color:
(make-frame)
(frame-property (selected-frame) 'custom-properties) ==>
(type x class color background dark)
Does anyone know where the calculation is done that deduces whether
the frame's background is light or dark? It seems the
(set-face-background 'default ....) should call that code.
BTW, here's how I'm working around this particular problem:
;; Set faces and colors
(and (equal (emacs-type) "xemacs")
(set-face-font 'default "-*-dejavu sans
mono-medium-r-normal--12-*-*-*-m-*-iso8859-1")
(set-face-foreground 'default "LightYellow")
(set-face-background 'default "Black"))
;; Workaround #4
(setq initial-frame-plist '(custom-properties (class color background dark)))
(frame-notice-user-settings)
I never used to have this problem because I used X resources to set
the foreground and background color and that caused the
custom-properties to get set correctly prior to the instantiation of
the first frame.
Thanks,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Is there some way to disable the (grotesque, IMO) underscore under the
"F" in "File", the "E" in "Edit", etc?
When I evaluate:
(set-menubar '(("ZZZZ" ["YYYY..." find-file])))
in the *scratch* buffer, this did not change the current menubar (even
after I call set-menubar-dirty-flag), but when I changed to a new
mode, i.e. M-x info, I do get get a new menubar with:
ZZZZ Info
but both the leading Z and the leading I were underlined (see the
attached menubar2.png). Insights appreciated.
Regards,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2011-11-01 - 2011-11-08)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
535 open ( +2) / 274 closed ( +0) / 809 total ( +2)
Open issues with patches: 11
Average duration of open issues: 955 days.
Median duration of open issues: 1005 days.
Open Issues Breakdown
new 212 ( +2)
deferred 6 ( +0)
napping 4 ( +0)
verified 54 ( +0)
assigned 150 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 17 ( +0)
Issues Created Or Reopened (2)
______________________________
etags.xemacs21 generates garbled paths 2011-11-02
http://tracker.xemacs.org/XEmacs/its/issue810 created anonymous
undefined function bound to C-x RET C 2011-11-07
http://tracker.xemacs.org/XEmacs/its/issue811 created jsparkes
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe Brauer writes:
> hm, when I use xemacs21.4.22 (debian) and run report-xemacs-bug
> then all the options they used for the compilation pop up. the complete
> list is a follows
I don't know, maybe that works in autoconf 2.13 (which just ignored
unknown options). Or maybe it works by accident (configure ignores it
and configures the Lucid menubar by default). It will give you a
warning in recent autoconf though.
> BTW I compiled 21.5.29 with the 3d athena option but I could not detect
> any difference to the xemacs 21.5 version which was compiled without
> this option. can you provide a screenshot of how xemacs should look with
> athena 3d?
It's only going to be visible in dialogs and the Customize buffer, and
maybe buffers tabs, since XEmacs provides its own 3d effect for the
modeline, toolbar, menubar, and scrollbar.
It's possible that a 3d Athena is used by default (it's supposed to be
a drop-in replacement for the flat widgets). Check your config.log to
see what configure thinks it is using.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe Brauer writes:
> Maybe I did not compile 21.5.29 correctly:
I think this may be a long-standing bug in XEmacs Customize. You need
to specify --with-widgets=$TOOLKIT in order to get display of the
buttons that are implemented as native button widgets.
> but when I try to use customize-option, say the Set Save and Done
> button, which I see in 21.4.22 are not there, (the reset button is)
> and therefore I cannot make any changes.
As a workaround, you can still use the [State] "button":
> ,----
> | This is a customization buffer.
> | Type RET or click button2 on an active field to invoke its action.
> | Invoke [Help] for more information.
> |
> | Operate on everything in this buffer:
> | reset
> |
> | Reftex Include File Commands: *
> | [INS] [DEL] String: include
> | [INS] [DEL] String: input
> | [INS] [DEL] String: subfile
> | [INS]
> | [State]: this option has been set and saved.
A
|
right here
To invoke it you TAB to it then use RET to display an action menu.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta