Skip to Content.
Sympa Menu

texmacs-users - Re: [TeXmacs] Inline v block context + Documentation of newer features and of the source editor?

Subject: mailing-list for TeXmacs Users

List archive

Re: [TeXmacs] Inline v block context + Documentation of newer features and of the source editor?


Chronological Thread 
  • From: Sam Liddicott <address@hidden>
  • To: Karl Hegbloom <address@hidden>
  • Cc: texmacs-users <address@hidden>
  • Subject: Re: [TeXmacs] Inline v block context + Documentation of newer features and of the source editor?
  • Date: Wed, 28 Sep 2016 10:39:01 +0100

Sorry for the delay in replying:

Here is an example. Note with it uses <merge> and <get-label> to avoid
an <if> clause which would make arguments inaccessible.

It gives a verbatim, which if not applied to a block (document) is
normal, but if applied to a block reduces the font size and removes
the paragraph separation.

The old-verbatim is a bit of a hack, I have not been successful in
duplicating tex's renew-command in texmacs yet.

<assign|old-verbatim|<value|verbatim>>

<assign|verbatim|<macro|x|<with|<merge|ov-|<get-label|<arg|x>>>|<macro|x|<old-verbatim|<arg|x>>>|ov-document|<macro|x|<with|par-par-sep|0fn|<small|<old-verbatim|<arg|x>>>>>|<compound|<merge|ov-|<get-label|<arg|x>>>|<arg|x>>>>>

Sam

On Mon, Sep 26, 2016 at 9:02 PM, Karl Hegbloom <address@hidden> wrote:
> Sam, do you recall which style files those are, to assist me in finding
> them? Are they part of the TeXmacs distribution?
>
> On Mon, Sep 26, 2016 at 11:50 AM Sam Liddicott <address@hidden> wrote:
>>
>> In the past I've done macros that behave differently depending if their
>> argument is document (block) or not.
>>
>> You probably need to do that
>>
>> Sam
>>
>>
>> On 22 Sep 2016 5:26 p.m., "Karl Hegbloom" <address@hidden> wrote:
>>>
>>> I was goofing around trying to create a \redact{} macro, and having
>>> trouble getting it to work right because the \phantom {} macro is inline
>>> and
>>> so when I try to wrap a block of text (where the text has a line break
>>> inside a paragraph) it gets turned into one long line. I want the \redact
>>> macro so that I can wrap things like people's names, social security
>>> numbers, telephone numbers, and home addresses with it in a legal filing,
>>> and then produce a redacted copy for more-public consumption.
>>>
>>> The \redact macro has a \with inside wrapping an \if so that a global
>>> setting can control whether \redact renders as text or as redacted text.
>>>
>>> I'm finding the source editor to be confusing because sometimes I think
>>> the macro needs to be line broken and indented, but other times it
>>> belongs
>>> all written in one line... Q: does writing the macro with a line break and
>>> indenting cause it to be block context? How can I control that? How can I,
>>> for example, cause the text inside the branches of an \if or \case to
>>> appear
>>> as block context content, fully line-broken?... or as inline content, if
>>> that's what I want? I could not get an \if to split like that.
>>>
>>> I found \repeat-through {}{} which uses \datoms {}{} to write /
>>> characters through each character of the tract inside of it, and it works
>>> for both inline and block text. It's great, but I can still read the
>>> text. I
>>> had been using a composition of \gnawed and \degraded font effects to
>>> achieve redaction. I want it to be unreadable but not solid black, since
>>> that wastes ink when printing. I also want the PDF produced when redaction
>>> is enabled to not carry the actual text (as internal strings that can be
>>> found with, e.g., grep or a text editor. When I tried to use those font
>>> effects within the \datoms, it slowed down TeXmacs to the point that it
>>> was
>>> unusable.
>>>
>>> So then I started experimenting with the items under the Insert -> Fold
>>> menu. I'm finding that those are not very well documented yet and I'm
>>> having
>>> a hard time figuring out how to use them. I think that the "it turns into
>>> one long line" problem happens no matter what I tried anyway.
>>>
>>> Also, I think there might be documentation files in the source repository
>>> that are not becoming part of the documentation available from the help
>>> menu. Are they out of date? Or forgotten due to other projects' higher
>>> precedence?



Archive powered by MHonArc 2.6.19.

Top of Page