ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>,
	Rik Kabel <context@rik.users.panix.com>
Subject: Re: Labels and Enumerations
Date: Mon, 15 Jan 2018 09:09:18 +0100	[thread overview]
Message-ID: <fb9e8e91-b6b4-0d6d-f8b0-c7f5bc8581aa@wxs.nl> (raw)
In-Reply-To: <ad1195fa-eded-e3a0-1659-685ab0292ff2@rik.users.panix.com>

On 1/14/2018 9:37 PM, Rik Kabel wrote:
> On 2018-01-14 09:46, Hans Hagen wrote:
>> On 1/13/2018 10:17 PM, Rik Kabel wrote:
>>> I would like to request the restoration of labels (\definelabel) to 
>>> full citizenship in MKIV. While enumerations are more flexible in 
>>> many ways, they cannot replace one particular use of labels if find 
>>> necessary. Enumerations are paragraph entities, while labels are not 
>>> so restricted.
>>>
>>> I use labels displayed as numbers in the margin to serially identify 
>>> quotations in a book about the development of quotation and 
>>> misquotation, at the same time generating reference information for 
>>> cross-referencing. While most quotations are blocks and can be 
>>> handled by enumerations, many are in-line quotations, and enumeration 
>>> cannot be used for these.
>>>
>>> The wiki describes enumerations as the MKIV replacement for labels, 
>>> and the documentation as far as I can see omits \definelabel. Unless 
>>> there is something else supported in MKIV that can assume this 
>>> function of labels, can we please have full support for labels? I 
>>> would not want to see labels deprecated before the functionality is 
>>> reproduced.
>>>
>>> (Of course, if you can suggest how enumeration can be adapted to this 
>>> requirement, or suggest an alternative mechanism, this request can be 
>>> rejected.)
>>
>> two options:
>>
>> \defineconstructionalternative
>>   [mylabel]
>>   [renderingsetup=constructionrenderings:mylabel,
>>    width=]
>>
>> \startsetups[constructionrenderings:mylabel]
>>     \dontleavehmode
>>     \flushconstructionheadbox
>> \stopsetups
>>
>> \defineenumeration[two][alternative=mylabel,display=no,before=,after=]
>>
>> \definelabel[foo][way=bychapter,prefix=chapter]
>>
>> \starttext
>>
>>     \startchapter[title=bar]
>>
>>         here \starttwo\stoptwo \input tufte
>>
>>         here \foo[xx] \input tufte
>>
>>         whatever \in{foo}[xx]
>>
>>     \stopchapter
>>
>> \stoptext
> 
> I played a bit more with enumerations and resolved one issue, I think. 
> The forced paragraph break is a feature of the default before/after keys 
> (both of which I need to null). Once this is done, enumerations can be 
> used for in-line text as well, and when an explicit \par is added to 
> \footnotes, the enumeration index appears there, unlike labels, where it 
> does not appear.

use

\startsetups[constructionrenderings:mylabel]
     \dontleavehmode
     \inright[scope=local]{\flushconstructionheadbox}
\stopsetups

also, an enumeration wants a paragraph as it needs to handle the 
following text an danythign between \whatever and the next \par (or 
emptyline) becomes that text so for the footnote it sees the end outside 
a group / argument

> Can you explain why the enumeration defined with constructionalternative 
> rendering fails in footnotes, as shown in the following example? I 
> suspect it has to do with my not understanding the use of 
> \flushconstructionheadbox.
> 
>     \defineconstructionalternative
>        [mylabel]
>        [renderingsetup=constructionrenderings:mylabel,
>         width=]
> 
>     \startsetups[constructionrenderings:mylabel]
>          \inright{\dontleavehmode\flushconstructionheadbox}
>     \stopsetups
> 
>     \defineenumeration[two][alternative=mylabel, % use mylabel rendering
>                              headcolor=darkgreen,
>                              text=,               % no name preceding
>     label number
>                              display=no,          % suppresses line
>     break with constructs
>                              before=,             % no added text before
>     label number
>                              after=]              % no added text after
>     label number
> 
>     \defineenumeration[why][alternative=inright, % use inright rendering
>                              headcolor=blue,
>                              display=yes,         % seems to be the default
>                              text=,               % no name preceding
>     label number
>                              before=,             % no added text before
>     label number
>                              after=]              % no added text after
>     label number
> 
>     \definelabel[foo][text=,headcolor=red,alternative=inright]
> 
>     \starttext
> 
>              \startchapter[title=bar]
> 
>              here \starttwo[reference=aa]\stoptwo \input ward
>     \starttwo[reference=bb]\stoptwo \input ward
> 
>              here as well?\footnote{\starttwo[reference=cc]\stoptwo This
>     fails.\par}
> 
>              whatever \in{two}[aa] and \in{two}[bb] and \in{two}[cc]
> 
>              \blank
> 
>              here \two[dd]\input ward \two[ee]\input ward
> 
>              here as well?\footnote{\two[ff]This fails.\par}
> 
>              whatever \in{two}[dd] and \in{two}[ee] and \in{two}[ff] and why
>              is this section not three paragraph?
> 
>              \blank
> 
>              here \why[gg]\input ward \why[hh] \input ward
> 
>              here as well?\footnote{\why[ii]This works!\par}
> 
>              whatever \in{why}[gg] and \in{why}[hh] and \in{why}[ii]
> 
>              \blank
> 
>              here \foo[xx] \input ward \foo[yy] \input ward
> 
>              here as well?\footnote{\foo[zz]This fails.}
> 
>              whatever \in{foo}[xx] and \in{foo}[yy] and \in{foo}[zz]
> 
>          \stopchapter
> 
> 
>     \stoptext
> 
> Could you explain the display key. The best I could determine from 
> strc-con.mkvi is that if it is not 'no' in a construction, a \par is 
> inserted, although I do not see why it is required in one case, and the 
> other in my example above.
> 
> Could you also explain why \par is required in the footnotes when it 
> does not seem to be needed in footnotes for any other use?
> 
> -- 
> Rik
> 
> 
> 
> ___________________________________________________________________________________
> If your question is of interest to others as well, please add an entry to the Wiki!
> 
> maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________
> 


-- 

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

  parent reply	other threads:[~2018-01-15  8:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-13 21:17 Rik Kabel
2018-01-13 22:14 ` Alan Braslau
2018-01-14 14:46 ` Hans Hagen
2018-01-14 20:37   ` Rik Kabel
2018-01-15  1:59     ` Rik Kabel
2018-01-15  8:09     ` Hans Hagen [this message]
2018-01-15 21:15       ` Rik Kabel
2018-01-16  8:21         ` Hans Hagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb9e8e91-b6b4-0d6d-f8b0-c7f5bc8581aa@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=context@rik.users.panix.com \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).