Ideas for more customizeable/complex item formatting

[cehteh]

I'd like if magit-todos could filter on rust like todo!() macros (and other forms for languages which allow such annotations). Further the buildin regex wants the todo keywords separated by whitespaces. In my own documentation system and issue tracker (https://git.pipapo.org/?p=pipadoc;a=blob_plain;f=pipadoc.html;hb=refs/heads/master) these are followed directly after a line-comment. I can work around that by setting magit-todos-keywords to '("//WIP" "WIP" "//FIXME" "FIXME" "//TODO" "TODO" "//PLANNED" "PLANNED")' its a hack, works, but this does not cover the rust macro case nor languages which use other line comment syntax.

For rust macros it needs some more elaborate matching because there will be no colon after the keyword and the following parenthesis do not contain a username.

In the long run it would be nice to have some feature to alias matches to a category like 'unimplemented!' should be treated as 'TODO' for example.

[alphapapa]

So you want to be able to control the prefix part of the regexp? (You can already set the suffix part.)

Note that, the less specific the regexp, the more false positives will be shown. e.g. not requiring a space before the keyword could match parts of other words, depending on other factors.

[cehteh]

So you want to be able to control the prefix part of the regexp? (You can already set the suffix part.)

Note that, the less specific the regexp, the more false positives will be shown. e.g. not requiring a space before the keyword could match parts of other words, depending on other factors.

Not necessary a 'prefix' part. It might be even better when the buildin rule which is currently something like '[:space:]keyword' would be '([:space:]|linecomment-sequence)keyword'. Where linecomment sequences should be obtained from the current mode (yes sorry I am bad at elisp by myself, otherwise I would send a patch). As well this prefix part might be defineable, then use only '[:space:]' for it by default to be compatible with the current semantics. I believe when one is careful about this this shouldnt produce false positives. But a key part is that one can retrieve the linecomment character sequence from the buffer mode rather than hardcode '//', '#' and so on.

The other thing, turning language annotations like rusts 'todo!()' macro into magit-todo item is a completely different beast, would be a nice to have and I may open another wishlist ticket for that, still i dont have a very good idea how to do this (really) well. In my pipadoc I could add macros which generate doc comments for those, but no idea how this could be done in magit-todos.

[alphapapa]

Not necessary a 'prefix' part. It might be even better when the buildin rule which is currently something like '[:space:]keyword' would be '([:space:]|linecomment-sequence)keyword'.

That seems like a prefix to me.

Where linecomment sequences should be obtained from the current mode (yes sorry I am bad at elisp by myself, otherwise I would send a patch).

I've already considered that. Using the comment prefix from the major mode is a nice idea, but external scanners are not aware of the major mode nor comment prefix, and files are searched which are not already open in Emacs.

The other thing, turning language annotations like rusts 'todo!()' macro into magit-todo item is a completely different beast, would be a nice to have and I may open another wishlist ticket for that, still i dont have a very good idea how to do this (really) well. In my pipadoc I could add macros which generate doc comments for those, but no idea how this could be done in magit-todos.

That would significantly increase the complexity of this package, requiring type-specific regexps, possibly multiple scans per file, etc. I'm doubtful it would be worth it. In any case, it's not a feature I would be interested in implementing myself.

As far as I can tell, you should probably change the format of your todo items, because that will make them unambiguous and more generally compatible with other tools. A simple sed invocation across your project's files would do the job quickly, or you could do it within Emacs.

[cehteh]

That seems like a prefix to me.

Where linecomment sequences should be obtained from the current mode (yes sorry I am bad at elisp by myself, otherwise I would send a patch).

I've already considered that. Using the comment prefix from the major mode is a nice idea, but external scanners are not aware of the major mode nor comment prefix, and files are searched which are not already open in Emacs.

call it prefix, I just didn't know how how a user can put the major-modes line comment into that.

The other thing, turning language annotations like rusts 'todo!()' ...

That would significantly increase the complexity of this package, requiring type-specific regexps, possibly multiple scans per file, etc. I'm doubtful it would be worth it. In any case, it's not a feature I would be interested in implementing myself.

As far as I can tell, you should probably change the format of your todo items, because that will make them unambiguous and more generally compatible with other tools. A simple sed invocation across your project's files would do the job quickly, or you could do it within Emacs.

I can't change the rust language. This also only served as example, generally I welcome any language where such kinds of annotations are language constructs (or macros) rather than comments which have no semantic meaning for the compiler.

This feature would be a nice to have, but its not so important to me.

[alphapapa]

See also https://github.com/alphapapa/magit-todos/pull/69