Since I'm stuck with Subversion and shell tools for the time, git-gui and such are out of the question. Are there any shell tools to apply a patch line-by-line interactively?
Try passing the --dry-run option to patch. This will let you identify the problem hunks and edit the patch and/or file being patched appropriately.
ipatch brings the power and convenience of selecting and editing patches in Darcs to those who are not using the Darcs version control system.
It allows the user to interactively split a patch file into several patch file, as well as applying a patch interactively and possibly partially.
There's an introduction from the author here.
See this answer.
Although not interactive, another option is to manually edit the .diff file and remove any changes you don't want.
If you open a diff file in emacs and put the editor in diff-mode you can edit patches and emacs will try to update the hunk markers. (Emacs will open .diff files in diff-mode automatically.)
To update markers manually after making changes do C-c C-w to regenerate the hunk.
To apply hunks one by one do C-c C-a. To reverse-apply do C-u C-c C-a. You can also M-x diff-tell-file-name to apply them to a different file.
I found patch original patch.diff to be more reliable than patch < patch.diff and patch files created with diff -u to be easier to work with.
Information also documented here.
UPDATE [5.21.21]:
C-c C-s lets you split up hunks which is very useful for manually editing. Sometimes C-c C-w (diff-ignore-whitespace-hunk) does not do what you intended, so the safest bet is to split the hunks and let emacs update the headers automatically. This is especially useful when keeping lines unchanged; just split into a hunk and delete to remove the change.
Related
I use zsh and I would like backward-kill-word in Emacs mode to behave like Emacs (and bash, fwiw). The behaviour that I have failed to reproduce is that when I press multiple backward-kill-word Emacs adds the killed text to the cut buffer (the first item in the killring) making it possible for me to yank everything with one yank command.
How can I configure zsh to behave like this aspect of Emacs editors?
Actually, by default, Zsh's cut buffer works exactly the same as in Emacs. Just use zsh -f to start Zsh without config files and try it.
However, are you perhaps using zsh-autosuggestions or zsh-syntax-highlighting? There are bugs in these plugins that break this feature:
https://github.com/zsh-users/zsh-autosuggestions/issues/363
https://github.com/zsh-users/zsh-syntax-highlighting/issues/150#issuecomment-658381485
Fixes have been submitted, but for zsh-autosuggestions, none have yet been merged, and for zsh-syntax-highlighting, the fix won't work until Zsh 5.9 has been released.
In the meantime, though, zsh-autocomplete contains a workaround that fixes the problem. If you add that plugin, your cut buffer will start functioning like normal again.
I'm using oh-my-zsh which pipes the output of some functions like git diff and git log into less, whilst this is great for reading the output in the terminal. If I need to refer back to it it isn't possible after quitting with :q
Is there an option to preserve the current view on the file in my terminal after quitting?
Secondly, If there is an option where would I need to edit my oh-my-zsh config to ensure anything piped to less passes this option?
To prevent less from clearing the screen on exit you can start it with the option -X:
less -X FILE
If you want to pass this option automatically to every instance of less, you can set the LESS environment variable accordingly in your ~/.zshrc:
export LESS="-X"
Note:
If your shell has syntax coloring enabled, the -X option will cause your less output to display those color change escape sequences as inline ESC text.
This can be fixed by also passing the raw-control-chars display option, -r. For example:
export LESS="-Xr"
This also includes instances where less is started by another program, for example man. If you want to disable this option for a single command, you can just prepend LESS=. For example
LESS= man less
For Git specifically, this can be handled with the following
git config --global color.ui true
git config --global core.pager 'less -Xr'
I would like to issue a patch command which is somewhat dumber than the default, but I cannot find the right flags (if they exist at all).
I don't want it to create .rej or .orig files, not even when the patch fails. If the patch fails I'd like the original files to remain unchanged.
I don't want it to try guessing if the patch is reversed or not, or try matching the lines before or after those given in the patch. If the lines at the given line numbers do not match, it should fail.
I've tried with -f -N -V never -r - --no-backup-if-mismatch, but still backup files are created and "fuzzy" matching is tried.
Run it with --dry-run -s and only apply if it doesn't report any problems (you may be able to key off the return code).
For disabling the fuzz, you need -F0
For my developer work I reside in the *nix shell environment pretty much all day, but still can't seem to memorize the name and argument specifics of programs I don't use daily. I wonder how other 'casual amnesiacs' handle this. Do you maintain an big cheat sheet? Do you rehearse the emacs shortcuts when you take your weekly shower? Or is your desk covered under sticky notes?
Using bash_completion is one way of not having to remember the precise syntax of program arguments.
> svn [tab][tab]
--help checkout delete lock pdel propget revert
--version ci diff log pedit proplist rm
-h cleanup export ls pget propset status
add co help merge plist pset switch
annotate commit import mkdir praise remove unlock
blame copy info move propdel rename update
cat cp list mv propedit resolved
If I don't use a command regularly enough to remember what I want, I tend to just use --help or the man pages when I need to.
Or, if I'm lucky, I use CTRL+R and let bash's history search find when I last used it.
Eventually you just remember them, well the set that you use anyway. I used to maintain a README in my home directory when I was starting out but that disappeared many years ago.
One useful command is man -k which you pass a word to and it will return a list of all commands whose man page summary contains that word.
'apropos' is also a very useful command. It will list all commands whose man pages contain the keyword.
Is there any standard way of providing list of program switches, so it would be possible for zsh to determine possible completions? Or must it provided directly to zsh developers and only they can add completions to zsh?
Your first stop should be man zshcompsys.
Then you could look at an example such as /usr/share/zsh/functions/Completion/Unix/_vim.
The Z-Shell doesn't automatically know what possible switches work with which binary files. As far as I'm aware, there's no standard way for a shell to determine this.
ZSH works by using completion functions, which are written for specific programs. For example, zsh ships with completion functions for ssh, cvs, git, ls, etc.
If you want to look at these completion functions, you can. If you're in a zsh shell, echo $fpath to see the function path that zsh uses to load completion functions. There's a directory called /usr/local/share/zsh/4.3.17/function (location may vary for distributions / zsh versions), which has a bunch of files beginning with _ - _ssh, _cvs, etc. Those are the completion functions.
One massive clue that these are not generated automatically comes from a comment in the _ssh completion function that ships with 4.3.17 (may or may not be in your specific version):
# Completions currently based on OpenSSH 5.9 (released on 2011-09-06).
#
# TODO: update ssh-keygen (not based on 5.9)
# TODO: sshd, ssh-keyscan, ssh-keysign
Providing completion for the Z-Shell: using fpath
You can write your own completion functions, and developers can write functions for their programs and submit to the zsh developers for inclusion. Z-Shell completion functions go somewhere on the fpath.
If the program, say foobar, follows GNU conventions for options, you can use:
compdef _gnu_generic foobar
Otherwise you can write your own functions. The easiest to use IMO is _describe.
Create a file _foobar with contents:
#compdef foobar
cmds=(
'--one:option one'
'--four:option four'
'no-slashes:options do not need to start with a slash'
)
_describe 'foobar' cmds
Place the file somewhere in your $fpath
Add compdef _foobar foobar
If You are using ruby with the optparse package there is a hidden flag --*-completion-zsh=NAME that will output all that is needed for the completion for that ruby program. Store it in a file named _NAME somewhere in your $fpath and it will work. NAME should be exactly what your program/script is called.
I use a folder in my $HOME for that and added the path to $fpath but that required an additional line in my .zshrc:
autoload -U ~/.completion/*(:t)