Braced material is kinda broken about hardwrap HOT 5 CLOSED

What are our options? Remove the braces (pretend like they don't exist) versus use the braces as treat-this-as-one-word markers versus ...?

Between those two choices, I think the former is better as it's likely to improve the readability of the log file. (And my primary goal, at least, is to improve the readability of the messages in my log file.)

from hardwrap.

My vague thinking is that

• Probably need a "keep on one line" command, but braces aren't the best way to do that

• I think that if you're inserting braces into messages, you probably want them to be printed, so we could add

  \HardWrapBraceOpen
  \HardWrapBraceClose
  

  which are inserted when braces are found and then if you want them to disappear you can just redefine these in \HardWrapSetup.

What do you think?

from hardwrap.

It'd be nice if the tie (~) worked as a nonbreakable space to keep words together. For keeping longer strings of text on one line we could offer something akin to \nobreak{blah blah blah}.

It may be difficult to determine the user's intent when it comes to inserting braces in the message. What should the output of the following lines of text be?

Hello {a b} world!
Hello \textit{a b} world!
Hello \abc world!  [where \def\abc{123 {45} 67 {{8}} 9}]

I think the more general problem is: where on the spectrum of fully-expanded vs. verbatim do we want to sit?

from hardwrap.

I need to document how this all works a little better (I kinda got started the other day). The steps involved in the processing are:

1. Fully expand everything with \edef. This replaces things like \\ and so on with their "protected" equivalents and is where the replacements for \emph and so on happen
2. Scan char-by-char and replace/interpret "protected" characters appropriately
3. Fully expand everything again to insert the proper definitions for "newline" etc

What we're currently saying is that any commands that are "protected" will be printed in a verbatim-like way, but otherwise commands are fully expanded. Braces are a bit of an edge case, and I think it's sensible to process them as if they should be printed — if they're used to delimit arguments of a command then they'll be absorbed in step 1.

Not sure if this makes sense but when I implement this we can discuss if it's behaving in a sensible/expected manner :)

from hardwrap.

print lone braces

(you can still use them as arguments for commands)

let me know if you think this needs more work...

closed by 20de5eb

from hardwrap.