I have had this problem myself, not with developer modules (cause I don’t use them) but with the PlayerModule and general third party code. Unfortunately, I doubt that this problem can or should be fixed at the level of individual comments. But as others have hinted, a solution more in the realm of being able to filter out results (e.g. by script) would be useful.
For what it’s worth, I will describe to you my own personal solution to this issue:
I prefix all my TODOs by @. Then by searching for @todo I can get results that are only my own. This style is uncommon enough that I haven’t had a conflict so far, and it lets you keep the fancy syntax highlighting (though to me I find that sort of thing matters less and less nowadays).
-- @TODO Fix this terrible bug!
Also if you want to disable results that are not relevant, you can insert a different character in between the @ and the searchable text (I use !).
-- @!TODO This comment is now hidden from typical search results.
Hiding comments this way is occasionally useful in my own code, and it’s more significantly useful in situations where third party code is using the same style as you and you want to quickly ignore their TODOs in a nice structured way. Because you can just find and replace every @todo with @!todo in their code and then you’ll never have to deal with those comments again.
Bonus description of how I generalize this system to help with other things
Turns out, being able to make specific, exclusively searchable comments is useful, so I call this general approach “tags” and use it for many things. I also use the colon : to separate a tag into pieces which can be searched independently and is useful to communicate relationships.
Here are some examples different tags I use:
-- @Debug Indicates code which is used for debugging purposes.
-- Is often enabled/disable temporarily via comments.
-- @Session:TODO Indicates something which should be done in
-- the short term (e.g. pending changes to a system you are
-- refactoring, things you need to get done before you release an
-- update).
-- @Session:Debug Indicates temporary debugging code with a
-- similar lifetime to @Session:TODO.
-- @Session Of course you can also search for this prefix on its
-- own which is useful if you want to quickly check that you have
-- cleaned up all your loose ends.
-- @SomeNewChange:On
-- @SomeNewChange:Off
-- These are used to indicate old/new/different pieces of code
-- doing a similar thing. Can be helpful when refactoring or trying
-- to compare solutions to a problem.
-- @SomeFeature:Variant1
-- @SomeFeature:Variant2
-- @SomeFeature:Variant3
-- ...
-- Similar to the on/off thing except more generalized, not just
-- binary or implying some kind of on/off state where the things
-- are just conceptually different.
-- @Modification This is used to indicate a modification made
-- to third party code. Particularly useful if those modifications
-- need to be tracked over time and/or migrated to newer
-- versions of the third party code (e.g. this is very useful for
-- maintaining a forked copy of the PlayerModule)
-- @Duplicate:SomePieceOfCode This is used with two or
-- more blocks of code which are doing something a similar way
-- and are sort of conceptually coupled together so if you change
-- one you should also change the other. Occasionally pieces of
-- code like this exist where it wouldn't be very productive to try
-- to abstract them and it's better to just document that the
-- duplication exists.
Tags are also greatly enhanced by using multiline comments, as you can use them to attach the tag to a particular block of commented code. Multiline comments can also be easily enabled/disabled by adding/removing an extra - to the beginning of comment opener --[[.
---[[ @Debug (code is currently enabled)
print("This is a debugging print!")
--]]
--[[ @Debug (code is currently disabled)
print("This is a debugging print!")
--]]
In practice, most of my use of tags end up being with these multiline comments, so that it’s very clear what code the tag corresponds to, and so the code can easily have its comment state toggled. The main exception are my TODOs which are usually isolated “blocks” of single-line comments.
