button.el (again)
Jerry James writes:
The last time we discussed this, we talked about adding button.el to
the
fsf-compat package. In light of the above (and the fact that I converted
it to use extents instead of overlays), is fsf-compat still the best place
for button.el? I admit that I don't see a package for which it is well
suited, but I wonder if it might not fit better somewhere else.
IMO, the question is better put as "are the API and semantics up to
XEmacs standards and conformant with 'the way we do things'?"
A quick look at the file suggests that answers are "API, not really;
semantics, not really; style, not really."
;; Buttons can either use extents, in which case the button is
;; represented by the extent itself, or text-properties,
But in XEmacs, text properties are just extents. So the option to use
text properties should be a no-op unless there are advantages other
than speed with "extremely large numbers of buttons". No?
(defun button-activate (button &optional use-mouse-action)
"Call BUTTON's action property.
If USE-MOUSE-ACTION is non-nil, invoke the button's mouse-action
instead of its normal action; if the button has no mouse-action,
the normal action is used instead.
The action can either be a marker or a function. If it's a
marker then goto it. Otherwise if it is a function then it is
called with BUTTON as only argument. BUTTON is either an
extent, a buffer position, or (for buttons in the mode-line or
header-line) a string."
What kind of an API is "extent-or-position-or-string"? This makes it
annoying to write generic functions for buttons.
(defun make-button (beg end &rest properties)
(defun insert-button (label &rest properties)
(defun make-text-button (beg end &rest properties)
(defun insert-text-button (label &rest properties)
It seems weird to me that the action isn't a required argument.
;; Finding buttons in a buffer
(defun button-at (pos)
"Return the button at position POS in the current buffer, or nil.
If the button at POS is a text property button, the return value
is a marker pointing to POS."
(let ((button (get-char-property pos 'button)))
(if (or (extentp button) (null button))
button
;; Must be a text-property button; return a marker pointing to it.
(copy-marker pos t))))
(defun button-at (pos) (extent-at pos nil 'button))
No? But I'm not sure about the semantics -- what if there are
multiple buttons at POS? What would Emacs do? Does it make sense?
For the reasons above (and that's probably just a start), I favor
fsf-compat as the home for this file.
That said, I don't have a really strong feeling about this. Nor am I
suggesting that you (or anyone else) need do anything about my gripes
before adding the file.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta