> 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
Folks,
I've just fixed some hyphenation issues.
o The `.hy' request should now work as documented (again).
Additionally, I've added values 16 and 32 to hyphenate before the
last and after the first character, respectively. There exist
languages (most notably Greek) that indeed allow (and
37 matches
Mail list logo
