nimsuggest: clean up nimsuggest.nim.cfg

[bung87]

Summary

Remove obsolete and disabled configuration options from the
nimsuggest.nim.cfg configuration file.

Details

• remove adding lib/packages/docutils to the import paths; imports
  in the compiler and tools should not (and do not) rely on extra
  import paths besides the compiler root and library directory
• remove the outdated and disabled defines for the booting and
  noDocgen symbols

The useStdoutAsStdmsg define, while also obsolete, is kept for
consistency with the compiler and nimfix, both which also define
this conditional symbol.

[zerbina]

The change looks good to me, but if you also remove the two disabled define lines, the title of the PR could be changed to clean up nimsuggest.nim.cfg.

[zerbina]

Since you've also removed the active useStdoutAsStdmsg define, please mention in the PR message what it does.

[bung87]

updated.

[zerbina]

I'm a bit uneasy about the useStdoutAsStdmsg change. While, as you noted, none of the compiler/nimsuggest code currently uses stdmsg, it could again in the future, and then the behaviour of code shared between the compiler and nimsuggest would be different depending on what program the code is compiled for (the useStdoutAsStdmsg condition symbol is enabled for both the compiler and nimfix).

I think it'd be better to leave the conditional symbol be.

[bung87]

no, they should use config's writeHook and writeLnHook

[zerbina]

Yep, I agree. But for consistency with the other programs (compiler and nimfix), I think that the define should either be used by all of them or none of them.

If none should, then I think that's better changed as a separate PR.

[bung87]

updated.

[zerbina]

@bung87: I've updated the PR title and body.

The removal of the disabled defines is self-explanatory, but removing the additional import path is not. In general, something being unused doesn't necessarily warrant its removal, so I added some elaboration as to why the import path should be removed.

[bung87]

okay, thank you! this one make me re consider the description thing, as it's 3 lines removal from config file, I never thought it worth to write such long description, as they exists maybe just by arbitrarily copy paste. anyway I'll try to do better.

[zerbina]

Personally, I think the length of the PR message should be dependent on the impact and complexity of the change, not on the number of lines changed. Nonetheless, I also think that a description should not be lengthy just for the sake of being long.

Take, for example, a hypothetical PR that removes all superfluous whitespace in a repository. If many of those exists, the changeset of said PR would be very large, possibly modifying each and every file. The impact on the code, architecture, future consideration, etc. would be very small, however, and I think a short description that includes a reason why superflous whitespace should be removed is enough.

On the other hand, even a single-line change can have a profound impact on the code base and possibly invalidate many invariants, in which case a longer description detailing the reasoning, consequences, etc. is warranted/needed.

[zerbina]

/merge

[github-actions]

Merge requested by: @zerbina

Contents after the first section break of the PR description has been removed and preserved below:

---