Preprocessing a word before spell checking in Vim - vim

I use Vim's spell checking to validate texts in Russian. We have letter ё in our alphabet which is often replaced with simple е. So, for example, word ёжик из written as ежик. It is a bad tone actually. Its like using - (hyphen) where — (em-dash) is required, like using "computer" quotes forgetting about existence of „typographic” «quotes», etc.
The bad thing is that spell dictionary for Vim composed out of simplified words with all ёs, replaced with еs. So I always get an error in a word with ё.
So the question, is there any hook I can use that will allow me to normalize a word just before it will be spell checked? Or maybe someone has a better idea? Thanks.
UPDATE
With the hint from #sarnold, I found the solution. One should use ru_yo locale instead of ru_ru if he wants ёёёёё

My first thought when reading your post was to suggest using zg to add the word to the spellfile; after a few weeks you'll have a lot of them. Not ideal, but simple.
:help spell-russian lists several different spelling variations, would one of these help?
I also notice in :help spell.txt that there are options for downloading your own spellfiles from OpenOffice or http://www.a-a-p.org to automate building spellfiles.

I would recommend you to use your own spell checking for vim. Use a method #2 explained here

Related

Is there a way to make sublime 3 spell check to check words with CAPITAL LETTERS?

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?

Is there a one-liner to tell vim/ctags autocompletion to search from the middle of a word?

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.

Is there a way to elegantly comment specific lines in vim search history, similar to " in command-line history?

I am using vim to edit structured text files.
Sometimes I use search-and-replace feature, and sometimes I am better off with search, followed with a macro, in which case I have several macros at hand, and the choice of one depends upon the particular search result.
In both cases, though I have to spend some effort to arrive at an acceptable regex to satisfy my editing needs. As the regexs are often very long and sophisticated, I end up with both command-line history and search history full of my trial-and-error by-products. The correct regex is not always the last one in a series of attempts, so if I want to reuse the hard-earned regex in a similar editing situation, I have to dig through the pile again.
In search-and-replace scenario I have quickly fixed this with comments that I now put in place at the end of a would-be reusable search-and-replace command string, for example:
:%s/very_long_and_sophisticated_regex/another_long_and_sophisticated_regex/gc "comments on what this search and replace command does and how it might be reused
This way I can easily ignore the piles of stuff in my command line history and quickly find relevant re-use candidates, they are shown in different color. The commands are reusable right away, comments are ignored.
Not so with the search history, though.
Having rtfmed and searched the web, I have not found anything similar. At the moment I put quasi-comments using XXX at the end of reusable search strings, for example:
/search_string_containing_very_long_and_sophisticated_regex XXX comments on what it finds and how it might be re-used
This way I can at least find the right string for re-use, but I have to first delete 'XXX' and the comments.
I wonder if there is a more elegant way of commenting the search strings in search history, similar to command-line history.
You used the word "elegant" in your title, and that I don't have on offer. If instead you can also accept a quirky workaround that relies on Vim internals, here's one.
To restate your problem, it is possible to add comments after Ex :commands,
:AComplicatedExCommand -42 -quux " this fizzes the brobble
:HardToRememberCommand test.txt " use this to brew the framble
but the same is not possible for complicated search /queries (or ?queries).
I've just discovered that you can trick Vim by terminating your search query with a literal null byte:
/[Complicated]*regexp/^# this regexp finds all scrobbles
/another\+Rege\x*p/^# use this to search foo bars
The ^# here is a literal NUL. You can enter it by pressing CtrlV and then 000.
Vim will ignore everything after the null byte, but it'll still show the whole line in the search history, including the "comment".
You can add a regexp branch that never matches, e.g. /\%$indicator\|search string
\%$ is a special Vim atom matching the end of the file. Since that will never match when followed by the indicator text, the first branch (up to \|) will never match and therefore can represent your indicator.
I've created the TaggedSearchPattern plugin to make adding the tag and recalling it even easier.

How to correct spelling in entire file?

