I have "v" aliased to "vim **/*.cpp **/*.hpp **/*.cxx"
Problem is, if I'm in a directory without any *.cxx files, zsh treats this as an error. Is there anyway to tell zsh to create the absence of **/*.cxx files as "" instead of an error?
It sounds like you want:
set -o NULL_GLOB
Another variation that may be of interest is:
set -o CSH_NULL_GLOB
They work slightly different when all the patterns fail to expand. When at least one pattern successfully expands, the two are the same. But if none of the patterns expand, NULL_GLOB will still run the command while CSH_NULL_GLOB will return an error.
Related
I am trying to set the dictionary option (to allow autocompletion of certain words of my choosing) using wildcards in a filename glob, as follows:
:set dict+=$VIM/dict/dict*.lst
The hope is that, with this line in the initially sourced .vimrc (or, in my case of Windows 10, _vimrc), I can add different dictionary files to my $VIM/dict directory later, and each new invocation of Vim will use those dictionary files, without me needing to modify my .vimrc settings.
However, an error message says that there is no such file. When I give a specific filename (as in :set dict+=$VIM/dict/dict01.lst ), then it works.
The thing is, I could swear that this used to work. I had this setting in my .vimrc files since I started using Vim 7.1, and I don't recall any such error message until recently. Now it shows up on my Linux laptop as well as my Windows 7 and Windows 10 laptops. I can't remember exactly when this started happening.
Yes, I tried using backslashes (as in :set dict+=$VIM\dict\dict*.lst ) in case it was a Windows compatibility issue, but that still doesn't work. (Also this is happening on my Linux laptop, too, and that doesn't use backslashes for filepaths.)
Am I going senile? Or is there some other mysterious force going on?
Assuming for now that it is a change in the latest version of Vim, is there some way to specify "use all the dictionary files that fit this glob"?
-- Edited 2021-02-14 06:17:07
I also checked to see if it was due to having more than one file that fits the wildcard glob. (I thought that if I had more than one file that fit the wildcard, the glob would turn into two filenames, equivalent to saying dict+=$VIM/dict/dict01.lst dict02.lst which would not be syntactically valid.) But it still did not working after removing extra files so that only one file fit my pathname of $VIM/dict/dict*.lst . (I had previously put another Addendum here happily explaining that this was how I solved my problem, but it turned out to be premature.)
You must expand wildcards before setting an option. Multiple file names must be separated by commas. For example,
let &dictionary = tr(expand("$VIM/dict/dict*.lst"), "\n", ",")
If adding a value to a non-empty option, don't forget to add comma too (let is more universal than set, so it's less forgiving):
let &dictionary .= "," . tr(expand(...)...)
I'm trying to give my tmux panes individual titles. Since there is nothing built into tmux to assign titles, I'm using a function that will receive various properties of the pane and then lookup the title that I want based on those properties, and echo it out.
However, the test inside the function is not working as expected. Even when the session_name "portal" is passed in, it does not match the string "portal", even though the output is always exactly "portal".
I've removed all irrelevant code from the function to show just exactly the failing match:
tmux_pane_title() {
local session_name=$1
# ...
if [[ "$session_name" = "portal" ]] && echo ".${session_name}." || echo "-${session_name}-"
# ...
}
tmux set pane-border-format "#P: `tmux_pane_title \"#{session_name}\" \"#{pane_current_command}\" \"#{pane_current_path}\"` "
It always echos out "-portal-", showing the $1 is in fact "portal", but it does not match "portal" in the test.
I have tried using sed to remove newlines, but it made no difference.
However if I hard-code "portal" into the tmux format for pane-border-format it will suddenly work, suggesting there's some weird control character hidden in the name preventing it from working when I pass in session_name
tmux set pane-border-format "#P: `tmux_pane_title \"portal\" \"#{pane_current_command}\" \"#{pane_current_path}\"` "
If that's the case, how can I find and eliminate the control character? (And why would it be there? I did not enter anything weird into my tmuxinator.yml file for the session name.)
I've already tried removing control characters like this:
local session_name=$(echo $1 | tr -d "[:cntrl:]")
If that's not the case, how can I figure out what is breaking this function?
P.S. I'm on tmux 3.1b.
This is NOT an answer to the question, but it is a step in the direction of a solution to the problem that led me to ask the question. If you have the same problem, this may be helpful.
Although I'm still interested in solving the mystery related to the failing test, I found a way to set my pane titles more easily1.
There is a pane_title property that can be used in your pane-border-format:
tmux set pane-border-format "#{pane_title}"
If you set this format, then you can set the title with printf and escape sequences:
printf '\033]2;%s\033\\' 'your desired title'
(I had read about the printf technique elsewhere, both on and off SO, but it fails if you don't have the proper format including pane_title. No where else did I see these two things mentioned together. Without the combination, it fails. Assuming that the default format is set is not a safe assumption.)
A complete answer is still useful, so I could do things like this:
tmux set pane-border-format " #P: #{?pane_title,#{pane_title},`tmux_pane_title \"#{session_name}\" \"#{pane_current_command}\" \"#{pane_current_path}\"`} "
That would choose an explicit title if one were set, and default to the function to choose one. So please don't close this question as a duplicate of others that relate to setting tmux pane titles. IT IS DIFFERENT.
1In other words, I solved the problem but I didn't answer the question. Many people think SO is a problem-solving site, but it describes itself as a question & answer site. I doubt if many people have given this distinction much thought, but they are very different things.
Using GNU make, I want to include a file, except if the current target is "clean".
That is, I want to do the equivalent of the following:
ifneq($(TARGET),clean)
-include somefile.txt
endif
But for that, I need a variable whose value is the target given on the command line (here named $(TARGET)). Such a variable does not seem to exist, and I can understand why, because you could have multiple targets on the command line, some of which you might want to include the file for, and others not. Actually, it would be fine if the file is included when there are other targets besides "clean". The only real problem I currently have is that when the file to be included does not exist, Make will try to build it, which is unnecessary when you're about to delete it again when executing the "clean" target.
So, is there another way to accomplish what I want?
You can use MAKECMDGOALS. Use it like this to handle multiple arguments on the command line:
ifeq (clean,$(filter clean,$(MAKECMDGOALS)))
-include somefile.txt
endif
However, this is often fraught because if you run make clean all or whatever, the include file won't be included even though it might be needed for all.
If you really need this to be reliable another way is to use recursion for your "top-level" arguments, running them one at a time in a sub-make.
You could usefully check that if clean is a target then it is the only target. Otherwise strange things can go wrong silently causing much wailing and gnashing of teeth. My most recent Makefile includes the following. (NB tested but not as yet used extensively).
ifeq (clean,$(filter clean,$(MAKECMDGOALS)))
ifneq($(strip $(filter-out clean,$(MAKECMDGOALS)))
$(error ERROR: can not make other targets with clean
endif
endif
In zsh (with oh-my-zsh, is that matters) when I enter empty commands (e.g. just press enter) I see empty lines added to my ~/.zsh_history:
: 1508496422:0;ls
: 1508496422:0;vim
: 1508496482:0;
: 1508496482:0;
: 1508496482:0;
: 1508496482:0;
: 1508496490:0;
: 1508496490:0;
: 1508496490:0;
: 1508496490:0;
: 1508496494:0;ls
I'm wondering if it's possible to avoid adding these lines. I checked http://zsh.sourceforge.net/Doc/Release/Options.html but no luck. The reason why I'm trying to avoid adding empty lines is I'm using fzf and fzf lists these empty commands when I search in last commands in a directory.
If this is not possible in zsh side I'll try to search for a solution in fzf side.
There are a few Zsh settings to control what goes into your history
(though I'm surprised emtpies end up there; I can't reproduce that
despite also using fzf and hitting blank RETs a lot).
The man page for zshoptions(1) describes:
HIST_IGNORE_[ALL_]DUPS — This should at least reduce your
consecutive multiple empties down to one.
HIST_IGNORE_SPACE — Your empties might be treated as whitespace
and thus be eliminated. I like this feature anyway for intentionall
discarding commands by starting them with a space.
There is also the HISTORY_IGNORE option (not to be confused with
Bash's HISTIGNORE) — described in zshparam(1) with an example —
which lets you remove a set of patterns. An empty pattern may fix
your case. It also has a zshaddhistory hook that you could use to
more finely control exactly what goes into history.
Now, I'm pretty sure of the limitation here. But let's step back.
The simple statement
READNULLCMD="less -R"
doesn't work, generating the following error:
$ <basic.tex
zsh: command not found: less -R
OK. Pretty sure this is because, by default, zsh doesn't split string variables at every space. Wherever zsh is using this variable, it's using $READNULLCMD where it should be using ${=READNULLCMD}, to ensure the option argument is properly separated from the command by a normal space. See this discussion from way back in 1996(!):
http://www.zsh.org/mla/users/1996/msg00299.html
So, what's the best way around this, without setting SH_WORD_SPLIT (which I don't want 99% of the time)?
So far, my best idea is assigning READNULLCMD to a simple zsh script which just calls "less -R" on STDIN. e.g.
#!/opt/local/bin/zsh
less -R /dev/stdin
Unfortunately this seems to be a non-starter as less used in this fashion for some reason misses the first few lines on input from /dev/stdin.
Anybody have any better ideas?
The problem is not that less doesn't read its environment variables (LESS or LESSOPEN). The problem is that the READNULLCMD is not invoked as you might think.
<foo
does not translate into
less $LESS foo
but rather to something like
cat foo | less $LESS
or, perhaps
cat foo $LESSOPEN | less $LESS
I guess that you (like me) want to use -R to obtain syntax coloring (by using src-hilite-lesspipe.sh in LESSOPEN, which in turn uses the "source-highlight" utility). The problem with the latter two styles of invocation is that src-hilite-lesspipe.sh (embedded in $LESSOPEN) will not receive a filename, and hence it will not be able to deduce the file type (via the --infer-lang option to "source-highligt"). Without a filename suffix, "source-highlight" will revert to "no highlighting".
You can obtain syntax coloring in READNULLCMD, but in a rather useless way. This by specifying the language explicitly via the --lang-def option. However, you'll have as little clue as "source-higlight", since the there's no file name when the data is passed anonymously through the pipe. Maybe there's a way to do a on-the-fly heuristic parser and deduce it by contents, but then you've for sure left this little exercise.
export LESS=… may be a good solution exclusively for less and if you want such behavior the default in all cases, but if you want more generic one then you can use functions:
function _-readnullcmd()
{
less -R
}
READNULLCMD=_-readnullcmd
(_- or readnullcmd have no special meaning just the former never appears in any distributed zsh script and the latter indicates the purpose of the function).
Set the $LESS env var to the options you always want to have in less.
So don't touch READNULLCMD and use export LESS="R" (and other options you want) in your zshrc.