Request: add option to break the minus symbol asymmetrically

[typomaster2]

Would it be possible to add a new feature to the package rmathbr? Namely, currently expressions like a – b are broken up symmetrically, i.e. as a – on the previous line and – b on the new line.

• There is also the option to prohibit any breaking at the minus sign via [brokenminus=false].
• And it is possible to restore the break of the minus sign to its "usual" TeX behavior via \UnsetBrokenCmd{-}.

BUT there is currently no option to break a – b asymmetrically, with a – on the previous line and + b on the new line. (Or the other way around).

Q: Could this be option be added in the future? Perhaps something like [brokenminus=-+] for a – and + b, and [brokenminus=+-] for a + and – b would be good syntax.

[dryabov]

1. -+ is possible, but +- requires temporary switching to text mode (like it is done for changing \cdot to \times on break). The latter is quote complicated and may lead to some other issues.
2. It cannot be added to the current codebase easily, but there is a dirty hack you can use in preamble (not sure about compatibility with unicode-math package):

   \makeatletter
   \def\minus@char{\mathchar8704}
   \def\plus@char{\mathchar8235}
   \def\rmathbr@selector#1{%
   \def\x@char{#1}%
   \ifx\x@char\minus@char\def\x@char{\plus@char}\fi%
   \mathchoice
   {\discretionary{}{\hbox{$\m@th\displaystyle\x@char$}}{}}
   {\discretionary{}{\hbox{$\m@th\textstyle\x@char$}}{}}
   {\discretionary{}{\hbox{$\m@th\scriptstyle\x@char$}}{}}
   {\discretionary{}{\hbox{$\m@th\scriptscriptstyle\x@char$}}{}}%
   }
   \makeatother

[typomaster2]

Thank you for commenting, and for providing the dirty fix! Based on initial testing, the solution you provide works great.

• Luckily, I only needed –+; the reverse option was intended to help a potential somebody-else in the future.
• I use pdflatex, so unicode-math-issues also, fortunately, do not concern me personally.

As far as I am concerned, we may consider this issue resolved (closed). But if you should choose to keep the issue open because you plan to try to add it to the package codebase in the future, that's OK too. Thank you very much once more!