manual

Problem: To read MySQL's manual effectively Error: mysql> create database plastronics -> ; ERROR 1007 (HY000): Can't create database 'plastronics'; database exists mysql> Question: How do I check it quickly like in Vim : ":h 1007"? The introduction material I was reading A list of error messages is available on the MySQL website. However, it isn't really going to help you if the error the server spit out didn't. You asked MySQL to create a database; MySQL replied that it can't create that database because it already exists. You can't have two databases on the same server with the same name.

I am making an R package using devtools and roxygen2. I can get a PDF manual using R CMD but I am really curious as to whether this can be done using devtools. devtools' build(), check(), install() all don't make a PDF manual. Is this tied to making vignettes? I have read and referred to a similar thread Package development : location of pdf manual and vignette After you install it, you can use: pack <- "name_of_your_package" path <- find.package(pack) system(paste(shQuote(file.path(R.home("bin"), "R")), "CMD", "Rd2pdf", shQuote(path))) There is devtools::build_manual() Maybe also devtools:

This question is based on this thread . Problem: to access MySQL's manual when the cursor is at the beginning of the word by Ctrl-A Esc Ctrl-m where m reminds about M ysql. How can you build a Vim-like K in Screen for MySQL's manuals? Assuming you've installed the man pages from MySQL's documentation site : Put the following in /path/to/mysql-help.screen : # mysql-help.screen # prevent messages from slowing this down msgminwait 0 # copy term starting at cursor copy stuff " e " # write term to a file writebuf /tmp/screen-copied-term # open that file in man in a new screen window # (use `read`

I develop in a proprietary script language with very resumed code in which most configurations are contained inside the code itself. The obvious problem would be the differences in the code itself between test and production environments and that's exactly what I'm trying to manage with GIT. As my test env is quite volatile I figured I could create a branch in GIT for it while there are changes being made (and keep the code with test configurations in there) and after the code has been accepted I'd merge it into production. Well, when I ask git to merge my branches it does a wonderful job with

As I'm often confronted with situations where S4 programming is needed to keep an overview, I've collected quite some sources on S4 objects, methods and programming. I've listed them here as a reference. Please add your own sources as well. On the web The methods help files : help files from the package methods, where much of the necessary information can be found S4 classes in 15 pages : Short introduction on the programming with S4 objects. How S4 methods work : more explanation about the underlying mechanisms. Not so short introduction to S4 : with practical examples of how to construct the