Box-drawing characters aren't aligned in Xmobar - utf

I've created a little Xmobar status indicator for https://complice.co. Inspired by the agnoster Zsh theme, I used some box-drawing characters to try to put triangle-like ends on the end of the status bar. But they aren't aligning correctly, as shown here:
The triangle is too small, leaving a lip at the bottom. It annoys me that it's not pixel-perfect. Does anyone have any insight into why it isn't sized correctly? I've never used box-drawing characters and couldn't find any documentation on the specific ones I'm using (\ue0b2 and \ue0b0) - any links would be appreciated.
I use a script to generate the text. The important part is here where I use the box-drawing characters: https://github.com/d4hines/beth/blob/master/scripts/complice#L38
And the Xmobar config: https://github.com/d4hines/beth/blob/master/flake.nix#L249-L265

Related

How to preserve white space at the start of a line in .Rd documentation?

I need to indent some math stuff in the \details section of my .Rd documentation to enhance its readability. I am using mathjaxr. Is there any way to indent without installing roxygen2 or similar?
The math stuff is inline, so simply setting to display using \mjdeqn won't solve this.
I seem to have a reasonable "cheating" work around for indenting the first line using mathjaxr, at least for the PDF and HTML output.
We need to do two things:
Use the mathjax/LaTeX phantom command. phantom works by making a box of the size necessary to type-set whatever its argument is, but without actually type-setting anything in the box. For my purposes, if I want to indent, say, about 2 characters wide, I would start the line with a \mjeqn{\phantom{22}}{ } and following with my actual text, possibly including actual mathy bits. If I want an indent of, say, roughly 4 characters wide, I might use \mjeqn{\phantom{2222}}{ }.
Because mathjaxr has a problem with tacking on unsolicited new lines when starting a line with mjeqn, we need to prefix the use of phantom in 1 above with an empty bit of something non-mathjaxr-ish like \emph{}.
Putting it all together, I can indent by about 2 characters using something like this:
\emph{}\mjeqn{\phantom{22}}Here beginneth mine indented line…
I need to explore whether the { } business actually indents for ASCII output, or whether I might accomplish that using or some such.

Paste bracketing causes slow pastes

When I paste in large blocks of text, or even just long commands or urls, pasting is done character by character and takes a long time. I can make it speed up by pressing right arrow but that sometimes autosuggest will then come in and paste other things.
I know this is caused in part by paste bracketing. I tried turning it off which makes it about the speed it goes when I press right arrow during a slow paste. But then indents aren't preserved and it executes line by line. This doesn't work for me since I regularly paste in multiline commands like with Docker for example. Also, syntax highlighting doesn't work anymore when using the right arrow technique.
Is there a way to make pasting instant but preserve the bracketing behavior? In vim it's instant but I guess indents are just newline characters or something I guess? Is bracketing even causing this problem or is there some other explanation/fix?
I'm using iTerm2 with ohmyzsh and Powerlevel10k on MacOS Catalina. Searched high and low but only found posts about the ~0 and ~1 characters being inserted with bracketing or something. I never had that happen.
A gif for illustration purposes:
https://i.imgur.com/vFL0gmL.mp4
Just disable magic functions in .zsh.
Uncoment DISABLE_MAGIC_FUNCTIONS="true"

How to represent markdown properly with escaping and line breaks?

