I don't think this is not worth the effort. if there were a way to provide instrictions, it would encourages developer to write more messages I suppose.
Sure, but analogous to port developers making patches that they don't try to send to upstream developers is a problem, making our own docs has some pitfalls too since sometimes we are doing what the developers should have (when it isn't stuff that is MacPorts specific). And I'm a little more pessimistic that creating a infrastructure will spur people to write more hints and docs because it takes time, patience, and they need to be updated once created. But I'm in no way opposed to doing anything that helps; I probably do more doc writing than any other port author. I'm all for anything doc related that helps that we can agree on as long as it is efficient and sustainable.
One option would be to simply hold back any message until all ports installed and output them afterwards. So all messages would be at the end of the log.
Or, use some new target like print_message {}, but which would need to be stored in the registry after installation to be always available in the state as it was on install.
I like these types of things.
For this rather long nedi help, I would prefer to put them into some file like /opt/local/share/doc/nedi/INSTALL.macports and just print a message that there is additional help in this file.
Yes, but if you want variables evaluated within the instructions, and I do, then you end up doing reinplace on keywords so you add another file to ${files} and require more coding and probably some errors in the process. So now you've got to debug the instructional phase. I prefer it either as it is (ui_msg) or by adding a command that would crank out and evaluate the ui_msg section on the fly after a port is installed. Mark