> > > A macro package does not hide the controls any more than writing
> > > macros yourself does. A macro package aggregates the requests
> > > needed to perform typesetting functions for convenience, not
> > > opacity.
>
> Isn't it an over generalization? Doesn't technology consist of
> compromises as well?
Certainly there are always compromises -- usually a tradeoff
between what one wants to achieve and the effort (or money)
one is willing to invest in order to achieve this.
("Fast, good, cheap -- pick any two.")
But the point was that macros are a tool; tools are normally
developed to simplify doing a job; and thus the reasonable
assumption is that using the tool will help you in your work.
Of course different tools are developed for different jobs.
Using a screwdriver for one task does not mean that you should
not use a hammer for another task. It's up to you to pick
the right tool from the set of available tools.
Using an existing macro package has the advantage that the
effort required by you is comparatively small; thus it's not
unreasonable to first look into the capabilities of existing
macro packages before deciding on a course of action.
Note that I'm not saying that you should generally not
write your own macros. On the contrary, I'm all for it.
Doing this will provide you with a better understanding of
how groff works, and thus will help you debug those cases
where something doesn't turn out as expected. I think it's
a useful skill to have, regardless of whether you write your
own macros or use an existing macro package (and possibly
adapt or extend it for your purposes). The question is
how much time you can justify investing in this, and
how deeply you need to understand the material.
One of the fundamental properties of computers as a tool is
that they are programmable. Using a computer without taking
advantage of this feature means you're not using it to its
full potential.
