I use oh-my-zsh for my main terminal on linuxmint 21, when I run command gb or git branch, I got this result:
boba
* main
(END)
I use zsh from this tutorial: FROM HERE
And this is the cheat sheet: CHEATSHEET COMMAND
Can I choose the boba branch in this situation?
EDIT: Completely different answer after clarification of problem.
That's because the command you ran lists the available branches using a pager.
The one marked with '*' is the current branch, and the "(END)" is how a pager tells you that the previous was the last line.
You cannot use the pager to switch branches. To switch you use
git checkout boba
With all the bells and whistles oh-my-zsh incorporates, you may bring up a selection widget by typing Tab after the checkout arg:
git checkout <TAB>
(I don't use oh-my-zsh so it may not work).
Related
https://doc.qt.io/archives/qt-4.8/qmake-environment-reference.html#installs
To help in the install process qmake has the concept of a install set.
It looks like a install set have members, i.e. path, files and extra:
documentation.path = /usr/local/program/doc
documentation.files = docs/*
Are there other members?
What members need to be set in order to consider the install set fully described?
Where the create_docs come from in the case below
unix:documentation.extra = create_docs; mv master.doc toc.doc
QMake is documented... not. Whenever you want to know something you go browse source code. In this case, it's in qmake/generators/makefile.cpp, function Makefilegenerator::writeInstalls().
As we can see, it's path, files, base, extra, CONFIG, uninstall and depends. extra (or commands) is an arbitrary line to insert at the top.
What members need to be set in order to consider the install set fully described?
QMake is Makefile generator. Whatever human does it simply outputs some Makefile. Whether it will work or not, that's a human's problem.
So, to better explain what I'm asking for, I am writing a zsh plugin for quickly navigating up directories and I want to offer the ability to traverse into a directory by specifying a starting directory in $PWD.
For example, if I am in a directory ~/example/first/left/second and I wanted to go to a directory ~/example/first/right, I could call $ up first/right. I managed to get the functionality working just fine, but I want to offer tab completions in the same way cd ..[/..]* does.
At the moment, here is what I have
_up() {
local -a args
args=(`echo ${PWD#/} | sed 's/\// /g'`)
_arguments ':paths:($args[#])'
}
And so I currently have tab completions working for all of the initial options available, but past that point I have no idea how to get zsh to tab complete like paths past this point.
I am using PicoCLI v4.0.0-beta-1b. I am using different subcommands linked from a parent command. The parent command's optional parameters get displayed when I launch the CLI but not for the subcommands. The subcommands only appears underneath commands (but with no options).
How does one go about to ensure that the options for subcommands appear in the CLI as well?
Options:
-a, --autocomplete Generate sample autocomplete
-h, --help Display this help message.
-v, --verbose Verbose mode. Helpful for troubleshooting.
-V, --version Show version info and exit.
Commands:
abc
def
By default, picocli only shows an overview of a command's subcommands, and no details. This follows the conventions of other command suites like git. The idea is that end users can always get details for another subcommand by asking for help for that specific subcommand, like git commit --help, or git help commit.
While this is a useful default, if that's not what you want, picocli usage help is highly customizable.
The picocli usage message has the following sections:
header heading
header
synopsis heading
synopsis
description heading
description
positional parameter list heading
positional parameter list
option list heading
option list
command list heading
command list
exit code list heading (since 4.0)
exit code list (since 4.0)
footer heading
footer
Each section has its own IHelpSectionRenderer, and you can change the usage help by removing, reordering or replacing these help section renderers.
An example to get you started is here:
https://github.com/remkop/picocli/blob/master/picocli-examples/src/main/java/picocli/examples/customhelp/ShowAll.java
The above example has a custom IHelpSectionRenderer for the command list, to show the full hierarchy of commands, subcommands, and sub-subcommands, etc. You may want to do something similar but show the options of the subcommands instead.
You will need to familiarize yourself with some details of the picocli Help API, like TextTable, Layout, IOptionRenderer, etc.
Wordpress allows you to extend its core using "hooks" and "filters." For example, to execute something quite early in the execution process I may write
add_action( 'init', function() { // Do something } );
Filters work similarly. The function that defines a hook is do_action, so to create the init hook a core developer wrote
do_action( 'init' );
do_action accepts several optional arguments that this hook doesn't demonstrate. The function names for filters are add_filter and apply_filter.
Say I'm browsing the source code of some plugin and it's using a hook from one of the source files and I don't know which one. What is the easiest way to locate it?
In Vim I use ctags a lot and I was hoping that it was possible to do something similar, only instead of giving the function name I could give the filter or hook name. Any ideas?
(If it can't be done from within Vim, like ctags, second best would be to run a command that will locate the script for me. This could also be acceptable if it is the best solution)
Say I'm browsing the source code of some plugin and it's using a hook
from one of the source files and I don't know which one. What is the
easiest way to locate it?
I use grep. Couldn't work without it. grep gets me just about anything I want. grep -Rni "do_action( 'init'" * should find the 'init' hook. You can use regex in the search string if you need to as well as tell it to ignore particular files and/or directories. I've tried other options but just haven't ever been sold on anything else. grep is quick and clean.
This isn't a 'Vim' answer but you did say 'or similar' :)
There is a very good hook database at http://adambrown.info/p/wp_hooks/version/3.4 too.
I've had to do this quite a lot lately so I wrote a little Vim plugin to ease the process.
Simply place the caret on name of the hook or filter, press Leader+f to find the hooked functions, or Leader+F to find the hook/filter definition.
To install:
cd ~/.vim/bundle && git clone https://github.com/borzhemsky/wp-hook-finder.git
Add the keybindings to ~/.vimrc:
nnoremap <Leader>f :FindWPHook<CR>
nnoremap <Leader>F :FindWPHookDef<CR>
Site note: Writing this taught me that, yes, people do things like using add_filter hook their functions to hooks defined with do_action, so searching for occurrences manually can be error-prone.
From the basic to the rather involved:
GREP
Already explained.
GREP FROM VIM OR VIMGREP
If you are already in Vim, you can use the :vimgrep command or its sister :grep:
:vim "do_action( 'init' )" **/*.php | copen
See :help starstar for the ** wildcard that let's you do recursive search. :vimgrep uses an internal method while :grep uses, well… grep. The latter may be faster.
CTAGS
Assuming you have ctags installed, the indexing can be done in the shell or in Vim:
$ ctags -R . <-- in the shell
:!ctags -R . <-- in Vim
and the querying is just a matter of :tag do_action. Read :help tags for an indepth explanation.
CSCOPE
Assuming you have cscope installed, you can use it right from the shell:
$ cscope -R *.php
Once the index is created you can search in cscope's interface and open the chosen files in your editor.
Assuming your Vim comes with cscope support, you have to:
create the index, :!cscope -bR *.php
locate the index, :cs add cscope.out
*f*ind the *d*efinition, :cs f d do_action
There are other specialized tools like Codesearch or GNU Global but I think that you don't really need to go further than plain grep or, at most, ctags.
I have completion menu configured in my zsh. It works great, no problem.
Now I want to make my zsh act like that:
Let's say there are 3 files in a directory:
somefile_first
somefile_second
somefile_third
Now when I press [TAB], I get completion menu with the first file placed in the command line.
But I want zsh to complete the common part of file names (in this example it would be somefile_), do not place anything else after the common part, and let me navigate through completion menu.
How do I do that?
I realize this question is old but I stumbled upon it when looking for the same answer. Here is what I found out.
AFAIK when using completion menu zsh will always place highlighted completion in the command line. However you can make it less hasty.
unsetopt menucomplete
setopt automenu
Changes the behaviour so
first TAB completes the common part
second lists completions without changing command line
third starts the menu and completes command line with highlighted completion
If you prefer no command line changes than fancy menu unset automenu too:
unsetopt menucomplete automenu
That gives bash-like completion. Only common part is completed and propositions are listed.