Noting that Lazarus now accepts %region and %endregion as well as %H-, is there a full list of these directives anywhere?
Would it be possible to add %todo as an alternative to todo:, to reduce proliferation of multiple formats?

Mailing lists / lazarus / 2013-12
16 messages · 4 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Noting that Lazarus now accepts %region and %endregion as well as %H-, is there a full list of these directives anywhere?
Would it be possible to add %todo as an alternative to todo:, to reduce proliferation of multiple formats?
Noting that Lazarus now accepts %region and %endregion as well as %H-, is there a full list of these directives anywhere?
There is a wiki page:
http://wiki.lazarus.freepascal.org/IDE_directives
Would it be possible to add %todo as an alternative to todo:, to reduce proliferation of multiple formats?
Do you mean like this:
http://xkcd.com/927/
Mattias
Thanks for that. So is there anything other than TODO: which isn't covered in there?
Well yes :-) But if %directive is being adopted as a standard, I'd suggest that encouraging the migration of TODO: to that form would be desirable.
How do yo want to encourage that?
Mattias
How do yo want to encourage that?
Deprecation in the next version of Lazarus.
Removal in the one after that.
R.
Deprecation and removal is 'discouraging'.
And what would be the reason to remove "todo:"?
Mattias
Deprecation and removal is 'discouraging'.
I always feel encouraged to use new features/syntax/we and discouraged to use the old if I know that the old will stop working. If you favor 'modern encouragement':
Advertise with 'Shiny, new, todo 2.0' or 'todo: is dead, long live %todo' or 'More %todo than ever' on the main page. Write a blog post about it, inform the masses how great the new '%todo' is and make a youtube video about it. But I think deprecation and removal are good enough to encourage people.
And what would be the reason to remove "todo:"?
Changed syntax to make it consistent with other directives? Old code should not be affected as the old todos should be done by the time of change. ;)
R.
Disclaimer: I don't favor any one of the todos over the other. You asked how to encourage usage and that's how I would do it.
On Mon, 16 Dec 2013 14:40:59 +0000 How do yo want to encourage that? Mattias
My suggestion would be to change the IDE to recognise %todo as well as todo:, in three releases time (1.8?) have the IDE insert new items favouring %todo, which is presumably not on anybody's radar at the moment- rewrite todo: as %todo.
On Mon, 16 Dec 2013 19:05:49 +0100 I always feel encouraged to use new features/syntax/we…
On Mon, 16 Dec 2013 19:05:49 +0100 Mattias Gaertner wrote: [...] Disclaimer: I don't favor any one of the todos over the other. You asked how to encourage usage and that's how I would do it.
Thanks.
The todo list package was abandoned by the original inventor. Currently I maintain it, that means keep it compiling. I don't use it myself and I have no plans to extend it. The package supports various todo formats and if someone wants to add another one feel free to send a patch. Parsing a todo is pretty simple so there is almost no maintenance cost to support another format. I see little reason to remove a format. At the moment it supports:
//todo, //#todo, {todo}, {#todo}, (*todo*), (*#todo*) And the same for 'done'.
IMHO it would be nice if the user can check what todo formats he likes (e.g. list of checkboxes). By default it could be only {%todo}, {%done}.
Keep in mind that IDE directives only supports the curly bracket comments.
Mattias
I'm not promising, I'm still trying to find a SPARC bug. But I think it would be nice if everything were guided towards consistency.
Keep in mind that IDE directives only supports the curly bracket comments.
Thanks for the reminder, I think FPC macros have a similar restriction.
Should be considered a bug, because "(*$" also triggers the parsing of a macro, but the ending "*)" is not respected (also any combination of opening/closing "(*" and "*)" are currently possible inside a macro while "{" and "}" need to be balanced...). Fixing this would only be consequent, because "(*" and "*)" are digraphs of "{" and "}"...
Regards,
Sven
I'll try to find the earlier discussion to refresh my memory, then raise a bug if it appears to still be am issue.
It is still an issue, because I tested before I wrote the mail. :)
Regards,
Sven
Will you do a bug report or shall I?
You can do it as well.
Regards,
Sven
Raised as 0025438.