How do I select multiple modules in the magit status window so I can update them all at once? What is the magic key binding that tags/marks them for that operation (o u)?
Answered best here with references to the relevant manual bits. Basically, use Emacs regions for selection, or use the universal prefix C-u before issuing the command, to apply to all modules (e.g., update becomes o C-u u).
Related
I'm working on a shell script that handles the build of several applications.
It features a configuration file that describes several possible builds: iOS-debug, iOS-release, android-all-arch-debug, android-all-arch-release, android-armeabi-v7a-debug, etc. Each build might have a different command to invoke, specific parameters, some post-build operations (apk signing for example).
The aim of this configuration file is to ask the user what he wants to build, and these options are not mutually exclusive. Basically, each selected option is placed in a queue and they're all built one by one, and placed in their respective output directories.
Using a graphical interface, you can just offer the user a checklist with one entry per option. Using a command line interface... It's a bit harder.
The solution that comes to mind is the following:
Select the targets to build:
[a] iOS-debug
[b] iOS-release
[c] android-all-arch-debug
[d] android-all-arch-release
[e] android-armeabi-v7a-debug
Your choice(s): abcde
In this solution, each option is represented by a single character (which leaves room for more options), and it's both clear to the user and easy to parse for the developper.
But this isn't really user-friendly or obvious to use, so I'd like to know.
Is there an idiomatic way to implement such a UI? Is there a better way?
Thanks in advance.
Emacs noob (sort of) here. I'm getting unexpected behavior from the goto-line command. The wording of the manual seems imprecise. I'm assuming the phrase "move to line LINE..." means "set point to line LINE". So my interpretation of the manual's entry on goto-line is that it is supposed to set mark at the current location of point and then move point to the line specified by the argument you enter. Is this correct? Because what is happening instead is that, yes, it does set mark at the current location successfully (which I don't care about since I can set mark myself very easily if I want to) but then it sets point at the beginning of the buffer instead of where I specified. Is this what goto-line is supposed to do? Am I misunderstanding either the manual or the purpose of this command?
The activity I'm engaged in is reading the Emacs Lisp manual and evaluating expressions in it. I have line numbers turned on in the left margin, and I would like to be able to simply do M-g g LINE-NUMBER, C-e, C-x C-e and see how the form evaluates. But instead, I have to do this klutzy routine of subtracting current point line number from target line number and then doing M-DIFFERENCE C-n. Or I just C-nnnnnnn...or C-pppppp... or even use the mouse, which is the type of slow and clumsy navigation I'm trying to get away from by using Emacs.
Unfortunately, goto-line in an Info buffer is working on the source rather than the rendered outcome.
(If you visit the elisp.info file, you'll see where the real line numbers are coming from.)
Unfortunately that doesn't help you (or anyone, I suspect), but it does explain why the feature doesn't work as expected.
You could M-x report-emacs-bug and propose that this be changed to work the way people would expect it to work.
If you're using Emacs 26 and its native display-line-numbers-mode then you can customize the display-line-numbers-widen option to prevent line numbers changing when buffers are narrowed, in which case you'll be able to use the number you can see with goto-line.
Simple question. I'd like to know how to tell whether the current shell is running as a mc subshell or not. If it is, I'd like to enter a degraded mode without some features mc can't handle.
In particular, I'd like this to
Be as portable as possible
Not rely on anything outside the shell and basic universal external commands.
Though it's not documented in the man page, a quick experiment shows that mc sets two environment variables: $MC_TMPDIR and $MC_SID. (It also sets $HISTCONTROL, but that's not specific to mc; it affects the behavior of bash, and could have been set by something other than mc.)
If you don't want to depend on undocumented features, you can always set an environment variable yourself. For example, in bash:
mc() { MC_IS_RUNNING=1 command mc "$#" ; }
Entering a "degraded mode" is another matter; I'm not sure how you'd do that. I don't know of any way in bash to disable specified features. You could disable selected built-in commands by defining functions that override them. What features do you have in mind?
It does not seem that dired provides an interface to sort the files/folders according to an arbitrary comparator function. (By default it only allows sorting by name and by date).
I have been digging into the source code in order to determine the mechanism for this sorting, and I see that it is the call to (revert-buffer) in dired-sort-toggle (in dired.el) which does the redisplaying. This leads me to realize that dired simply runs an ls command with certain switches, and then reads the output into the buffer.
Is there a better way to achieve this custom sorting than to point dired's ls function to a custom one? I feel that there could be a variable which holds the ordered list of files/directories in the dired buffer, which I could potentially re-arrange.
I have found the variable dired-subdir-alist, but this only seems to contain the top directory (even though according to the documentation, this seems like exactly the list I want)
dired-subdir-alist is a variable defined in `dired.el'.
Documentation: Association list of subdirectories and their buffer
positions. Each subdirectory has an element: (DIRNAME . STARTMARKER).
The order of elements is the reverse of the order in the buffer. In
simple cases, this list contains one element.
How could I find such a variable?
Your understanding is correct. And, as #Stefan notes, ls-lisp.el provides some flexibility.
See also library Dired Sort Menu, which at least provides more ls possibilities and lets you combine sort orders. (It does not let you provide an arbitrary sort order, however -- for that, see ls-lisp.el.)
You might like to use ls-lisp, which is an Elisp implementation of insert-directory, which is the function used by Dired to (normally) run ls. This is used typically under Windows where ls is often absent:
(require 'ls-lisp)
It should be easy to tweak the code to be able to use your own sorting function.
I have been spending a lot of time in the shell lately and I'm wondering how the tab autocomplete works. What's the mechanism behind it? How does the bash know the contents of every directory?
There are two parts to the autocompletion:
The readline library, as already mentioned by fixje, manages the command line editing, and calls back to bash when tab is pressed, to enable completion. Bash then gives (see next point) a list of possible completions, and readline inserts as much characters as are identified unambiguously by the characters already typed in. (You can configure the readline library quite much, see the section Command line editing of the Bash manual for details.)
Bash itself has the built-in complete to define a completion mechanism for individual commands. If for the current command nothing is defined, it used completion by file name (using opendir/readdir, as Ignacio said).
The part to define your own completions is described in the section Programmable Completion. In short, with
complete «options» «command» you define the completion for some command. For example complete -u su says
when completing an argument for the su command, search for users of the current system.
If this is more complicated than the
normal options can cover (e.g. different completions depending on argument index, or depending on previous arguments),
you can use -F function, which will then invoke a shell function to generate the list of possible completions.
(This is used for example for the git completion, which is very complicated, depending on subcommand and sometimes
on options given, and using sometimes names of branches (which are nothing bash knows about).
You can list the existing completions defined in your current bash environment using simply complete, to have an impression on what is possible. If you have the bash-completion package installed (or however it is named on your system), completions for a lot of commands are installed, and as Wrikken said, /etc/bash_completion contains a bash script which is then often executed at shell startup to configure this. Additional custom completion scripts may be placed in /etc/bash_completion.d; those are all sourced from /etc/bash_completion.
If you are interested in the basics:
Bash uses readline which features history and basic completion. You could inspect the source if you want to get a detailed understanding.
Furthermore, you can use readline to build your own CLI interfaces with completion