Paste bracketing causes slow pastes - zsh

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"

Related

writing an output to a file in Gp Pari

I'm running a rather long computation on Gp Pari, and Pari crashed in the middle of the computation, effectively wasting a week of computation time. Before I run the program again, I would like to figure out a way write the outputs to a file as they are being computed so that if this happens again, I'll be able to start where the program left off instead of needing to start over.
With that said, I cannot for the life of me get Pari's read function to work properly. Every variation of the code
for(i=1,10, write("C:\Users\Jonathan Hales\Desktop\pari_data.txt",i))
just gives me the error
"write: error opening output file: `UsersJonathan HalesDesktoppari_data.txt'."
I can however use the metacommand
\w"C:\Users\Jonathan Hales\Desktop\pari_data.txt" and that will print the last output from pari to the document. I can't however use a metacommand in the middle of a for loop, defeating the purpose of writing it to a document in the first place.
Use a forward slash (/) rather than a back slash (\) to separate parts of the path. Backslash is the escape character, so you can also double it up.

Parsing strings with grep/str_extract

As part of my feature engineering, I need to parse text strings from different languages and keep text enclosed within parentheses. Everything was going well until I encountered a very strange phenomenon. For some languages, the parentheses I need to find look slightly different, and various regexp options fail.
I'm pasting screen-shots because strangely, copying and pasting the strange parentheses changes it to a 'normal' one, so I can't set up a different regex to find those separately.
Notice that the parentheses in the first entry look normal, but for the second entry, it appears sort of 'sharp'
If I use stringr's str_extract, the first instance works fine, but the second fails.
But, the encodings are the same. Anyone know what's going on?
[Edit: here are the results of dput on these same examples. dput apparently sees the parentheses as equivalent, even though grep does not]
c("Obnaružena poterâ šaga na (Motor šprica pipettora R1).", "(STAT tàn zhen Z zhóu ma dá) tàn cè dào diu bù<U+3002>")
Finally, I am actually copy and pasting the two parentheses from R into the code window below; they do appear different this way. First is normal, second is the strange one.
( (

Multiline prompt formatting incorrectly due to date command in zsh

I have the following in my .zshrc:
setopt PROMPT_SUBST
precmd(){
echo""
LEFT="$fg[cyan]$USERNAME#$HOST $fg[green]$PWD"
RIGHT="$fg[yellow]$(date +%I:%M\ %P)"
RIGHTWIDTH=$(($COLUMNS-${#LEFT}))
echo $LEFT${(l:$RIGHTWIDTH:)RIGHT}
}
PROMPT="$ "
This gives me the following screenshot
The time part on the right is always not going all the way to the edge of the terminal, even when resized. I think this is due to the $(date +%I:%M\ %P) Anyone know how to fix this?
EDIT: Zoomed in screenshot
While your idea is commendable, the problem you suffer from is that your LEFT and RIGHT contains ANSI escape sequences (for colors), which should be zero-width characters, but are nevertheless counted toward the length of a string if you naively use $#name, or ${(l:expr:)name}.
Also, as a matter of style, you're better off using Zsh's builtin prompt expansion, which wraps a lot of common things people may want to see in their prompts in short percent escape sequences. In particular, there are builtin sequences for colors, so you don't need to rely on nonstandard $fg[blah].
Below is an approximate of your prompt written in my preferred coding style... Not exactly, I made everything super verbose so as to be understandable (hopefully). The lengths of left and right preprompts are calculated after stripping the escape sequences for colors and performing prompt expansion, which gives the correct display length (I can't possibly whip that up in minutes; I ripped the expression off pure).
precmd(){
local preprompt_left="%F{cyan}%n#%m %F{green}%~"
local preprompt_right="%F{yellow}%D{%I:%M %p}%f"
local preprompt_left_length=${#${(S%%)preprompt_left//(\%([KF1]|)\{*\}|\%[Bbkf])}}
local preprompt_right_length=${#${(S%%)preprompt_right//(\%([KF1]|)\{*\}|\%[Bbkf])}}
local num_filler_spaces=$((COLUMNS - preprompt_left_length - preprompt_right_length))
print -Pr $'\n'"$preprompt_left${(l:$num_filler_spaces:)}$preprompt_right"
}
PROMPT="$ "
Edit: In some terminal emulators, printing exactly $COLUMN characters might wrap the line. In that case, replace the appropriate line with
local num_filler_spaces=$((COLUMNS - preprompt_left_length - preprompt_right_length - 1))
End of edit.
This is very customizable, because you can put almost anything in preprompt_left and preprompt_right and still get the correct lengths — just remember to use prompt escape sequence for zero width sequences, e.g., %F{}%f for colors, %B%b for bold, etc. Again, read the docs on prompt expansion: http://zsh.sourceforge.net/Doc/Release/Prompt-Expansion.html.
Note: You might notice that %D{%I:%M %p} expands to things like 11:35 PM. That's because I would like to use %P to get pm, but not every implementation of strftime supports %P. Worst case scenario: if you really want lowercase but %P is not supported, use your original command subsitution $(date +'%I:%M %P').
Also, I'm using %~ instead of %/, so you'll get ~/Desktop instead of /c/Users/johndoe/Desktop. Some like it, some don't. However, as I said, this is easily customizable.

How do I avoid this while printing to screen?

When I do a printk with "bad" characters, sometimes I scrambles my screen,
Is this unavoidable when printing them?
Type reset and Enter on your command line to get it fixed again. If you don't see it anymore, you might have to type it blindly, but it works often.
Depending on how you set up your environment, there are characters that can't be printed without messing up your command line.
You can try to print hex values %x. Like this it is usually much easier to find a logic behind the data.

Why is a % symbol appearing in my standard output?

Sometimes I echo a string to the standard output (I see it at the Kubuntu console) and a trailing % symbol gets appended with it's colors inverted (black text on white background).
I can't find any accidental additional character (or half-baked-UTF8 or anything) in the string I'm printing. The character seems to get added when the program finishes.
I'm using Go (golang) right now, but I've already seen this in the past, and I think I was using PHP back then.
What could be causing this?
what shell are you using? sounds like what happens in zsh when there is no carriage return at the end of your output

Resources