mirror of
https://github.com/KevinMidboe/linguist.git
synced 2025-10-28 17:20:22 +00:00
Revert "Revert "Merge pull request #695 from github/detect-prose""
This commit is contained in:
@@ -23,7 +23,7 @@
|
||||
# Any additions or modifications (even trivial) should have corresponding
|
||||
# test change in `test/test_blob.rb`.
|
||||
#
|
||||
# Please keep this list alphabetized.
|
||||
# Please keep this list alphabetized. Capitalization comes before lower case.
|
||||
|
||||
ABAP:
|
||||
type: programming
|
||||
@@ -103,6 +103,16 @@ Arduino:
|
||||
lexer: C++
|
||||
primary_extension: .ino
|
||||
|
||||
AsciiDoc:
|
||||
type: markup
|
||||
lexer: Text only
|
||||
ace_mode: asciidoc
|
||||
wrap: true
|
||||
primary_extension: .asciidoc
|
||||
extensions:
|
||||
- .adoc
|
||||
- .asc
|
||||
|
||||
Assembly:
|
||||
type: programming
|
||||
lexer: NASM
|
||||
@@ -364,6 +374,12 @@ Cpp-ObjDump:
|
||||
- .c++objdump
|
||||
- .cxx-objdump
|
||||
|
||||
Creole:
|
||||
type: markup
|
||||
lexer: Text only
|
||||
wrap: true
|
||||
primary_extension: .creole
|
||||
|
||||
Cucumber:
|
||||
lexer: Gherkin
|
||||
primary_extension: .feature
|
||||
@@ -976,6 +992,12 @@ Max:
|
||||
- .mxt
|
||||
- .pat
|
||||
|
||||
MediaWiki:
|
||||
type: markup
|
||||
lexer: Text only
|
||||
wrap: true
|
||||
primary_extension: .mediawiki
|
||||
|
||||
MiniD: # Legacy
|
||||
searchable: false
|
||||
primary_extension: .minid # Dummy extension
|
||||
@@ -1111,6 +1133,12 @@ OpenEdge ABL:
|
||||
- abl
|
||||
primary_extension: .p
|
||||
|
||||
Org:
|
||||
type: markup
|
||||
lexer: Text only
|
||||
wrap: true
|
||||
primary_extension: .org
|
||||
|
||||
Oxygene:
|
||||
type: programming
|
||||
lexer: Text only
|
||||
@@ -1291,6 +1319,13 @@ REALbasic:
|
||||
- .rbtbar
|
||||
- .rbuistate
|
||||
|
||||
RDoc:
|
||||
type: markup
|
||||
lexer: Text only
|
||||
ace_mode: rdoc
|
||||
wrap: true
|
||||
primary_extension: .rdoc
|
||||
|
||||
RHTML:
|
||||
type: markup
|
||||
group: HTML
|
||||
|
||||
13
samples/AsciiDoc/encoding.asciidoc
Normal file
13
samples/AsciiDoc/encoding.asciidoc
Normal file
@@ -0,0 +1,13 @@
|
||||
Gregory Romé has written an AsciiDoc plugin for the Redmine project management application.
|
||||
|
||||
https://github.com/foo-users/foo
|
||||
へと `vicmd` キーマップを足してみている試み、
|
||||
アニメーションgifです。
|
||||
|
||||
tag::romé[]
|
||||
Gregory Romé has written an AsciiDoc plugin for the Redmine project management application.
|
||||
end::romé[]
|
||||
|
||||
== Überschrift
|
||||
|
||||
* Codierungen sind verrückt auf älteren Versionen von Ruby
|
||||
10
samples/AsciiDoc/list.asc
Normal file
10
samples/AsciiDoc/list.asc
Normal file
@@ -0,0 +1,10 @@
|
||||
AsciiDoc Home Page
|
||||
==================
|
||||
|
||||
Example Articles
|
||||
~~~~~~~~~~~~~~~~
|
||||
- Item 1
|
||||
|
||||
- Item 2
|
||||
|
||||
- Item 3
|
||||
25
samples/AsciiDoc/sample.adoc
Normal file
25
samples/AsciiDoc/sample.adoc
Normal file
@@ -0,0 +1,25 @@
|
||||
Document Title
|
||||
==============
|
||||
Doc Writer <thedoc@asciidoctor.org>
|
||||
:idprefix: id_
|
||||
|
||||
Preamble paragraph.
|
||||
|
||||
NOTE: This is test, only a test.
|
||||
|
||||
== Section A
|
||||
|
||||
*Section A* paragraph.
|
||||
|
||||
=== Section A Subsection
|
||||
|
||||
*Section A* 'subsection' paragraph.
|
||||
|
||||
== Section B
|
||||
|
||||
*Section B* paragraph.
|
||||
|
||||
.Section B list
|
||||
* Item 1
|
||||
* Item 2
|
||||
* Item 3
|
||||
47
samples/Creole/creole.creole
Normal file
47
samples/Creole/creole.creole
Normal file
@@ -0,0 +1,47 @@
|
||||
= Creole
|
||||
|
||||
Creole is a Creole-to-HTML converter for Creole, the lightweight markup
|
||||
language (http://wikicreole.org/). Github uses this converter to render *.creole files.
|
||||
|
||||
Project page on github:
|
||||
|
||||
* http://github.com/minad/creole
|
||||
|
||||
Travis-CI:
|
||||
|
||||
* https://travis-ci.org/minad/creole
|
||||
|
||||
RDOC:
|
||||
|
||||
* http://rdoc.info/projects/minad/creole
|
||||
|
||||
== INSTALLATION
|
||||
|
||||
{{{
|
||||
gem install creole
|
||||
}}}
|
||||
|
||||
== SYNOPSIS
|
||||
|
||||
{{{
|
||||
require 'creole'
|
||||
html = Creole.creolize('== Creole text')
|
||||
}}}
|
||||
|
||||
== BUGS
|
||||
|
||||
If you found a bug, please report it at the Creole project's tracker
|
||||
on GitHub:
|
||||
|
||||
http://github.com/minad/creole/issues
|
||||
|
||||
== AUTHORS
|
||||
|
||||
* Lars Christensen (larsch)
|
||||
* Daniel Mendler (minad)
|
||||
|
||||
== LICENSE
|
||||
|
||||
Creole is Copyright (c) 2008 - 2013 Lars Christensen, Daniel Mendler. It is free software, and
|
||||
may be redistributed under the terms specified in the README file of
|
||||
the Ruby distribution.
|
||||
90
samples/MediaWiki/mediawiki.mediawiki
Normal file
90
samples/MediaWiki/mediawiki.mediawiki
Normal file
@@ -0,0 +1,90 @@
|
||||
|
||||
= Overview =
|
||||
|
||||
The GDB Tracepoint Analysis feature is an extension to the Tracing and Monitoring Framework that allows the visualization and analysis of C/C++ tracepoint data collected by GDB and stored to a log file.
|
||||
|
||||
= Getting Started =
|
||||
|
||||
The feature can be installed from the Eclipse update site by selecting '''Linux Tools''' > '''GDB Tracepoint Analysis'''.
|
||||
|
||||
The feature requires GDB version 7.2 or later to be installed on the local host. The executable program 'gdb' must be found in the path.
|
||||
|
||||
= GDB Trace Perspective =
|
||||
|
||||
To open the perspective, select '''Window''' > '''Open Perspective''' > '''Other...''' > '''GDB Trace'''.
|
||||
|
||||
The perspective includes the following views by default:
|
||||
|
||||
* '''Project Explorer''': This view shows the projects in the workspace and is used to create and manage Tracing projects.
|
||||
* '''Debug''': This view shows the running C/C++ Postmortem Debugger instances and displays the thread and stack trace associated with a tracepoint.
|
||||
* '''Trace Control''': This view shows the status of the debugger and allows navigation of trace records.
|
||||
* '''Console''': This view displays console output of the C/C++ Postmortem Debugger.
|
||||
|
||||
The editor area contains the '''Events''' and '''C/C++''' editors when a GDB Trace is opened.
|
||||
|
||||
[[Image:images/GDBTracePerspective.png]]
|
||||
|
||||
= Collecting Tracepoint Data =
|
||||
|
||||
Collecting the C/C++ tracepoint data is outside the scope of this feature. It can be done from the GDB command line or by using the CDT debug component within Eclipse. See the CDT FAQ entry in the [[#References | References]] section.
|
||||
|
||||
= Importing Tracepoint Data =
|
||||
|
||||
Some information in this section is redundant with the LTTng User Guide. For further details, see the LTTng User Guide entry in the [[#References | References]] section.
|
||||
|
||||
== Creating a Tracing Project ==
|
||||
|
||||
In the '''Project Explorer''' view, right-click and select '''New''' > '''Project...''' from the context menu. In the '''New Project''' dialog, select '''Tracing''' > '''Tracing Project''', click '''Next''', name your project and click '''Finish'''.
|
||||
|
||||
== Importing a GDB Trace ==
|
||||
|
||||
In your tracing project, right-click on the '''Traces''' folder and select '''Import...'''. Browse to, or enter, a source directory. Select the trace file in the tree. Optionally set the trace type to '''GDB : GDB Trace'''. Click '''Finish'''.
|
||||
|
||||
Alternatively, the trace can be drag & dropped to the '''Traces''' folder from any external file manager.
|
||||
|
||||
== Selecting the GDB Trace Type ==
|
||||
|
||||
Right-click the imported trace in the '''Traces''' folder and choose '''Select Trace Type...''' > '''GDB''' > '''GDB Trace''' from the context menu. This step can be omitted if the trace type was selected at import.
|
||||
|
||||
The trace will be updated with the GDB icon [[Image:images/gdb_icon16.png]].
|
||||
|
||||
== Selecting the Trace Executable ==
|
||||
|
||||
The executable file that created the tracepoint data must be identified so that the C/C++ Postmortem Debugger can be launched properly.
|
||||
|
||||
Right-click the GDB trace in the '''Traces''' folder and choose '''Select Trace Executable...''' from the context menu. Browse to, or enter, the path of the executable file and press '''OK'''.
|
||||
|
||||
The selected file must be recognized by GDB as an executable.
|
||||
|
||||
= Visualizing Tracepoint Data =
|
||||
|
||||
== Opening a GDB Trace ==
|
||||
|
||||
In the '''Traces''' folder, double-click the GDB trace or right-click it and select '''Open''' from the context menu.
|
||||
|
||||
The tracepoint data will be opened in an Events editor, and a C/C++ Postmortem Debugger instance will be launched.
|
||||
|
||||
If available in the workspace, the source code corresponding to the first trace record will also be opened in a C/C++ editor.
|
||||
|
||||
At this point it is recommended to relocate the Events editor outside of the default editor area, so that it is not hidden by the C/C++ editor.
|
||||
|
||||
== Viewing Trace Data ==
|
||||
|
||||
In the Events editor, a table is shown with one row for each trace record. The '''Trace Frame''' column shows the sequential trace record number. The '''Tracepoint''' column shows the number assigned by GDB at collection time for this tracepoint. The '''File''' column shows the file name, line number and method where the tracepoint was set. The '''Content''' column shows the data collected at run-time by the tracepoint.
|
||||
|
||||
Searching and filtering can be done on any column by entering a regular expression in the column header.
|
||||
|
||||
== Navigating the GDB Trace ==
|
||||
|
||||
Trace records can be selected in the Events editor using the keyboard or mouse. The C/C++ Postmortem Debugger in the '''Debug''' view will be updated to show the stack trace of the current trace record.
|
||||
|
||||
The trace can also be navigated from the '''Trace Control''' view by clicking the '''Next Trace Record''' or '''Previous Trace Record''' buttons. The Events editor and '''Debug''' views will be updated.
|
||||
|
||||
= References =
|
||||
|
||||
* [http://wiki.eclipse.org/index.php/Linux_Tools_Project/LTTng2/User_Guide LTTng User Guide]
|
||||
* [http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_trace_my_application_using_C.2FC.2B.2B_Tracepoints.3F CDT FAQ - How can I trace my application using C/C++ Tracepoints?]
|
||||
|
||||
= Updating This Document =
|
||||
|
||||
This document is maintained in a collaborative wiki. If you wish to update or modify this document please visit [http://wiki.eclipse.org/index.php/Linux_Tools_Project/GDB_Tracepoint_Analysis/User_Guide http://wiki.eclipse.org/Linux_Tools_Project/GDB_Tracepoint_Analysis/User_Guide]
|
||||
164
samples/Org/org.org
Normal file
164
samples/Org/org.org
Normal file
@@ -0,0 +1,164 @@
|
||||
#+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:(HIDE) tags:not-in-toc
|
||||
#+STARTUP: align fold nodlcheck hidestars oddeven lognotestate
|
||||
#+SEQ_TODO: TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
|
||||
#+TAGS: Write(w) Update(u) Fix(f) Check(c)
|
||||
#+TITLE: org-ruby
|
||||
#+AUTHOR: Brian Dewey
|
||||
#+EMAIL: bdewey@gmail.com
|
||||
#+LANGUAGE: en
|
||||
#+PRIORITIES: A C B
|
||||
#+CATEGORY: worg
|
||||
|
||||
{Back to Worg's index}
|
||||
|
||||
* Motivation
|
||||
|
||||
The dominant simple plain-text markup languages for the web are
|
||||
Textile and Markdown. A factor for the popularity of those markup
|
||||
formats is the widespread availability of simple, free packages for
|
||||
converting the formats to HTML. For example, the world of
|
||||
Ruby-powered websites has settled on RedCloth for converting Textile
|
||||
to HTML.
|
||||
|
||||
The default way to convert org-mode files to HTML is the powerful
|
||||
publishing functionality provided by =emacs=. However, =emacs= does
|
||||
not easiliy integrate into many existing website frameworks.
|
||||
|
||||
=Org-ruby= tries to make it easier to use org-mode files in both
|
||||
dyanmic and static website generation tools written in
|
||||
Ruby. =Org-ruby= is a simple Ruby gem to convert org-mode files to
|
||||
HTML.
|
||||
|
||||
* Using Org-ruby
|
||||
|
||||
=Org-ruby= follows the same model as other Ruby markup
|
||||
libraries. You install the gem:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
sudo gem install org-ruby
|
||||
#+END_EXAMPLE
|
||||
|
||||
Then, to convert an org-file to HTML in your Ruby code:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
require 'rubygems'
|
||||
require 'org-ruby'
|
||||
|
||||
data = IO.read(filename)
|
||||
puts Orgmode::Parser.new(data).to_html
|
||||
#+END_EXAMPLE
|
||||
|
||||
* Walkthrough: Using org-ruby with Webby
|
||||
|
||||
Here is an example of how to integrate =org-ruby= into Webby, a
|
||||
static website generation tool written in Ruby.
|
||||
|
||||
Webby follows a similar pattern to other static site generation
|
||||
tools (like nanoc, Jekyll, and webgen):
|
||||
|
||||
- You author website content in text with simple markup
|
||||
- Each page is fed through one or more /filters/ to produce HTML
|
||||
- The HTML is mixed in with layouts to produce the final pages
|
||||
|
||||
For a Webby site, a the source for a page may look like this:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
---
|
||||
title: Special Directories
|
||||
created_at: 2009-12-17
|
||||
status: Complete
|
||||
filter:
|
||||
- erb
|
||||
- maruku
|
||||
tags:
|
||||
- powershell
|
||||
---
|
||||
<%= @page.title %>
|
||||
==================
|
||||
|
||||
Special Directories are a set of directories, each of which has a
|
||||
function that will navigate you to the appropriate directory using
|
||||
the push-location cmdlet. For example, the function `home` might
|
||||
navigate to `c:\users\bdewey.`
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
Copy the module to somewhere in `ENV:PSModulePath`. Then,
|
||||
|
||||
InstallModule SpecialDirectories
|
||||
#+END_EXAMPLE
|
||||
|
||||
In the above example, the text is written in Markdown. At the top of
|
||||
the file, metadata informs Webby to pass the text through two
|
||||
/filters/ to produce HTML. The first filter, =erb=, handles embedded
|
||||
Ruby. In this case, it will replace ~<%= @page.title %>~ with the
|
||||
page title (=Special Directories=). The second filter uses Maruku to
|
||||
translate Markdown into HTML.
|
||||
|
||||
You can use the exact same pattern to include org-mode files in a
|
||||
Webby site. For this walkthrough, I assume you already have Webby
|
||||
installed, and that you've already created a site.
|
||||
|
||||
1. Make sure you have =org-ruby= installed: =sudo gem install
|
||||
org-ruby=.
|
||||
2. You need to register a new Webby filter to handle org-mode
|
||||
content. Webby makes this easy. In the =lib/= folder of your
|
||||
site, create a file =orgmode.rb=:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
require 'org-ruby'
|
||||
|
||||
Webby::Filters.register :org do |input|
|
||||
Orgmode::Parser.new(input).to_html
|
||||
end
|
||||
#+END_EXAMPLE
|
||||
|
||||
This code creates a new filter, =org=, that will use the
|
||||
=org-ruby= parser to translate org-mode input into HTML.
|
||||
3. Create your content. For example:
|
||||
|
||||
#+BEGIN_EXAMPLE
|
||||
---
|
||||
title: Orgmode Parser
|
||||
created_at: 2009-12-21
|
||||
status: Under development
|
||||
filter:
|
||||
- erb
|
||||
- org
|
||||
tags:
|
||||
- orgmode
|
||||
- ruby
|
||||
---
|
||||
<%= @page.title %>
|
||||
|
||||
Status: <%= @page.status %>
|
||||
|
||||
* Description
|
||||
|
||||
Helpful Ruby routines for parsing orgmode files. The most
|
||||
significant thing this library does today is convert orgmode files
|
||||
to textile. Currently, you cannot do much to customize the
|
||||
conversion. The supplied textile conversion is optimized for
|
||||
extracting "content" from the orgfile as opposed to "metadata."
|
||||
|
||||
|
||||
* History
|
||||
|
||||
** 2009-12-29: Version 0.4
|
||||
|
||||
- The first thing output in HTML gets the class "title"
|
||||
- HTML output is now indented
|
||||
- Proper support for multi-paragraph list items.
|
||||
|
||||
See? This paragraph is part of the last bullet.
|
||||
|
||||
- Fixed bugs:
|
||||
- "rake spec" wouldn't work on Linux. Needed "require 'rubygems'".
|
||||
#+END_EXAMPLE
|
||||
|
||||
This file will go through the =erb= and =org= filters; as defined
|
||||
in the previous step, the =org= filter will use =org-ruby= to
|
||||
generate HTML.
|
||||
|
||||
That's all there is to it!
|
||||
129
samples/RDoc/rdoc.rdoc
Normal file
129
samples/RDoc/rdoc.rdoc
Normal file
@@ -0,0 +1,129 @@
|
||||
= \RDoc - Ruby Documentation System
|
||||
|
||||
home :: https://github.com/rdoc/rdoc
|
||||
rdoc :: http://docs.seattlerb.org/rdoc
|
||||
bugs :: https://github.com/rdoc/rdoc/issues
|
||||
code quality :: {<img src="https://codeclimate.com/badge.png" alt="code climate">}[https://codeclimate.com/github/rdoc/rdoc]
|
||||
|
||||
== Description
|
||||
|
||||
RDoc produces HTML and command-line documentation for Ruby projects. RDoc
|
||||
includes the +rdoc+ and +ri+ tools for generating and displaying documentation
|
||||
from the command-line.
|
||||
|
||||
== Generating Documentation
|
||||
|
||||
Once installed, you can create documentation using the +rdoc+ command
|
||||
|
||||
$ rdoc [options] [names...]
|
||||
|
||||
For an up-to-date option summary, type
|
||||
|
||||
$ rdoc --help
|
||||
|
||||
A typical use might be to generate documentation for a package of Ruby
|
||||
source (such as RDoc itself).
|
||||
|
||||
$ rdoc
|
||||
|
||||
This command generates documentation for all the Ruby and C source
|
||||
files in and below the current directory. These will be stored in a
|
||||
documentation tree starting in the subdirectory +doc+.
|
||||
|
||||
You can make this slightly more useful for your readers by having the
|
||||
index page contain the documentation for the primary file. In our
|
||||
case, we could type
|
||||
|
||||
% rdoc --main README.rdoc
|
||||
|
||||
You'll find information on the various formatting tricks you can use
|
||||
in comment blocks in the documentation this generates.
|
||||
|
||||
RDoc uses file extensions to determine how to process each file. File names
|
||||
ending +.rb+ and +.rbw+ are assumed to be Ruby source. Files
|
||||
ending +.c+ are parsed as C files. All other files are assumed to
|
||||
contain just Markup-style markup (with or without leading '#' comment
|
||||
markers). If directory names are passed to RDoc, they are scanned
|
||||
recursively for C and Ruby source files only.
|
||||
|
||||
To generate documentation using +rake+ see RDoc::Task.
|
||||
|
||||
To generate documentation programmatically:
|
||||
|
||||
gem 'rdoc'
|
||||
require 'rdoc/rdoc'
|
||||
|
||||
options = RDoc::Options.new
|
||||
# see RDoc::Options
|
||||
|
||||
rdoc = RDoc::RDoc.new
|
||||
rdoc.document options
|
||||
# see RDoc::RDoc
|
||||
|
||||
== Writing Documentation
|
||||
|
||||
To write documentation for RDoc place a comment above the class, module,
|
||||
method, constant, or attribute you want documented:
|
||||
|
||||
##
|
||||
# This class represents an arbitrary shape by a series of points.
|
||||
|
||||
class Shape
|
||||
|
||||
##
|
||||
# Creates a new shape described by a +polyline+.
|
||||
#
|
||||
# If the +polyline+ does not end at the same point it started at the
|
||||
# first pointed is copied and placed at the end of the line.
|
||||
#
|
||||
# An ArgumentError is raised if the line crosses itself, but shapes may
|
||||
# be concave.
|
||||
|
||||
def initialize polyline
|
||||
# ...
|
||||
end
|
||||
|
||||
end
|
||||
|
||||
The default comment markup format is the RDoc::Markup format.
|
||||
TomDoc[rdoc-ref:RDoc::TomDoc], Markdown[rdoc-ref:RDoc::Markdown] and
|
||||
RD[rdoc-ref:RDoc::RD] format comments are also supported. You can set the
|
||||
default comment format for your entire project by creating a
|
||||
<tt>.rdoc_options</tt> file. See RDoc::Options@Saved+Options for instructions
|
||||
on creating one. You can also set the comment format for a single file
|
||||
through the +:markup:+ directive, but this is only recommended if you wish to
|
||||
switch markup formats. See RDoc::Markup@Other+directives.
|
||||
|
||||
Comments can contain directives that tell RDoc information that it cannot
|
||||
otherwise discover through parsing. See RDoc::Markup@Directives to control
|
||||
what is or is not documented, to define method arguments or to break up
|
||||
methods in a class by topic. See RDoc::Parser::Ruby for directives used to
|
||||
teach RDoc about metaprogrammed methods.
|
||||
|
||||
See RDoc::Parser::C for documenting C extensions with RDoc.
|
||||
|
||||
To determine how well your project is documented run <tt>rdoc -C lib</tt> to
|
||||
get a documentation coverage report. <tt>rdoc -C1 lib</tt> includes parameter
|
||||
names in the documentation coverage report.
|
||||
|
||||
== Bugs
|
||||
|
||||
See CONTRIBUTING@Bugs for information on filing a bug report. It's OK to file
|
||||
a bug report for anything you're having a problem with. If you can't figure
|
||||
out how to make RDoc produce the output you like that is probably a
|
||||
documentation bug.
|
||||
|
||||
== License
|
||||
|
||||
RDoc is Copyright (c) 2001-2003 Dave Thomas, The Pragmatic Programmers.
|
||||
Portions (c) 2007-2011 Eric Hodel. Portions copyright others, see individual
|
||||
files and LEGAL.rdoc for details.
|
||||
|
||||
RDoc is free software, and may be redistributed under the terms specified in
|
||||
LICENSE.rdoc.
|
||||
|
||||
== Warranty
|
||||
|
||||
This software is provided "as is" and without any express or implied
|
||||
warranties, including, without limitation, the implied warranties of
|
||||
merchantability and fitness for a particular purpose.
|
||||
Reference in New Issue
Block a user