Add language definition and samples for RUNOFF

lib/linguist/languages.yml

@@ -3154,6 +3154,15 @@ RMarkdown:
   - .rmd
   tm_scope: source.gfm
 
+RUNOFF:
+  type: markup
+  color: "#665a4e"
+  extensions:
+  - .rnh
+  - .rno
+  tm_scope: text.runoff
+  ace_mode: text
+
 Racket:
   type: programming
   color: "#22228f"

samples/Groff/refs.rno

@@ -0,0 +1,35 @@
+.\" Copyright (c) 1980 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"	@(#)refs.rno	6.1 (Berkeley) 4/29/86
+.\"
+.NS 1 "References"
+.sp
+.ip "[Bac78]"
+John Backus, \*(lqCan Programming Be Liberated from the von Neumann Style?
+A Functional Style and Its Algebra of Programs,\*(rq \fICACM\fP, Turing
+Award Lecture,  21, 8 (August 1978), 613-641.
+.sp 6p
+.ip "[Fod80]"
+John K. Foderaro, \*(lqThe \s-2FRANZ LISP\s+2
+Manual,\*(rq University of California,
+Berkeley, California, 1980.
+.sp 6p
+.ip "[Joy79]"
+W.N. Joy, O. Babaoglu, \*(lqUNIX Programmer's Manual,\*(rq November 7,
+1979, Computer Science Division, University of California, Berkeley,
+California.
+.sp 6p
+.ip "[Mc60]"
+J. McCarthy, \*(lqRecursive Functions of Symbolic expressions and their
+Computation by Machine,\*(rq Part I, \fICACM\fP 3, 4 (April 1960), 184-195.
+.sp 6p
+.ip "[Pat80]"
+Dorab Ratan Patel, \*(lqA System Organization for Applicative Programming,\*(rq
+M.S Thesis, University of California, Los Angeles, California, 1980.
+.sp 6p
+.ip "[Pat81]"
+Dorab Patel, \*(lqFunctional Language Interpreter User Manual,\*(rq
+University of California, Los Angeles, California, 1981.
+.bp

samples/RUNOFF/contributing.rnh

@@ -0,0 +1,324 @@
+.na
+.ll 72
+.pl 90
+.m1 4
+.m2 4
+.m3 6
+.m4 6
+.sp 8
+.ds
+.ce
+CONTRIBUTING TO LINGUIST
+.sp
+.ce
+by
+.ce
+GITHUB
+.sp
+.ce
+and the
+.sp
+.ce
+OPEN SOURCE COMMUNITY
+.sp
+.bp
+.sp 5
+.ce
+_I_N_T_R_O_D_U_C_T_I_O_N:
+.sp
+     Hi there! We're thrilled that you'd like to contribute to this
+project. Your help is  essential for keeping it great. This project
+adheres to the Contributor Covenant Code of Conduct. By participating,
+you are expected to uphold this code.
+.br
+The majority of contributions won't need to touch any Ruby code at all.
+.sp 5
+.ce
+_A_d_d_i_n_g _a_n _e_x_t_e_n_s_i_o_n _t_o _a
+_l_a_n_g_u_a_g_e
+.sp
+     We try only to add new extensions once they have some usage on
+GitHub. In most cases we prefer that extensions be in use in hundreds of
+repositories before supporting them in Linguist.
+.sp
+To add support for a new extension:
+.sp
+.in 5
+.un 5
+1.   Add your extension to the language entry in
+_l_a_n_g_u_a_g_e_s_._y_m_l, keeping the extensions in
+alphabetical order.
+.br
+.un 5
+2.   Add at least one sample for your extension to the samples directory
+in the correct subdirectory.
+.br
+.un 5
+3.   Open a pull request, linking to a GitHub search result showing
+in-the-wild usage.
+.in 0
+.sp
+In addition, if this extension is already listed in
+_l_a_n_g_u_a_g_e_s_._y_m_l then sometimes a few more steps
+will need to be taken:
+.sp
+.in 5
+.un 5
+1.   Make sure that example .yourextension files are present in the
+samples directory for each language that uses .yourextension.
+.br
+.un 5
+2.   Test the performance of the Bayesian classifier with a relatively
+large number (1000s) of sample .yourextension files. (ping @arfon or
+@bkeepers to help with this) to ensure we're not misclassifying files.
+.br
+.un 5
+3.   If the Bayesian classifier does a bad job with the sample files
+then a heuristic may need to be written to help.
+.in 0
+.sp 5
+.ce
+_A_d_d_i_n_g _a _l_a_n_g_u_a_g_e
+.sp
+     We try only to add languages once they have some usage on GitHub.
+In most cases we prefer that each new extension be in use in hundreds of
+repositories before supporting them in Linguist.
+.sp
+To add support for a new language:
+.in 5
+.un 5
+1.   Add an entry for your language to
+_l_a_n_g_u_a_g_e_s_._y_m_l.
+.br
+.un 5
+2.   Add a grammar for your language. Please only add grammars that have
+a license that permits redistribution.
+.br
+.in +5
+.un 5
+i.   Add your grammar as a submodule:
+.br
+.in +4
+git submodule add
+https://github.com/Alhadis/language-roff
+vendor/grammars/language-roff
+.in -4
+.un 5
+ii.  Add your grammar to grammars.yml:
+.br
+.in +4
+script/convert-grammars --add vendor/grammars/MyGrammar
+.in -4
+.un 5
+iii. Download the license for the grammar by running script/licensed.
+Be careful to only commit the file for the new grammar, as this script
+may update licenses for other grammars as well.
+.br
+.in -5
+.un 5
+3.   Add samples for your language to the samples directory in the
+correct subdirectory.
+.br
+.un 5
+4.   Open a pull request, linking to a GitHub search result showing
+in-the-wild usage.
+.br
+.in 0
+.sp
+In addition, if your new language defines an extension that's already
+listed in _l_a_n_g_u_a_g_e_s_._y_m_l (such as `.foo`) then
+sometimes a few more steps will need to be taken:
+.sp
+.in +5
+.un 5
+1.   Make sure that example .foo files are present in the samples
+directory for each language that uses .foo.
+.br
+.un 5
+2.   Test the performance of the Bayesian classifier with a relatively
+large number (1000s) of sample `.foo` files. (ping @arfon or @bkeepers
+to help with this) to ensure we're not misclassifying files.
+.br
+.un 5
+3.   If the Bayesian classifier does a bad job with the sample .foo
+files then a heuristic may need to be written to help.
+.br
+.in 0
+.sp
+Remember, the goal here is to try and avoid false positives!
+.sp 2
+.ce
+_F_i_x_i_n_g _a _m_i_s_c_l_a_s_s_i_f_i_e_d
+_l_a_n_g_u_a_g_e
+.br
+     Most languages are detected by their file extension defined in
+_l_a_n_g_u_a_g_e_s_._y_m_l.  For disambiguating between
+files with common extensions, linguist applies some heuristics and a
+statistical classifier.   This process can help differentiate between,
+for example, .h files which could be either C, C++, or Obj-C.
+.sp
+     Misclassifications can often be solved by either adding a new
+filename or extension for the language or adding more samples to make
+the classifier smarter.
+.sp
+.m4 -2
+.ce
+_F_i_x_i_n_g _s_y_n_t_a_x
+_h_i_g_h_l_i_g_h_t_i_n_g
+.br
+     Syntax highlighting in GitHub is performed using
+TextMate-compatible grammars. These are the same grammars that TextMate,
+Sublime Text and Atom use. Every language in languages.yml is mapped to
+its corresponding TM `scope`. This scope will be used when picking up a
+grammar for highlighting.
+.sp
+     Assuming your code is being detected as the right language, in most
+cases this is due to a bug in the language grammar rather than a bug in
+Linguist. _g_r_a_m_m_a_r_s_._y_m_l lists all the grammars
+we use for syntax highlighting on github.com. Find the one corresponding
+to your code's programming language and submit a bug report upstream.
+.sp
+If you can, try to reproduce the highlighting problem in the text editor
+that the grammar is designed for (TextMate, Sublime Text, or Atom) and
+include that information in your bug report.
+.sp
+     You can also try to fix the bug yourself and submit a Pull Request.
+TextMate's documentation offers a good introduction on how to work with
+TextMate-compatible grammars. You can test grammars using Lightshow.
+.sp
+     Once the bug has been fixed upstream, we'll pick it up for GitHub
+in the next release of Linguist.
+.sp 2
+.ce
+_T_e_s_t_i_n_g
+.br
+     For development you are going to want to checkout out the source.
+To get it, clone the repo and run Bundler to install its dependencies.
+.sp
+.in 4
+git clone https://github.com/github/linguist.git
+.br
+cd linguist/
+.br
+script/bootstrap
+.br
+.in 0
+.sp
+To run the tests:
+.sp
+.in 4
+    bundle exec rake test
+.in 0
+.sp
+    Sometimes getting the tests running can be too much work, especially
+if you don't have much Ruby experience.  It's okay:  be lazy and let our
+build bot Travis run the tests for you. Just open a pull request and the
+bot will start cranking away.
+.sp
+.ce
+_M_a_i_n_t_a_i_n_e_r_s
+.br
+Linguist is maintained with love by:
+.sp
+.in -2
+- @arfon (GitHub Staff)
+.br
+- @larsbrinkhoff
+.br
+- @pchaigno
+.in 0
+.br
+.sp
+As Linguist is a production dependency for GitHub we have a couple of
+workflow restrictions:
+.sp
+.in -2
+- Anyone with commit rights can merge Pull Requests provided that there
+is a :+1: from a GitHub member of staff
+.br
+- Releases are performed by GitHub staff so we can ensure GitHub.com
+always stays up to date with the latest release of Linguist and there
+are no regressions in production.
+.in 0
+.sp
+.ce
+_R_e_l_e_a_s_i_n_g
+.sp
+If you are the current maintainer of this gem:
+.sp
+.in 5
+.ul 5
+1.   Create a branch for the release:
+.sp
+.in +2
+git checkout -b cut-release-vxx.xx.xx
+.in -2
+.sp
+.ul 5
+2.   Make sure your local dependencies are up to date:
+.sp
+.in +2
+script/bootstrap
+.in -2
+.sp
+.ul 5
+3.   If grammar submodules have not been updated recently, update them:
+.sp
+.in +2
+git submodule update --remote _&_& git commit -a
+.in -2
+.sp
+.ul 5
+4.   Ensure that samples are updated:
+.sp
+.in +2
+bundle exec rake samples
+.in -2
+.sp
+5.   Ensure that tests are green:
+.sp
+.in +2
+bundle exec rake test
+.in -2
+.sp
+.ul 5
+6.   Bump gem version in lib/linguist/version.rb
+.br
+.ul 5
+7.   Make a PR to github/linguist
+.br
+.ul 5
+8.   Build a local gem: `bundle exec rake build_gem`
+.br
+.ul 5
+9.   Test the gem:
+.sp
+.in +5
+.un 5
+i.   Bump the Gemfile and Gemfile.lock versions for an app which relies
+on this gem
+.un 5
+ii.  Install the new gem locally
+.un 5
+iii. Test behaviour locally, branch deploy, whatever needs to happen.
+.br
+.in -5
+.sp
+.ul 5
+10. Merge github/linguist PR
+.sp
+.ul 5
+11. Tag and push:
+.sp
+.in +2
+git tag vx.xx.xx;
+.br
+git push --tags
+.in -2
+.sp
+12. Push to rubygems.org
+.br
+.in +2
+gem push github-linguist-3.0.0.gem
+.in -2
+.sp 2