## Search for string while viewing a manpage - manpage

### How do I setup a default checkin comment for CVS?

How do I generate a default comment for cvs? I'd like every checkin comment to start with "Change #: " and be available for the user to edit.
I know this can be done globally in the repository. Can it also be done as a single user on the client side?
I am using command line cvs.
We already have verification that the checkin starts with "Change #: " and that a valid change number is provided. I'd like to default the checkin comment to "Change #: " to save developers some typing. How can this be done globally? Can it be done locally/client side?

You can use the rcsinfo file to specify a template to use for the check in.
This is done server side, so you need your template files on your server.
Also, as noted above, you can override the template with your own check in comments on the CVS command line.

Be cautious. You must also ensure that the default comment does not become a crutch. For example, you should validate that the defect number is valid (currently open, for example, as well as actually exists). Otherwise, the programmers will simply use the default comment as the only comment.
In my view, it would be better to put the effort into validating the comment than into providing a default. Tell the developers that their changes will be rejected unless the comments meet the requirements - and document what is expected (and accepted).
The questioner challenges "nicely said, but does not answer the question".
Fair enough. I don't really use CVS, so take what follows with a pinch of salt.
Looking at Karl Fogel's book "Open Source Development with CVS" (Coriolis, 1999), I don't see a good way to do it. There are 'commitinfo', 'loginfo' and 'verifymsg' files that all seem to specify programs that validate log messages, and the editor is launched when the user doesn't specify 'cvs ci -m"Why I committed this"' (or, 'cvs ci -F why' for a message in a file), but personally I always checkin with comments on the command line and would hate to have an editor launched for me. So, short of writing a wrapper for the cvs command (which would be moderately complex), I don't see a way in the book of doing what you request.
Hmmm...unless you override the user's definition of CVSEDITOR in a shell script wrapper for cvs with a program that creates the default message in the given file and then launches ${VISUAL:-${EDITOR:-vim}} instead. Ick, and likewise yuck! But, done carefully, it would work. Probably the hardest part is ensuring that the programmers use your script version of cvs instead of the binary.

### Don't make me manually abort a LaTeX compile when there's an error

