> Here is, I think, the third iteration of the patch, taking into
> account Ralph's feedback on the length and overworked nature of the
> previous iteration's diagnostic messages.
LGTM, thanks!
Werner
At 2018-05-04T19:23:15-0400, G. Branden Robinson wrote:
> I've attached a proposed patch. I'm not completely thrilled with it
> because some people might interpret it as suggesting that .hy 62 is
> valid; it isn't, but not because it is too large. Still, I would prefer
> to tell people the limit
At 2018-05-06T12:10:13+0100, Ralph Corderoy wrote:
> > My debugging instincts tell me to always report the value of an
> > argument being rejected. For one thing, the user could have passed
> > .hy a register value (possibly with arithmetic manipulation), and if
> > we screw up the validity checks
> @Example
> .ll 1
> .hy 48
> @endExample
>
> It seems the word "splitting" should be on a third input line (after
> the .hy request).
Fixed, thanks.
Werner
I hate to distract from the robust discussion on C coding style with a
comment about groff, but I noticed what appears to be a missing line
from the changes commit d592d320cd43cf4ecee67a7aa80b52691671465d made
to doc/groff.texi. Part of the added text reads:
@Example
.ll 1
.hy 48
@endExample
ret
Hi Ralph,
Ralph Corderoy wrote on Sun, May 06, 2018 at 01:19:09PM +0100:
> I think those struggling with Andersons' `right left' rule, or
> equivalent, will probably find that const being allowed to shift
> position but not meaning is significant
Nobody is suggesting that it should be allowed to
Hi Carsten,
> C++ has the same rules as C regarding this.
Thanks for clarifying. Sorry you had to do it twice; Mike must have
forwarded my off-list email from earlier to the list so there was some
duplication.
> See e.g. Bjarne Stroustrup's "The C++ Programming Language" Forth
> Edition §7.5 p
> Ralph Corderoy hat am 6. Mai 2018 um 14:33
> geschrieben:
> I don't know if C++ has different semantics that mean choice of position
> is less flexible; I've just been talking about C.
C++ has the same rules as C regarding this. See e.g. Bjarne Stroustrup's "The
C++ Programming Language" Fo
Hi Ingo,
> > Perhaps you're in a bit of a silo? :-)
>
> Perhaps. :-)
Branden's cited one source he's seen. I had a Google last night, but
was too tired to post the results.
A _Dr Dobbs_ blog article in 2010 recommends always writing `int const'.
http://www.drdobbs.com/cpp/the-mutable-comprehe
Hi Ingo,
> What you described as a pointer to a 2x3 array of immutable pointers
> to strings might be
> char **const (*gbrs_evil)[2][3]
> But as i said, it is evil, so maybe i'm wrong, too.
It's really not that evil.
char **const (*gbrs_evil)[2][3]
gbrs_evil is a
Hi Branden,
> I had first _heard_ of it some years ago, but the most significant bit
> of prominent evangelism for it I'm aware of is from Ben Klemens's
> _21st Century C_:
> https://www.goodreads.com/book/show/14514281-21st-century-c
Interesting, thanks. The second edition gets a better star ra
Hi Branden,
> Getting back on topic...
Square!
> My debugging instincts tell me to always report the value of an
> argument being rejected. For one thing, the user could have passed
> .hy a register value (possibly with arithmetic manipulation), and if
> we screw up the validity checks it's eas
Getting back on topic...
At 2018-05-05T15:43:35+0200, Werner LEMBERG wrote:
[...]
> Please use `const int' – there is no single instance of `int const' in
> the groff code.
[...]
> >> I'd suggest adding
> >>
> >> HYPHEN_NONE = 0,
> >> HYPHEN_DEFAULT = 1,
> >> HYPHEN_MAX = 63 // Or wha
At 2018-05-06T00:19:44+0100, Ralph Corderoy wrote:
> That was my point. Though the widespread conventional method has that
> in its favour, it doesn't mean the more logical consistent one is wrong
> or misleading. It mainly means the alternative hasn't been considered
> for its merits, just dismi
Hi Ralph,
Ralph Corderoy wrote on Sun, May 06, 2018 at 12:19:44AM +0100:
>> Even though you are right
> ...
>> i strongly object to your argument.
> I don't know what you think my argument is.
I thought your argument was "usually, writing char const is better
than writing const char".
>> [obj
Hi Branden,
G. Branden Robinson wrote on Sat, May 05, 2018 at 05:20:19PM -0400:
> At 2018-05-05T20:05:20+0200, Ingo Schwarze wrote:
>> P.S.
>> By the way, using "char const" doesn't make understanding
>>
>> char *const *evil[2][3];
>>
>> any easier for people who do not know the rules...
> T
Hi Ingo,
> Even though you are right
...
> i strongly object to your argument.
I don't know what you think my argument is.
> [objective simplicity] undeniably favours "char const",
That was my point. Though the widespread conventional method has that
in its favour, it doesn't mean the more log
At 2018-05-05T20:05:20+0200, Ingo Schwarze wrote:
> P.S.
> By the way, using "char const" doesn't make understanding
>
> char *const *evil[2][3];
>
> any easier for people who do not know the rules...
This looks like a wonderful opportunity to embarrass myself.
"evil" is a pointer to a 2x3 ar
At 2018-05-05T15:43:35+0200, Werner LEMBERG wrote:
>
> >> > + static int n_max = (HYPHEN_NOT_LAST_LINE | HYPHEN_NOT_LAST_CHARS
> >> > +| HYPHEN_NOT_FIRST_CHARS | HYPHEN_LAST_CHAR
> >> > +| HYPHEN_FIRST_CHAR);
> >>
> >> s/static int/int const/?
>
> Please use `const int' – there is no si
Hi Ralph,
Ralph Corderoy wrote on Sat, May 05, 2018 at 05:08:22PM +0100:
>> char const *foo;
> I used your syntax for decades and only switched in the last year after
> chatting to a programmer that's always done it the other way since
> introducing the Small C compiler into his company to rep
Hi Keith,
> I was taught to:
>
> - find the symbol name
> - look right, for parentheses
> - look left, token by token, to find the type
Yes, that's a simplification of the `right left' rule that I first saw
in Paul and Gail Anderson's _Advanced C: Tips and Techniques_,
https://amzn.to/2rn2L
>> > + static int n_max = (HYPHEN_NOT_LAST_LINE | HYPHEN_NOT_LAST_CHARS
>> > +| HYPHEN_NOT_FIRST_CHARS | HYPHEN_LAST_CHAR
>> > +| HYPHEN_FIRST_CHAR);
>>
>> s/static int/int const/?
Please use `const int' – there is no single instance of `int const' in
the groff code.
>> Given the enum,
At 2018-05-05T14:01:00+0100, Keith Marshall wrote:
> On 05/05/18 12:40, G. Branden Robinson wrote:
> > At 2018-05-05T11:51:00+0100, Keith Marshall wrote:
> >> On 05/05/18 10:48, G. Branden Robinson wrote:
> >>> (Incidentally, I share your preference for putting type qualifiers
> >>> [as opposed to
On 05/05/18 12:40, G. Branden Robinson wrote:
> At 2018-05-05T11:51:00+0100, Keith Marshall wrote:
>> On 05/05/18 10:48, G. Branden Robinson wrote:
>>> (Incidentally, I share your preference for putting type qualifiers
>>> [as opposed to storage classes] _after_ the type name itself. It
>>> makes
Keith Marshall wrote:
|On 05/05/18 10:48, G. Branden Robinson wrote:
|> (Incidentally, I share your preference for putting type qualifiers
|> [as opposed to storage classes] _after_ the type name itself. It
|> makes complex declarations easier to understand.)
|
|Personally, I consider that
At 2018-05-05T11:51:00+0100, Keith Marshall wrote:
> On 05/05/18 10:48, G. Branden Robinson wrote:
> > (Incidentally, I share your preference for putting type qualifiers
> > [as opposed to storage classes] _after_ the type name itself. It
> > makes complex declarations easier to understand.)
>
>
Hi Keith,
> conventionally:
>
> const int foo;
>
> is more common than:
>
> int const foo;
Agreed. Though that convention started before all the other bells and
whistles were added.
> const char *foo;
foo is a pointer to a char that's const.
> char const *foo;
foo is a pointer to a c
On 05/05/18 10:48, G. Branden Robinson wrote:
> (Incidentally, I share your preference for putting type qualifiers
> [as opposed to storage classes] _after_ the type name itself. It
> makes complex declarations easier to understand.)
Personally, I consider that to be a poor choice ... especially
At 2018-05-05T10:31:48+0100, Ralph Corderoy wrote:
> Hi Branden,
>
> > + static int n_max = (HYPHEN_NOT_LAST_LINE | HYPHEN_NOT_LAST_CHARS
> > +| HYPHEN_NOT_FIRST_CHARS | HYPHEN_LAST_CHAR
> > +| HYPHEN_FIRST_CHAR);
>
> s/static int/int const/?
Yes, of course. Thanks! (Incidentally, I s
Hi Branden,
> + static int n_max = (HYPHEN_NOT_LAST_LINE | HYPHEN_NOT_LAST_CHARS
> +| HYPHEN_NOT_FIRST_CHARS | HYPHEN_LAST_CHAR
> +| HYPHEN_FIRST_CHAR);
s/static int/int const/?
>if (has_arg() && get_integer(&n)) {
> -if (((n & HYPHEN_FIRST_CHAR) && (n & HYPHEN_NOT_FIRST_CHARS))
At 2018-05-04T23:30:15+0200, Werner LEMBERG wrote:
>
> > Going forward, should groff generate a warning if a document
> > contains an undefined value of .hy, so that this problem will not
> > recur with any future changes?
>
> This makes sense. I currently can't remember whether other, similar
>
> Going forward, should groff generate a warning if a document
> contains an undefined value of .hy, so that this problem will not
> recur with any future changes?
This makes sense. I currently can't remember whether other, similar
flag registers exhibit similar behaviour.
Werner
Hi Werner,
I know groff isn't your primary focus anymore, so I'm pleased to see
you've tackled these hyphenation bugs and enhancements.
On 3/1/18, Werner LEMBERG wrote:
> o The `.hy' request should now work as documented (again).
> Additionally, I've added values 16 and 32 to hyphenate before
On Sun, Mar 04, 2018, Bertrand Garrigues wrote:
> Peter,
>
> I've just seen that you have commited version 2.3 of 'mom', does this
> include the fixes Werner mentioned?
I believe so. The only issue not taken care of is the troff "transparent
throughput" warnings that appear when building the mom
> Just one remark on the 'NEWS' file: you added new entries in the
> 1.22.3 version, shouldn't these belong to a new 1.22.4 paragraph?
Oops, yes. Thanks for noticing, fixed in git now.
Werner
Hi Werner,
On Thu, Mar 01 2018 at 08:50:48 PM, Werner LEMBERG wrote:
> Folks,
>
>
> I've just fixed some hyphenation issues.
[...]
I wasn't very active these days as I cought the flu (the weather was
terribly cold in Paris), I've made only a few tests and it looks OK to
me, I'll test more next w
36 matches
Mail list logo
