We recently changed our project boilerplates for using single quotes to using backticks. Working with backticks in *Storm on OSX is not as convenient as working with single quotes, thus we tried to come up with some solutions which still lack some convenience. We're looking for further ideas to find better solutions now.
How single quotes work in *Storm on OSX
typing one single quote results in two single quotes with the cursor in between ('|')
typing afterwards results in text between the single quotes ('what has been typed')
if 'surround selection on typing quote or brace' is true, selecting some text and typing a single quote results in
the text being wrapped in single quotes ('some text')
How backticks work in *Storm on OSX
typing one backtick results in one backtick (`), when pressing space you get two backticks with the cursor in between (`|`)
when typing a letter, you get two backticks with the cursor in between (`|`) except if the letter is a, e, o, u, i, then you'll get (à, è, ò, ù, ì) which is quite disturbing
when pressing space, you get two backticks with the cursor in between (`|`)
selecting some text and typing a backtick results in a backtick (`), which is also not what we'd like to have
Since a backtick is a dead key by default, I am struggled with the same issue.
Live Template
Currently I created a live template named it -- (double-dash) for a quick which prepares a backtick-surrounded string. Below you can find the settings I used for the template:
Abbreviation: --
Description: Backticks
Template text:
`$0$`$END$
Apply: JavaScript
Unfortunately PHPStorm/Webstorm does not provide a way to toggle the quote style. Similar to the case toggler (Edit -> Toggle Case)
Concerning the typing
Just use keystrokes <backtick> + <space>and type a text and you'll get `a text`.
Concerning surrounding
Create a Live Template called backticks with a content of `$SELECTION$`$END$, set the context to Javascript. Go to the keymap and search for 'Surround with Live Template'. Assign a key combination. Go back to the editor, select some text, press the just assigned
combination and press 'ENTER' to confirm selecting your 'backticks' template. This will wrap your text in backticks.
Related
I usually press alt + , to insert <, it works fine in my zsh terminal and on every other application, but unfortunatly not on vim or neovim.
I tried following but nothing worked:
map <M-,> "<"
map <M-,>='<'
I appreciate any help
Everything is wrong, here.
First, you can't expect any of those mappings to do anything in insert mode because the :map command creates mappings for normal, visual, and operator-pending modes, not for insert mode. The first thing to change is thus to use the proper :map variant:
imap <M-,> "<"
imap <M-,>='<'
Second, the left-hand side of a mapping (the keys you want to press) and the right-hand side (what you want Vim to press instead) are supposed to be separated by whitespace so your second example wouldn't produce a mapping to begin with. It asks Vim to list insert mode mappings that contain <M-,>='<', which is pointless.
Third, the right-hand side of a mapping is a macro, where every character is used as if you typed it. "<" would literally insert a double quote, an angle bracket, and a double quote. If you want the mapping to insert a <, use a <:
imap <M-,> <
Fourth, I've heard that Neovim handles the Meta/Alt key better than Vim so the mapping above is still likely to be problematic in Vim, depending on the OS or the keyboard layout. For example, in Vim on macOS with the AZERTY layout, the system translates Alt+, to ∞ before it even reaches Vim so <M- and <A- mappings simply don't work reliably.
I found image literals to be rather distracting than useful.
Is there any way to disable this Xcode feature?
A good method for this is to replace all occurrences of #imageLiteral with UIImage(imageLiteralResourceName:) initializers (thanks for the suggestion, #D6mi!). Here's how you can do it automatically:
Navigate to Find/Find and Replace... (or press ⌥⌘F).
Open the dropdown list on the right side and select Regular Expression.
For the search term, enter the following regex:
#imageLiteral\(resourceName: (.*)\)
For the replacement, enter this:
UIImage(imageLiteralResourceName: $1)
This regular expression captures the value of the resource name with (.*) and inserts it again with $1. The backslashes are for escaping the parentheses, since they count as special characters.
Note that you don't have to use regular expression in this case (as LinusGeffarth pointed out), but it can be more useful in more complex cases than this.
I have been using nano to write a bash script and I am at several times indenting various lines at once with Alt + }. The problem is that the following occurs:
Several lines without text in them get white-spaces by the amount that I indent the text and they are coloured green. They don't affect the program but they make it look bad. I have been deleting them one by one but it gets frustrating over time. Is there a way to get rid of all the white-spaces at once? maybe some way to select the text (short cut for selecting text in nano is Alt + a) and have a short cut do it?
Use global search and replace with the expression ^\s+$.
Switch to search and replace mode with C-\.
Switch to regex mode with Alt-R.
Type the expression ^\s+$.
Hit Enter to replace with an empty string.
On the match, hit A for All.
I am creating a custom code highlight for notepad++. What I want to do is the following:
some fieldnames are writen in the code with a ' in front of their name, for exampe
if 'variable = "test" then ...
I would like to highlight these words, but notepad++ does not seem to allow a delimiter starting with ' and ending with a space, not does it allow space as an escape character. Also, using ' as a keyword and enabling prefix mode has no effect. Anyone has a suggestion? Should I use another expression to let notepad recognise the space/' ?
Thanks in advance!
If you only need to highlight a single word, you can use a keyword in prefix mode. However when using single or double quotes in a keyword, they need to be escaped with a backslash. So your keyword would be:
\'
This may not be possible in notepad++. I can get the behavior you want using a character other than a single quote, like a back-tic, but it doesn't seem to work with single or double quotes. I suspect those characters are treated special within the syntax highlighter.
I have a specific method for my bash prompt, let's say it looks like this:
CHAR="༇ "
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
To explain the above, I'm builidng my bash prompt by executing a function stored in a string, which was a decision made as the result of this question. Let's pretend like it works fine, because it does, except when unicode characters get involved
I am trying to find the proper way to escape a unicode character, because right now it messes with the bash line length. An easy way to test if it's broken is to type a long command, execute it, press CTRL-R and type to find it, and then pressing CTRL-A CTRL-E to jump to the beginning / end of the line. If the text gets garbled then it's not working.
I have tried several things to properly escape the unicode character in the function string, but nothing seems to be working.
Special characters like this work:
COLOR_BLUE=$(tput sgr0 && tput setaf 6)
my_function="
prompt="\\[\$COLOR_BLUE\\] \"
echo -e \$prompt"
Which is the main reason I made the prompt a function string. That escape sequence does NOT mess with the line length, it's just the unicode character.
The \[...\] sequence says to ignore this part of the string completely, which is useful when your prompt contains a zero-length sequence, such as a control sequence which changes the text color or the title bar, say. But in this case, you are printing a character, so the length of it is not zero. Perhaps you could work around this by, say, using a no-op escape sequence to fool Bash into calculating the correct line length, but it sounds like that way lies madness.
The correct solution would be for the line length calculations in Bash to correctly grok UTF-8 (or whichever Unicode encoding it is that you are using). Uhm, have you tried without the \[...\] sequence?
Edit: The following implements the solution I propose in the comments below. The cursor position is saved, then two spaces are printed, outside of \[...\], then the cursor position is restored, and the Unicode character is printed on top of the two spaces. This assumes a fixed font width, with double width for the Unicode character.
PS1='\['"`tput sc`"'\] \['"`tput rc`"'༇ \] \$ '
At least in the OSX Terminal, Bash 3.2.17(1)-release, this passes cursory [sic] testing.
In the interest of transparency and legibility, I have ignored the requirement to have the prompt's functionality inside a function, and the color coding; this just changes the prompt to the character, space, dollar prompt, space. Adapt to suit your somewhat more complex needs.
#tripleee wins it, posting the final solution here because it's a pain to post code in comments:
CHAR="༇"
my_function="
prompt=\" \\[`tput sc`\\] \\[`tput rc`\\]\\[\$CHAR\\] \"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
The trick as pointed out in #tripleee's link is the use of the commands tput sc and tput rc which save and then restore the cursor position. The code is effectively saving the cursor position, printing two spaces for width, restoring the cursor position to before the spaces, then printing the special character so that the width of the line is from the two spaces, not the character.
(Not the answer to your problem, but some pointers and general experience related to your issue.)
I see the behaviour you describe about cmd-line editing (Ctrl-R, ... Cntrl-A Ctrl-E ...) all the time, even without unicode chars.
At one work-site, I spent the time to figure out the diff between the terminals interpretation of the TERM setting VS the TERM definition used by the OS (well, stty I suppose).
NOW, when I have this problem, I escape out of my current attempt to edit the line, bring the line up again, and then immediately go to the 'vi' mode, which opens the vi editor. (press just the 'v' char, right?). All the ease of use of a full-fledged session of vi; why go with less ;-)?
Looking again at your problem description, when you say
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
That is just a string definition, right? and I'm assuming your simplifying the problem definition by assuming this is the output of your my_function. It seems very likely in the steps of creating the function definition, calling the function AND using the values returned are a lot of opportunities for shell-quoting to not work the way you want it to.
If you edit your question to include the my_function definition, and its complete use (reducing your function to just what is causing the problem), it may be easier for others to help with this too. Finally, do you use set -vx regularly? It can help show how/wnen/what of variable expansions, you may find something there.
Failing all of those, look at Orielly termcap & terminfo. You may need to look at the man page for your local systems stty and related cmds AND you may do well to look for user groups specific to you Linux system (I'm assuming you use a Linux variant).
I hope this helps.