No. 232 - indent-new-comment-line misbehaviour

Andreas Röhler andreas.roehler at online.de
Wed Mar 12 04:37:04 EDT 2008


Am Mittwoch, 12. März 2008 00:27 schrieb Stephen J. Turnbull:
> Andreas Röhler writes:
> 
>  > To start with the less important: some of the routines
>  > in newcomment.el are very intrinsic. Too they contain a
>  > lot of circulars, calling themselves again and
>  > again. This makes debugging labourious.
> 
> Well, that's usually good Lisp style.
> 


Maybe I wasn't precise: it's not about recursive calls,
but about putting functions in a circled chaine,
running many times around until some state is reached.

It looks clever and it is to the extent, you still know
what's happening. But why all this bugs over the years
then?

As I'm nearly through with an alternative approach to
commenting, let's look at it next days.

Thanks

Andreas Röhler



> Be careful here.  AFAIK newcomment is Stefan Monnier's baby, and he is
> not famous for being an icky programmer.
> 
>  > Presently it's not easy to detect for the user where a
>  > variable like `comment-column' is set. He or she may
>  > look into newcomment.el, see `defcustom comment-column'
>  > there and customize it.
> 
> This is in some sense not a problem.  C-h v will tell you that the
> value is an automatic buffer-local, which is almost always a signal
> that modes use different values for the variable.  I suppose M-x
> customize-variable probably does a sucky job of handling this, but the
> documentation is there.
> 
> It might make sense to demote it to a defvar, though.  It sounds like
> this is not a variable that it is very useful to customise.
> 
>  > However, that value might be overridden by
>  > `lisp-mode-variables' which uses a hard-coded value.
> 
> You should look into using a specifier for this variable.  The problem
> with that is that the interface for using it will change globally,
> from `setq' and implicit `symbol-value' to `set-specifier' and
> `specifier-instance'.  You'll just about have to rename it, and figure
> out some way to handle legacy code that uses `comment-column'.  And of
> course it will cause an ongoing cost of sync'ing to GNU Emacs.
> 
> One possibility would be to have a defvar for `comment-column' which
> is backward- and GNU-compatible.  Then have a defcustom for
> `comment-column-specifier' which would be consulted by the code that
> sets comment-column.
> 
> The main problem with this scheme is that there is no `mode' locale,
> but it wouldn't be hard to add it, I think.
> 
>  > IMO the right place to put in defcustom-forms for
>  > commenting are the programming modes. So I'll delete
>  > this forms in my new comment.el and introduce it there?
> 
> Definitely not.  A single variable should have a single defcustom, and
> that defcustom should be in the place where the variable is used, not
> where it is set.  Briefly, it is an interface exported by comment.el.
> 
> _______________________________________________
> XEmacs-Beta mailing list
> XEmacs-Beta at xemacs.org
> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
> 



More information about the XEmacs-Beta mailing list