Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove space after INVOKE (please complete before applying p0604r0) #1510

Closed
burblebee opened this issue Mar 3, 2017 · 7 comments
Closed
Assignees
Milestone

Comments

@burblebee
Copy link
Contributor

burblebee commented Mar 3, 2017

In email from Daniel Krugler:

Dear editors of the working draft!

I would like to ask whether the following editorial improvement could
be realized, when (In case of acceptance),

http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0604r0.html

would be transferred into the working draft:

I noticed in the past, that in the pdf output of the working draft, a
font change between italics and non-italics (such as in
"INVOKE(" between 'INVOKE' and '(') there often seems to
be an additional space character introduced. This makes is hard to
search reliably for the character sequence 'INVOKE(', for example.
Now, for this sequence there is not often a use-case. But P0604R0
introduces a new "overload" of INVOKE, INVOKE<something>. When my
paper was discussed, people were concerned that this overload will be
hard to search in the working draft when looking for 'INVOKE<'. And
given the above problem, I tend to agree. Therefore I would like to
ask, whether it would be possible for your and hopefully lead to a
more reliable search success, when you editors could rewrite the
currently term in partial html

INVOKE<R> (in html: <i>INVOKE</i>&lt;R&gt;)

into the alternative partial html form

INVOKE<R> (in html: <i>INVOKE&lt;</i>R<i>&gt;</i>)

?

This change wouldn't change the semantic meaning, because neither
INVOKE nor INVOKE are C++ language constructs but plain symbolic
definitions and in fact it would presumably slightly improve the
clarity that this is just such a construction when it would be spelled
as

INVOKE<R> (in html: <i>INVOKE&lt;</i>R<i>&gt;</i>)

I should say that it is just my guess that this rewrite would also
solve the font-change-additional-space character problem, but maybe
you can give a better explanation for this artifact.

Thanks very much,

  • Daniel
@tkoeppe
Copy link
Contributor

tkoeppe commented Mar 3, 2017 via email

@tkoeppe
Copy link
Contributor

tkoeppe commented Mar 3, 2017

The problem also appears with DECAY_COPY. Maybe we should use \placeholdernc for all shouty pseudo-functions.

@zygoloid
Copy link
Member

zygoloid commented Mar 4, 2017

Yes, using \placeholdernc when the next character is punctuation seems to be an improvement. (I think itcorr is supposed to take care of that itself, but perhaps the font change is preventing that from firing?)

@jwakely
Copy link
Member

jwakely commented Mar 9, 2017

I don't like the appearance of INVOKE<R> when the angle brackets are in italics, this is the output of \tcode{\textit{INVOKE}<R>(f, t1, t2, ..., tN)}

display1

This is the output of \tcode{\placeholdernc{INVOKE}<R>(f, t1, t2, ..., tN)}

display1

And this is \tcode{\placeholdernc{INVOKE<}R\placeholdernc{>}(f, t1, t2, ..., tN)}

display1

I think the second one looks best, and searching for it works perfectly in Okular (which isn't true when \placeholdernc is not used).

@jwakely
Copy link
Member

jwakely commented Mar 9, 2017

I haven't changed the presentation of any INVOKEs in the branch for P0604R0, https://github.com/cplusplus/draft/tree/motions-2017-03-lwg-13

But I will create a pull request to change them all to use \placeholdernc after it's merged.

@tkoeppe
Copy link
Contributor

tkoeppe commented Mar 9, 2017

Second form, absolutely. When in doubt I recall Bringhurst's advice that it doesn't actually make sense to italicise punctuators, which usually results in the superior presentation.

@jwakely jwakely self-assigned this Mar 9, 2017
@Dani-Hub
Copy link
Member

Dani-Hub commented Mar 9, 2017 via email

@jwakely jwakely added this to the C++17 milestone Mar 15, 2017
tkoeppe added a commit that referenced this issue Mar 17, 2017
tkoeppe added a commit that referenced this issue Mar 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants