I am trying to use the icicle-search-file/icicle-search-buffer commands, but am having the same problem with both where C-RET seems to perform no operation on completion options once I have already entered the search context pattern.
The operations described are using Emacs 24.3.1 on Ubuntu 13.10 with icicles, workgroups2, and some custom key bindings all done with H-_ or C-c _ to avoid conflicts. I have icicles and workgroups2 set to be on at start in my .emacs file. I don’t have anything custom bound to C-c `.
I have learned to use icicle-search (C-c `) with progressive completion (S-SPC) and it works well, which is why I wanted to figure out these commands.
I have called the icicle-search-buffer command with each of these options just to be sure there is no difference, and the result are the same:
C-9 C-c `
M-s M-s b
M-x icicle-search-buffer RET
I enter the search regex (.* RET - to make things simple) just as with icicle-search, and am then prompted for the buffers to search. I move through the completion options with arrow keys and use C-RET on the buffers I want to search. The result of this is the buffer I chose disappearing from the completion list and no obvious result appearing. Hitting RET at any point just searches the buffer I had active before beginning the search, just as if I had used C-c `. It does not search the currently selected buffer in the completions list.
Does anyone see where I am failing to understand the usage of these commands? I have read through the information on the Icicles - Search Commands, Overview page.
The "Search Multiple Buffers, Files, and Bookmarks" section seems to describe this simply, but beyond using C-RET not much is said that suggests to me where my problem is.
I also followed the link in that section to the Icicles - Multi-Commands page
which was helpful in seeing how icicles modifies vanilla Emacs commands and how multi-commands work in general, but I could not determine from that where my mistake is.
You were doing nothing wrong. (And your description of using Icicles search is a good one.)
I introduced a bug recently.
Should be OK now. Please download the latest version of icicles-mac.el. Or wait (up to a day) for it to be mirrored on MELPA and download it from there. Sorry for your trouble, and thanks for bringing this to my attention.
IMPORTANT:
If you byte-compile Icicles (recommended), then whenever (as now) icicles-mac.el is updated, you
must load icicles-mac.el (not just icicles-mac.elc), then compile it, then *recompile ALL***of the other **Icicles source files as well. You want to make sure that all byte-compiled files are up-to-date.
This is normal for Lisp. Code that depends on macros needs to be byte-compiled anew after loading the updated macros.
Related
I have vim with airline, that tells me which mode I am in. I would like to change it so that rather than the whole word it just displays the first letter. So N, I or V. Although I can find instructions for changing colours of the mode indicator, I can't find the command to add to my .vimrc that will change the text.
What do I add?
I don't use the plugin, but was able to locate the information in its help almost immediately.
You're looking for the g:airline_mode_map configuration; the example even does exactly what you're asking for (single mode letters), so just copy-and-paste the fragment into your ~/.vimrc!
Also, I would recommend to open an issue / ask the plugin author next time. It might take a bit longer until you get an answer, but it alerts the author about things that aren't yet documented or are hard to find in the documentation, so he can improve it.
Two part question:
First, when using VIM what process do I take and what keys do I type to "go to definition" or "go to declaration" etc.? This document might be the answer to my question, but I can't get it to work, so I'm unsure. It looks like its merely text matching the string rather than finding the true definition. If I can get this to work, then will I be able to jump outside of the current document to a definition/declaration? Or does this only work within a single document?
Second, how do I make this work specifically with the Go programming language? It sure would be nice to "click" the Client in
clnt := &http.Client{Transport: tr}
And be taken to the actual code that defines an http.Client.
Possible? How?
As you guess, gd (and other commands) is merely text matching, vim doesn't understand the syntax as it is just a text editor, :h gd will explain how gd works.
Usually, 'go to definition' is brought by using CTRL-] and tag files. A user manual about this topic can be read by :h 29.1.
First you need to generate a tags file for your project, as latest Exuberant Ctags has supported golang (from here), command
cd /path/to/your/project
ctags -f tags -R --fields=+K+a
will do the job.
Second, open vim, by default vim will find tag files under working directory (according to 'tags' option), if the tag file is found successfully, then CTRL-]` should works well.
Also check two useful plugins Tagbar and Easytags.
For golang, you can use the application godef to do it. The pluging vim-go helps you on setting everything, so, you just type 'gd' in a definition and it goes to the exact definition.
https://github.com/fatih/vim-go/blob/master/doc/vim-go.txt
I started using AutoComplPop for automatic code completions. It works great on the single file I am editing, but if file1 is making a reference to a method defined in file2, it doesn't find it.
The docs don't specify if there is a way to make it search a whole project directory, or even just all open buffers, so I can't tell if this is simply not something the plugin does, or if I need to enable something.
I was testing it out on two Ruby files, if that's relevant. Thanks!
Looks like that the cause of the problem is that ACP set the complete option for its purposes to .,w,b,k (see line #125 in autocomplpop/plugin/acp.vim),
call l9#defineVariableDefault('g:acp_completeOption', '.,w,b,k')
while the default value that is used when pressing \<C-n> is .,w,b,u,t,i. And it appears that the very last letter i actually makes the difference: for some reason vim would not use word from an include file opened in a buffer to complete words in another buffer. So, b option is not enough, i must also be included. Adding the following line into my .vimrc helped
let g:acp_completeOption = '.,w,b,u,t,i'
At least it worked for C++ files, but I'm not sure it fixes the problem for the case of Ruby scripts.
Depending on what is on the left of the cursor, ACP (like all the alternatives) decides what completion mechanism to use.
But ACP only uses Vim's default completion mechanisms: if <C-x><C-o> and <C-n>/<C-p> don't provide what you are looking for, ACP won't help. Try them out first.
Oh cool, this plugin looks a lot like neocomplcache but maybe cleaner...looks a little old. Little concerning that there are so many open tickets on that project and no updates in two years.
Anyway, according to the documentation it doesn't...really...say. Very likely its one of the following things:
Your pwd. If the root directory for your source is some/path then that should also be your current working directory. Try typing :cd some/path to see if that makes a difference.
The runtime path rtp. See if adding the directory with your source files to &rtp does the trick.
The path. Same deal as the &rtp setting.
Very likely this plugin is just falling back on the built in ruby omni completion functions bundled with vim. Try help ft-ruby-omni.
I just had the same problem, and I actually found a solution for this.
Apparently you have to set in your .vimrc file the following:
let g:acp_behaviorKeywordCommand = "\<C-x>\<C-i>"
This will make acp look in every file included by your source for completions, as if you were actually typing <C-p>. However, it is slow, after trying it I decided to revert using <C-p> when there are no matches and default behaviour in the other cases.
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
I want to ditch my current editor. I feel I need something else. That do not expose my hands to the risk of RSI. I need to see why I should change editor. And it would be nice to believe, that I will be coding when I'm 80 years old.
All the big guys out there are using Vim. The only Emacs guy I know are RMS. Paul Graham is a Vi dude.
. (dot) - repeats the last editing action. Really handy when you need to perform a few similar edits.
:help usr_12.txt
That'll bring up a section in the help system that discusses "Clever Tricks". If those don't get you excited I don't know what will!
Recording macros
The asterisk.
*
Its effect: Immediately search for the next instance of the word under the cursor.
The best thing is the efficiency with which you can edit code (which is done a lot in programming). The commands such as
cw to change a word
dw to delete a word
ct, to change all text until the next comma
ci( to change the contents of the parentheses you're currently in
xp to correct spelling mistakes ("spleling" -> cursor on l -> xp -> "spelling")
o to insert a new line below and start editing
O to insert a new line above
Then there is the possibility to work with named registers very quickly. To move a block, just select it, press d, then move to it's new location and press p. Much faster than Ctrl-C and Ctrl-V. Use "ud to delete text and move it to register u (I use this one for the commenting template).
And also Vim has all the scripting support you need (either using it's native scripting language or using Python, Ruby, ...)
the numbers.
in command mode
type a number ( any number of digits )
type a command.
that command will be executed $number times
ie:
99dd
erases the next 99 lines.
The fast startup time.
The sharp distinction between editing and viewing. (you know when you edit)
The only way you ever find what you are looking for is with search "/" and that is good, since it much faster than your eyes.
But the best command(s) are:
/ - search string
ZZ - quit
. - repeat last insert (I think)
%! - insert unix command
Handling multi line regexps in search strings with "\_.". While checking over 4GB text files of various formats, it had saved my life several times.
Why are you looking to be convinced to start using a different editor? If you're happy with what you have now, stick. If not, perhaps ask about editors with features that you lack.
Even if you are using Visual Studio there is the wonderful vsvim.
I love the speed of Vim but I find it lacks the features of a modern IDE for C++ development. Eclipse CDT with the viPlugin is a good compromise.
You get the power and source overview provided by Eclipse CDT with the speed and flexibility of Vim for coding.
The lovely built in regular expression evaluator.
Maybe reading "Come home to vim" by Steve Losh article is a good start, or
a series of videos about interesting plugins. And be sure to see some articles on the site vimcasts.org
You should map Caps Lock to Esc. It will make getting out of insert mode feel natural as opposed to the awkward move you must make to press the ESC key. Besides, who uses Caps Lock anyway?
\v
Make your regular expressions mostly Perl compatible.
See very magic section here for more information.
To be truly inspired, you must see a vim guru in action. If you do not have a local guru, here is a video to inspire you.
http://www.youtube.com/watch?v=jDWBJOXs_iI&feature=related
If you don't already know vim, the speed at which code is navigated, sliced, and diced will be indistinguishable from magic. After a few months of studying vim, the same editing speed will seem commonplace.