Re: [bug #34752] compiling with clang gives warnings about unsupported options

[Robert Slover]

I had declined to reply to this, since the response seemed a bit hostile for 
what was only a benign suggestion. However, since this is specifically being 
discussed, here are the general reasons I suggested the approach that I did:

1) I most often encounter this sort of issue in code that isn't a string of 
English text containing a contraction. "Plain good english" will not suffice to 
prevent a regular expression or embedded quote in a sed or awk expression from 
tripping up Emacs.
2) In the products I work on, user-visible messages will show up in 
documentation, screenshots, and other places. There is always resistance to 
changing message output based on this reason alone. My convenience, as one of 
the few Emacs users, will generally not be considered a sufficient 
justification for a change. Unless I visit the code frequently I will generally 
remove my little "martian style comment" myself before submitting such code for 
review, which is the lowest-impact method of dealing with the issue. 
3) In some of our older code, the original English format strings are used as 
keys in message translation for internationalization purposes. Changing them 
has significant overhead associated with it.

Best regards,


--Robert

On Mar 4, 2013, at 4:19, Richard Frith-Macdonald <richard@tiptree.demon.co.uk> 
wrote:

> 
> On 28 Feb 2013, at 10:08, Jean-Charles BERTIN wrote:
> 
>> What is the best way of correcting this: write plain good english or add
>> a martian style comment? You decide.
> 
> Stylistically, the best english output here is to use the contraction.  In 
> english, contractions should be used except where there is specific reason 
> not to.
> 
> ie, "it's" is to be preferred over "it is", since the latter is read as 
> emphasising "is".  This unusual emphasis breaks the flow of reading as it 
> prompts the reader to look for the reason for the emphasis; which is good if 
> there is a reason, but poor if there isn't.
>