On Sat, 11 Aug 2018 18:12:18 +0200 Ingo Schwarze <schwa...@usta.de> wrote:
[context removed however] > Oh, and why don't you just pick one of the existing macro sets? Here are some reasons to avoid frameworks like Latex or mom. (You may ask yourself why I mention Latex as well and further on talk about frameworks in general. Well what's because I doesn't use mom. Therefore some of my claims may more or less not be applicable to it. On the other hand, I don't think.) First lets assume that here is a diametral contradistinction between plain groff and a macro package like mom in terms of user interface. The first provides you all the controls to type set. The latter hides that controls as much as possible, claiming the writers perspective. Here is a reason to do so, because mixing up text and groff requests will disturb reading/writing. Document writing using markup technologies will always suffer this problem. So if you wanna write, you will end up with a macro set. So why not an existing one? For me, I want to preserve creativity. Well the framework desires to make things easy. (As a rule of thumb: Always avoid people claiming that.) But "making things easy" is different to providing a professional tool that do exactly that it claims to do--therefore is "easy to use". Encapsulation is not hiding! Tools don't simplify your task. A Tool simplifies the accomplishment. And don't confuse to learn with to obey. All of this nifty differences emerging especially along software _solutions_. It's not special to groff or mom. writing a macro set (not a high priority in my life, but does what I want), is to develop an API (for my macro set), that give me control about independent tasks and defines only as few as possible globals. (You cannot go without.) Whereas the globals being an singular institution. However, I'm not being what better, except what I can change it myself. independent tasks singular globals no interference with plain groff temporal variables ave an API () to become Not only valid for groff macro sets, the sole concept of beginning with defining a frame in order to use the framework debars it. A framework only is of use, if you fit to the dedicated use case and know it in detail. Therefore the acceptance of a macro set goes along with its concept and the documentation of it (the concept not the functions only). So macro packages for man pages are perfectly fine. Clear and easy use case. Macro packages for articles, from my point of view, miss the point and lack design. To transform an big ASCII text into a printout that becomes an A6 book, I have to do by myself anyway. The same is true for business cards and calendars, for instance. Further, it often turns out to be hard to integrate your own (business card) macros into a framework or vice versa, because of side effects, one are not aware. ps: Plain groff is fun to work with!
