Peter S Galbraith wrote:
Weird that this happens simply by loading the code.  Any idea what's
happening ?

Yes. :-) I tried to explain it already in my original report, but may
not have been clear enough.  Take the following steps to get a
backtrace in emacs-snapshot[1]:

M-x debug-on-entry RET modify-frame-parameters RET
M-x load-library RET bar-cursor.el RET[2]

This gave me the following backtrace:

Debugger entered--entering a function:
* modify-frame-parameters(#<frame Emacs:  *Minibuf-1* 0x87ba448> ((cursor-type 
. block)))
  bar-cursor-set-cursor-type(block nil)
  (if (and bar-cursor-mode (not overwrite-mode)) (bar-cursor-set-cursor-type 
(quote bar) frame) (bar-cursor-set-cursor-type (quote block) frame))
  bar-cursor-set-cursor()
  bar-cursor-change()
  (lambda (symbol value) (set-default symbol value) 
(bar-cursor-change))(bar-cursor-mode nil)
  custom-initialize-reset(bar-cursor-mode nil)
  custom-declare-variable(bar-cursor-mode nil "*Non-nil means to convert the 
block cursor into a bar cursor.\nIn overwrite mode, the bar cursor
changes back into a block cursor.\nThis is a quasi-minor mode, meaning that it can be 
turned on & off easily\nthough only globally (hence the quasi-)"
:type boolean :group bar-cursor :require bar-cursor :set (lambda (symbol value) 
(set-default symbol value) (bar-cursor-change)))
  (defcustom bar-cursor-mode nil "*Non-nil means to convert the block cursor 
into a bar cursor.\nIn overwrite mode, the bar cursor changes back into
a block cursor.\nThis is a quasi-minor mode, meaning that it can be turned on & off 
easily\nthough only globally (hence the quasi-)" :type (quote
boolean) :group (quote bar-cursor) :require (quote bar-cursor) :set (lambda 
(symbol value) (set-default symbol value) (bar-cursor-change)))
  eval-buffer(#<buffer  *load*> nil "bar-cursor.el" nil t)  ; Reading at buffer 
position 7456
  
load-with-code-conversion("/usr/share/emacs-snapshot/site-lisp/emacs-goodies-el/bar-cursor.el"
 "bar-cursor.el" nil nil)
  load("bar-cursor.el")
  load-library("bar-cursor.el")
  call-interactively(load-library)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

That's pretty much crystal-clear for an Emacs Lisp wizard. ;-)

You can also see it by evaluating the `frame-parameter' function.
Before loading bar-cursor.el:
(frame-parameter (selected-frame) 'cursor-type) => box

After loading it:
(frame-parameter (selected-frame) 'cursor-type) => block

And Emacs does not know what a "block" cursor is. :-(
The only difference between Emacs 21 and 22 is the handling of an unknown
cursor-type.  While Emacs 21 displays a solid box cursor then, Emacs 22
shows a hollow box.

I might close this bug simply by not including it for Emacs-22 (skipping
byte-compilation).  Okay with you?

I would prefer the following patch to work around this problem (please
test with XEmacs, I don't have it):

--------------------------------------<-8------------------
--- bar-cursor.el.orig  2005-09-24 12:56:56.000000000 +0200
+++ bar-cursor.el       2005-10-07 19:28:30.000000000 +0200
@@ -184,7 +184,7 @@
 if not passed in."
   (if (and bar-cursor-mode (not overwrite-mode))
          (bar-cursor-set-cursor-type 'bar frame)
-       (bar-cursor-set-cursor-type 'block frame)))
+       (bar-cursor-set-cursor-type 'box frame)))

 ;;; --------------------------------------------------------------------------
 (defgroup bar-cursor nil
--------------------------------------<-8------------------

But it should be noted that bar-cursor.el is at least half-broken anyway,
even for Emacs 21.  If the user prefers a different cursor than a box
cursor, loading bar-cursor might change it.  And if you have something like

(setq-default cursor-type '(bar . 4))

in your .emacs, then bar-cursor-mode won't work at all, because setting the
variable cursor-type takes precedence over the frame-parameters (see also
my original report).


[1] This does not work in Emacs 21, because debug-on-entry only works
    for Lisp functions, not for C primitives like `modify-frame-parameters'.

[2] Loading the uncompiled file prevents ugly bytecode in the debugger
    backtrace.









--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to