10:31 a.m.
Hi all,
during last years I watched the show ups of several
rather elementary bugs as No. 232,
"indent-new-comment-line misbehaviour?", which doesn't
pertain to a new or exotic language.
Looking for the causes of this and other bugs, I came
to the conclusion: the basic responsible is the design,
is the way commenting presently is implemented.
Or put it vice versa: patching a bug in present
conditions IMO bears a high risk to produce the next
bug in your back.
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.
IMO this complexity must not be, it's possible to make
it much easier to read and follow.
So far I'm considering a patch during next weeks.
The second point needs your advice:
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.
However, that value might be overridden by
`lisp-mode-variables' which uses a hard-coded value.
That's just an example, there are more clashes of this
kind around.
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?
What's your opinion about that?
Thanks
Andreas Röhler
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:27 p.m.
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.
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(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:37 a.m.
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(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6099
days inactive
6100
days old
2 comments
2 participants
participants (2)
-
Andreas Röhler -
Stephen J. Turnbull