Re: check-parens
Andreas Roehler writes:
GNU has it in lisp.el.
If GNU already has it, then there's no *need* for the implementation
to be compatible. We just need to have the interface be compatible.
For convenience of mintenance, it may be desirable for the
implementation to be *identical* if their implementation is not GPLv3.
(Or you could wait until we go GPLv3.) But if there are reasons to do
it differently, we may as well use our features.
I wrote:
> For this to be robust, it needs to handle narrowed buffers. I
think
> it would be annoying to have it move point just because I had a
> restriction in effect. Confusing, too.
> ;; To handle restrictions, wrap the condition-case in
`save-restriction'.
> ;; That's not enough, though: need to decide what behavior should be if
> ;; an error is not in the narrowed region!
I think this function is quite useful without handling restrictions,
so it would be sufficient to check for a restriction and exit with an
`(error 'unimplemented "not implemented for narrowed buffers")'.
Please document the fact that narrowed buffers aren't handled in the
docstring, and mention that save-restriction isnt enough and why in a
comment near the check for restriction.
> ;; Yeah, I know, we should be GNU-compatible here.
Yes, please. Altogether as this form will break a lot of code
dealing with defun.
Doesn't GNU have `defun-when-void'? If that's not the issue, what do
you mean?
Works fine for me. Thanks.
If you could work up an improved contribution as follows:
1. Provide a ChangeLog.
2. Handle the restriction issue (eg, by error if there is one).
3. Any additional whitespace characters you can think of?
4. What happens if there is a comment before the broken sexp? AIUI
the code as written will stop before the comment. Do you think
the function should handle that case? If not, explain briefly (it
might be difficult to decide whether to do a forward-comment, and
how many to do, etc). What does GNU do here?
5. I think this function should be available to 21.4, too, which is
simplest if we put it in a package.
Suggestions for the best place to put it in the xemacs-base
package would be welcome.
6. Since it's not obvious where this function should go, you need not
provide a diff, but just the ChangeLog and the function itself.
7. Submit to xemacs-patches.
I think this could go into the packages immediately.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta