Sort the help file to give the user the inherent GUI implementation first. When I search help, it provides me with all of the under-lying calls for the macro language. I don't want to write the editor myself as is a very expensive product. Additionally, if the feature is already implemented, I don't want to RE-implement it just because the help for that was lost in help search results noise. I am under tight schedules all the time and REALLY don't have time to become a SlickEdit macro programmer for every little thing. I can do it. I just don't often enough to get good at it and it distracts from the task at hand. If is something that Boxer can handle, I usually just switch over to Boxer, complete the task, and then come back to SE.
Lastly, just because a user can get to a feature with the macro language, does not mean that it should not be implemented as part of the core product (for reasons I stated above, I have work to do). Such, get file name or insert date for example. It is not enough to assume the few that need can just write a macro so it doesn't need to be implemented. I am not saying that that rationale actually occurs. I am merely stating that it shouldn't.