When searching for text in Sublime Text, the search is sensitive to accented letters. This is not very practical when I want to find all matches regardless of the accents. Is there a setting for the search function that makes it ignore the accents?
Unfortunately Sublime Text's Find feature does not support Character Equivalence, so there is no way to get it to ignore the accents.
I explored this before in the context of snippets and replacements, but for this use case, you could write a Python plugin to build the character equivalence for you and populate the Find panel appropriately.
You may find it is enough to just temporarily replace the whole file with it's unidecoded representation and search that.
Related
Is there a way to make sublime 3 spell check to check words with CAPITAL LETTERS? I'm typing here and the spell check just ignore words with 2 or more capital letters. Anyone?
I found a very bad palliative solution for the problem, but it works. It is using OpenOffice writer editor. There you can go to tools, spelling and Grammar, click options, and, then, set verify capitalized, and, also, words with numbers. This can give me a hand on seeing bad typed words in my code. But it is a bad solution, c'os I'm using Sublime, so I have to open it in open office Writer just to use the spell checker. Also, I have to "feed" the dic with the right words in Writer. Hope this could give a hand to those with the same problem, but the ideal solution was to have these spell checker options inside Sublime.
By default, no. You could potentially add a dictionary that has words in all caps and then it'll work. I looked for a couple minutes and didn't see one but you might get lucky.
Sublime text uses Hunspell as the spell-checking engine:
Sublime Text uses Hunspell for its spell checking support. Additional
dictionaries can be obtained from the OpenOffice.org Extension List.
Dictionaries in a format ready to be used by Sublime Text are available at https://github.com/titoBouzout/Dictionaries.
https://www.sublimetext.com/docs/3/spell_checking.html
Hunspell does not allow case insensitive spell-checking
How to check spelling in Hunspell with case insensitive
I am a little lost as how the suggestion by #Giollia is expected to work. Adding a new dictionary will supply a new list of valid spellings, how is that going to help highlight misspellings?
In vim (in Insert mode, after running exuberant ctags), I am using ctrl-x followed by ctrl-] to bring up a dropdown of various possible words/tokens. It's a great feature.
The problem is that by default, this list starts with a bunch of numeric options and automatically inserts the first numeric option, and if I backspace to get rid of the numbers and start typing a part of a word fresh -- with the idea of searching from the middle of the word -- the autocompletion behavior exits entirely.
I know I could type the first letter of the word that I want, then go from there. But that assumes that I know the first letter of the word, which is not necessarily a given.
For example, if I'm working on a pair-programming project with a friend during a long weekend, I might not remember at any given moment whether he called his method promoteRecordStatus(), updateRecordStatus() or boostRecordStatus(). In this example, I would like to type RecordStatus and get the relevant result, which does not seem to be possible at a glance with the current behavior.
So with that scenario in mind: Is there a simple, vim-native way to tell the editor to start its autocompletion without any assumptions, then search all available tokens for my typed string in all parts of each token?
I will of course consider plugin suggestions helpful, but I would prefer a short, vim-native answer that doesn't require any plugins if possible. Ideally, the configuration could be set using just a line or two.
The built-in completions all require a match at the starting position. In some cases, you could drop separator characters from the 'iskeyword' option (e.g. in Vimscript, drop # to be able to complete individual components from foo#bar#BazFunction()), but this won't work for camelCaseWords at all.
Custom :help complete-functions can implement any completion search, though. To be based on the tags database, it would have to use taglist() as a source, and filter according to the completion base entered before triggering the completion. If you do not anchor this pattern match at the beginning, you have your desired completion.
I am facing a problem with a file with lots of dead characters ( maybe because of porting from multiple file systems and code pages ). Hence, I just want to find all the characters that are beyond 127 and delete them by using the search and replace method.
This did not help
How can I search in Vim, using regular expressions for letters (both ascii and non ascii)?
There are many characters whose
ga
returns me for example 65533.
Or in other words, is there any way to search all 65533's and replace them with nothing in VIM?
The exact problem: I have a source in C++ and I need to replace a symbol name to some other name. However, I need that this replace the symbol only, not accidentally the same looking word in comments or text in "".
The source information what particular language section it is, is enough defined in the syntax highlighting rules. I know they can fail sometimes, but let's state this isn't a problem. I need some way to walk through all found occurrences of the phrase, then check in which section it is found, and if it's text or comment, this phrase should be skipped. Otherwise the replacement should be done either immediately, or by asking first, depending on well known c flag.
What I imagine would be at least theoretically possible is:
Having a kinda "callback" when doing substitution (called for each phrase found, and requesting the answer whether to substitute or not), or extract the list of positions where the phrase has been found, then iterate through all of them
Extract the name of the current "hi-linked" syntax highlighting rule, which is used to color the text at given position
Is it at all possible within the current features of vim?
Yes, with a :help sub-replace-expression, you can evaluate arbitrary expressions in the replacement part of :substitute. Vim's synID() and synstack() functions allow you to get the current syntax element.
Luc Hermitte has an implementation that omits replacement inside strings, here. You can easily adapt this to your use case.
With the help of my ingo-library plugin, you can define a short predicate function, e.g. matching comments and constants (strings, numbers, etc.):
function! CommentOrConstant()
return ingo#syntaxitem#IsOnSyntax(getpos('.'), '^\%(Comment\|Constant\)$')
endfunction
My PatternsOnText plugin now provides a :SubstituteIf command that works like :substitute, but also takes a predicate expression. With that, it's very easy to do a replacement anywhere except in comments or constants:
:%SubstituteIf/pattern/replacement/g !CommentOrConstant()
When pasting text from outside sources into a plain-text editor (e.g. TextMate or Sublime Text 2) a common problem is that special characters are often pasted in as well. Some of these characters render fine, but depending on the source, some might not display correctly (usually showing up as a question mark with a box around it).
So this is actually 2 questions:
Given a special character (e.g., ’ or ♥) can I determine the UTF-8 character code used to display that character from inside my text editor, and/or convert those characters to their character codes?
For those "extra-special" characters that come in as garbage, is there any way to figure out what encoding was used to display that character in the source text, and can those characters somehow be converted to UTF-8?
My favorite site for looking up characters is fileformat.info. They have a great Unicode character search that includes a lot of useful information about each character and its various encodings.
If you see the question mark with a box, that means you pasted something that can't be interpreted, often because it's not legal UTF-8 (not every byte sequence is legal UTF-8). One possibility is that it's UTF-16 with an endian mode that your editor isn't expecting. If you can get the full original source into a file, the file command is often the best tool for determining the encoding.
At &what I built a tool to focus on searching for characters. It indexes all the Unicode and HTML entity tables, but also supplements with hacker dictionaries and a database of keywords I've collected, so you can search for words like heart, quot, weather, umlaut, hash, cloverleaf and get what you want. By focusing on search, it avoids having to hunt around the Unicode pages, which can be frustrating. Give it a try.