headers
Danilo Segan | 1 Oct 2003 02:35
Picon

Re: Changing the no-toolkit scrollbar thumb color. (minor issue)

Robert J. Chassell wrote:
> I agree with you.  But I don't know what to do.  Incidentally, the
> scroll bars in Emacs configured with --with-x-toolkit=gtk look
> different than the scroll bars on my xterms and on my instances of
> Galeon.  It turns out the feature is not common throughout Gnome, at
> least not in my instance of Gnome.

Mine Gnome (2.4.0) and Emacs 21.3.50.5 (a bit old, was it late June or  
July, I don't recall) doesn't have this problem.

xterm does show a different scrollbar, because it's not using the same  
toolkit (Gtk+), but Galeon 1.3.7, Emacs, and all the other apps show  
scroll bars as set in my theme.

> 
> The blue was *not* the trough color.  It appeared on the right side  
> of the thumb as a narrow line.

For me, blue appeared as background of the arrow buttons when I pressed  
and held arrow buttons.

> The white did appear in the grey75 (or so, I estimate) top of the
> thumb when I put the mouse over it, but I want to see the white thumb
> against a dark background when I do not put the cursor over it.

This seems to be a theme issue to me. I'll try to find out later if  
there's a Gtk+ theme which has a greater contrast between the thumb and  
the entire bar (you may also try looking at art.gnome.org in Gtk+  
section, if you find some spare time)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Luc Teirlinck | 1 Oct 2003 04:16
Picon

Info mutilates user overlays.

Is there a reason for the behavior of Info, described below?  It
prevents the user from using his own overlays, as well as from using
any Emacs feature that uses overlays, in Info buffers.  They all get
mysteriously moved and made empty after minimal browsing.  I find it
pretty annoying and unexpected.

emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &

C-h i

M-: (point-min) Result: 188

M-: (setq ov (make-overlay 190 210)) 
Result: #<overlay from 190 to 210 in *info*≥

M-: ov 
Same result (of course).

m Emacs RET d

M-: ov
Result: #<overlay from 1 to 1 in *info*≥ (Not so "of course" to me.)

Sincerely,

Luc.
Permalink | Reply | 16 comments |
headers
Miles Bader | 1 Oct 2003 04:26
Picon
Picon

Re: Info mutilates user overlays.

Luc Teirlinck <teirllm <at> dms.auburn.edu> writes:
> Is there a reason for the behavior of Info, described below?  It
> prevents the user from using his own overlays, as well as from using
> any Emacs feature that uses overlays, in Info buffers.

Um, is user overlays in an *info* buffer considered an important
feature?!?  My general impression is that you can't rely on such things
in `special' buffers.

-miles
--

-- 
.Numeric stability is probably not all that important when you're guessing.
Permalink | Reply | 3 comments |
headers
Luc Teirlinck | 1 Oct 2003 04:40
Picon

Re: Info mutilates user overlays.

Miles Bader wrote:

   Um, is user overlays in an *info* buffer considered an important
   feature?!?  My general impression is that you can't rely on such things
   in `special' buffers.

That would mean that no Emacs package could use overlays, except in
buffers it manages itself.  At the very least that should be pointed
out in the Elisp section on overlays.  That would really tremendously
limit the usefulness of overlays.  Is there a reason for this?  Why
does Info, or why would any other special buffer, _need_ to do this?

Sincerely,

Luc.
Permalink | Reply | 0 comments |
headers
Luc Teirlinck | 1 Oct 2003 06:00
Picon

Re: Info mutilates user overlays.

>From my own previous reply:

   Is there a reason for this?  Why does Info, or why would any other
   special buffer, _need_ to do this?

OK I believe I understand now.  It believe it is because the Info
buffer keeps visiting _different_ files during its lifetime.  I
nevertheless believe this should be pointed out in the Elisp manual in
the section on overlays, unless we could think of some way to get
around the problem.

Sincerely,

Luc.
Permalink | Reply | 1 comment |
headers
Miles Bader | 1 Oct 2003 06:37
Picon
Picon

Re: Info mutilates user overlays.

Luc Teirlinck <teirllm <at> dms.auburn.edu> writes:
> OK I believe I understand now.  It believe it is because the Info
> buffer keeps visiting _different_ files during its lifetime.

So it's pretty normal behavior.

> I nevertheless believe this should be pointed out in the Elisp manual
> in the section on overlays, unless we could think of some way to get
> around the problem.

Can you say why you wanted to use overlays in this case?

-Miles
--

-- 
"1971 pickup truck; will trade for guns"
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Oct 2003 07:55
Picon

Re: NTEmacs build fails

> From: David Abrahams <dave <at> boost-consulting.com>
> Date: Tue, 30 Sep 2003 17:40:40 -0400
> 
> Anyone got a clue?  Where is loaddefs.el supposed to be?

It was removed from the repository.  Doing a "make autoloads" once in
the lisp/ subdirectory (or running the commands it's supposed to run
manually) should recreate it.  After that, the build should work as
usual.
Permalink | Reply | 10 comments |
headers
Eli Zaretskii | 1 Oct 2003 08:07
Picon

Re: lisp/ChangeLog too big?

> From: Nick Roberts <nick <at> nick.uklinux.net>
> Date: Tue, 30 Sep 2003 19:25:24 +0100
> 
> It takes a long time for me to commit the ChangeLog in the lisp directory. I
> presume this is related to its size which is now bigger than any of the 
> earlier ChangeLogs and the lisp files. Is it time to split it?
> 
> Nick
> 
> 
>   /home/nick/emacs/lisp:
>   -rw-r--r--    1 nick     nick       950671 Sep 30 18:39 ChangeLog

IMHO, at 950KB, it's definitely time to split it.
Permalink | Reply | 0 comments |
headers
Jason Rumney | 1 Oct 2003 09:40
Picon

Re: [BUG] Emacs thinks it has a BDF font

David Abrahams <dave <at> boost-consulting.com> writes:

> In http://article.gmane.org/gmane.emacs.devel/16583/ I reported that
> emacs is following an execution path which attempts to draw a BDF font
> even though none is in use, resulting in a crash deep in the drawing
> machinery about once a day for me.  I'm unfamiliar with this part of
> Emacs' display code.  Is there someone who can give me a little
> guidance about what to assert, where to set a breakpoint, or something
> (anything) that will help us to track this down?

In a previous report, you mentioned that this occured when you were
using Gnus 5.10. Does that try to use a BDF font behind your back?

If not, then you are probably looking at stack or heap
corruption. Since it is happening in display code variables that are
exected to change frequently, it will be very difficult to track
down with data breakpoints. Take a look at the structures involved,
and see if there are any arrays that might overrun. assert that the
length is within limits wherever they are written. See if you can work
out what variables are next to the font structure on the heap or stack
when the bug occurs. Add assertions to any arrays writes there too.
Permalink | Reply | 1 comment |
headers
Kim F. Storm | 1 Oct 2003 11:58
Picon

Re: lisp/ChangeLog too big?

Nick Roberts <nick <at> nick.uklinux.net> writes:

> It takes a long time for me to commit the ChangeLog in the lisp directory. I
> presume this is related to its size which is now bigger than any of the 
> earlier ChangeLogs and the lisp files. Is it time to split it?

I agree that the size indicates it is time to split, but if you look
closer, lisp/ChangeLog only contains entries for changes since 21.1,
so IMHO it is problematic to split it before the next release from CVS
head.

.. which implies that it's about time to have a new release from head!!

> 
> Nick
> 
> 
>   /home/nick/emacs/lisp:
>   -rw-r--r--    1 nick     nick       950671 Sep 30 18:39 ChangeLog
>   -rw-r--r--    1 nick     nick        97800 Sep  4 23:06 ChangeLog.1
>   -rw-r--r--    1 nick     nick       124237 Sep  4 23:06 ChangeLog.2
>   -rw-r--r--    1 nick     nick       449785 Sep  4 23:06 ChangeLog.3
>   -rw-r--r--    1 nick     nick       320790 Sep  4 23:06 ChangeLog.4
>   -rw-r--r--    1 nick     nick       341585 Sep  4 23:06 ChangeLog.5
>   -rw-r--r--    1 nick     nick       291553 Sep  4 23:06 ChangeLog.6
>   -rw-r--r--    1 nick     nick       845943 Sep  4 23:06 ChangeLog.7
>   -rw-r--r--    1 nick     nick       348197 Sep  4 23:06 ChangeLog.8
>   -rw-r--r--    1 nick     nick       750054 Sep  4 23:06 ChangeLog.9
> 
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane