GNU bug report logs -
#2224
[PATCH] add-log.el: Modularize add-log-current-defun, new types supported
Previous Next
Reported by: Jari Aalto <jari.aalto <at> cante.net>
Date: Fri, 6 Feb 2009 17:50:03 UTC
Severity: wishlist
Tags: patch
Done: Chong Yidong <cyd <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>>>> (add-log-current-defun-type-javascript-like): New function.
>>>> (add-log-current-defun-type-shell-bourne-like): New function.
>>>> (add-log-current-defun-type-makefile-like): New function.
>>>> (add-log-current-defun-type-text-asciidoc-like): New function.
>>>> (add-log-current-defun-type-default): New function.
> [...]
>> Having them be separate functions is indeed very good. But most of them
>> shouldn't be in add-log.el: they should be in their respective
>> major-mode instead.
> You mean just define `add-log-current-defun-type-javascript' in js.el,
> and stuff? Doesn't that seem kinda... I don't know. Error-prone?
I thought you were going to say "Obvious?".
Think about it: why should add-log support be different than say,
font-lock, outline, imenu, younameit? Oh and BTW, this same function
can/should be used for which-func-mode.
Of course in js.el it shouldn't be called
`add-log-current-defun-type-javascript' but `js--current-defun-name' or
something like that.
> Because add-log (in the patch) has a major cond up there that will call
> the functions unconditionally if there's a match with the mode (and
> other things), so there's potential for things getting out of sync if
> people are using different versions of (say) js.el that doesn't define
> the function in question...
We had the same problem when we moved the font-lock defs away from
font-lock.el. Yes, it's a problem. No, it's not insurmountable.
Stefan
This bug report was last modified 12 years and 234 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.