Spelling mistakes can be fixed by pointing the cursor on the misspelled word and pressing z= (a list appears and you can select correct word). But this will fix the mistake only once (on current word). This is not that much of us will want, most will be happy to do replacement in entire file. How can I do so?
Unsuccessful Attempt:
I got an idea of substitute that mistake with correct one (i.e. :%s/badspell/goodspell/g). But the bad part of this is, it is painful. First I need to (atleast) correct a word, then store bad spelling and corrected spelling in my buffer (brain), then write the command for substitution (chances are I will do mistake in writing bad spelling and good one.). Though its time taking too.
There's a similar question on StackOverflow which says I can solve my problem with doing :spellrepall after the correction. The only problem is I don't want to all this typing. I want to automate this everytime there is a spelling correction.
And don't suggest me about plugins.
you can set the spell on in .vimrc
set spell
or if u execute this on vim directly do in vim command mode.
:set spell
Once the spell is on, you need to know following command:
]s — move to the next mispelled word
[s — move to the previous mispelled word
zg — add a word to the dictionary
zug — undo the addition of a word to the dictionary
z= — view spelling suggestions for a mispelled word
If most of the time you're selecting the first fix from the query you can use a remap for 1z= as such:
nnoremap 1z= 1z=:spellrepall<cr>
Although I would recommend binding :spellrepall to a seperate key as many people already suggested. I highly doubt you have run out of keybindings with all those <leader> and <localleader> combos. (something like <leader>z would be a perfect candidate for this)
I don't think this can go any easier without you loosening your expectations.

Which editors out of Emacs, Vim and JEdit support multiple simultaneous text insertion points?

Background: JEdit (and some other text editors as well) support a feature called Multiple simultaneous text insertion points. (at least that's what I'm calling it here).
To understand what this means, take a look at the link.
Out of all the features in use in modern text editors, initial research seems to indicate that this is one feature that both Emacs and Vim do not actually support. If correct, this would be pretty exceptional since it's quite difficult to find a text editor feature that has not made its way into at least one of these two old-school editors.
Question: Has anyone ever seen or implemented this feature in either Emacs, Vim, or both? If so, please point me to a link, script, reference or summary that explains the details.
If you know an alternate way to do the same (or similar) thing, please let me know.
The vim way to do this is the . command which repeats the last change. So, for instance, if I change a pointer to a reference and I have a bunch of
obj->func
that I want to change to
obj.func
then I search for obj->, do 2cw to change the obj-> to obj., then do n.n.n. until all the instances are changed.
Perhaps not a flexible as what you're talking about, but it works frequently and is very intuitive and fast when it does.
moccur-edit.el almost does what you want. All the locations matching the regexp are displayed, and the editing the matches makes changes in the corresponding source. However, the editing is done on a single instance of the occurrence.
I imagine it'd be straight forward to extend it to allow you to edit them all simultaneously (at least in the simple case).
There is a demo of it found here.
Turns out, the newest versions of moccur-edit don't apply changes in real-time - you must apply the changes. The changes are also now undoable (nice win).
In EMACS, you could/would do it with M-x find-grep and a macro. If you really insist that it be fully automatic, then you'd include the find-next in the macro.
But honestly, this strikes me as a sort of Microsoft-feature: yes, it adds to the feature list, but why bother? And would you remember it existed in six months, when you want to use it again?
For emacs, multiple-cursors does exactly that.
Have a look at emacsrocks episode 13, by the author of the module.
I don't think this feature has a direct analogue in either Emacs or Vim, which is not to say that everything achievable with this feature is not possible in some fashion with the two 'old-school' editors. And like most things Emacs and Vim, power-users would probably be able to achieve such a task exceedingly quickly, even if mere mortals like myself could spend five minutes figuring out the correct grep search and replace with appropriate back-references, for example.
YASnippet package for Emacs uses it. See 2:13 and 2:44 in the screencast.
Another slight similarity: In Emacs, the rectangle editing features provided by cua-selection-mode (or cua-mode) automatically gives you multiple insertion points down the left or right edge of the marked rectangle, so that you can type a common prefix or suffix to all of those lines.
e.g.:
M-x cua-selection-mode RET (enable the global minor mode, if you don't already use this or cua-mode)
C-RET down down down (marks a 1x3 character rectangle)
type prefix here
C-RET (unmark the rectangle to return to normal editing)
It should be something like this in vim:
%s/paint.\((.*),/\1.paint(/
Or something like that, I am really bad at "mock" regular expressions.
The idea is substitute the pattern:
/paint(object,/
with
/object.paint(/
So, yes, it is "supported"
It seemed simple to do a basic version of this in Emacs lisp. This is for when you just want two places to insert text in parallel:
(defun cjw-multi-insert (text)
"insert text at both point and mark"
(interactive "sText:")
(insert-before-markers text)
(save-excursion
(exchange-point-and-mark)
(insert-before-markers text)))
When you run it, it prompts for text and inserts it at both point (current position) and mark. You can set the mark with C-SPC. This could be easily extended for N different positions. A function like set-insert-point would record current position (stored as an Emacs marker) into a list and then when you run the multi-insert command, it just iterates through the list adding text at each.
I'm not sure about what would a simple way to handle a more general "multi-editing" feature.
Nope. This would be quite difficult to do with a primarily console-based UI.
That said, there is similar features in vim (and emacs, although I've not used it nearly as much) - search and replace, as people have said, and more similarly, column insert mode: http://pivotallabs.com/users/brian/blog/articles/350-column-edit-mode-in-vi

Resources