Re: mdocml: Churn-ish check-in getting mdoc_parseln() and man_parseln() to

Re: mdocml: Churn-ish check-in getting mdoc_parseln() and man_parseln() to

[Ingo Schwarze]

Hi Kristaps,

kristaps@mdocml.bsd.lv wrote on Sat, Jun 26, 2010 at 11:36:38AM -0400:

> Log Message:
> -----------
> Churn-ish check-in getting mdoc_parseln() and man_parseln() to accept a
> const struct regset pointer.  No functionality.
[...]
> +++ man.h
> @@ -108,7 +108,9 @@ struct	man;
>  void	 	  man_free(struct man *);
>  struct	man	 *man_alloc(void *, int, mandocmsg);
>  void		  man_reset(struct man *);
> -int	 	  man_parseln(struct man *, int, char *, int);
> +int	 	  man_parseln(struct man *, 
> +			const struct regset *,
> +			int, char *, int);

This must not be const.

.Sh SYNOPSIS implies .nr nS 1,
any other .Sh implies .nr nS 0.

Apart from that, it might be possible to get your approach working.
The decisive point will be implementing the frontend cues.

The nice thing about my patch is that the backend and the frontend
can use identical roff_reg_(get|set)* functions, so some functions
can be shared between mdoc_validate and mdoc_term.

With your approach, you must be careful to not implement the same
thing twice, once in the backend using the roff register data
structure, then the same logic in the frontend using a different
cues data structure.

So, i shall not merge this yet, but wait how it goes.  :)

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: mdocml: Churn-ish check-in getting mdoc_parseln() and man_parseln() to

[Kristaps Dzonsons]

Ingo,

> This must not be const.

Registers should be written only by libroff (they're roff constructs).
It's up to libmdoc and libman if they want to cue the front-ends by
looking at both their internal state and the registers.  This will be
apparent by the next commit that implements the cue for SYNOPSIS formatting.

> .Sh SYNOPSIS implies .nr nS 1,
> any other .Sh implies .nr nS 0.
> 
> Apart from that, it might be possible to get your approach working.
> The decisive point will be implementing the frontend cues.

That'll be in the next patch.  I'm committing a big fat clean-up right
now that stuffs regset into struct mdoc/man/roff, because it must reach
deep into the system and I'm tired of changing function prototypes.

> The nice thing about my patch is that the backend and the frontend
> can use identical roff_reg_(get|set)* functions, so some functions
> can be shared between mdoc_validate and mdoc_term.

True, but I don't want the front-ends looking at raw registers.

In general, the compilers should tell the front-ends exactly what to do
with flags and cached data: I want dumb front-ends in terms of semantics.

> With your approach, you must be careful to not implement the same
> thing twice, once in the backend using the roff register data
> structure, then the same logic in the frontend using a different
> cues data structure.
> 
> So, i shall not merge this yet, but wait how it goes.  :)

Thanks for the comments!  Keep an eye peeled.

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: mdocml: Churn-ish check-in getting mdoc_parseln() and man_parseln() to

[Ingo Schwarze]

Hi Kristaps,

Kristaps Dzonsons wrote on Sun, Jun 27, 2010 at 06:00:43PM +0200:
> Ingo Schwarze wrote:

>> This must not be const.

> Registers should be written only by libroff

Not true.
In roff, registers can be set (.nr) and read (\n).
Reading can either embed the result in the output stream
or use it in a condition.
Thus, it is easily possible to inspect registers,
and it turns out .Sh DOES change the register.

> (they're roff constructs).

Sure, but alas, in the mdoc(7) language, layering is weak.

> It's up to libmdoc and libman if they want to cue the front-ends by
> looking at both their internal state and the registers.

That's not sufficient.
Conditions depending on the nS register can be used to find out
on the roff level whether we are in SYNOPSIS, so libmdoc must cue
libroff, too.  Granted, we don't implement conditions inspecting
registers so far, but we are heading that way.

I have already seen real manuals using real non-trivial conditions
inspecting registers in the wild, so we should pay attention keeping
register content accurate at all times.

> This will be apparent by the next commit that implements the cue
> for SYNOPSIS formatting.

Looking forward to it...

[...]
>> The nice thing about my patch is that the backend and the frontend
>> can use identical roff_reg_(get|set)* functions, so some functions
>> can be shared between mdoc_validate and mdoc_term.

> True, but I don't want the front-ends looking at raw registers.

Indeed, you have a point here.

> In general, the compilers should tell the front-ends exactly what to do
> with flags and cached data: I want dumb front-ends in terms of semantics.

That sound sane as well.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: mdocml: Churn-ish check-in getting mdoc_parseln() and man_parseln() to

[Kristaps Dzonsons]

Heh, wish I'd gotten this clue-stick earlier.  Anyway, committing fix to
this now.  Note the next commit will make regset a bit more intelligent
regarding default values...
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: mdocml: Churn-ish check-in getting mdoc_parseln() and man_parseln() to

[Kristaps Dzonsons]

>> This must not be const.
> 
> Registers should be written only by libroff (they're roff constructs).
> It's up to libmdoc and libman if they want to cue the front-ends by
> looking at both their internal state and the registers.  This will be
> apparent by the next commit that implements the cue for SYNOPSIS formatting.

No--on further analysis, I'm wrong:

.Sh FOOBAR
.nr nS 1
.Ft "void"
.Fn config_init "void"
.Sh FOOBAR2
.Ft "void"
.Fn config_init "void"

The `Sh' will reset the register.  This, thanks to my last checkin, is a
simple fix.  Coming in a few minutes...
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv