emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: use and doc of function symbol properties [was: bug#11381: 23.3; ise


From: Drew Adams
Subject: RE: use and doc of function symbol properties [was: bug#11381: 23.3; isearch-search-and-update issue?]
Date: Mon, 28 May 2012 11:26:35 -0700

> > Can you be more specific about what is missing from the 
> > Commentary in delsel.el?
> 
> It basically doesn't explain anything apart of the fact that the
> property can have several values.  The exact effect of each value is
> left unclear to the degree of obfuscation.

The effect of each value is described, though perhaps imperfectly and not to
your liking.

Again, what specifically do you feel is missing?  Just repeating "obfuscation"
does not help.  Please specify the information that you would add.

> And the names of the values are similarly non-specific.

The names do not stand alone without their descriptions.  Even so, I think that
`yank' and `kill' are pretty clear even without reading their descriptions.
`supersede' is not so obvious, but its description seems clear.

"non-nil" should be "anything else non-nil".  And we should say that this is the
usual case.

FWIW, in my version of delsel.el I changed the wording a tiny bit, to improve it
slightly:

;; The property can have one of these values:
;;
;;  `yank' - For commands that do a yank. Ensures that the region
;;           about to be deleted is not yanked.
;;
;;  `supersede' - Delete the active region and ignore the current
;;           command: the command just deletes the region.
;;
;;  `kill' - `kill-region' is used on the selection, rather than
;;           `delete-region'.  Text selected with the mouse is
;;           typically yankable anyway.
;;
;;  anything else non-nil - Deletes the active region prior to
;;           executing the command, which inserts replacement
;;           text. This is the usual case.

I'm not saying the existing descriptions should not be changed.  I'm asking you
what changes you have in mind.

> What is needed is a clear description what each value does,

For instance?  What is missing, in your opinion?

> and it should be part of the doc string.  Right now, this info is only
> available by reading the code.

Agreed.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]