I'm currently trying to build a chat app, using the official markdown package as well as underscore's escape function, and my template contains something like this:
<span class="message-content">
{{#markdown}}{{text}}{{/markdown}}
</span>
When I grab the text from the chat input box, I try to escape any HTML and then add in line breaks. safeText is then inserted into the database and displayed in the above template.
rawText = $("#chat-input-textbox").val();
safeText = _.escape(rawText).replace(/(?:\r\n|\r|\n)/g, '\n');
The normal stuff like headings, italics, and bold looks okay. However, there are two major problems:
Code escape issue - With the following input:
<script>alert("test")</script>
```
alert('hello');
```
This is _italics_!
Everything looks fine, except the alert('hello'); has become alert('hello'); instead. The <pre> blocks aren't rendering the escaped characters, which makes sense. But the problem is, the underscore JS escape function escapes everything.
SOLVED: Line break Issue - With the following input:
first
second
third
I get first second third being displayed with no line breaks. I understand this could be a markdown thing. Since I believe you need an empty line between paragraphs to get linebreaks in markdown. But having the above behaviour would be the most ideal, anyone know how to do this?
UPDATE Line break issue has been solved by adding an extra \n to my regex. So now I'm making sure that any line break will be represented with at least two \n characters (i.e. \n\n).
You should check the showdown docs and the wiki article they have on the topic.
The marked npm package, which is used by Telescope removes disallowed-tags. These include <script> of course. As the article I linked to above explains, there's still another problem with this:
<a href='javascript:alert("kidding! Im more the world domination kinda guy. Muhahahah")'>
click me for world peace!
</a>
Which isn't prevented by marked. I'd follow the advice of the author and use a HTML sanitation library. Like OWASP's ESAPI or Caja's html-sanitizer. Both of these project's seem outdated dough. I also found a showdown extension for it called showdown-xss-filter. So my advice is to write your own helper, and use showdown-xss-filter.

How to turn off word wrap in iTerm2?

How to turn off word wrap in iTerm2? Is there a specific command to do so or in the preferences? I am trying to avoid having the text run down to the next line. I would rather scroll side to side.
lifted directly from https://apple.stackexchange.com/a/210666/115119
Props to #michid
Disable line wrapping:
tput rmam
Enable line wrapping:
tput smam
It appears that iTerm2 does not have the ability to turn off word wrap. There is an open issue (iTerm2 issue #1790) reported to "Provide toggle to turn on/off line wrapping".
The description of that issue reads:
Looks like a conversation was had in the Google Groups about this but no one ever actually filed a feature request.
http://groups.google.com/group/iterm2-discuss/browse_thread/thread/e0f4e9b552d8acd4
In general I don't like having horizontal scrollbars and prefer to have the lines wrap, but there are occasions...such as looking at long stack traces, that I'd rather just have sequentially indented lines line up and just be forced to scroll to the right to expose all the details. To accomplish this task now, I end up making the text incredibly small so I can read stack traces lined up, but even that doesn't always work.
In October, 2014, the creator of iTerm2 commented regarding the feature request to toggle word wrap, "I'd like to do this but it's a lot of work, so feel free to send a pull request, but don't be [a jerk]."
In April, 2015, the milestone for the feature request was changed to "Future Release".
For me, my issue was purely down to the configuration of my PS1 - not what I had originally expected!
The key for me was surrounding the following with any characters that wouldn't be printed as in your prompt - such as encoding colours. Sourced from https://linoxide.com/how-tos/change-bash-prompt-variable-ps1/
\[ This sequence should appear before a sequence of characters that don’t move the cursor (like color escape sequences). This allows bash to calculate word wrapping correctly.
\] This sequence should appear after a sequence of non-printing characters.

How to fix prettytable to display chinese character properly

from prettytable import PrettyTable
header="乘客姓名,性别,出生日期".split(",")
x = PrettyTable(header)
x.align["乘客姓名"]="l"
table='''HuangTianhui,男,1948/05/28
姜翠云,女,1952/03/27
李红晶,女,1994/12/09
LuiChing,女,1969/08/02
宋飞飞,男,1982/03/01
唐旭东,男,1983/08/03
YangJiabao,女,1988/08/25
买买提江·阿布拉,男,1979/07/10
安文兰,女,1949/10/20
胡偲婠(婴儿),女,2011/02/25
(有待确定姓名),男,1985/07/20
'''
data=[row for row in table.split("\n") if row]
for row in data:
x.add_row(row.strip().split(","))
print(x)
What I want the output format is as the following.
In this example, prettytable.py can not display properly chinese ambiguous width of character · in 买买提江·阿布拉 , the character has ambiguous width. How to fix the bug in prettytable.py?
I have add two lines in def _char_block_width(char) of prettytable.py, but the problem still remains.
if char == 0xb7:
return 2
I have solved it, the file prettytable.py should be installed in my computer d:\python33\Lib\site-packagesdirectly not in as the form of d:\python33\Lib\site-packages\prettytable\prettytable.py
There are many chinese character with ambiguous width, it is stupid for us to add two lines such as the following to fix the bug, if there are 50 ambiguous character,100 lines will be added in the prettytable.py, is there a simple way to do that? Just fix some lines to treat all the ambiguous character?
if char == 0xb7:
return 2
The issue you're running into has to do with the dot character in the incorrectly padded line of your Python output. The dot is Unicode code point U+00B7 · middle dot. This character is considered to have an "ambiguous" width, as it is a narrow character in most non-East-Asian fonts, but is rendered a full-width in most Asian ones. Without context, a program can't tell how wide it will appear on the screen. Unfortunately, Python's Unicode system doesn't appear to have any way to provide that context.
One fix might be to replace the offending dot with one that has an unambiguous width, such as U+30FB katakana middle dot (which is always full width). This way the padding logic will be able to recognize that extra space is needed for that line.
Another solution could be to set your console to use a font with more Western treatment of the middle dot character, rather than the current one that follows the East-Asian style of rendering of it as full-width. This will mean that the existing padding is correct. Your output from R clearly uses a different font that the Python output does, and its font renders the dot as half-width.

Resources