Xmonad paste special character \x00f6 with pasteString? - haskell

When using Xmonad.Util.Paste I'm trying to paste a ö character with pasteString but nothing appears. How can I paste this character?
I tried to use:
, ((mod4Mask , xK_o ), pasteString "ö")
But this gave me a compilation error (which I expected): lexical error in string/character literal (UTF-8 decoding error) So I looked up the corresponding escape sequence here and tried the following line:
, ((mod4Mask , xK_o ), pasteString "\x00f6")
This compiled fine but when pressing the key combination nothing seems to appear (I tried it with a regular string and it worked fine, also pasteSelection works like intended). What am I doing wrong?
On a side note: I also tried \x00F6 but it didn't make any difference. Also I'm using ghc version 7.8.4.
Update 1:
I found this cheatsheet for haskell, so I tried the string \xC\&4 which results in ,4. When only using \&4 it results in 4 and when using \x2C it prints ,.
Update 2:
It seems like XMonad.Util.Paste doesn't work with Umlauts at all, as mentioned the function pasteSelection works. But when selecting an ö character it doesn't. So I guess I need to use xdotool or something similar.
Your help would be appreciated a lot, thanks for looking at this issue!

pasteString maps pasteChar over each char in the string; pasteChar, in turn, have trouble with non-ASCII characters, which is stated in the comments to the source code:
Note that this function makes use of 'stringToKeysym', and so will probably have trouble with any 'Char' outside ASCII.
In light of that, I suggest setting up an X Compose key, where you can type "ö" with Compose o ".

Related

Exact strings do not match in Jupyter Notebook

What did I want to do?
I was reading file names with various organ names in their file endings and there are many such files using glob.glob('filename/**/blabla')
Later, I tried to match a particular string if present inside the filename using IN operator. like
"ADRENALGLAND(LEFT).NRRD" IN "blabla/blabla/blabla/blablabla_ADRENALGLAND(LEFT).NRRD"
It worked for other filenames with the same ending whereas it did not work for a few.
To debug, I was trying to match if visually the same filename endings from two files are the same programmatically, but they are not!!! why?
For debug, I tried to match string to string. Like below. But I saw a peculiar thing while comparing strings in python.
Can anyone tell me what is the difference here?
**
'ADRENALGLAND(LEFT).NRRD' == 'АDRENALGLAND(LEFT).NRRD' => False !!!
**
I bring it down to this part where 'A's do not match whereas others matched properly.
As mentioned by #canbax, I checked the underline ASCII value for both the character and found that they are different. One gave 65 (Normal ASCII Code for English Alphabet 'A') whereas the other one gave 1040.
You can use ord() to get the ASCII int value of a character.
Although the int values are different, visually they look the same, which might be an issue from the jupyter notebook side.
Final Solution: Replaced the fancy A with the normal A in the file.

Why is this comma mapping not working for me in GVim?

I want to use the comma key as a leader for shortcuts, so I tried to map the original , functionality to ,, with this line:
noremap ,, ,
It worked fine in terminal, but in GVim it just gives off a warning sound and nothing happens. Why does this happen and how can I fix it?
EDIT: I also tried mapping other keys to , but they didn't work either (same outcome, giving off an alert sound). The only way I can get the , function to work now is to press , once and then wait. Does anybody have some idea what could possibly be the reason it is not working for me?
So I found out why it is not working and I'll post it as an answer here. Basically, it was because I had the plugin fanfingtastic which replaced the original comma to an enhanced one, so the correct mapping for me should be:
map ,, <Plug>fanfingtastic_,

Is it possible to change the way Maxima generates LaTeX code?

I would like to be able to change the way Maxima generates the LaTeX code (in general). For example, I have the following code in Maxima:
I then exported the code to LaTeX, and I immediately get an error saying:
! Package inputenc Error: Unicode char \u8:− not set up for use with LaTeX.
See the inputenc package documentation for explanation.
Type H <return> for immediate help.
You can check out the LaTeX code generated through this gist on GitHub.
I would like at least not only to not get any errors, but also to change a little bit the style of the LaTeX code generation to adapt it to certain circumstances. For example, I would like to be able to insert a break line (or more) after the outputs...
Is it possible to do? Are there any alternatives?
You can put the following line in the preamble of the LaTeX output:
\DeclareUnicodeCharacter{2212}{-}
which tells LaTeX what to do with the Unicode hyphen (character 2212 according to this table).
WxMaxima should generate this declaration itself -- it is a bug that it does not.
Most likely something happened when you exported the code. To fix the existing file you can follow the accepted answer to this question.
https://tex.stackexchange.com/questions/83440/inputenc-error-unicode-char-u8-not-set-up-for-use-with-latex
But try exporting again and see if the error was accidental.
Update:
Add
\DeclareUnicodeCharacter{00A0}{ }
to your preamble.
Well, the gistfile1.txt at line 54 contains − characters instead of -. I wonder how those characters were generated. What commands did you enter in wxMaxima to generate gistfile1.txt?
Anyway, I find that if I replace those characters with ordinary hyphens, it avoids the error you reported. So perhaps the problem is to avoid generating those characters in the first place.
EDIT: This answer is off the mark. See my other answer for a real solution.

In Vim, how to substitute text with combining characters?

In Vim, for text é,e (\x65 \u0301 \x2c \x65):
If I use :s/\Ze/x/g, I get x,x. How to get x́,x?
If I use :s/́/̂/g (substitue \u0301 with \u0302), I get ̂,e. How to get ê,e?
If you have vim compiled with perl support, you can try this:
:perldo s/e/x/g
:perldo s/́/̂/g
This works for me in case that the ́ sign should have been above the , sign which is what I got when used the sequence you provided. Similarly, I get the ̂ sign above the , sign in the result of second command. But I still guess this is what you want as I was getting same copy-paste errors when compiling the answer.

How to type ASCII 145/146 (quotes) in vim?

Using vim 7.2.330 on a Ubuntu host from an XP host, I'm stuck at how to type/paste the following line in a text file:
include_once(‘/full/path/to/app’);
The document says it's important to use ASCII 145 and 146, but vim turns them into "<92><93>", and Nano turns them into �.
Note that I'm using a European keyboard layout, not the US layout.
Does someone know how to solve this?
Thank you.
Er, you should not be using the 2 types of special quotes for string quoting in PHP.
You should be typing
include_once('/full/path/to/app');
( That's ASCII character 39 )
This is not what it says at the end of
this document:
www.wpbbpthemes.org/integration/
"beware some pasting of this code make
the ‘ character change, make sure it’s
the button left of the enter key on
your [US] keyboard"
No, you are misinterpreting it. Lots of software in windows, and varying keyboards, erroneously do "smart quotes". Word and Internet Explorer are such examples. As a result, copy-pasting from these applications results in the wrong type of character in your source code, often conflicting with the content-encoding the document is served as, which renders on the displaying browser as a silly Ä or similar character.
Do not use characters 145 and 146 in your PHP source, it is not necessary, and it won't work.
Also, Important to note, the authors of that page have USED THE WRONG QUOTES IN THEIR EXAMPLES and as such, WILL NOT WORK AS STATED.
Their statement with regard to "beware some pasting will make the character change" is bogusly incorrect, they have the incorrect character in their source, and as such, copy-pasting it at any time will not work.

Resources