Re: check-parens
Stephen J. Turnbull wrote:
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.
No. At GNU it works well as is.
Wrote it anew with respect at your concerns at occasion
of `beginning-of-defun-function'.
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?
well, that's a minor issue. Maybe let's exchange the
views nonetheless:
`defun-when-void' breaks my (GNUish)
`beginning-of-defun-function', as these knows only about
`defun' and `defsubst'.
Too from the graphical point I would prefer a form like
(unless (fboundp 'MY-DEFUN)
rather than this macro, because it shows more clearly
the exceptionally.
Otherwise the macro writes it shorter, more clean in
other respect.
Maybe I need some time still to get used at the XEmacs
differences.
> 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.
If a switch to GPLv3 is feasible, it would preserve time
to wait.
Until then, maybe it's usable as it is?
If you want to have it now for some package, I can look
for it nonetheless.
This will unfortunately not be possible next two
weeks. Have to do some writing in an other matter.
Maybe let's raise this question again in two weeks then?
Andreas
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta