change word boundary intellij - android-studio

Is there any way to change the word boundary in IntelliJ so that when I use the "move caret to next word" command, punctuation is ignored? (ie brackets periods quotations etc. etc.) Every time I look this up all I seem to find is tutorials on how to write Regex. Which I can see why that would be useful here, but where do I actually change the regex that defines word boundary?
Example, step by step:
current functionality:
|foo.bar
foo|.bar
foo.|bar
foo.bar|
desired functionality:
|foo.bar
foo.|bar
foo.bar|

To the best of my knowledge, there is no setting to modify this behavior. A search of the IntelliJ IDEA source code,as detailed below, seems to confirm this. To get the behavior you desire, you'll need to either open a feature request, or write a plug-in to do it.
From the Source Code:
The "Move Caret to the next word" action is done via the NextWordAction class.That action uses the NextPrevWordHandler to do the work. NextPrevWordHandler only has three boolean options:
next
withSelection
inDifferentHumpMode
These booleans are set in different permutations for the various actions that use this handler:
NextWordAction
NextWordInDifferentHumpsModeAction
NextWordInDifferentHumpsModeWithSelectionAction
NextWordWithSelectionAction
PreviousWordAction
PreviousWordInDifferentHumpsModeAction
PreviousWordInDifferentHumpsModeWithSelectionAction
PreviousWordWithSelectionAction
The NextPrevWordHandler in turn calls EditorActionUtil.moveCaretToNextWord(...). Likewise, it does not take, or reference, any sort of word boundary setting. Thus there does not appear to be a way to modify the behavior to do what you desire.

Related

How to remove tabs on multiple rows at once

This is not a programming question but an inconvenience in the android-studio editor.
If you have an unwanted tab before all your lines, how can you remove them all at once? Now I have to manually go over 50 lines to remove all the tabs to make my code look clean.
If you want to add multiple tabs at once you just select all your code and press the tab button. So I'm looking for the reverse of that.
If I understood you right, you want to beautify the code itself. Fortunately, you don't have to do that manually - at all.
There's a keybinding for it, which may vary by your OS and which layout you use by default. Go to file -> settings -> Keymap and search for auto-indent. Here's what I get on Windows 10 with the default keymap:
Again, which you have may depend on OS (I'm assuming that mainly applies to Mac though) and your keymap, but you can automatically indent your code as per language standards using Ctrl+Alt+I.
Note that this mainly does indentation. If you chose to golf code and want to ungolf it, this will not work. At least it doesn't for Java.
However: This only works with code files the IDE or plugins support. This won't work for i.e. a .txt file out of the box.
If I misunderstood you and you only want to remove tabs without doing the auto-indent, there's at least two other options.
The first option is using multiple cursors. You can add an additional cursor with shift+alt+a mouse click where you want the cursor, or holding the mouse wheel and moving the cursor with the mouse wheel held down. There might be other methods as well, but those are the two I know of.
Once you have multiple cursors, delete the tabs just like normal. But be careful! Doing so might delete the entire line itself. If it does, you can do 1 tab/n units per indent level to the left, and press delete instead.
There's (AFAIK) no limit to how many cursors you can have at once, but you can theoretically do it with 50 lines at once if you want to. But general advice - don't add more cursors than you can see at once. These do run in parallel and it's easy to lose track if you're not careful, and you might end up deleting stuff you didn't want to delete.
And finally, the regex solution:
Note: Be careful with this. If you use it incorrectly, you might get unwanted results.
If you only want to do this in a limited area, highlight it first. Then CTRL+R and you'll be presented with the regular replace menu. Make sure Regex and In Selection are selected.
A base regex to go off is ^([\s]{2,4}|\t). Explanation just for reference:
^ - At the start of the line
(
\s{4} - Match 4 spaces
|\t - Or a tab character
)
Replace with nothing and click "replace all" (or just use the regular "replace" button if you want to double-check before you do anything). This will replace one occurrence of 4 spaces or a single tab character. If you use indentation that isn't based on 4, change the number.
This is only useable and useful if you've found yourself with incorrect indentation that's the same across all the relevant lines - it will not fix indentation mistakes and/or inconsistencies such as 3-space indentation when you want 4, or random indetation for the same block. Use the first or alternatively second method for that instead.

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 better method for find and replace in Vim?

Edit: I moved this over to the Vi and Vim site: https://vi.stackexchange.com/questions/13689/how-to-find-and-replace-in-vim-without-having-to-type-the-original-word
I'd like to optimize my "find and replace" workflow in Vim. It's something I do often, as I'm sure most of you do too. Usually something along the lines of -- copy a block and change the name of a variable in a few places. I know, I know, that probably triggers your "why are you copying and pasting code" reflex, but let's not go down that road... There are plenty of valid use cases :)
I'm well aware of the search and replace commands: :s or :%s but I don't like them. It forces me to type out both the full variable name I'm searching for and what I'm changing it to. Maybe there is a better way fix the the amount of typing with :%s? I often use long descriptive variable names, so that is really a deal breaker for me. I also don't like how typing out a variable name from scratch is typo prone and can consume time and brainpower hunting down typos. I much prefer typing it once, and then copying and pasting to just avoid this entirely if possible.
My current workflow uses some combination of movement/yank/select/search/put to move around the file and replace one by one. It is not great but has the benefit of avoiding typing out full variable names. I might just need to type the first few letters with / or use another movement command (i.e. fx) depending on what's around and then hit ve to select the whole word. I also don't mind that I have to repeat for every instance. I never do a full find replace without confirming each change. But it would be much preferable if I could repeat the replacement action with a single keystroke (which I can't do with this method). each replacement is usually something like n then ve then p (or even worse "0p)
Is there a faster way?
My own workflow is similar to yours:
To start, get the cursor on one instance, possibly with / or by navigation.
Hit * to find the next instance of that word.
Change one instance with cw and then the new variable name.
Then it's fast: n/N to get to the next/previous instance, and . to repeat the last edit.
This workflow gives me the same advantage as yours, in that I can review each case before applying the change, but it's just two keystrokes for each additional change.
Hope this helps.
I like the "visual highlight then edit" approach.
shift + v to highlight the region that you want to modify.
then :s/old/new/r where old is what word you want to replace with new.
r changes the first instance of that word old.
Note* There are options other than r which modify its behavior how you want to replace the word.

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.

Vim Autocomplete Menu Format

When I'm using Autocompletion in Vim, it doesn't just show the words, it shows information to the right of it:
For me it's not important where the matches are coming from (in this case, it's the path to the dictionary file). As you can see, the paths form a block of text that really distracts from the matches...Is there a way to just show the matching words?
I'm using Vim's builtin complete features, no YCM/neocomplcache/...
I'm not aware of any way to turn that off, other than completely turning off the completion popup menu with :set completeopt-=menu; this will insert one candidate after the other on <C-N>, so you're losing the overview altogether.
When you're writing a custom completion (see :help complete-functions), you can influence / suppress the additional information; it's the menu attribute of the returned match objects. So you could in theory re-implement the dictionary completion in Vimscript, but I'd advise against that, because it will be cumbersome and probably also much slower.
So, unless you have a lot of energy to write and submit a patch (e.g. a new option to turn that off, or restrict to a certain length), it's best to accept this as a fact and learn to focus on the first column.

Resources