Re: [groff] Creating a numbered list without macros

[Holger Herrlich]

Sorry, the former mail was an Hot-Key-Accident (sticky keys and
focus follows mouse) and my first reply a misdirecting filter rule.
While it's kinda hard, using few words, to claim that here is use for
private macro sets between plain groff and "don't care" frameworks, I
was trying and then ..


Uhm, but it is out...

and this part is valid:

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 will always
suffer this problem. So if you wanna write, you will end up with a
macro set.

Why not an existing one?

For me, I want to use tools that preserve creativity. But a framework
desires to make things easy. (As a rule of thumb: Always avoid people
claiming that.) But the kindergarten teacher's "making things easy" is
different to providing a professional tool that do exactly that it
claims to do--therefore is "easy to use".

Very general nowadays:
 - Tools don't simplify your task. A Tool simplifies the
   accomplishment. 
 - Encapsulation is not hiding!
 - And don't confuse to learn with to obey (learn the ticket window).

The framework takes away flexibility. so to create business cards I
had to do it myself from the scratch. Programming languages as well as
GUIs are just instances of an user interface. Therefore I like the
design of an multi level (high,low) API.

OKAY, that's the idea. A framework doesn't provide smaller entities
(the UNIX thing) to be more creative (not only graphically).

Sorry again, Holger



On Thu, 16 Aug 2018 11:55:59 +0200
Holger Herrlich <address@hidden> wrote:

> On Sat, 11 Aug 2018 18:12:18 +0200
> Ingo Schwarze <address@hidden> 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!
>