I often use Greek letters in my calculations. Is there any way, to replace all occurrences of say ø with µ? From a computational/mathematical standpoint, it makes no difference what the variable name is. But sometimes, we are conditioned to use certain variables and become used to them. So if I happen to use an odd variable and need to share my notebook with a colleague, I'd like to change the variable before sending it. Is there an efficient way to search and replace Greek letters in mma?
Using Mathematica 7 or later, you can use the "Find" dialog to do this. Type \[Phi] as the search string and \[Mu] as the replacement string. This may also work in Mathematica 6 or earlier, but I don't have those versions at hand at the moment to try it.
See the "Listing of Named Characters" in the Mathematica help for the escape codes that you can use.
The find and replace dialog should work for this.
Assuming version 8, you can either use long names (\[OSlash]) to input the names, or shortcuts (shift-esc o / shift-esc).
(shift-esc being necessary because plain old esc in the find dialog will dismiss the dialog.)
In earlier versions the long name method should work. (The long name won't collapse into the character, but after finding/replacing it's all fine.)
In mma7, one possibility that is sometimes handy is Use Selection for Find. That is, select the greek letter (or whatever you want to replace), then (from the EDIT menu) -> Find -> Use Selection for Find.
When the Search/Replace dialog box is now invoked, the \ [phi] (for example) will be in the Find dialog box. On a Macintosh, the shortcut is command E (followed by command F). Also works for\ [CapitalDelta] etc.
Related
Sometimes I find myself editing a C source file which sees both use of tab as four spaces, and regular tab.
Is there any tool that attempts to parse the file and "normalize" this, i.e. convert all occurrences of four spaces to regular tab, or all occurrences of tab to four spaces, to keep it consistent?
I assume something like this can be done even with just a simple vim one-liner?
There's :retab and :retab! which can help, but there are caveats.
It's easier if you're using spaces for indentation, then just set 'expandtab' and execute :retab, then all your tabs will be converted to spaces at the appropriate tab stops (which default to 8.) That's easy and there are no traps in this method!
If you want to use 4 space indentation, then keep 'expandtab' enabled and set 'softtabstop' to 4. (Avoid modifying the 'tabstop' option, it should always stay at 8.)
If you want to do the inverse and convert to tabs instead, you could set 'noexpandtab' and then use :retab! (which will also look at sequences of spaces and try to convert them back to tabs.) The main problem with this approach is that it won't just consider indentation for conversion, but also sequences of spaces in the middle of lines, which can cause the operation to affect strings inside your code, which would be highly undesirable.
Perhaps a better approach for replacing spaces with tabs for indentation is to use the following substitute command:
:%s#^\s\+#\=repeat("\t", indent('.') / &tabstop).repeat(" ", indent('.') % &tabstop)#
Yeah it's a mouthful... It's matching whitespace at the beginning of the lines, then using the indent() function to find the total indentation (that function calculates indentation taking tab stops in consideration), then dividing that by the 'tabstop' to decide how many tabs and how many spaces a specific line needs.
If this command works for you, you might want to consider adding a mapping or :command for it, to keep it handy. For example:
command! -range=% Retab <line1>,<line2>s#^\s\+#\=repeat("\t", indent('.') / &tabstop).repeat(" ", indent('.') % &tabstop)
This also allows you to "Retab" a range of the file, including one you select with a visual selection.
Finally, one last alternative to :retab is that to ask Vim to "reformat" your code completely, using the = command, which will use the current 'indentexpr' or other indentation configurations such as 'cindent' to completely reindent the block. That typically respects your 'noexpandtab' and 'smarttabstop' options, so it use tabs and spaces for indentation consistently. The downside of this approach is that it will completely reformat your code, including changing indentation in places. The upside is that it typically has a semantic understanding of the language and will be able to take that in consideration when reindenting the code block.
I am working with Cygwin/Mintty/Vim.
With <C-v> I see that <C-S-c> is encoded <83>. This mean vim can read it and I can map it using the map command.
Unfortunately if I try:
:inoremap <C-S-c> foobar
it doesn't work...
How can I make it work and why vim refuses to map Unicode keystokes?
Same question for <C-S-F1>. If I execute this command:
:inoremap <C-S-F1> foobar
I will get something like this:
[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~[20;5~
Where F1 is [1;5P and F9 is [20;5~
Vim apparently does not support exotic key combinations involving Control (<C-…>). That includes F1 – though your other attempted mapping ShiftC is supported (and is equivalent to Control with just C). From a post by Tony Mechelynck on a forum thread “Mapping ctrl-; (ctrl semicolon)”:
The only printable keys which can reliably be used with Ctrl, with
predictable results, in cooked mode on any OS, are those defined by
ASCII, and that means the following AND NO OTHERS:
ASCII characters 0x40 to 0x5F (i.e. uppercase A to Z, plus the six
nonalpha characters at-sign, left-bracket, slash, right-bracket,
[caret] and underscore), where Ctrl subtracts 0x40, thus mapping them
to 0x00 to 0x1F respectively. This explains why Ctrl-[ means Esc, Ctrl-I
means Tab, Ctrl-M means Enter, etc.
Lowercase letters, whose Ctrl counterpart is the same as for the
corresponding uppercase (thus Ctrl+letter and Ctrl+Shift+letter are
always the same for a given letter)
In addition, Ctrl-? is mapped to 0x7F (DEL).
Vim may or may not see other Ctrl-combinations, but that depends on the
terminal, and in most cases it won't see them, or confuse them with
something else such as the same key without Ctrl.
As for your <C-S-c> mapping, I’m not totally sure why you can see <C-S-c> with <C-v> but you can’t map it. When I test in MacVim (a GUI), I get the character ^C when I try <C-v><C-S-c>, and :inoremap <C-S-c> foobar works. When I test in OS X’s Terminal, the Terminal swallows the keystroke and beeps, with both <C-v> and :inoremap. In both cases, <C-v>’s behavior is consistent with :inoremap’s, so I don’t know why you are seeing the discrepancy.
Due to the way that the keyboard input is handled internally, this unfortunately isn't generally possible today, even in GVIM. Some key combinations, like Ctrl + non-alphabetic cannot be mapped, and Ctrl + letter vs. Ctrl + Shift + letter cannot be distinguished. (Unless your terminal sends a distinct termcap code for it, which most don't.) In insert or command-line mode, try typing the key combination. If nothing happens / is inserted, you cannot use that key combination. This also applies to <Tab> / <C-I>, <CR> / <C-M> / <Esc> / <C-[> etc. (Only exception is <BS> / <C-H>.) This is a known pain point, and the subject of various discussions on vim_dev and the #vim IRC channel.
Some people (foremost Paul LeoNerd Evans) want to fix that (even for console Vim in terminals that support this), and have floated various proposals, cp. http://groups.google.com/group/vim_dev/browse_thread/thread/626e83fa4588b32a/bfbcb22f37a8a1f8
But as of today, no patches or volunteers have yet come forward, though many have expressed a desire to have this in a future Vim 8 major release.
I want to use vim :sort to alphabetize a list of french words and have sort consider accented words (é) as unaccented (e). French dictionaries are arranged after this fashion. For example, sorting the list "eduquer ébats" yields "ébats eduquer". However, a simple sort with vim yields the first list. Is there a :sort flag i can set to accomplish this?
At the bottom of :help :sort, there's this note:
The details about sorting depend on the library function used. There is no
guarantee that sorting obeys the current locale. You will have to try it out.
Vim does do a "stable" sort.
First, ensure that you're running in a French locale. This can be done inside Vim via
:lang fr_FR
but it's probably even better to set the LANG environment variable in the shell (assuming Linux; on Windows, you probably need to set your user's language accordingly).
If that does not work, you can fall back to an external sort (which is commonly provided on Linux, you can also download a Windows port of GNU sort here). Sort from Vim via
:%! LANG=fr_FR sort ...
You can try sorting with Unicode::Collate module from perl. It's a perl core module.
Assume your word list is written in utf8:
:%!perl -CIO -MUnicode::Collate -e '$col = Unicode::Collate->new(level => 1); print for $col->sort(<>)'
Apparently, there is no direct vim sort method to accomplish what I want. My workaround consists in setting up 2 macros as mentioned above.
To recap: each line of my text file contains French language "term : definition". Some terms contain accented characters. In order to get the lines alphabetized so that accented letters are treated as unaccented, I wrote a macro the copies the "term", opens a new line, pastes the "term" on that separate line, then invoke a macro that converts accented characters to unaccented in that pasted "term", e.g., let #m=':s/^Vu00e0/a/ge'; my macro is a long string that searches for all accented characters in French.
Once that is done, I cut and paste the modified "term" to the head of the original line and wind up with: "unaccentedterm:accentedterm:definition". Then I run vim :sort, then set up a quick vim macro to strip out the first term, the unaccentedterm.
Many thanks to all who jumped it to help.
It seems simple but i couldn't find an answer for it .
I want to replace all strings in my code in a certain class only, with another strings .
so anywhere in the class where i have :
[self.instance setObject:#"403911" forKey:#"something-design"];
[self.instance setObject:#"403911" forKey:#"somethingelse-art"];
so it will become :
[self.instance setObject:#"403911" forKey:#"something-DESIGN"]; //replace only the word design
[self.instance setObject:#"403911" forKey:#"somethingelse-ART"];
or some other word i will choose.
I think Xcode can't do that, but you can copy the whole code into Sublime Text, then use regular expression -(\w+)"]; to match all the suffixes, finally you could Upper Case all suffixes.
In Xcode 12.4, the "Replace" and "Replace all" buttons magically appear when pressing "cmd-option-shift F". Probably also in earlier versions.
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.