In PCL-CVS documentation, following section describes how to see CVS differentce. It also talks about giving prefix argument to specify previous revision. But I am not able understand what prefix argument should be given for previous revision.
d e
This uses ediff (or emerge, depending on ‘cvs-idiff-imerge-handlers’)
to allow you to view diffs. If a prefix argument is given, PCL-CVS
will prompt for a revision against which the diff should be made, else
the default will be to use the BASE revision.
Thanks.
In general, prefix arguments in Emacs are given by prefixing a command with C-u followed by an optional argument.
In this case, it doesn't sounds like it matters what the argument is, so C-u d e should cause Emacs to prompt you for a revision.
Related
I've just noticed a pattern (in git and the CommandLineParser lib for .NET) for verb-style command arguments, and wondering if someone can confirm:
myprog dothis -a "someArg"
-a
--arg
What's the difference between the single-dash-prefix and the double-dash-prefix? Is the single dash prefix always for a single-letter argument specifier, where a double dash prefix always for a "long name" of the argument?
Is there a formal convention somewhere that drives this, or is it a generally accepted informal practice? (or am I just making something of nothing?)
Just curious... the I had never noticed the pattern in git and the CommandLineParser docs are pretty thin and some blog post or another implicated the convention.
(for that matter... what's this style of verb/args even called? I can't seem to find much of anything on it)
From the wikipedia: https://en.wikipedia.org/wiki/Command-line_interface
Option conventions in Unix-like systems
In Unix-like systems, the ASCII hyphen-minus begins options; the new
(and GNU) convention is to use two hyphens then a word (e.g. --create)
to identify the option's use while the old convention (and still
available as an option for frequently-used options) is to use one
hyphen then one letter (e.g. -c); if one hyphen is followed by two or
more letters it may mean two options are being specified, or it may
mean the second and subsequent letters are a parameter (such as
filename or date) for the first option.
Two hyphen-minus characters without following letters (--) may
indicate that the remaining arguments should not be treated as
options, which is useful for example if a file name itself begins with
a hyphen, or if further arguments are meant for an inner command (e.g.
sudo). Double hyphen-minuses are also sometimes used to prefix "long
options" where more descriptive option names are used. This is a
common feature of GNU software. The getopt function and program, and
the getopts command are usually used for parsing command-line options.
There is posix convention and getopt
But it's not always the case, e.g. java and find.
See also:
https://golang.org/pkg/flag/
http://docs.oracle.com/javase/8/javafx/api/javafx/application/Application.Parameters.html
I am the author of an Emacs package, and occasionally when working on my package, I will come across a useful-looking function and use it in my code. Then, shortly after I release, someone using an older Emacs version (but still a version that I want to support) will report that the function is not defined, and I realize that this function has only recently been added in the latest version of Emacs, and am forced to revert the change (example). So, is there any way to check the version of Emacs in which a specific function was first added? Or better yet, a way to read my whole elisp file and report the minimum version of Emacs it would require and why?
I suppose the brute-force solution would be to install every version of Emacs I want to support and test-compile my package with each of them. So I'm asking if there's a better way that.
The file etc/NEWS and its siblings for older versions NEWS.[12]* contains very detailed change history for every Emacs version since the neolithic age. (The oldest ones are -- perhaps predictably -- somewhat less detailed.)
Unfortunately, this information is not in machine readable form; but you could still grep around for the information with some less-than-perfect precision.
Here is a quick and dirty Awk script I cobbled together.
#!/bin/sh
# Path to your emacs etc directory
emacs_etc=$HOME/git/emacs-snapshot/etc
# Reverse the order of the wildcard matches so we search newest to oldest
printf '%s\n' $emacs_etc/NEWS.[12]* $emacs_etc/NEWS |
tac |
xargs awk -v fn="$1" 'BEGIN { regex="^[*]+ New .*" fn }
/^\*[^*]/ { version=$NF }
$0~regex { print version ":" $0; exit 0 }
END { exit 1 }'
This is slightly inexact in that it requires the entry to begin with New (this seems to be somewhat consistent in the newer entries, but less so in the older ones) and it will find a prefix of the search string, not necessarily an exact match.
However, the change you are looking for does not match this expected format. The commit which added set-default-toplevel-value just added a free-form notice to NEWS which does not mention that it introduced a new variable.
To actually find it, I located it in the source tree (src/eval.c) and a straightforward git blame on the line which contains the definition pointed straight to the pertinent commit. (In the general case, you might need to peel off commits in layers; fortunately, Git has fairly good support for this kind of thing.)
If you want to know the version of Emacs when a specific function was introduced, for relatively recent version of Emacs (version 18 and later), then you could search into the NEWS files located in the etc directory.
Clone the latest Emacs version git repo from https://git.savannah.gnu.org/cgit/emacs.git
Then you can grep search the function name in the emacs/etc directory with contains the NEWS files:
NEWS NEWS.18 NEWS.20 NEWS.22 NEWS.24 NEWS.26
NEWS.1-17 NEWS.19 NEWS.21 NEWS.23 NEWS.25 NEWS.27
It will depend on what your looking for, but if the name your looking for is distinguishable enough you should find something in there.
Using the excellent ripgrep tool I was looking for that info related to the function string-to-syntax and the macro defvar-local, and this is what I got:
> rg string-to-syntax
NEWS.21
3031:** The new function `string-to-syntax' can be used to translate syntax
3038: (string-to-syntax "()")
>
> rg defvar-local
NEWS.24
2189:** New macros `setq-local' and `defvar-local'.
>
I am using emacs 23 on two computers.
On both, dpkg -s emacs outputs the following version number.
However one has window.el and the other not. This make some function such as split-window behave differently. The help page of this function on the computer that apparently has not window.el installed reads that it comes from C source code instead.
Where does this difference comes from?
I prefer the behaviour of the one that says that split-window comes from window.el: it allows to specify the SIDE when splitting window and provide additional function such as window-resize.
I suppose this is the most recent one but I do not know how to check it nor how to upgrade the other to this state.
Library window.el is as old as the hills. Perhaps you meant that one of your Emacs installlations has window.elc but not window.el?
More likely, you are referring only to function split-window. Yes, it used to be a built-in function (i.e., defined in C), and now it is defined in window.el (which file exists also for the older Emacs versions where that function is a built-in).
FYI, lots of window and buffer-display stuff was changed around the same time as split-window was rewritten in Lisp. Lots of behaviors changed, in minor or major ways.
What is not at all clear is what the problem is that you are reporting. You ask, "Where does this difference comes from? How to fix it?" I've explained a bit about the difference. As for how to fix it -- what is the "it" that needs fixing, and what would the fixed behavior be like?
IOW, your question is, so far, unanswerable. If you specify things more exactly, perhaps we can help more.
I'm not certain what's going on with your debian packages, but if memory serves the readable .el(.gz) files are not supplied in the basic package, but in a separate package. This is because all you strictly need is the byte-compiled .elc files, so they can reduce the base package filesize by omitting them (at the expense of enabling you to read the elisp code).
Is M-x load-library RET window RET successful?
Note that Emacs 24 is the current stable version. You might want to upgrade.
Edit:
M-x emacs-version tells you which version of Emacs you're running, which will always give you a definitive answer.
(And if the versions are identical, then run emacs -Q to eliminate and site- and user-specific config files from the picture, as those are always a likely culprit for differing behaviours.)
why doesn't eclipse match the argument while doing code completion. In the following example it should have automatically matched the throwable. In stead it shows arg1 as the first option.
The autocomplete options in Eclipse for auto-completed method arguments, start with the parameter names found in the source distribution (that contains the class with the method). If no source distribution is available, then it will use the parameter names as indicated in the binary distributions i.e. in the compiled byte code. This is the default behavior
If you want to change this behavior of inserting parameter names from source code or binaries to inserting the best guessed arguments (including local variables), then you can configure the auto-complete options of Eclipse to do so, as shown in the following screenshot:
This will produce the desired result of automatically displaying the options containing the list of best-guessed arguments. This also seems to avoid suggesting parameter names:
I guess arg1 is thing you already typed. So the proposal eclipse can provide is trying to find something which start from arg1.
So it puts it as the first choice.
You can type t , and try Alt+/ , to see if this is the reason.
99.9% of the time, I don't care how many links are pointing to a file. How do I get dired (or alternatively, ls) to not display the number of links?
For reference, the output of ls -l is something like:
-rw-rw-rw- 1 root dir 104 Dec 25 19:32 file
The number of links, in this case, is 1. ls has a flag to remove the group number (104) but not one to remove the number of links, from what I can tell.
I'm afraid editing the format will screw up dired's parsing, as ls has a special flag for producing output to dired.
To control how things are displayed in dired, you can customize the variable dired-listing-switches. However, as you noted, not displaying the number of links is not an option.
A slightly different approach would be to use the package dired-details, which hides all details until you want them. This hides the number of links (but also hides other information). Follow the link to find the package (and a dired-details+ which sounds like it fixes a couple minor inconveniences with dired-details).
Original answer information follows:
(setq dired-listing-switches "-l")
From the "Entering Dired" info page:
The variable
dired-listing-switches' specifies the
options to give tols' for listing
the directory; this string must
contain -l'. If you use a numeric
prefix argument with thedired'
command, you can specify the ls'
switches with the minibuffer before
you enter the directory specification.
No matter how they are specified, the
ls' switches can include short
options (that is, single characters)
requiring no arguments, and long
options (starting with --') whose
arguments are specified with='.
You can use ls-lisp to customize the dired buffer display. ls-lisp is part of GNU Emacs (22.1 or perhaps even earlier) ls-lisp has a ls-lisp-verbosity customize variable that will allow you to show/hide "links", "uid" and "gid". It also has other things that may tickle your customize fancy.
I like ls-lisp so much I use it everywhere, on my Windows and even Linux sessions.