As suggested here, latexmk is a handy way to continually compile your document whenever the source changes. But often when you're working on a document you'll end up with errors and then latex will panic and wait for user input before continuing. That can get very annoying, especially recently when I hacked up something to compile latex directly from an etherpad document, which saves continuously as you type.
Is there a setting for latex or latexmk to make it just abort with an error message if it can't compile? Or, if necessary, how would I set up some kind of Expect script to auto-dismiss LaTeX's complaints?
(I had thought pdflatex's option -halt-on-error would do the trick but apparently not.)
Bonus question: Skim on Mac OSX is a nice pdf viewer that autorefreshes when the pdf changes (unlike Preview), except that whenever there's a latex error it makes you reconfirm that you want autorefreshing. Texniscope doesn't have this problem, but I had to ditch Texniscope for other reasons. Is there a way to make Skim always autorefresh, or is there another viewer that gets this right?
Get latexmk here: http://www.phys.psu.edu/~collins/software/latexmk-jcc/
$pdflatex = 'pdflatex -interaction=nonstopmode'; (For OS X with Skim)$pdf_previewer = "open -a /Applications/Skim.app";
While editing your source file, foo.tex, run the following in a terminal:
latexmk -pvc -pdf foo.tex
Use Skim or another realtime pdf viewer to view foo.pdf. For Skim, just look at the “Sync” tab in Skim’s preferences and set it up for your editor.
Voila! Hitting save on foo.tex will now cause foo.pdf to refresh without touching a thing.

With MikTeX, pdflatex has this command-line option:
-interaction=MODE Set the interaction mode; MODE must be one
of: batchmode, nonstopmode, scrollmode,
errorstopmode.
Edit suggested by #9999years:
Those values are equivalent to a set of LaTeX \commands that provide the same functionality.
From TeX usage tips:
The modes make TeX behave in the following way:
errorstopmode stops on all errors, whether they are about errors in the
source code or non-existent files.
scrollmode doesn't stop on errors in the source but requests input when a
more serious error like like a missing file occurs.
In the somewhat misnamed nonstopmode, TeX does not request input after
serious errors but stops altogether.
batchmode prevents all output in addition to that (intended for use in
automated scripts). In all cases, all errors are written to the log file
(yourtexfile.log).

You can also put \nonstopmode or \batchmode at the very beginning of your tex file; then it'll work with any TeX version, not just pdflatex. For more info on these and related commands see the very good reference on (raw) TeX commands by David Bausum. Especially the command from the debugging family could be of interest here.

Another possible hack is simply to use:
yes x | latexmk source.tex
You could always create an alias for 'yes x | latexmk' if you're going to use this option lots. The main advantage of this that I can see above the other suggestions is that it is very quick for when you occasionally want latexmk to behave like this.
Mehmet

There is also a \batchmode command may do the work.

### Vimrc Command Ordering

I'm curious about the ordering and loading of vimrc commands. I've been searching the vim documentation for days now trying to find and answer and have yet to find what I'm looking for. The most relevant pages I've found are:
:h initialization
:h vimrc-intro
:h $VIM :h$VIMRUNTIME
:h after-directory
To be a little more explicit:
It's obvious that the lines of a vimrc file are executed and evaluated sequentially by the order in which they appear in a vimrc file when executing vim, but it's less obvious to me in some cases what the relationships are between settings and what order they should occur in (or even if it matters). I have been unable to find a page in the user manual that has additional information about this. Is there one that I'm missing?
I'm hoping that there may be a general rule that applies here, but as I think through it I think it's probably more likely that the answers are on a case-by-case basis.
The implication of vimrc command ordering is very obvious in some cases:
Filetype detection must be disabled before initializing a runtimepath manager.
A runtime path manager must be initialized before registering bundles.
Plugins typically provide default settings, so it's safer to configure your settings after they have been registered & loaded.
However in many cases, I don't understand if the vimrc command ordering is important and what affects it might have:
It's common practice to set filetype plugin indent on directly after your plugin manager has finished registering it's plugins and before any other commands appear, but is this necessary?
One example I can think of, but am unsure about, are autocommands that set filetype specific settings. What happens if you create these autocommands prior to enabling filetype detection, filetype plugins, and filetype indentation? I'd imagine this has to do with the way that pointers are handled internally by vim, but again, I've really got no clue.
scriptencoding utf-8 specifies the character encoding of the current script and I commonly see this specified at the start of a script. I don't see any information in the usermanual that specifies if the location of this command is important or what impact it might have.
:h initialization specifies that on startup, one of the first things vim does is check for the values of $SHELL &$TERM and sets the corresponding vim term & shell variables. I typically put my encoding & terminal settings directly after my filetype plugin indent on because I've seen other people do it and it seems like it may impact other settings, but honestly I've no clue and I can't find docs to shed light.
Settings like backup and backupdir. The order seems unimportant - I can set backupdir and if backup is not set, then the setting is simply ignored. I can enable backup before or after I set the backupdir value and things work as expected. I'm unsure if that's relevant information for figuring out the larger question.
To Summarize:
Is there a general rule for determining the order in which commands should appear in a vimrc file? Is there documentation on this subject that I have not found in the vim user manual somewhere?
If there is not a general rule, are there more specific rules & examples that you know of?
Do you have any debugging/troubleshooting/testing steps for working through these sort of issues?
Thanks!

Plugins typically provide default settings, so it's safer to configure your settings after they have been registered & loaded.
Plugins are sourced after your ~/.vimrc. Where you put your let g:plugin_option = 1 lines doesn't matter from a technical point of view as long as Vim sees them before the corresponding plugins are sourced.
It's common practice to set filetype plugin indent on directly after your plugin manager has finished registering it's plugins and before any other commands appear, but is this necessary?
The entire point of that practice is only to activate filetype detection and filetype-specific plugins and indent scripts. It is usually done near the top because it is a basic and very useful setting. It's simply pushed down by the plugin manager stuff, no more no less.
What happens if you create these autocommands prior to enabling filetype detection, filetype plugins, and filetype indentation?
The autocommand is a passive event listener: no event, no execution. You can define it before or after filetype detection, it doesn't matter.
scriptencoding utf-8 specifies the character encoding of the current script and I commonly see this specified at the start of a script. I don't see any information in the usermanual that specifies if the location of this command is important or what impact it might have.
Before that command is executed, the script is sourced with the default encoding, after that command is executed, the rest of the script is executed with the new encoding. The earlier the better.
:h initialization specifies that on startup, one of the first things vim does is check for the values of $SHELL &$TERM and sets the corresponding vim term & shell variables. I typically put my encoding & terminal settings directly after my filetype plugin indent on because I've seen other people do it and it seems like it may impact other settings, but honestly I've no clue and I can't find docs to shed light.
set shell… is generally useful but there's no reason whatsoever to redefine your TERM in your ~/.vimrc. Do that in your shell init files or directly in your terminal emulator. Neither 'shell' nor 'term' have any impact on other Vim options.
Settings like backup and backupdir. The order seems unimportant - I can set backupdir and if backup is not set, then the setting is simply ignored. I can enable backup before or after I set the backupdir value and things work as expected. I'm unsure if that's relevant information for figuring out the larger question.
Yes, the order of options generally doesn't matter.
Is there a general rule for determining the order in which commands should appear in a vimrc file? Is there documentation on this subject that I have not found in the vim user manual somewhere?
There is no general rule AFAIK. The specifics of every option/command is usually clearly explained in the documentation and you are supposed to use common sense:
source a function/command before calling it
group related lines together
use only longform option/command names

### Making Sublime Text more like TextMate

Well, I'm under Mac OS X and I use TextMate 1.5.11 to compile LaTeX documents. But I've found that Sublime Text 2 has some features I like more than TextMate (and also TM v2, which is in beta). TextMate 2 has some of that features, but it's still buggy.
So, I would like to move to ST2, but there is only one thing which stops me. In TM there are four very different ways of understanding the snippets:
True snippets which you introduce with tab key after writing a word. (i.e. if you write mat and then press tab you get the basic matrix environment)
Commands based on the word (i.e. if you write frac then you get \frac{$0}{$1})
LaTeX symbol based on current word (i.e. if you write a then you get \alpha, and if you press again, in some cases, it becomes cyclic with more than one symbol)
Environment based in current word (i.e. if you write document and you press the keys assigned your get \begin{document} \$0 \end{document})
But in ST2 you only can press tab. I wold like to differentiate this four cases. Is there an easy way of setting Sublime Text up this way? (I know nothing about programming)

I just made the same switch from TM to ST2 and I'm mostly using it to write LaTeX.
First you need to install the packet installer Package Control - the Sublime Text package manager.
With this installed you invoke Package Control with cmd+shift+p fuzzy search "install package" hit enter, search for "LaTeXTools" and install it.
Now you have a lot of what you know from the LaTeX bundles in TextMate. Study the readme where the developer gets into all the different key commands.
mat+TAB will work out of the box. A lot of other things you expect as well.
word based commands are called Key Bindings and can be configured in Preferences > Package Settings > LaTeXTools > Key Bindings User. I am myself not quite sure of the syntax there. But you can invoke commands with every key combination you can think of. Just typing a word, using a trigger like TAB or whatever floats your boat.
(btw. I'm not sure if you have to put Key Bindings you just want to use in LaTeX in the Key Bindings file inside the LaTeSTools package. Could be that you can define the scope inside the global Key Bindings - User file.)
I am not aware of that behavior in TM. I do this with TextExpander. Just hitting a+TAB = \alpha but I'm sure you can do this in Key Bindings as well
There is an environment command in LaTeXTools. Just type your environmens name and then hit CMD+l,e. That is CMD+l then leaving the CMD key and then type the letter l. Yes, ST can do this.
So, if you'd like to put an enumerate environment you have at lease two options.
enum+TAB gives you
\begin{enumerate}
\item
\end{enumerate}
enumerate CMD+l,e gives you
\begin{enumerate}
\end{enumerate}
There is one other handy command. CMD+l,c turns the previous word into a command. So hat CMD+l,c gives you \hat{}.

### How do I create keyboard shortcuts programmatically in KDE?

I am able to create keyboard shortcuts for Ctrl-F1 and Ctrl-F2, making them launch a script, using the Control Center interface, Input Actions section. The platform of interest is KDE 3.5 on CentOS 5 at present, but 4.x is also of
less immediate interest.
What I need, however, is to create the same shortcuts from a shell script, run after installation of an RPM: this RPM creates a user and then preconfigures its KDE environment completely. So far, I've been able to do stuff like
cat > kdesktoprc <<- EOM
[Desktop0]
WallpaperMode=NoWallpaper
EOM
and then upon first login the KDE setup would pick up from there just fine.
I guess what I am trying to do is preseeding this specific account, but I
don't want to interfere with any other present or future account on the
same host.
Unfortunately, I have not been able to make the same work with Input
Actions, whose configuration is somewhat more involved. Before attempting
to unravel it further, I decided to ask if there was a better way.
In other words, is there a command to create a keyboard shortcut (I don't
think I can use DCOP, because KDE would not be running at the time) ?
I skimmed hints to the kconf_update mechanism, but was unable to ascertain if it was appropriate for my use case: is there a reference available ?

I found an approach which appears to work. First, I create a .khotkeys file,
call it zzz.khotkeys, and store it under /usr/hsare/apps/khotkeys. A good
starting point for that is the printscreen.khotkeys file.
This .khotkeys file has two sections, a [Data] section with the hotkey definition(s), and a [Main] section where among other keys we have
Id=zzz
which is used to remember which key definitions have been already imported.
To put the definitions in zzz.khotkeys into effect, you could use this
/usr/lib/kconf_update_bin/khotkeys_update --id zzz
which seems to invoke functionality equivalent to the "Import" button in
the "Input Actions" user interface.
This step incurs a number of obstacles in my scenario, which is running all
of the abovce in the %post script of an RPM install.
First, khotkeys_update fails if it cannot contact an X server; on the
surface this seems silly, as it should only need to perform text wrangling,
but this can be addressed by placing its invocation inside a .desktop file in .kde/Autostart.
Second, khotkeys_update does not exactly look like a published interface
which can be relied upon over time; since this is for CentOS/KDE 3.5 in
a context where little evolution is expected, I enjoy the privilege to
consider this a minor issue. If there is a published (shell) interface to
perform the import, I could not find it (I did not investigate DCOP).
In the end, the same script which directly customized other configuration
files under .kde/share/config also adds under .kde/Autostart a file named
zzz-keys.desktop which looks like
[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=ZZZ Hotkeys
Comment=Ensure ZZZ keyboard shortctus are available
Exec=/usr/lib/kconf_update_bin/khotkeys_update --id zzz
which gets the hotkeys added the first time (they end up inside khotkeysrc)
and is skipped on subsequent invocations, because khotkeysrc includes a key
name AlreadyInstalled which is also updated to include "zzz", so on
subsequent runs khotkeys_update finds it and does not add duplicates.