mirror of
https://github.com/vale981/emacs-ipython-notebook
synced 2025-03-06 17:41:40 -05:00
Squashed 'lib/markdown-mode/' content from commit 3f11a4a
git-subtree-dir: lib/markdown-mode git-subtree-split: 3f11a4a7609ba2a507ee10f491bdadab28e9b985
This commit is contained in:
commit
b431f57ce1
31 changed files with 14833 additions and 0 deletions
16
.dir-locals.el
Normal file
16
.dir-locals.el
Normal file
|
@ -0,0 +1,16 @@
|
|||
;;; Directory Local Variables
|
||||
;;; See Info node `(emacs) Directory Variables' for more information.
|
||||
|
||||
((nil
|
||||
(require-final-newline . t)
|
||||
;; not tabs in code
|
||||
(indent-tabs-mode)
|
||||
;; checkdoc, one space is enough
|
||||
(sentence-end-double-space . nil)
|
||||
;; checkdoc, don't botch English grammar
|
||||
(checkdoc-arguments-in-order-flag . nil)
|
||||
;; checkdoc, we don't want docs for internal vars
|
||||
(checkdoc-force-docstrings-flag . nil))
|
||||
(emacs-lisp-mode
|
||||
;; remove trailing whitespace
|
||||
(eval . (add-hook 'before-save-hook 'delete-trailing-whitespace nil t))))
|
7
.gitignore
vendored
Normal file
7
.gitignore
vendored
Normal file
|
@ -0,0 +1,7 @@
|
|||
*.elc
|
||||
index.text
|
||||
archive
|
||||
reference
|
||||
attic
|
||||
patches
|
||||
extra
|
14
.travis.yml
Normal file
14
.travis.yml
Normal file
|
@ -0,0 +1,14 @@
|
|||
language: generic
|
||||
sudo: false
|
||||
before_install:
|
||||
- curl -fsSkL https://gist.github.com/rejeep/ebcd57c3af83b049833b/raw > x.sh && source ./x.sh
|
||||
- evm install $EVM_EMACS --use --skip
|
||||
env:
|
||||
- EVM_EMACS=emacs-24.1-travis CL="-l cl-lib-0.5.el"
|
||||
- EVM_EMACS=emacs-24.2-travis CL="-l cl-lib-0.5.el"
|
||||
- EVM_EMACS=emacs-24.3-travis
|
||||
- EVM_EMACS=emacs-24.4-travis
|
||||
- EVM_EMACS=emacs-24.5-travis
|
||||
script:
|
||||
- emacs --version
|
||||
- cd tests && make clean && make test
|
339
LICENSE
Normal file
339
LICENSE
Normal file
|
@ -0,0 +1,339 @@
|
|||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 2, June 1991
|
||||
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
License is intended to guarantee your freedom to share and change free
|
||||
software--to make sure the software is free for all its users. This
|
||||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Lesser General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
this service if you wish), that you receive source code or can get it
|
||||
if you want it, that you can change the software or use pieces of it
|
||||
in new free programs; and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
anyone to deny you these rights or to ask you to surrender the rights.
|
||||
These restrictions translate to certain responsibilities for you if you
|
||||
distribute copies of the software, or if you modify it.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must give the recipients all the rights that
|
||||
you have. You must make sure that they, too, receive or can get the
|
||||
source code. And you must show them these terms so they know their
|
||||
rights.
|
||||
|
||||
We protect your rights with two steps: (1) copyright the software, and
|
||||
(2) offer you this license which gives you legal permission to copy,
|
||||
distribute and/or modify the software.
|
||||
|
||||
Also, for each author's protection and ours, we want to make certain
|
||||
that everyone understands that there is no warranty for this free
|
||||
software. If the software is modified by someone else and passed on, we
|
||||
want its recipients to know that what they have is not the original, so
|
||||
that any problems introduced by others will not reflect on the original
|
||||
authors' reputations.
|
||||
|
||||
Finally, any free program is threatened constantly by software
|
||||
patents. We wish to avoid the danger that redistributors of a free
|
||||
program will individually obtain patent licenses, in effect making the
|
||||
program proprietary. To prevent this, we have made it clear that any
|
||||
patent must be licensed for everyone's free use or not licensed at all.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. This License applies to any program or other work which contains
|
||||
a notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The "Program", below,
|
||||
refers to any such program or work, and a "work based on the Program"
|
||||
means either the Program or any derivative work under copyright law:
|
||||
that is to say, a work containing the Program or a portion of it,
|
||||
either verbatim or with modifications and/or translated into another
|
||||
language. (Hereinafter, translation is included without limitation in
|
||||
the term "modification".) Each licensee is addressed as "you".
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
running the Program is not restricted, and the output from the Program
|
||||
is covered only if its contents constitute a work based on the
|
||||
Program (independent of having been made by running the Program).
|
||||
Whether that is true depends on what the Program does.
|
||||
|
||||
1. You may copy and distribute verbatim copies of the Program's
|
||||
source code as you receive it, in any medium, provided that you
|
||||
conspicuously and appropriately publish on each copy an appropriate
|
||||
copyright notice and disclaimer of warranty; keep intact all the
|
||||
notices that refer to this License and to the absence of any warranty;
|
||||
and give any other recipients of the Program a copy of this License
|
||||
along with the Program.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy, and
|
||||
you may at your option offer warranty protection in exchange for a fee.
|
||||
|
||||
2. You may modify your copy or copies of the Program or any portion
|
||||
of it, thus forming a work based on the Program, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a) You must cause the modified files to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
b) You must cause any work that you distribute or publish, that in
|
||||
whole or in part contains or is derived from the Program or any
|
||||
part thereof, to be licensed as a whole at no charge to all third
|
||||
parties under the terms of this License.
|
||||
|
||||
c) If the modified program normally reads commands interactively
|
||||
when run, you must cause it, when started running for such
|
||||
interactive use in the most ordinary way, to print or display an
|
||||
announcement including an appropriate copyright notice and a
|
||||
notice that there is no warranty (or else, saying that you provide
|
||||
a warranty) and that users may redistribute the program under
|
||||
these conditions, and telling the user how to view a copy of this
|
||||
License. (Exception: if the Program itself is interactive but
|
||||
does not normally print such an announcement, your work based on
|
||||
the Program is not required to print an announcement.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Program,
|
||||
and can be reasonably considered independent and separate works in
|
||||
themselves, then this License, and its terms, do not apply to those
|
||||
sections when you distribute them as separate works. But when you
|
||||
distribute the same sections as part of a whole which is a work based
|
||||
on the Program, the distribution of the whole must be on the terms of
|
||||
this License, whose permissions for other licensees extend to the
|
||||
entire whole, and thus to each and every part regardless of who wrote it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or contest
|
||||
your rights to work written entirely by you; rather, the intent is to
|
||||
exercise the right to control the distribution of derivative or
|
||||
collective works based on the Program.
|
||||
|
||||
In addition, mere aggregation of another work not based on the Program
|
||||
with the Program (or with a work based on the Program) on a volume of
|
||||
a storage or distribution medium does not bring the other work under
|
||||
the scope of this License.
|
||||
|
||||
3. You may copy and distribute the Program (or a work based on it,
|
||||
under Section 2) in object code or executable form under the terms of
|
||||
Sections 1 and 2 above provided that you also do one of the following:
|
||||
|
||||
a) Accompany it with the complete corresponding machine-readable
|
||||
source code, which must be distributed under the terms of Sections
|
||||
1 and 2 above on a medium customarily used for software interchange; or,
|
||||
|
||||
b) Accompany it with a written offer, valid for at least three
|
||||
years, to give any third party, for a charge no more than your
|
||||
cost of physically performing source distribution, a complete
|
||||
machine-readable copy of the corresponding source code, to be
|
||||
distributed under the terms of Sections 1 and 2 above on a medium
|
||||
customarily used for software interchange; or,
|
||||
|
||||
c) Accompany it with the information you received as to the offer
|
||||
to distribute corresponding source code. (This alternative is
|
||||
allowed only for noncommercial distribution and only if you
|
||||
received the program in object code or executable form with such
|
||||
an offer, in accord with Subsection b above.)
|
||||
|
||||
The source code for a work means the preferred form of the work for
|
||||
making modifications to it. For an executable work, complete source
|
||||
code means all the source code for all modules it contains, plus any
|
||||
associated interface definition files, plus the scripts used to
|
||||
control compilation and installation of the executable. However, as a
|
||||
special exception, the source code distributed need not include
|
||||
anything that is normally distributed (in either source or binary
|
||||
form) with the major components (compiler, kernel, and so on) of the
|
||||
operating system on which the executable runs, unless that component
|
||||
itself accompanies the executable.
|
||||
|
||||
If distribution of executable or object code is made by offering
|
||||
access to copy from a designated place, then offering equivalent
|
||||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
4. You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
void, and will automatically terminate your rights under this License.
|
||||
However, parties who have received copies, or rights, from you under
|
||||
this License will not have their licenses terminated so long as such
|
||||
parties remain in full compliance.
|
||||
|
||||
5. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify or
|
||||
distribute the Program or its derivative works. These actions are
|
||||
prohibited by law if you do not accept this License. Therefore, by
|
||||
modifying or distributing the Program (or any work based on the
|
||||
Program), you indicate your acceptance of this License to do so, and
|
||||
all its terms and conditions for copying, distributing or modifying
|
||||
the Program or works based on it.
|
||||
|
||||
6. Each time you redistribute the Program (or any work based on the
|
||||
Program), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute or modify the Program subject to
|
||||
these terms and conditions. You may not impose any further
|
||||
restrictions on the recipients' exercise of the rights granted herein.
|
||||
You are not responsible for enforcing compliance by third parties to
|
||||
this License.
|
||||
|
||||
7. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent issues),
|
||||
conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot
|
||||
distribute so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you
|
||||
may not distribute the Program at all. For example, if a patent
|
||||
license would not permit royalty-free redistribution of the Program by
|
||||
all those who receive copies directly or indirectly through you, then
|
||||
the only way you could satisfy both it and this License would be to
|
||||
refrain entirely from distribution of the Program.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable under
|
||||
any particular circumstance, the balance of the section is intended to
|
||||
apply and the section as a whole is intended to apply in other
|
||||
circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of any
|
||||
such claims; this section has the sole purpose of protecting the
|
||||
integrity of the free software distribution system, which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is willing
|
||||
to distribute software through any other system and a licensee cannot
|
||||
impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
8. If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Program under this License
|
||||
may add an explicit geographical distribution limitation excluding
|
||||
those countries, so that distribution is permitted only in or among
|
||||
countries not thus excluded. In such case, this License incorporates
|
||||
the limitation as if written in the body of this License.
|
||||
|
||||
9. The Free Software Foundation may publish revised and/or new versions
|
||||
of the General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Program
|
||||
specifies a version number of this License which applies to it and "any
|
||||
later version", you have the option of following the terms and conditions
|
||||
either of that version or of any later version published by the Free
|
||||
Software Foundation. If the Program does not specify a version number of
|
||||
this License, you may choose any version ever published by the Free Software
|
||||
Foundation.
|
||||
|
||||
10. If you wish to incorporate parts of the Program into other free
|
||||
programs whose distribution conditions are different, write to the author
|
||||
to ask for permission. For software which is copyrighted by the Free
|
||||
Software Foundation, write to the Free Software Foundation; we sometimes
|
||||
make exceptions for this. Our decision will be guided by the two goals
|
||||
of preserving the free status of all derivatives of our free software and
|
||||
of promoting the sharing and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
|
||||
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
|
||||
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
|
||||
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
|
||||
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
|
||||
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
|
||||
REPAIR OR CORRECTION.
|
||||
|
||||
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
|
||||
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
|
||||
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
|
||||
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
|
||||
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
|
||||
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License along
|
||||
with this program; if not, write to the Free Software Foundation, Inc.,
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If the program is interactive, make it output a short notice like this
|
||||
when it starts in an interactive mode:
|
||||
|
||||
Gnomovision version 69, Copyright (C) year name of author
|
||||
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the appropriate
|
||||
parts of the General Public License. Of course, the commands you use may
|
||||
be called something other than `show w' and `show c'; they could even be
|
||||
mouse-clicks or menu items--whatever suits your program.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or your
|
||||
school, if any, to sign a "copyright disclaimer" for the program, if
|
||||
necessary. Here is a sample; alter the names:
|
||||
|
||||
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
|
||||
`Gnomovision' (which makes passes at compilers) written by James Hacker.
|
||||
|
||||
<signature of Ty Coon>, 1 April 1989
|
||||
Ty Coon, President of Vice
|
||||
|
||||
This General Public License does not permit incorporating your program into
|
||||
proprietary programs. If your program is a subroutine library, you may
|
||||
consider it more useful to permit linking proprietary applications with the
|
||||
library. If this is what you want to do, use the GNU Lesser General
|
||||
Public License instead of this License.
|
38
Makefile
Normal file
38
Makefile
Normal file
|
@ -0,0 +1,38 @@
|
|||
EMACS=emacs
|
||||
|
||||
PACKAGE=markdown-mode
|
||||
|
||||
SOURCE=markdown-mode.el
|
||||
COMPILED=markdown-mode.elc
|
||||
|
||||
VERSION=$(shell cat $(SOURCE) | sed -n 's/^;; Version: \(.*\)/\1/p')
|
||||
|
||||
TEST_FILES=tests/Makefile tests/*.el tests/*.text tests/*.md
|
||||
|
||||
.el.elc:
|
||||
$(EMACS) -q -no-site-file -no-init-file -batch -f batch-byte-compile $<
|
||||
|
||||
all: $(COMPILED)
|
||||
|
||||
.PHONY: dist test
|
||||
|
||||
test:
|
||||
make -C tests test
|
||||
|
||||
clean:
|
||||
rm -f $(COMPILED)
|
||||
make -C tests clean
|
||||
|
||||
dist:
|
||||
DIR=$$(mktemp -d -t "$(PACKAGE)"); \
|
||||
DESTDIR="$$DIR/$(PACKAGE)-$(VERSION)"; \
|
||||
mkdir -p $$DESTDIR; \
|
||||
cp -a $(SOURCE) $$DESTDIR; \
|
||||
mkdir -p $$DESTDIR/tests; \
|
||||
cp -a $(TEST_FILES) $$DESTDIR/tests; \
|
||||
tar zcf $(CURDIR)/$(PACKAGE)-$(VERSION).tar.gz -C $$DIR .; \
|
||||
rm -r $$DIR; \
|
||||
echo "$(PACKAGE)-$(VERSION).tar.gz has been created"
|
||||
|
||||
update: $(COMPILED)
|
||||
cp -a $(SOURCE) $(COMPILED) $(HOME)/.emacs.d/site-lisp
|
891
README.md
Normal file
891
README.md
Normal file
|
@ -0,0 +1,891 @@
|
|||
# Emacs Markdown Mode [![MELPA badge][melpa-badge]][melpa-link] [![MELPA stable badge][melpa-stable-badge]][melpa-stable-link] [![Travis CI Build Status][travis-badge]][travis-link]
|
||||
|
||||
[melpa-link]: https://melpa.org/#/markdown-mode
|
||||
[melpa-stable-link]: https://stable.melpa.org/#/markdown-mode
|
||||
[melpa-badge]: https://melpa.org/packages/markdown-mode-badge.svg
|
||||
[melpa-stable-badge]: https://stable.melpa.org/packages/markdown-mode-badge.svg
|
||||
[travis-link]: https://travis-ci.org/jrblevin/markdown-mode
|
||||
[travis-badge]: https://travis-ci.org/jrblevin/markdown-mode.svg?branch=master
|
||||
|
||||
<!-- This file is autogenerated by webpage.sh from the comments at the top of
|
||||
markdown-mode.el. Make edits there, not here. -->
|
||||
|
||||
markdown-mode is a major mode for editing [Markdown][]-formatted
|
||||
text. The latest stable version is markdown-mode 2.1, released on
|
||||
January 9, 2016. See the [release notes][] for details.
|
||||
markdown-mode is free software, licensed under the GNU GPL.
|
||||
|
||||

|
||||
|
||||
[Markdown]: http://daringfireball.net/projects/markdown/
|
||||
[release notes]: http://jblevins.org/projects/markdown-mode/rev-2-1
|
||||
|
||||
## Installation
|
||||
|
||||
The recommended way to install markdown-mode is to install the package
|
||||
from [MELPA Stable](https://stable.melpa.org/#/markdown-mode)
|
||||
using `package.el`. First, configure `package.el` and the MELPA Stable
|
||||
repository by adding the following to your `.emacs`, `init.el`,
|
||||
or equivalent startup file:
|
||||
|
||||
(require 'package)
|
||||
(add-to-list 'package-archives
|
||||
'("melpa-stable" . "https://stable.melpa.org/packages/"))
|
||||
(package-initialize)
|
||||
|
||||
Then, after restarting Emacs or evaluating the above statements, issue
|
||||
the following command: <kbd>M-x package-install RET markdown-mode RET</kbd>.
|
||||
When installed this way, the major modes `markdown-mode` and `gfm-mode`
|
||||
will be autoloaded and `markdown-mode` will be used for file names
|
||||
ending in either `.md` or `.markdown`.
|
||||
|
||||
Alternatively, if you manage loading packages with [use-package][]
|
||||
then you can automatically install and configure `markdown-mode` by
|
||||
adding a declaration such as this one to your init file (as an
|
||||
example; adjust settings as desired):
|
||||
|
||||
(use-package markdown-mode
|
||||
:ensure t
|
||||
:commands (markdown-mode gfm-mode)
|
||||
:mode (("README\\.md\\'" . gfm-mode)
|
||||
("\\.md\\'" . markdown-mode)
|
||||
("\\.markdown\\'" . markdown-mode))
|
||||
:init (setq markdown-command "multimarkdown"))
|
||||
|
||||
[MELPA Stable]: http://stable.melpa.org/
|
||||
[use-package]: https://github.com/jwiegley/use-package
|
||||
|
||||
**Direct Download**
|
||||
|
||||
Alternatively you can manually download and install markdown-mode.
|
||||
First, download the [latest stable version][markdown-mode.el] and
|
||||
save the file where Emacs can find it (i.e., a directory in your
|
||||
`load-path`). You can then configure `markdown-mode` and `gfm-mode`
|
||||
to load automatically by adding the following to your init file:
|
||||
|
||||
(autoload 'markdown-mode "markdown-mode"
|
||||
"Major mode for editing Markdown files" t)
|
||||
(add-to-list 'auto-mode-alist '("\\.markdown\\'" . markdown-mode))
|
||||
(add-to-list 'auto-mode-alist '("\\.md\\'" . markdown-mode))
|
||||
|
||||
(autoload 'gfm-mode "markdown-mode"
|
||||
"Major mode for editing GitHub Flavored Markdown files" t)
|
||||
(add-to-list 'auto-mode-alist '("README\\.md\\'" . gfm-mode))
|
||||
|
||||
[markdown-mode.el]: http://jblevins.org/projects/markdown-mode/markdown-mode.el
|
||||
|
||||
**Development Version**
|
||||
|
||||
To follow or contribute to markdown-mode development, you can
|
||||
browse or clone the Git repository
|
||||
[on GitHub](https://github.com/jrblevin/markdown-mode):
|
||||
|
||||
git clone https://github.com/jrblevin/markdown-mode.git
|
||||
|
||||
If you prefer to install and use the development version, which may
|
||||
become unstable at some times, you can either clone the Git
|
||||
repository as above or install markdown-mode from
|
||||
[MELPA](https://melpa.org/#/markdown-mode).
|
||||
|
||||
If you clone the repository directly, then make sure that Emacs can
|
||||
find it by adding the following line to your startup file:
|
||||
|
||||
(add-to-list 'load-path "/path/to/markdown-mode/repository")
|
||||
|
||||
**Packaged Installation**
|
||||
|
||||
markdown-mode is also available in several package managers. You
|
||||
may want to confirm that the package you install contains the
|
||||
latest stable version first (and please notify the package
|
||||
maintainer if not).
|
||||
|
||||
* Debian Linux: [elpa-markdown-mode][] and [emacs-goodies-el][]
|
||||
* Ubuntu Linux: [elpa-markdown-mode][elpa-ubuntu] and [emacs-goodies-el][emacs-goodies-el-ubuntu]
|
||||
* RedHat and Fedora Linux: [emacs-goodies][]
|
||||
* NetBSD: [textproc/markdown-mode][]
|
||||
* MacPorts: [markdown-mode.el][macports-package] ([pending][macports-ticket])
|
||||
* FreeBSD: [textproc/markdown-mode.el][freebsd-port]
|
||||
|
||||
[elpa-markdown-mode]: https://packages.debian.org/sid/lisp/elpa-markdown-mode
|
||||
[elpa-ubuntu]: http://packages.ubuntu.com/search?keywords=elpa-markdown-mode
|
||||
[emacs-goodies-el]: http://packages.debian.org/emacs-goodies-el
|
||||
[emacs-goodies-el-ubuntu]: http://packages.ubuntu.com/search?keywords=emacs-goodies-el
|
||||
[emacs-goodies]: https://apps.fedoraproject.org/packages/emacs-goodies
|
||||
[textproc/markdown-mode]: http://pkgsrc.se/textproc/markdown-mode
|
||||
[macports-package]: https://trac.macports.org/browser/trunk/dports/editors/markdown-mode.el/Portfile
|
||||
[macports-ticket]: http://trac.macports.org/ticket/35716
|
||||
[freebsd-port]: http://svnweb.freebsd.org/ports/head/textproc/markdown-mode.el
|
||||
|
||||
**Dependencies**
|
||||
|
||||
`markdown-mode` depends on `cl-lib`, which has been bundled with
|
||||
GNU Emacs since 24.3. Users of GNU Emacs 24.1 and 24.2 can install
|
||||
`cl-lib` with `package.el`.
|
||||
|
||||
## Usage
|
||||
|
||||
Keybindings are grouped by prefixes based on their function. For
|
||||
example, the commands for inserting links are grouped under `C-c
|
||||
C-a`, where the <kbd>C-a</kbd> is a mnemonic for the HTML `<a>` tag. In
|
||||
other cases, the connection to HTML is not direct. For example,
|
||||
commands dealing with headings begin with <kbd>C-c C-t</kbd> (mnemonic:
|
||||
titling). The primary commands in each group will are described
|
||||
below. You can obtain a list of all keybindings by pressing `C-c
|
||||
C-h`. Movement and shifting commands tend to be associated with
|
||||
paired delimiters such as <kbd>M-{</kbd> and <kbd>M-}</kbd> or <kbd>C-c <</kbd> and <kbd>C-c ></kbd>.
|
||||
Outline navigation keybindings the same as in `org-mode`. Finally,
|
||||
commands for running Markdown or doing maintenance on an open file
|
||||
are grouped under the <kbd>C-c C-c</kbd> prefix. The most commonly used
|
||||
commands are described below. You can obtain a list of all
|
||||
keybindings by pressing <kbd>C-c C-h</kbd>.
|
||||
|
||||
* Hyperlinks: <kbd>C-c C-a</kbd>
|
||||
|
||||
In this group, <kbd>C-c C-a l</kbd> inserts an inline link of the form
|
||||
`[text](url)`. The link text is determined as follows. First,
|
||||
if there is an active region (i.e., when transient mark mode is
|
||||
on and the mark is active), use it as the link text. Second,
|
||||
if the point is at a word, use that word as the link text. In
|
||||
these two cases, the original text will be replaced with the
|
||||
link and point will be left at the position for inserting a
|
||||
URL. Otherwise, insert empty link markup and place the point
|
||||
for inserting the link text.
|
||||
|
||||
<kbd>C-c C-a L</kbd> inserts a reference link of the form `[text][label]`
|
||||
and, optionally, a corresponding reference label definition.
|
||||
The link text is determined in the same way as with an inline
|
||||
link (using the region, when active, or the word at the point),
|
||||
but instead of inserting empty markup as a last resort, the
|
||||
link text will be read from the minibuffer. The reference
|
||||
label will be read from the minibuffer in both cases, with
|
||||
completion from the set of currently defined references. To
|
||||
create an implicit reference link, press <kbd>RET</kbd> to accept the
|
||||
default, an empty label. If the entered referenced label is
|
||||
not defined, additionally prompt for the URL and (optional)
|
||||
title. If a URL is provided, a reference definition will be
|
||||
inserted in accordance with `markdown-reference-location`.
|
||||
If a title is given, it will be added to the end of the
|
||||
reference definition and will be used to populate the title
|
||||
attribute when converted to XHTML.
|
||||
|
||||
<kbd>C-c C-a u</kbd> inserts a bare url, delimited by angle brackets. When
|
||||
there is an active region, the text in the region is used as the
|
||||
URL. If the point is at a URL, that url is used. Otherwise,
|
||||
insert angle brackets and position the point in between them
|
||||
for inserting the URL.
|
||||
|
||||
<kbd>C-c C-a f</kbd> inserts a footnote marker at the point, inserts a
|
||||
footnote definition below, and positions the point for
|
||||
inserting the footnote text. Note that footnotes are an
|
||||
extension to Markdown and are not supported by all processors.
|
||||
|
||||
<kbd>C-c C-a w</kbd> behaves much like the inline link insertion command
|
||||
and inserts a wiki link of the form `[[WikiLink]]`. If there
|
||||
is an active region, use the region as the link text. If the
|
||||
point is at a word, use the word as the link text. If there is
|
||||
no active region and the point is not at word, simply insert
|
||||
link markup. Note that wiki links are an extension to Markdown
|
||||
and are not supported by all processors.
|
||||
|
||||
* Images: <kbd>C-c C-i</kbd>
|
||||
|
||||
<kbd>C-c C-i i</kbd> inserts markup for an inline image, using the
|
||||
active region or the word at point, if any, as the alt text.
|
||||
<kbd>C-c C-i I</kbd> behaves similarly and inserts a reference-style
|
||||
image.
|
||||
|
||||
Local images associated with image links may be displayed
|
||||
inline in the buffer by pressing <kbd>C-c C-i C-t</kbd>
|
||||
(`markdown-toggle-inline-images`). This is a toggle command, so
|
||||
pressing this once again will remove inline images.
|
||||
|
||||
* Styles: <kbd>C-c C-s</kbd>
|
||||
|
||||
<kbd>C-c C-s e</kbd> inserts markup to make a region or word italic (<kbd>e</kbd>
|
||||
for `<em>` or emphasis). If there is an active region, make
|
||||
the region italic. If the point is at a non-italic word, make
|
||||
the word italic. If the point is at an italic word or phrase,
|
||||
remove the italic markup. Otherwise, simply insert italic
|
||||
delimiters and place the cursor in between them. Similarly,
|
||||
use <kbd>C-c C-s s</kbd> for bold (`<strong>`), <kbd>C-c C-s c</kbd> for
|
||||
inline code (`<code>`), and <kbd>C-c C-s k</kbd> for inserting `<kbd>`
|
||||
tags.
|
||||
|
||||
<kbd>C-c C-s b</kbd> inserts a blockquote using the active region, if any,
|
||||
or starts a new blockquote. <kbd>C-c C-s C-b</kbd> is a variation which
|
||||
always operates on the region, regardless of whether it is
|
||||
active or not. The appropriate amount of indentation, if any,
|
||||
is calculated automatically given the surrounding context, but
|
||||
may be adjusted later using the region indentation commands.
|
||||
|
||||
<kbd>C-c C-s p</kbd> behaves similarly for inserting preformatted code
|
||||
blocks, with <kbd>C-c C-s C-p</kbd> being the region-only counterpart.
|
||||
|
||||
* Headings: <kbd>C-c C-t</kbd>
|
||||
|
||||
All heading insertion commands use the text in the active
|
||||
region, if any, as the heading text. Otherwise, if the current
|
||||
line is not blank, they use the text on the current line.
|
||||
Finally, the setext commands will prompt for heading text if
|
||||
there is no active region and the current line is blank.
|
||||
|
||||
<kbd>C-c C-t h</kbd> inserts a heading with automatically chosen type and
|
||||
level (both determined by the previous heading). <kbd>C-c C-t H</kbd>
|
||||
behaves similarly, but uses setext (underlined) headings when
|
||||
possible, still calculating the level automatically.
|
||||
In cases where the automatically-determined level is not what
|
||||
you intended, the level can be quickly promoted or demoted
|
||||
(as described below). Alternatively, a <kbd>C-u</kbd> prefix can be
|
||||
given to insert a heading promoted by one level or a <kbd>C-u C-u</kbd>
|
||||
prefix can be given to insert a heading demoted by one level.
|
||||
|
||||
To insert a heading of a specific level and type, use <kbd>C-c C-t 1</kbd>
|
||||
through <kbd>C-c C-t 6</kbd> for atx (hash mark) headings and <kbd>C-c C-t !</kbd> or
|
||||
<kbd>C-c C-t @</kbd> for setext headings of level one or two, respectively.
|
||||
Note that <kbd>!</kbd> is <kbd>S-1</kbd> and <kbd>@</kbd> is <kbd>S-2</kbd>.
|
||||
|
||||
If the point is at a heading, these commands will replace the
|
||||
existing markup in order to update the level and/or type of the
|
||||
heading. To remove the markup of the heading at the point,
|
||||
press <kbd>C-c C-k</kbd> to kill the heading and press <kbd>C-y</kbd> to yank the
|
||||
heading text back into the buffer.
|
||||
|
||||
* Horizontal Rules: <kbd>C-c -</kbd>
|
||||
|
||||
<kbd>C-c -</kbd> inserts a horizontal rule. By default, insert the
|
||||
first string in the list `markdown-hr-strings` (the most
|
||||
prominent rule). With a <kbd>C-u</kbd> prefix, insert the last string.
|
||||
With a numeric prefix <kbd>N</kbd>, insert the string in position <kbd>N</kbd>
|
||||
(counting from 1).
|
||||
|
||||
* Markdown and Maintenance Commands: <kbd>C-c C-c</kbd>
|
||||
|
||||
*Compile:* <kbd>C-c C-c m</kbd> will run Markdown on the current buffer
|
||||
and show the output in another buffer. *Preview*: <kbd>C-c C-c p</kbd>
|
||||
runs Markdown on the current buffer and previews, stores the
|
||||
output in a temporary file, and displays the file in a browser.
|
||||
*Export:* <kbd>C-c C-c e</kbd> will run Markdown on the current buffer
|
||||
and save the result in the file `basename.html`, where
|
||||
`basename` is the name of the Markdown file with the extension
|
||||
removed. *Export and View:* press <kbd>C-c C-c v</kbd> to export the
|
||||
file and view it in a browser. *Open:* <kbd>C-c C-c o</kbd> will open
|
||||
the Markdown source file directly using `markdown-open-command`.
|
||||
*Live Export*: Press <kbd>C-c C-c l</kbd> to turn on
|
||||
`markdown-live-preview-mode` to view the exported output
|
||||
side-by-side with the source Markdown. **For all export commands,
|
||||
the output file will be overwritten without notice.**
|
||||
`markdown-live-preview-window-function` can be customized to open
|
||||
in a browser other than `eww`.
|
||||
|
||||
To summarize:
|
||||
|
||||
- <kbd>C-c C-c m</kbd>: `markdown-command` > `*markdown-output*` buffer.
|
||||
- <kbd>C-c C-c p</kbd>: `markdown-command` > temporary file > browser.
|
||||
- <kbd>C-c C-c e</kbd>: `markdown-command` > `basename.html`.
|
||||
- <kbd>C-c C-c v</kbd>: `markdown-command` > `basename.html` > browser.
|
||||
- <kbd>C-c C-c w</kbd>: `markdown-command` > kill ring.
|
||||
- <kbd>C-c C-c o</kbd>: `markdown-open-command`.
|
||||
- <kbd>C-c C-c l</kbd>: `markdown-live-preview-mode` > `*eww*` buffer.
|
||||
|
||||
<kbd>C-c C-c c</kbd> will check for undefined references. If there are
|
||||
any, a small buffer will open with a list of undefined
|
||||
references and the line numbers on which they appear. In Emacs
|
||||
22 and greater, selecting a reference from this list and
|
||||
pressing <kbd>RET</kbd> will insert an empty reference definition at the
|
||||
end of the buffer. Similarly, selecting the line number will
|
||||
jump to the corresponding line.
|
||||
|
||||
<kbd>C-c C-c n</kbd> renumbers any ordered lists in the buffer that are
|
||||
out of sequence.
|
||||
|
||||
<kbd>C-c C-c ]</kbd> completes all headings and normalizes all horizontal
|
||||
rules in the buffer.
|
||||
|
||||
* Following Links: <kbd>C-c C-o</kbd>
|
||||
|
||||
Press <kbd>C-c C-o</kbd> when the point is on an inline or reference
|
||||
link to open the URL in a browser. When the point is at a
|
||||
wiki link, open it in another buffer (in the current window,
|
||||
or in the other window with the <kbd>C-u</kbd> prefix). Use <kbd>M-p</kbd> and
|
||||
<kbd>M-n</kbd> to quickly jump to the previous or next link of any type.
|
||||
|
||||
* Jumping: <kbd>C-c C-l</kbd>
|
||||
|
||||
Use <kbd>C-c C-l</kbd> to jump from the object at point to its counterpart
|
||||
elsewhere in the text, when possible. Jumps between reference
|
||||
links and definitions; between footnote markers and footnote
|
||||
text. If more than one link uses the same reference name, a
|
||||
new buffer will be created containing clickable buttons for jumping
|
||||
to each link. You may press <kbd>TAB</kbd> or <kbd>S-TAB</kbd> to jump between
|
||||
buttons in this window.
|
||||
|
||||
* Promotion and Demotion: <kbd>C-c C--</kbd> and <kbd>C-c C-=</kbd>
|
||||
|
||||
Headings, horizontal rules, and list items can be promoted and
|
||||
demoted, as well as bold and italic text. For headings,
|
||||
"promotion" means *decreasing* the level (i.e., moving from
|
||||
`<h2>` to `<h1>`) while "demotion" means *increasing* the
|
||||
level. For horizontal rules, promotion and demotion means
|
||||
moving backward or forward through the list of rule strings in
|
||||
`markdown-hr-strings`. For bold and italic text, promotion and
|
||||
demotion means changing the markup from underscores to asterisks.
|
||||
Press <kbd>C-c C--</kbd> or <kbd>M-LEFT</kbd> to promote the element at the point
|
||||
if possible.
|
||||
|
||||
To remember these commands, note that <kbd>-</kbd> is for decreasing the
|
||||
level (promoting), and <kbd>=</kbd> (on the same key as <kbd>+</kbd>) is for
|
||||
increasing the level (demoting). Similarly, the left and right
|
||||
arrow keys indicate the direction that the atx heading markup
|
||||
is moving in when promoting or demoting.
|
||||
|
||||
* Completion: <kbd>C-c C-]</kbd>
|
||||
|
||||
Complete markup is in normalized form, which means, for
|
||||
example, that the underline portion of a setext header is the
|
||||
same length as the heading text, or that the number of leading
|
||||
and trailing hash marks of an atx header are equal and that
|
||||
there is no extra whitespace in the header text. <kbd>C-c C-]</kbd>
|
||||
completes the markup at the point, if it is determined to be
|
||||
incomplete.
|
||||
|
||||
* Editing Lists: <kbd>M-RET</kbd>, <kbd>M-UP</kbd>, <kbd>M-DOWN</kbd>, <kbd>M-LEFT</kbd>, and <kbd>M-RIGHT</kbd>
|
||||
|
||||
New list items can be inserted with <kbd>M-RET</kbd> or <kbd>C-c C-j</kbd>. This
|
||||
command determines the appropriate marker (one of the possible
|
||||
unordered list markers or the next number in sequence for an
|
||||
ordered list) and indentation level by examining nearby list
|
||||
items. If there is no list before or after the point, start a
|
||||
new list. Prefix this command by <kbd>C-u</kbd> to decrease the
|
||||
indentation by one level. Prefix this command by <kbd>C-u C-u</kbd> to
|
||||
increase the indentation by one level.
|
||||
|
||||
Existing list items can be moved up or down with <kbd>M-UP</kbd> or
|
||||
<kbd>M-DOWN</kbd> and indented or exdented with <kbd>M-RIGHT</kbd> or <kbd>M-LEFT</kbd>.
|
||||
|
||||
* Editing Subtrees: <kbd>M-S-UP</kbd>, <kbd>M-S-DOWN</kbd>, <kbd>M-S-LEFT</kbd>, and <kbd>M-S-RIGHT</kbd>
|
||||
|
||||
Entire subtrees of ATX headings can be promoted and demoted
|
||||
with <kbd>M-S-LEFT</kbd> and <kbd>M-S-RIGHT</kbd>, which mirror the bindings
|
||||
for promotion and demotion of list items. Similarly, subtrees
|
||||
can be moved up and down with <kbd>M-S-UP</kbd> and <kbd>M-S-DOWN</kbd>.
|
||||
|
||||
Please note the following "boundary" behavior for promotion and
|
||||
demotion. Any level-six headings will not be demoted further
|
||||
(i.e., they remain at level six, since Markdown and HTML define
|
||||
only six levels) and any level-one headings will promoted away
|
||||
entirely (i.e., heading markup will be removed, since a
|
||||
level-zero heading is not defined).
|
||||
|
||||
* Shifting the Region: <kbd>C-c <</kbd> and <kbd>C-c ></kbd>
|
||||
|
||||
Text in the region can be indented or exdented as a group using
|
||||
<kbd>C-c ></kbd> to indent to the next indentation point (calculated in
|
||||
the current context), and <kbd>C-c <</kbd> to exdent to the previous
|
||||
indentation point. These keybindings are the same as those for
|
||||
similar commands in `python-mode`.
|
||||
|
||||
* Killing Elements: <kbd>C-c C-k</kbd>
|
||||
|
||||
Press <kbd>C-c C-k</kbd> to kill the thing at point and add important
|
||||
text, without markup, to the kill ring. Possible things to
|
||||
kill include (roughly in order of precedece): inline code,
|
||||
headings, horizonal rules, links (add link text to kill ring),
|
||||
images (add alt text to kill ring), angle URIs, email
|
||||
addresses, bold, italics, reference definitions (add URI to
|
||||
kill ring), footnote markers and text (kill both marker and
|
||||
text, add text to kill ring), and list items.
|
||||
|
||||
* Outline Navigation: <kbd>C-c C-n</kbd>, <kbd>C-c C-p</kbd>, <kbd>C-c C-f</kbd>, <kbd>C-c C-b</kbd>, and <kbd>C-c C-u</kbd>
|
||||
|
||||
Navigation between headings is possible using `outline-mode`.
|
||||
Use <kbd>C-c C-n</kbd> and <kbd>C-c C-p</kbd> to move between the next and previous
|
||||
visible headings. Similarly, <kbd>C-c C-f</kbd> and <kbd>C-c C-b</kbd> move to the
|
||||
next and previous visible headings at the same level as the one
|
||||
at the point. Finally, <kbd>C-c C-u</kbd> will move up to a lower-level
|
||||
(higher precedence) visible heading.
|
||||
|
||||
* Movement by Paragraph or Block: <kbd>M-{</kbd> and <kbd>M-}</kbd>
|
||||
|
||||
The definition of a "paragraph" is slightly different in
|
||||
markdown-mode than, say, text-mode, because markdown-mode
|
||||
supports filling for list items and respects hard line breaks,
|
||||
both of which break paragraphs. So, markdown-mode overrides
|
||||
the usual paragraph navigation commands <kbd>M-{</kbd> and <kbd>M-}</kbd> so that
|
||||
with a <kbd>C-u</kbd> prefix, these commands jump to the beginning or
|
||||
end of an entire block of text, respectively, where "blocks"
|
||||
are separated by one or more lines.
|
||||
|
||||
* Movement by Defun: <kbd>C-M-a</kbd>, <kbd>C-M-e</kbd>, and <kbd>C-M-h</kbd>
|
||||
|
||||
The usual Emacs commands can be used to move by defuns
|
||||
(top-level major definitions). In markdown-mode, a defun is a
|
||||
section. As usual, <kbd>C-M-a</kbd> will move the point to the
|
||||
beginning of the current or preceding defun, <kbd>C-M-e</kbd> will move
|
||||
to the end of the current or following defun, and <kbd>C-M-h</kbd> will
|
||||
put the region around the entire defun.
|
||||
|
||||
As noted, many of the commands above behave differently depending
|
||||
on whether Transient Mark mode is enabled or not. When it makes
|
||||
sense, if Transient Mark mode is on and the region is active, the
|
||||
command applies to the text in the region (e.g., <kbd>C-c C-s s</kbd> makes the
|
||||
region bold). For users who prefer to work outside of Transient
|
||||
Mark mode, since Emacs 22 it can be enabled temporarily by pressing
|
||||
<kbd>C-SPC C-SPC</kbd>. When this is not the case, many commands then
|
||||
proceed to look work with the word or line at the point.
|
||||
|
||||
When applicable, commands that specifically act on the region even
|
||||
outside of Transient Mark mode have the same keybinding as their
|
||||
standard counterpart, but the letter is uppercase. For example,
|
||||
`markdown-insert-blockquote` is bound to <kbd>C-c C-s b</kbd> and only acts on
|
||||
the region in Transient Mark mode while `markdown-blockquote-region`
|
||||
is bound to <kbd>C-c C-s B</kbd> and always applies to the region (when nonempty).
|
||||
|
||||
Note that these region-specific functions are useful in many
|
||||
cases where it may not be obvious. For example, yanking text from
|
||||
the kill ring sets the mark at the beginning of the yanked text
|
||||
and moves the point to the end. Therefore, the (inactive) region
|
||||
contains the yanked text. So, <kbd>C-y</kbd> followed by <kbd>C-c C-s C-b</kbd> will
|
||||
yank text and turn it into a blockquote.
|
||||
|
||||
markdown-mode attempts to be flexible in how it handles
|
||||
indentation. When you press <kbd>TAB</kbd> repeatedly, the point will cycle
|
||||
through several possible indentation levels corresponding to things
|
||||
you might have in mind when you press <kbd>RET</kbd> at the end of a line or
|
||||
<kbd>TAB</kbd>. For example, you may want to start a new list item,
|
||||
continue a list item with hanging indentation, indent for a nested
|
||||
pre block, and so on. Exdention is handled similarly when backspace
|
||||
is pressed at the beginning of the non-whitespace portion of a line.
|
||||
|
||||
markdown-mode supports outline-minor-mode as well as org-mode-style
|
||||
visibility cycling for atx- or hash-style headings. There are two
|
||||
types of visibility cycling: Pressing <kbd>S-TAB</kbd> cycles globally between
|
||||
the table of contents view (headings only), outline view (top-level
|
||||
headings only), and the full document view. Pressing <kbd>TAB</kbd> while the
|
||||
point is at a heading will cycle through levels of visibility for the
|
||||
subtree: completely folded, visible children, and fully visible.
|
||||
Note that mixing hash and underline style headings will give undesired
|
||||
results.
|
||||
|
||||
## Customization
|
||||
|
||||
Although no configuration is *necessary* there are a few things
|
||||
that can be customized. The <kbd>M-x customize-mode</kbd> command
|
||||
provides an interface to all of the possible customizations:
|
||||
|
||||
* `markdown-command` - the command used to run Markdown (default:
|
||||
`markdown`). This variable may be customized to pass
|
||||
command-line options to your Markdown processor of choice.
|
||||
|
||||
* `markdown-command-needs-filename` - set to <kbd>t</kbd> if
|
||||
`markdown-command` does not accept standard input (default:
|
||||
`nil`). When `nil`, `markdown-mode` will pass the Markdown
|
||||
content to `markdown-command` using standard input (`stdin`).
|
||||
When set to <kbd>t</kbd>, `markdown-mode` will pass the name of the file
|
||||
as the final command-line argument to `markdown-command`. Note
|
||||
that in the latter case, you will only be able to run
|
||||
`markdown-command` from buffers which are visiting a file.
|
||||
|
||||
* `markdown-open-command` - the command used for calling a standalone
|
||||
Markdown previewer which is capable of opening Markdown source files
|
||||
directly (default: `nil`). This command will be called
|
||||
with a single argument, the filename of the current buffer.
|
||||
A representative program is the Mac app [Marked 2][], a
|
||||
live-updating Markdown previewer which can be [called from a
|
||||
simple shell script](http://jblevins.org/log/marked-2-command).
|
||||
|
||||
* `markdown-hr-strings` - list of strings to use when inserting
|
||||
horizontal rules. Different strings will not be distinguished
|
||||
when converted to HTML--they will all be converted to
|
||||
`<hr/>`--but they may add visual distinction and style to plain
|
||||
text documents. To maintain some notion of promotion and
|
||||
demotion, keep these sorted from largest to smallest.
|
||||
|
||||
* `markdown-bold-underscore` - set to a non-nil value to use two
|
||||
underscores when inserting bold text instead of two asterisks
|
||||
(default: `nil`).
|
||||
|
||||
* `markdown-italic-underscore` - set to a non-nil value to use
|
||||
underscores when inserting italic text instead of asterisks
|
||||
(default: `nil`).
|
||||
|
||||
* `markdown-asymmetric-header` - set to a non-nil value to use
|
||||
asymmetric header styling, placing header characters only on
|
||||
the left of headers (default: `nil`).
|
||||
|
||||
* `markdown-header-scaling` - set to a non-nil value to use
|
||||
a variable-pitch font for headings where the size corresponds
|
||||
to the level of the heading (default: `nil`).
|
||||
|
||||
* `markdown-header-scaling-values` - list of scaling values,
|
||||
relative to baseline, for headers of levels one through six,
|
||||
used when `markdown-header-scaling` is non-nil
|
||||
(default: `(list 1.8 1.4 1.2 1.0 1.0 1.0)`).
|
||||
|
||||
* `markdown-list-indent-width` - depth of indentation for lists
|
||||
when inserting, promoting, and demoting list items (default: 4).
|
||||
|
||||
* `markdown-indent-function` - the function to use for automatic
|
||||
indentation (default: `markdown-indent-line`).
|
||||
|
||||
* `markdown-indent-on-enter` - set to a non-nil value to
|
||||
automatically indent new lines when the enter key is pressed
|
||||
(default: <kbd>t</kbd>)
|
||||
|
||||
* `markdown-enable-wiki-links` - syntax highlighting for wiki
|
||||
links (default: `nil`). Set this to a non-nil value to turn on
|
||||
wiki link support by default. Wiki link support can be toggled
|
||||
later using the function `markdown-toggle-wiki-links`."
|
||||
|
||||
* `markdown-wiki-link-alias-first` - set to a non-nil value to
|
||||
treat aliased wiki links like `[[link text|PageName]]`
|
||||
(default: <kbd>t</kbd>). When set to nil, they will be treated as
|
||||
`[[PageName|link text]]`.
|
||||
|
||||
* `markdown-uri-types` - a list of protocol schemes (e.g., "http")
|
||||
for URIs that `markdown-mode` should highlight.
|
||||
|
||||
* `markdown-enable-math` - syntax highlighting for LaTeX
|
||||
fragments (default: `nil`). Set this to <kbd>t</kbd> to turn on math
|
||||
support by default. Math support can be enabled, disabled, or
|
||||
toggled later using the function `markdown-toggle-math`."
|
||||
|
||||
* `markdown-css-paths` - CSS files to link to in XHTML output
|
||||
(default: `nil`).
|
||||
|
||||
* `markdown-content-type` - when set to a nonempty string, an
|
||||
`http-equiv` attribute will be included in the XHTML `<head>`
|
||||
block (default: `""`). If needed, the suggested values are
|
||||
`application/xhtml+xml` or `text/html`. See also:
|
||||
`markdown-coding-system`.
|
||||
|
||||
* `markdown-coding-system` - used for specifying the character
|
||||
set identifier in the `http-equiv` attribute when included
|
||||
(default: `nil`). See `markdown-content-type`, which must
|
||||
be set before this variable has any effect. When set to `nil`,
|
||||
`buffer-file-coding-system` will be used to automatically
|
||||
determine the coding system string (falling back to
|
||||
`iso-8859-1` when unavailable). Common settings are `utf-8`
|
||||
and `iso-latin-1`.
|
||||
|
||||
* `markdown-xhtml-header-content` - additional content to include
|
||||
in the XHTML `<head>` block (default: `""`).
|
||||
|
||||
* `markdown-xhtml-standalone-regexp` - a regular expression which
|
||||
`markdown-mode` uses to determine whether the output of
|
||||
`markdown-command` is a standalone XHTML document or an XHTML
|
||||
fragment (default: `"^\\(<\\?xml\\|<!DOCTYPE\\|<html\\)"`). If
|
||||
this regular expression not matched in the first five lines of
|
||||
output, `markdown-mode` assumes the output is a fragment and
|
||||
adds a header and footer.
|
||||
|
||||
* `markdown-link-space-sub-char` - a character to replace spaces
|
||||
when mapping wiki links to filenames (default: `"_"`).
|
||||
For example, use an underscore for compatibility with the
|
||||
Python Markdown WikiLinks extension. In `gfm-mode`, this is
|
||||
set to `"-"` to conform with GitHub wiki links.
|
||||
|
||||
* `markdown-reference-location` - where to insert reference
|
||||
definitions (default: `header`). The possible locations are
|
||||
the end of the document (`end`), after the current block
|
||||
(`immediately`), before the next header (`header`).
|
||||
|
||||
* `markdown-footnote-location` - where to insert footnote text
|
||||
(default: `end`). The set of location options is the same as
|
||||
for `markdown-reference-location`.
|
||||
|
||||
* `markdown-nested-imenu-heading-index` - Use nested imenu
|
||||
heading instead of a flat index (default: `nil`). A nested
|
||||
index may provide more natural browsing from the menu, but a
|
||||
flat list may allow for faster keyboard navigation via tab
|
||||
completion.
|
||||
|
||||
* `comment-auto-fill-only-comments` - variable is made
|
||||
buffer-local and set to `nil` by default. In programming
|
||||
language modes, when this variable is non-nil, only comments
|
||||
will be filled by auto-fill-mode. However, comments in
|
||||
Markdown documents are rare and the most users probably intend
|
||||
for the actual content of the document to be filled. Making
|
||||
this variable buffer-local allows `markdown-mode` to override
|
||||
the default behavior induced when the global variable is non-nil.
|
||||
|
||||
* `markdown-gfm-additional-languages`, - additional languages to
|
||||
make available, aside from those predefined in
|
||||
`markdown-gfm-recognized-languages`, when inserting GFM code
|
||||
blocks (default: `nil`). Language strings must have be trimmed
|
||||
of whitespace and not contain any curly braces. They may be of
|
||||
arbitrary capitalization, though.
|
||||
|
||||
* `markdown-gfm-use-electric-backquote` - use
|
||||
`markdown-electric-backquote` for interactive insertion of GFM
|
||||
code blocks when backquote is pressed three times (default: <kbd>t</kbd>).
|
||||
|
||||
* `markdown-make-gfm-checkboxes-buttons` - Whether GitHub
|
||||
Flavored Markdown style task lists (checkboxes) should be
|
||||
turned into buttons that can be toggled with mouse-1 or RET. If
|
||||
non-nil (default), then buttons are enabled. This works in
|
||||
`markdown-mode` as well as `gfm-mode`.
|
||||
|
||||
Additionally, the faces used for syntax highlighting can be modified to
|
||||
your liking by issuing <kbd>M-x customize-group RET markdown-faces</kbd>
|
||||
or by using the "Markdown Faces" link at the bottom of the mode
|
||||
customization screen.
|
||||
|
||||
[Marked 2]: https://itunes.apple.com/us/app/marked-2/id890031187?mt=12&uo=4&at=11l5Vs&ct=mm
|
||||
|
||||
## Extensions
|
||||
|
||||
Besides supporting the basic Markdown syntax, Markdown Mode also
|
||||
includes syntax highlighting for `[[Wiki Links]]`. This can be
|
||||
enabled by setting `markdown-enable-wiki-links` to a non-nil value.
|
||||
Wiki links may be followed by pressing <kbd>C-c C-o</kbd> when the point
|
||||
is at a wiki link. Use <kbd>M-p</kbd> and <kbd>M-n</kbd> to quickly jump to the
|
||||
previous and next links (including links of other types).
|
||||
Aliased or piped wiki links of the form `[[link text|PageName]]`
|
||||
are also supported. Since some wikis reverse these components, set
|
||||
`markdown-wiki-link-alias-first` to nil to treat them as
|
||||
`[[PageName|link text]]`. If `markdown-wiki-link-fontify-missing`
|
||||
is also non-nil, Markdown Mode will highlight wiki links with
|
||||
missing target file in a different color. By default, Markdown
|
||||
Mode only searches for target files in the current directory.
|
||||
Sequential parent directory search (as in [Ikiwiki][]) can be
|
||||
enabled by setting `markdown-wiki-link-search-parent-directories`
|
||||
to a non-nil value.
|
||||
|
||||
[Ikiwiki]: https://ikiwiki.info
|
||||
|
||||
[SmartyPants][] support is possible by customizing `markdown-command`.
|
||||
If you install `SmartyPants.pl` at, say, `/usr/local/bin/smartypants`,
|
||||
then you can set `markdown-command` to `"markdown | smartypants"`.
|
||||
You can do this either by using <kbd>M-x customize-group markdown</kbd>
|
||||
or by placing the following in your `.emacs` file:
|
||||
|
||||
(setq markdown-command "markdown | smartypants")
|
||||
|
||||
[SmartyPants]: http://daringfireball.net/projects/smartypants/
|
||||
|
||||
Syntax highlighting for mathematical expressions written
|
||||
in LaTeX (only expressions denoted by `$..$`, `$$..$$`, or `\[..\]`)
|
||||
can be enabled by setting `markdown-enable-math` to a non-nil value,
|
||||
either via customize or by placing `(setq markdown-enable-math t)`
|
||||
in `.emacs`, and then restarting Emacs or calling
|
||||
`markdown-reload-extensions`.
|
||||
|
||||
## GitHub Flavored Markdown (GFM)
|
||||
|
||||
A [GitHub Flavored Markdown][GFM] mode, `gfm-mode`, is also
|
||||
available. The GitHub implementation differs slightly from
|
||||
standard Markdown in that it supports things like different
|
||||
behavior for underscores inside of words, automatic linking of
|
||||
URLs, strikethrough text, and fenced code blocks with an optional
|
||||
language keyword.
|
||||
|
||||
The GFM-specific features above apply to `README.md` files, wiki
|
||||
pages, and other Markdown-formatted files in repositories on
|
||||
GitHub. GitHub also enables [additional features][GFM comments] for
|
||||
writing on the site (for issues, pull requests, messages, etc.)
|
||||
that are further extensions of GFM. These features include task
|
||||
lists (checkboxes), newlines corresponding to hard line breaks,
|
||||
auto-linked references to issues and commits, wiki links, and so
|
||||
on. To make matters more confusing, although task lists are not
|
||||
part of [GFM proper][GFM], [since 2014][] they are rendered (in a
|
||||
read-only fashion) in all Markdown documents in repositories on the
|
||||
site. These additional extensions are supported to varying degrees
|
||||
by `markdown-mode` and `gfm-mode` as described below.
|
||||
|
||||
* **URL autolinking:** Both `markdown-mode` and `gfm-mode` support
|
||||
highlighting of URLs without angle brackets.
|
||||
|
||||
* **Multiple underscores in words:** You must enable `gfm-mode` to
|
||||
toggle support for underscores inside of words. In this mode
|
||||
variable names such as `a_test_variable` will not trigger
|
||||
emphasis (italics).
|
||||
|
||||
* **Fenced code blocks:** Code blocks quoted with backticks, with
|
||||
optional programming language keywords, are highlighted in
|
||||
both `markdown-mode` and `gfm-mode`. They can be inserted with
|
||||
<kbd>C-c C-s P</kbd>. If there is an active region, the text in the
|
||||
region will be placed inside the code block. You will be
|
||||
prompted for the name of the language, but may press enter to
|
||||
continue without naming a language.
|
||||
|
||||
* **Strikethrough:** Strikethrough text is only supported in
|
||||
`gfm-mode` and can be inserted (and toggled) using <kbd>C-c C-s d</kbd>.
|
||||
Following the mnemonics for the other style keybindings, the
|
||||
letter <kbd>d</kbd> coincides with the HTML tag `<del>`.
|
||||
|
||||
* **Task lists:** GFM task lists will be rendered as checkboxes
|
||||
(Emacs buttons) in both `markdown-mode` and `gfm-mode` when
|
||||
`markdown-make-gfm-checkboxes-buttons` is set to a non-nil value
|
||||
(and it is set to t by default). These checkboxes can be
|
||||
toggled by clicking `mouse-1` or pressing <kbd>RET</kbd> over the button.
|
||||
|
||||
* **Wiki links:** Generic wiki links are supported in
|
||||
`markdown-mode`, but in `gfm-mode` specifically they will be
|
||||
treated as they are on GitHub: spaces will be replaced by hyphens
|
||||
in filenames and the first letter of the filename will be
|
||||
capitalized. For example, `[[wiki link]]` will map to a file
|
||||
named `Wiki-link` with the same extension as the current file.
|
||||
|
||||
* **Newlines:** Neither `markdown-mode` nor `gfm-mode` do anything
|
||||
specifically with respect to newline behavior. If you use
|
||||
`gfm-mode` mostly to write text for comments or issues on the
|
||||
GitHub site--where newlines are significant and correspond to
|
||||
hard line breaks--then you may want to enable `visual-line-mode`
|
||||
for line wrapping in buffers. You can do this with a
|
||||
`gfm-mode-hook` as follows:
|
||||
|
||||
;; Use visual-line-mode in gfm-mode
|
||||
(defun my-gfm-mode-hook ()
|
||||
(visual-line-mode 1))
|
||||
(add-hook 'gfm-mode-hook 'my-gfm-mode-hook)
|
||||
|
||||
* **Preview:** GFM-specific preview can be powered by setting
|
||||
`markdown-command` to use [Docter][]. This may also be
|
||||
configured to work with [Marked 2][] for `markdown-open-command`.
|
||||
|
||||
[GFM]: http://github.github.com/github-flavored-markdown/
|
||||
[GFM comments]: https://help.github.com/articles/writing-on-github/
|
||||
[since 2014]: https://github.com/blog/1825-task-lists-in-all-markdown-documents
|
||||
[Docter]: https://github.com/alampros/Docter
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
markdown-mode has benefited greatly from the efforts of the
|
||||
following people:
|
||||
|
||||
* Cyril Brulebois for Debian packaging.
|
||||
* Conal Elliott for a font-lock regexp patch.
|
||||
* Edward O'Connor for a font-lock regexp fix and
|
||||
GitHub Flavored Markdown mode (`gfm-mode`).
|
||||
* Greg Bognar for menus and running
|
||||
`markdown` with an active region.
|
||||
* Daniel Burrows for filing Debian bug #456592.
|
||||
* Peter S. Galbraith for maintaining `emacs-goodies-el`.
|
||||
* Dmitry Dzhus for undefined reference checking.
|
||||
* Carsten Dominik for `org-mode`, from which the
|
||||
visibility cycling functionality was derived, and for a bug fix
|
||||
related to `orgtbl-mode`.
|
||||
* Bryan Kyle for indentation code.
|
||||
* Ben Voui for font-lock face customizations.
|
||||
* Ankit Solanki for `longlines.el`
|
||||
compatibility and custom CSS.
|
||||
* Hilko Bengen for proper XHTML output.
|
||||
* Jose A. Ortega Ruiz for Emacs 23 fixes.
|
||||
* Nelson Minar for `html-helper-mode`, from which
|
||||
comment matching functions were derived.
|
||||
* Alec Resnick for bug reports.
|
||||
* Joost Kremers for footnote-handling
|
||||
functions, bug reports regarding indentation, and
|
||||
fixes for byte-compilation warnings.
|
||||
* Peter Williams for `fill-paragraph`
|
||||
enhancements.
|
||||
* George Ogata for fixing several
|
||||
byte-compilation warnings.
|
||||
* Eric Merritt for wiki link features.
|
||||
* Philippe Ivaldi for XHTML preview
|
||||
customizations and XHTML export.
|
||||
* Jeremiah Dodds for supporting
|
||||
Markdown processors which do not accept input from stdin.
|
||||
* Werner Dittmann for bug reports
|
||||
regarding the `cl` dependency and `auto-fill-mode` and indentation.
|
||||
* Scott Pfister for generalizing the space
|
||||
substitution character for mapping wiki links to filenames.
|
||||
* Marcin Kasperski for a patch to
|
||||
escape shell commands.
|
||||
* Christopher J. Madsen for patches to fix a match
|
||||
data bug and to prefer `visual-line-mode` in `gfm-mode`.
|
||||
* Shigeru Fukaya for better adherence to
|
||||
Emacs Lisp coding conventions.
|
||||
* Donald Ephraim Curtis for fixing the `fill-paragraph`
|
||||
regexp, refactoring the compilation and preview functions,
|
||||
heading font-lock generalizations, list renumbering,
|
||||
and kill ring save.
|
||||
* Kevin Porter for wiki link handling in `gfm-mode`.
|
||||
* Max Penet and Peter Eisentraut <peter_e@gmx.net>
|
||||
for an autoload token for `gfm-mode`.
|
||||
* Ian Yang for improving the reference definition regex.
|
||||
* Akinori Musha for an imenu index function.
|
||||
* Michael Sperber for XEmacs fixes.
|
||||
* Francois Gannaz for suggesting charset
|
||||
declaration in XHTML output.
|
||||
* Zhenlei Jia for smart exdention function.
|
||||
* Matus Goljer for improved wiki link following
|
||||
and GFM code block insertion.
|
||||
* Peter Jones for link following functions.
|
||||
* Bryan Fink for a bug report regarding
|
||||
externally modified files.
|
||||
* Vegard Vesterheim for a bug fix
|
||||
related to `orgtbl-mode`.
|
||||
* Makoto Motohashi for before- and after-
|
||||
export hooks, unit test improvements, and updates to support
|
||||
wide characters.
|
||||
* Michael Dwyer for `gfm-mode` underscore regexp.
|
||||
* Chris Lott for suggesting reference label
|
||||
completion.
|
||||
* Gunnar Franke for a completion bug report.
|
||||
* David Glasser for a `paragraph-separate` fix.
|
||||
* Daniel Brotsky for better auto-fill defaults.
|
||||
* Samuel Freilich for improved filling
|
||||
behavior regarding list items, footnotes, and reference
|
||||
definitions, improved killing of footnotes, and numerous other
|
||||
tests and bug fixes.
|
||||
* Antonis Kanouras for strikethrough support.
|
||||
* Tim Visher for multiple CSS files and other
|
||||
general improvements.
|
||||
* Matt McClure for a patch to prevent
|
||||
overwriting source files with .html extensions upon export.
|
||||
* Roger Bolsius for ordered list improvements.
|
||||
* Google's Open Source Programs Office for recognizing the project with
|
||||
a monetary contribution in June 2015.
|
||||
* Howard Melman for supporting GFM checkboxes
|
||||
as buttons.
|
||||
* Danny McClanahan for live preview
|
||||
mode, completion of GFM programming language names, improved
|
||||
font lock for fenced code blocks and metadata blocks, `cl-lib`
|
||||
updates, and numerous other improvements.
|
||||
* Syohei Yoshida for better heading detection
|
||||
and movement functions, improved italic font lock, fixing adaptive
|
||||
filling for hanging list items, more efficient fontification,
|
||||
and numerous other improvements.
|
||||
* Vitalie Spinu for improvements to font
|
||||
lock and source code aesthetics.
|
||||
* Kévin Le Gouguec for improvements
|
||||
related to ATX headings and Pandoc fancy lists.
|
||||
|
||||
## Bugs
|
||||
|
||||
markdown-mode is developed and tested primarily for compatibility
|
||||
with GNU Emacs 24.3 and later. If you find any bugs in
|
||||
markdown-mode, please construct a test case or a patch and open a
|
||||
ticket on the [GitHub issue tracker][issues].
|
||||
|
||||
[issues]: https://github.com/jrblevin/markdown-mode/issues
|
||||
|
||||
## History
|
||||
|
||||
markdown-mode was written and is maintained by Jason Blevins. The
|
||||
first version was released on May 24, 2007.
|
||||
|
||||
* 2007-05-24: Version 1.1
|
||||
* 2007-05-25: Version 1.2
|
||||
* 2007-06-05: [Version 1.3][]
|
||||
* 2007-06-29: Version 1.4
|
||||
* 2007-10-11: [Version 1.5][]
|
||||
* 2008-06-04: [Version 1.6][]
|
||||
* 2009-10-01: [Version 1.7][]
|
||||
* 2011-08-12: [Version 1.8][]
|
||||
* 2011-08-15: [Version 1.8.1][]
|
||||
* 2013-01-25: [Version 1.9][]
|
||||
* 2013-03-24: [Version 2.0][]
|
||||
* 2016-01-09: [Version 2.1][]
|
||||
|
||||
[Version 1.3]: http://jblevins.org/projects/markdown-mode/rev-1-3
|
||||
[Version 1.5]: http://jblevins.org/projects/markdown-mode/rev-1-5
|
||||
[Version 1.6]: http://jblevins.org/projects/markdown-mode/rev-1-6
|
||||
[Version 1.7]: http://jblevins.org/projects/markdown-mode/rev-1-7
|
||||
[Version 1.8]: http://jblevins.org/projects/markdown-mode/rev-1-8
|
||||
[Version 1.8.1]: http://jblevins.org/projects/markdown-mode/rev-1-8-1
|
||||
[Version 1.9]: http://jblevins.org/projects/markdown-mode/rev-1-9
|
||||
[Version 2.0]: http://jblevins.org/projects/markdown-mode/rev-2-0
|
||||
[Version 2.1]: http://jblevins.org/projects/markdown-mode/rev-2-1
|
||||
|
6842
markdown-mode.el
Normal file
6842
markdown-mode.el
Normal file
File diff suppressed because it is too large
Load diff
14
scripts/get-recognized-gfm-languages.el
Normal file
14
scripts/get-recognized-gfm-languages.el
Normal file
|
@ -0,0 +1,14 @@
|
|||
(require 'cl-lib)
|
||||
|
||||
(let ((urlbuf
|
||||
(url-retrieve-synchronously
|
||||
"https://raw.githubusercontent.com/github/linguist/master/lib/linguist/languages.yml"
|
||||
t)))
|
||||
(prog1 (with-current-buffer urlbuf
|
||||
(goto-char (point-min))
|
||||
;; get past http headers
|
||||
(re-search-forward "^$")
|
||||
(cl-loop while (re-search-forward "^\\([^#[:space:]][^:]+\\):" nil t)
|
||||
for lang = (match-string-no-properties 1)
|
||||
collect (replace-regexp-in-string " " "-" lang)))
|
||||
(kill-buffer urlbuf)))
|
1
tests/.gitignore
vendored
Normal file
1
tests/.gitignore
vendored
Normal file
|
@ -0,0 +1 @@
|
|||
*.html
|
143
tests/GFM.md
Normal file
143
tests/GFM.md
Normal file
|
@ -0,0 +1,143 @@
|
|||
# Strikethrough
|
||||
|
||||
~~This text should be parsed as _strikethroughed_.~~
|
||||
|
||||
~~There may be __bold__ or _italic_ text inside strikethroughed text.~~
|
||||
|
||||
~~There may be a keyboard shortcut like <kbd>Enter</kbd> inside strikethroughed text.~~
|
||||
|
||||
__There may be ~~strikethroughed text~~ inside bold text.__
|
||||
_There may be ~~strikethroughed text~~ inside italic text._
|
||||
|
||||
~~ If there is a space in the beginning or end, it won't work as per the [GFM][GFM] docs ~~
|
||||
|
||||
~~Strikethrough can be applied to
|
||||
multiple lines. Just keep in mind
|
||||
not to put any space in the beginning or end.~~
|
||||
|
||||
# Underscore In Words
|
||||
|
||||
The word `complicated` must be neither bold nor italic below:
|
||||
|
||||
perform_complicated_task
|
||||
perform__complicated__task
|
||||
|
||||
But the first part below is italic and bold respectively:
|
||||
|
||||
_perform_complicated_task
|
||||
__perform__complicated__task
|
||||
|
||||
# Keyboard Shortcuts
|
||||
|
||||
Keyboard shortcuts below should be highlighted:
|
||||
|
||||
---
|
||||
|
||||
A keyboard shortcut <kbd>Enter</kbd> can be in paragraph.
|
||||
|
||||
* A keyboard shortcut <kbd>Enter</kbd> can be in list.
|
||||
|
||||
_A keyboard shortcut <kbd>Enter</kbd> can be in italic._
|
||||
__A keyboard shortcut <kbd>Enter</kbd> can be in bold.__
|
||||
|
||||
~~A keyboard shortcut <kbd>Enter</kbd> can be in deleted text.~~
|
||||
|
||||
<p>A keyboard shortcut <kbd>Enter</kbd> can be in HTML.</p>
|
||||
|
||||
<div>
|
||||
A keyboard shortcut <kbd>Enter</kbd> can be in block level tags.
|
||||
</div>
|
||||
|
||||
# Fenced Code Blocks
|
||||
|
||||
## In / Near List Items
|
||||
|
||||
Below fenced code blocks _should_ be highlighted.
|
||||
|
||||
---
|
||||
|
||||
* List item
|
||||
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
* List item
|
||||
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Below are _not_ valid fenced code blocks according to the [GFM docs][GFM]. It says there must be a blank line before the code block. However, GitHub highlights them. So, they _should_ be highlighted.
|
||||
|
||||
---
|
||||
|
||||
* List item
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
* List item
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
## In / Near Paragraphs
|
||||
|
||||
Below is _not_ a _fenced_ code block, just a normal code block.
|
||||
|
||||
---
|
||||
|
||||
Paragraph
|
||||
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Below 2 blocks are fenced code blocks. They _should_ be highlighted.
|
||||
|
||||
---
|
||||
|
||||
Paragraph
|
||||
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
Paragraph
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Below is not any type of code block. It _should not_ be highlighted.
|
||||
|
||||
---
|
||||
|
||||
Paragraph
|
||||
```js
|
||||
for (var i = 0; i < 10; i++) {
|
||||
console.log(i);
|
||||
}
|
||||
```
|
||||
|
||||
[GFM]: https://help.github.com/articles/github-flavored-markdown
|
40
tests/Makefile
Normal file
40
tests/Makefile
Normal file
|
@ -0,0 +1,40 @@
|
|||
EMACS=emacs
|
||||
MARKDOWN=Markdown.pl
|
||||
|
||||
.SUFFIXES: .text .html
|
||||
.PHONY: test
|
||||
|
||||
TEST_SRCS = $(wildcard *.text)
|
||||
TEST_HTML = $(TEST_SRCS:.text=.html)
|
||||
|
||||
.text.html:
|
||||
$(MARKDOWN) < $< > $@
|
||||
|
||||
test: compile-all checkdoc
|
||||
$(EMACS) -Q --batch $(CL) \
|
||||
--eval '(setq byte-compile-warnings (quote (not cl-functions)))' \
|
||||
-l ert -l ../markdown-mode.elc -l markdown-test.elc \
|
||||
-f ert-run-tests-batch-and-exit
|
||||
|
||||
checkdoc:
|
||||
$(EMACS) -Q --batch $(CL) -l checkdoc-batch.el 2>&1 | \
|
||||
grep -E "markdown-mode.el:[1-9]+" && exit 1 || exit 0
|
||||
|
||||
compile-all:
|
||||
$(EMACS) -Q --batch $(CL) \
|
||||
--eval '(setq byte-compile-warnings (quote (not cl-functions)))' \
|
||||
--eval '(setq byte-compile-error-on-warn t)' \
|
||||
-l ../markdown-mode.el \
|
||||
-f batch-byte-compile ../markdown-mode.el markdown-test.el
|
||||
|
||||
html: $(TEST_HTML)
|
||||
|
||||
clean:
|
||||
rm -f $(TEST_HTML) *.elc ../*.elc
|
||||
|
||||
evm:
|
||||
$(MAKE) test EMACS="$(shell evm bin emacs-24.1)" CL="-l cl-lib-0.5.el"
|
||||
$(MAKE) test EMACS="$(shell evm bin emacs-24.2)" CL="-l cl-lib-0.5.el"
|
||||
$(MAKE) test EMACS="$(shell evm bin emacs-24.3)" CL=""
|
||||
$(MAKE) test EMACS="$(shell evm bin emacs-24.4)" CL=""
|
||||
$(MAKE) test EMACS="$(shell evm bin emacs-24.5)" CL=""
|
120
tests/Markdown.md
Normal file
120
tests/Markdown.md
Normal file
|
@ -0,0 +1,120 @@
|
|||
Source: https://github.com/textmate/markdown.tmbundle/blob/master/Tests/test-minimal.markdown
|
||||
|
||||
Inline styles
|
||||
===============
|
||||
|
||||
_italic_
|
||||
|
||||
_italic one_ not italic _italic two_
|
||||
|
||||
_italic\__
|
||||
|
||||
_italic \__
|
||||
|
||||
stuff * not italic*
|
||||
|
||||
*italic__*
|
||||
|
||||
_all _ italic_
|
||||
|
||||
_italic
|
||||
end italic_
|
||||
|
||||
\\\\_italic\\_
|
||||
|
||||
\\\\_italic\\\_\\\\_
|
||||
|
||||
\\\\_italic\\_
|
||||
|
||||
\_ not italic _
|
||||
|
||||
_not italic _
|
||||
|
||||
\\\\_not italic\_
|
||||
|
||||
_not italic \_
|
||||
|
||||
\\\_not italic\\_
|
||||
|
||||
_not italic
|
||||
|
||||
not end italic_
|
||||
|
||||
__bold__
|
||||
|
||||
**bold\***
|
||||
|
||||
___bold_and_italic___
|
||||
|
||||
***bold_and_italic***
|
||||
|
||||
`raw more`
|
||||
|
||||
``dobule ` raw``
|
||||
|
||||
`raw \` more`
|
||||
|
||||
Headings
|
||||
================
|
||||
|
||||
heading 2
|
||||
----------
|
||||
|
||||
## heading 2
|
||||
|
||||
### heading 3
|
||||
|
||||
###### heading 6
|
||||
|
||||
Horizontal lines
|
||||
=================
|
||||
|
||||
***
|
||||
|
||||
* * *
|
||||
|
||||
___
|
||||
|
||||
__ __ __
|
||||
|
||||
- - -
|
||||
|
||||
----------------
|
||||
|
||||
|
||||
Block formatting
|
||||
================
|
||||
|
||||
Lists
|
||||
----------------
|
||||
|
||||
* This *is a list!*
|
||||
* This is another list item.
|
||||
But this one spans *two* lines.
|
||||
* Another list item with __inline__ formatting
|
||||
* This one is tricky
|
||||
* *This is a list*
|
||||
|
||||
Because this should still be a list item.
|
||||
|
||||
1. This is a list item too
|
||||
2. This list is numbered
|
||||
|
||||
1986\. This shouldn't be a list.
|
||||
|
||||
Code block
|
||||
---------------
|
||||
|
||||
asdfsdafasdf
|
||||
This is code.
|
||||
Isn't it pretty!
|
||||
|
||||
Quotes
|
||||
---------------
|
||||
|
||||
> Here is a quote block
|
||||
This quote continues on. Line breaking is OK in markdown
|
||||
> Here it is again
|
||||
> Lah-di-dah
|
||||
> I should really match headings in here too:
|
||||
> ## This is a heading in a block quote
|
10
tests/checkdoc-batch.el
Normal file
10
tests/checkdoc-batch.el
Normal file
|
@ -0,0 +1,10 @@
|
|||
(require 'checkdoc)
|
||||
|
||||
(defun markdown-test--checkdoc-file (file)
|
||||
"Check FILE for document, comment, error style, and rogue spaces.
|
||||
Taken from Emacs 25 source."
|
||||
(with-current-buffer (find-file-noselect file)
|
||||
(let ((checkdoc-diagnostic-buffer "*warn*"))
|
||||
(checkdoc-current-buffer t))))
|
||||
|
||||
(markdown-test--checkdoc-file "../markdown-mode.el")
|
410
tests/cl-lib-0.5.el
Normal file
410
tests/cl-lib-0.5.el
Normal file
|
@ -0,0 +1,410 @@
|
|||
;;; cl-lib.el --- Properly prefixed CL functions and macros -*- coding: utf-8 -*-
|
||||
|
||||
;; Copyright (C) 2012, 2013, 2014 Free Software Foundation, Inc.
|
||||
|
||||
;; Author: Stefan Monnier <monnier@iro.umontreal.ca>
|
||||
;; vcomment: Emacs-24.3's version is 1.0 so this has to stay below.
|
||||
;; Version: 0.5
|
||||
|
||||
;; This program is free software; you can redistribute it and/or modify
|
||||
;; it under the terms of the GNU General Public License as published by
|
||||
;; the Free Software Foundation, either version 3 of the License, or
|
||||
;; (at your option) any later version.
|
||||
|
||||
;; This program is distributed in the hope that it will be useful,
|
||||
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
;; GNU General Public License for more details.
|
||||
|
||||
;; You should have received a copy of the GNU General Public License
|
||||
;; along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
;;; Commentary:
|
||||
|
||||
;; This is a forward compatibility package, which provides (a subset of) the
|
||||
;; features of the cl-lib package introduced in Emacs-24.3, for use on
|
||||
;; previous emacsen.
|
||||
|
||||
;; Make sure this is installed *late* in your `load-path`, i.e. after Emacs's
|
||||
;; built-in .../lisp/emacs-lisp directory, so that if/when you upgrade to
|
||||
;; Emacs-24.3, the built-in version of the file will take precedence, otherwise
|
||||
;; you could get into trouble (although we try to hack our way around the
|
||||
;; problem in case it happens).
|
||||
|
||||
;; This code is largely copied from Emacs-24.3's cl.el, with the alias bindings
|
||||
;; simply reversed.
|
||||
|
||||
;;; Code:
|
||||
|
||||
;; We need to handle the situation where this package is used with an Emacs
|
||||
;; that comes with a real cl-lib (i.e. ≥24.3).
|
||||
|
||||
;; First line of defense: try to make sure the built-in cl-lib comes earlier in
|
||||
;; load-path so we never get loaded:
|
||||
;;;###autoload (let ((d (file-name-directory #$)))
|
||||
;;;###autoload (when (member d load-path)
|
||||
;;;###autoload (setq load-path (append (remove d load-path) (list d)))))
|
||||
|
||||
(when (functionp 'macroexp--compiler-macro)
|
||||
;; `macroexp--compiler-macro' was introduced as part of the big CL
|
||||
;; reorganization which moved/reimplemented some of CL into core (mostly the
|
||||
;; setf and compiler-macro support), so its presence indicates we're running
|
||||
;; in an Emacs that comes with the new cl-lib.el, where this file should
|
||||
;; never be loaded!
|
||||
(message "Real cl-lib shadowed by compatibility cl-lib? (%s)" load-file-name)
|
||||
(when load-file-name
|
||||
;; (message "Let's try to patch things up")
|
||||
(let ((loaddir (file-name-directory load-file-name))
|
||||
load-path-dir)
|
||||
;; Find the problematic directory from load-path.
|
||||
(dolist (dir load-path)
|
||||
(if (equal loaddir (expand-file-name (file-name-as-directory dir)))
|
||||
(setq load-path-dir dir)))
|
||||
(when load-path-dir
|
||||
;; (message "Let's move the offending dir to the end")
|
||||
(setq load-path (append (remove load-path-dir load-path)
|
||||
(list load-path-dir)))
|
||||
;; Here we could manually load cl-lib and then return immediately.
|
||||
;; But Emacs currently doesn't provide any way for a file to "return
|
||||
;; immediately", so instead we make sure the rest of the file does not
|
||||
;; throw away any pre-existing definition.
|
||||
))))
|
||||
|
||||
(require 'cl)
|
||||
|
||||
;; Some of Emacs-24.3's cl.el definition are not just aliases, because either
|
||||
;; the feature was dropped from cl-lib.el or because the cl-lib version is
|
||||
;; not fully compatible.
|
||||
;; Let's just not include them here, since it is very important that if code
|
||||
;; works with this cl-lib.el it should also work with Emacs-24.3's cl-lib.el,
|
||||
;; whereas the reverse is much less important.
|
||||
|
||||
(dolist (var '(
|
||||
;; loop-result-var
|
||||
;; loop-result
|
||||
;; loop-initially
|
||||
;; loop-finally
|
||||
;; loop-bindings
|
||||
;; loop-args
|
||||
;; bind-inits
|
||||
;; bind-block
|
||||
;; lambda-list-keywords
|
||||
float-negative-epsilon
|
||||
float-epsilon
|
||||
least-negative-normalized-float
|
||||
least-positive-normalized-float
|
||||
least-negative-float
|
||||
least-positive-float
|
||||
most-negative-float
|
||||
most-positive-float
|
||||
;; custom-print-functions
|
||||
))
|
||||
(let ((new (intern (format "cl-%s" var))))
|
||||
(unless (boundp new) (defvaralias new var))))
|
||||
|
||||
;; The following cl-lib functions were already defined in the old cl.el,
|
||||
;; with a different meaning:
|
||||
;; - cl-position and cl-delete-duplicates
|
||||
;; the two meanings are clearly different, but we can distinguish which was
|
||||
;; meant by looking at the arguments.
|
||||
;; - cl-member
|
||||
;; the old meaning hasn't been used for a long time and is a subset of the
|
||||
;; new, so we can simply override it.
|
||||
;; - cl-adjoin
|
||||
;; the old meaning is actually the same as the new except for optimizations.
|
||||
|
||||
(dolist (fun '(
|
||||
(get* . cl-get)
|
||||
(random* . cl-random)
|
||||
(rem* . cl-rem)
|
||||
(mod* . cl-mod)
|
||||
(round* . cl-round)
|
||||
(truncate* . cl-truncate)
|
||||
(ceiling* . cl-ceiling)
|
||||
(floor* . cl-floor)
|
||||
(rassoc* . cl-rassoc)
|
||||
(assoc* . cl-assoc)
|
||||
;; (member* . cl-member) ;Handle specially below.
|
||||
(delete* . cl-delete)
|
||||
(remove* . cl-remove)
|
||||
(defsubst* . cl-defsubst)
|
||||
(sort* . cl-sort)
|
||||
(function* . cl-function)
|
||||
(defmacro* . cl-defmacro)
|
||||
(defun* . cl-defun)
|
||||
(mapcar* . cl-mapcar)
|
||||
|
||||
remprop
|
||||
getf
|
||||
tailp
|
||||
list-length
|
||||
nreconc
|
||||
revappend
|
||||
concatenate
|
||||
subseq
|
||||
random-state-p
|
||||
make-random-state
|
||||
signum
|
||||
isqrt
|
||||
lcm
|
||||
gcd
|
||||
notevery
|
||||
notany
|
||||
every
|
||||
some
|
||||
mapcon
|
||||
mapcan
|
||||
mapl
|
||||
maplist
|
||||
map
|
||||
equalp
|
||||
coerce
|
||||
tree-equal
|
||||
nsublis
|
||||
sublis
|
||||
nsubst-if-not
|
||||
nsubst-if
|
||||
nsubst
|
||||
subst-if-not
|
||||
subst-if
|
||||
subsetp
|
||||
nset-exclusive-or
|
||||
set-exclusive-or
|
||||
nset-difference
|
||||
set-difference
|
||||
nintersection
|
||||
intersection
|
||||
nunion
|
||||
union
|
||||
rassoc-if-not
|
||||
rassoc-if
|
||||
assoc-if-not
|
||||
assoc-if
|
||||
member-if-not
|
||||
member-if
|
||||
merge
|
||||
stable-sort
|
||||
search
|
||||
mismatch
|
||||
count-if-not
|
||||
count-if
|
||||
count
|
||||
position-if-not
|
||||
position-if
|
||||
;; position ;Handle specially via defadvice below.
|
||||
find-if-not
|
||||
find-if
|
||||
find
|
||||
nsubstitute-if-not
|
||||
nsubstitute-if
|
||||
nsubstitute
|
||||
substitute-if-not
|
||||
substitute-if
|
||||
substitute
|
||||
;; delete-duplicates ;Handle specially via defadvice below.
|
||||
remove-duplicates
|
||||
delete-if-not
|
||||
delete-if
|
||||
remove-if-not
|
||||
remove-if
|
||||
replace
|
||||
fill
|
||||
reduce
|
||||
compiler-macroexpand
|
||||
define-compiler-macro
|
||||
assert
|
||||
check-type
|
||||
typep
|
||||
deftype
|
||||
defstruct
|
||||
callf2
|
||||
callf
|
||||
letf*
|
||||
letf
|
||||
rotatef
|
||||
shiftf
|
||||
remf
|
||||
psetf
|
||||
declare
|
||||
the
|
||||
locally
|
||||
multiple-value-setq
|
||||
multiple-value-bind
|
||||
symbol-macrolet
|
||||
macrolet
|
||||
progv
|
||||
psetq
|
||||
do-all-symbols
|
||||
do-symbols
|
||||
dotimes
|
||||
dolist
|
||||
do*
|
||||
do
|
||||
loop
|
||||
return-from
|
||||
return
|
||||
block
|
||||
etypecase
|
||||
typecase
|
||||
ecase
|
||||
case
|
||||
load-time-value
|
||||
eval-when
|
||||
destructuring-bind
|
||||
gentemp
|
||||
gensym
|
||||
pairlis
|
||||
acons
|
||||
subst
|
||||
;; adjoin ;It's already defined.
|
||||
copy-list
|
||||
ldiff
|
||||
list*
|
||||
cddddr
|
||||
cdddar
|
||||
cddadr
|
||||
cddaar
|
||||
cdaddr
|
||||
cdadar
|
||||
cdaadr
|
||||
cdaaar
|
||||
cadddr
|
||||
caddar
|
||||
cadadr
|
||||
cadaar
|
||||
caaddr
|
||||
caadar
|
||||
caaadr
|
||||
caaaar
|
||||
cdddr
|
||||
cddar
|
||||
cdadr
|
||||
cdaar
|
||||
caddr
|
||||
cadar
|
||||
caadr
|
||||
caaar
|
||||
tenth
|
||||
ninth
|
||||
eighth
|
||||
seventh
|
||||
sixth
|
||||
fifth
|
||||
fourth
|
||||
third
|
||||
endp
|
||||
rest
|
||||
second
|
||||
first
|
||||
svref
|
||||
copy-seq
|
||||
evenp
|
||||
oddp
|
||||
minusp
|
||||
plusp
|
||||
floatp-safe
|
||||
declaim
|
||||
proclaim
|
||||
nth-value
|
||||
multiple-value-call
|
||||
multiple-value-apply
|
||||
multiple-value-list
|
||||
values-list
|
||||
values
|
||||
pushnew
|
||||
decf
|
||||
incf
|
||||
|
||||
dolist
|
||||
dotimes
|
||||
))
|
||||
(let ((new (if (consp fun) (prog1 (cdr fun) (setq fun (car fun)))
|
||||
(intern (format "cl-%s" fun)))))
|
||||
(if (fboundp new)
|
||||
(unless (or (eq (symbol-function new) fun)
|
||||
(eq new (and (symbolp fun) (fboundp fun)
|
||||
(symbol-function fun))))
|
||||
(message "%S already defined, not rebinding" new))
|
||||
(defalias new fun))))
|
||||
|
||||
(unless (symbolp (symbol-function 'position))
|
||||
(autoload 'cl-position "cl-seq")
|
||||
(defadvice cl-position (around cl-lib (cl-item cl-seq &rest cl-keys) activate)
|
||||
(let ((argk (ad-get-args 2)))
|
||||
(if (or (null argk) (keywordp (car argk)))
|
||||
;; This is a call to cl-lib's `cl-position'.
|
||||
(setq ad-return-value
|
||||
(apply #'position (ad-get-arg 0) (ad-get-arg 1) argk))
|
||||
;; Must be a call to cl's old `cl-position'.
|
||||
ad-do-it))))
|
||||
|
||||
(unless (symbolp (symbol-function 'delete-duplicates))
|
||||
(autoload 'cl-delete-duplicates "cl-seq")
|
||||
(defadvice cl-delete-duplicates (around cl-lib (cl-seq &rest cl-keys) activate)
|
||||
(let ((argk (ad-get-args 1)))
|
||||
(if (or (null argk) (keywordp (car argk)))
|
||||
;; This is a call to cl-lib's `cl-delete-duplicates'.
|
||||
(setq ad-return-value
|
||||
(apply #'delete-duplicates (ad-get-arg 0) argk))
|
||||
;; Must be a call to cl's old `cl-delete-duplicates'.
|
||||
ad-do-it))))
|
||||
|
||||
(when (or (not (fboundp 'cl-member))
|
||||
(eq (symbol-function 'cl-member) #'memq))
|
||||
(defalias 'cl-member #'member*))
|
||||
|
||||
;; `cl-labels' is not 100% compatible with `labels' when using dynamic scoping
|
||||
;; (mostly because it does not turn lambdas that refer to those functions into
|
||||
;; closures). OTOH it is compatible when using lexical scoping.
|
||||
|
||||
(unless (fboundp 'cl-labels)
|
||||
(defmacro cl-labels (&rest args)
|
||||
(unless (and (boundp 'lexical-binding) lexical-binding)
|
||||
;; We used to signal an error rather than a message, but in many uses of
|
||||
;; cl-labels, the value of lexical-binding doesn't actually matter.
|
||||
;; More importantly, the value of `lexical-binding' here is unreliable
|
||||
;; (it does not necessarily reflect faithfully whether the output of this
|
||||
;; macro will be interpreted as lexically bound code or not).
|
||||
(message "This `cl-labels' requires `lexical-binding' to be non-nil"))
|
||||
`(labels ,@args)))
|
||||
|
||||
;;;; ChangeLog:
|
||||
|
||||
;; 2014-02-25 Stefan Monnier <monnier@iro.umontreal.ca>
|
||||
;;
|
||||
;; Fixes: debbugs:16671
|
||||
;;
|
||||
;; * cl-lib.el (cl-position, cl-delete-duplicate): Don't advise if >=24.3.
|
||||
;; (load-path): Try to make sure we're at the end.
|
||||
;;
|
||||
;; 2014-01-25 Stefan Monnier <monnier@iro.umontreal.ca>
|
||||
;;
|
||||
;; * cl-lib.el: Resolve conflicts with old internal definitions
|
||||
;; (bug#16353).
|
||||
;; (dolist fun): Don't skip definitions silently.
|
||||
;; (define-setf-expander): Remove, not in cl-lib.
|
||||
;; (cl-position, cl-delete-duplicates): Add advice to distinguish the use
|
||||
;; case.
|
||||
;; (cl-member): Override old definition.
|
||||
;;
|
||||
;; 2013-05-22 Stefan Monnier <monnier@iro.umontreal.ca>
|
||||
;;
|
||||
;; * cl-lib.el (cl-labels): Demote error to message and improve it.
|
||||
;;
|
||||
;; 2012-11-30 Stefan Monnier <monnier@iro.umontreal.ca>
|
||||
;;
|
||||
;; * cl-lib.el: Try and patch things up in case we're hiding the real
|
||||
;; cl-lib.
|
||||
;;
|
||||
;; 2012-11-22 Stefan Monnier <monnier@iro.umontreal.ca>
|
||||
;;
|
||||
;; Add cl-letf and cl-labels.
|
||||
;;
|
||||
;; 2012-11-16 Stefan Monnier <monnier@iro.umontreal.ca>
|
||||
;;
|
||||
;; * packages/cl-lib: New package.
|
||||
;;
|
||||
|
||||
|
||||
(provide 'cl-lib)
|
||||
;;; cl-lib.el ends here
|
78
tests/gfm.text
Normal file
78
tests/gfm.text
Normal file
|
@ -0,0 +1,78 @@
|
|||
# Introduction to GFM
|
||||
|
||||
GitHub uses what we're calling "GitHub Flavored Markdown" (GFM) for messages, issues, and comments. It differs from standard Markdown (SM) in a few significant ways and adds some additional functionality.
|
||||
|
||||
If you're not already familiar with Markdown, you should spend 15 minutes and go over the excellent [Markdown Syntax Guide](http://daringfireball.net/projects/markdown/syntax) at Daring Fireball.
|
||||
|
||||
If you prefer to learn by example, see the following source and result:
|
||||
|
||||
* [Source](sample_content.html)
|
||||
* [Result](http://github.com/mojombo/github-flavored-markdown/issues/#issue/1)
|
||||
|
||||
If you're interested in how we render Markdown files, you might want to check out [Redcarpet](https://github.com/vmg/redcarpet), our Ruby interface to the [Sundown](https://www.github.com/vmg/sundown) library.
|
||||
|
||||
## Differences from traditional Markdown
|
||||
|
||||
### Newlines
|
||||
|
||||
The biggest difference that GFM introduces is in the handling of linebreaks. With SM you can hard wrap paragraphs of text and they will be combined into a single paragraph. We find this to be the cause of a huge number of unintentional formatting errors. GFM treats newlines in paragraph-like content as real line breaks, which is probably what you intended.
|
||||
|
||||
The next paragraph contains two phrases separated by a single newline character:
|
||||
|
||||
Roses are red
|
||||
Violets are blue
|
||||
|
||||
becomes
|
||||
|
||||
Roses are red
|
||||
Violets are blue
|
||||
|
||||
### Multiple underscores in words
|
||||
|
||||
It is not reasonable to italicize just _part_ of a word, especially when you're dealing with code and names often appear with multiple underscores. Therefore, GFM ignores multiple underscores in words.
|
||||
|
||||
perform_complicated_task
|
||||
do_this_and_do_that_and_another_thing
|
||||
|
||||
becomes
|
||||
|
||||
perform_complicated_task do_this_and_do_that_and_another_thing
|
||||
|
||||
### URL autolinking
|
||||
|
||||
GFM will autolink standard URLs, so if you want to link to a URL (instead of setting link text), you can simply enter the URL and it will be turned into a link to that URL.
|
||||
|
||||
### Fenced code blocks
|
||||
|
||||
Markdown converts text with four spaces at the front of each line to code blocks. GFM supports that, but we also support fenced blocks. Just wrap your code blocks in `` ``` `` and you won't need to indent manually to trigger a code block.
|
||||
|
||||
### Syntax highlighting
|
||||
|
||||
We take code blocks a step further and add syntax highlighting if you request
|
||||
it. In your fenced block, add an optional language identifier and we'll run it
|
||||
through syntax highlighting. For example, to syntax highlight Ruby code:
|
||||
|
||||
```ruby
|
||||
require 'redcarpet'
|
||||
markdown = Redcarpet.new("Hello World!")
|
||||
puts markdown.to_html
|
||||
```
|
||||
|
||||
This yields
|
||||
|
||||
```ruby
|
||||
require 'redcarpet'
|
||||
markdown = Redcarpet.new("Hello World!")
|
||||
puts markdown.to_html
|
||||
```
|
||||
|
||||
## Code
|
||||
|
||||
The newline and underscore modification code can be seen below. If you find a bug in the rendering, we'd love to hear about it. Browse through open Issues and report new Issues on the [GitHub-flavored Markdown Issues page](https://github.com/github/github-flavored-markdown/issues).
|
||||
|
||||
## Markdown Cheat Sheet
|
||||
|
||||
On Markdown-enabled portions of the site, press **M** on your keyboard to display a cheat sheet.
|
||||
|
||||
© 2013 GitHub Inc. All rights reserved.
|
||||
<http://github.github.com/github-flavored-markdown/>
|
3
tests/ikiwiki/root
Normal file
3
tests/ikiwiki/root
Normal file
|
@ -0,0 +1,3 @@
|
|||
[[sub/foo]]
|
||||
|
||||
[[sub/doesnotexist]]
|
3
tests/ikiwiki/sub/foo
Normal file
3
tests/ikiwiki/sub/foo
Normal file
|
@ -0,0 +1,3 @@
|
|||
[[doesnotexist]]
|
||||
|
||||
[[root]]
|
30
tests/inline.text
Normal file
30
tests/inline.text
Normal file
|
@ -0,0 +1,30 @@
|
|||
This is *italic.*
|
||||
This is **bold.**
|
||||
This is `code`.
|
||||
This is ``code`containing`backticks``.
|
||||
|
||||
Seven backquotes in a row ``````` do not constitute a code span.
|
||||
|
||||
If backquotes begin or end a code span, you have to use spaces,
|
||||
like `` `this` ``. Markdown removes any leading and trailing
|
||||
whitespace. Only the space a the end is necessary,
|
||||
like ```this` ``.
|
||||
|
||||
A backslash as the final character in an inline code fragment does
|
||||
*not* escape the backquote. That is, `C-h C-\` will render as
|
||||
|
||||
<code>C-h C-\</code>
|
||||
|
||||
However, we can escape what would otherwise be a leading backquote,
|
||||
as in \`foo\` or \`bar\`.
|
||||
|
||||
But this will be a code span crossing lines: \`foo` or
|
||||
bar ` containing only "or bar".
|
||||
|
||||
This should result in three backquotes in a code span `` ``` `` and
|
||||
they should even match across across lines `` ```
|
||||
``, like so. However, backquotes should not `` ``` match
|
||||
|
||||
across two blocks``.
|
||||
|
||||
Links have several components: [text](http://www.w3.org/ "title").
|
19
tests/itex.text
Normal file
19
tests/itex.text
Normal file
|
@ -0,0 +1,19 @@
|
|||
LaTeX/itex Tests
|
||||
================
|
||||
|
||||
Test unnumbered display mode equation:
|
||||
$$ y = mx + b $$
|
||||
|
||||
Test unnumbered display mode equation on multiple lines:
|
||||
$$
|
||||
y = mx + b
|
||||
$$
|
||||
|
||||
Test numbered display mode equation:
|
||||
\[ y = mx + b \]
|
||||
|
||||
Test numbered display mode equation on multiple lines:
|
||||
\[
|
||||
\label{test}
|
||||
y = \psi(mx + b)
|
||||
\]
|
160
tests/lists.text
Normal file
160
tests/lists.text
Normal file
|
@ -0,0 +1,160 @@
|
|||
# List Cases
|
||||
|
||||
Indentation is described in terms of four components: the position of
|
||||
the beginning of the block, the actual indentation of the block (first
|
||||
line), in terms of spaces, followed by whether the block begins with a
|
||||
list marker, and the list level.
|
||||
|
||||
|
||||
## Case 1
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
|
||||
eiusmod tempor incididunt ut labore et dolore magna aliqua.
|
||||
|
||||
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
|
||||
nisi ut aliquip ex ea commodo consequat.
|
||||
|
||||
Duis aute irure dolor in reprehenderit in voluptate velit esse
|
||||
cillum dolore eu fugiat nulla pariatur.
|
||||
|
||||
Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
|
||||
officia deserunt mollit anim id est laborum.
|
||||
|
||||
*Indentation:* (273 0 nil 0) (399 3 nil 0) (514 1 nil 0) (620 0 nil 0)
|
||||
|
||||
*Notes:* These are all just normal paragraphs, since there are no list
|
||||
markers or blocks indented at least four spaces.
|
||||
|
||||
|
||||
## Case 2
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
|
||||
eiusmod tempor incididunt ut labore et dolore magna aliqua.
|
||||
|
||||
- Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
|
||||
nisi ut aliquip ex ea commodo a consequat.
|
||||
|
||||
Duis aute irure dolor in reprehenderit in voluptate velit esse
|
||||
cillum dolore eu fugiat nulla pariatur.
|
||||
|
||||
- Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
|
||||
officia deserunt mollit anim id est laborum.
|
||||
|
||||
*Indentation:* (931 0 nil 0) (1063 0 t 1) (1178 1 nil 1) (1283 0 t 1)
|
||||
|
||||
*Notes:* Even though the third block is only indented one space, it is
|
||||
indented one more space than the list marker, so it becomes a second
|
||||
paragraph within the first list item.
|
||||
|
||||
|
||||
## Case 3
|
||||
|
||||
+ This is a list item with
|
||||
no leading indentation and
|
||||
no hanging indent.
|
||||
|
||||
A four-space indented block that follows
|
||||
is parsed as a paragraph within the list item.
|
||||
|
||||
+ Second list item
|
||||
|
||||
*Indentation:* (1659 0 t 1) (1733 4 nil 1) (1830 0 t 1)
|
||||
|
||||
|
||||
## Case 4
|
||||
|
||||
* This is a list item with
|
||||
no leading indentation and
|
||||
a hanging indent.
|
||||
|
||||
A four-space indented block that follows
|
||||
is parsed as a paragraph within the list item.
|
||||
|
||||
*Indentation:* (1919 0 t 1) (1996 4 nil 1)
|
||||
|
||||
|
||||
## Case 5
|
||||
|
||||
* This is a list item with
|
||||
single space leading indentation and
|
||||
no hanging indentation.
|
||||
|
||||
A four-space indented block that follows
|
||||
is parsed as a paragraph within the list item.
|
||||
|
||||
*Indentation:* (2149 1 t 1) (2239 4 nil 1)
|
||||
|
||||
|
||||
## Case 6
|
||||
|
||||
* This is a list item with
|
||||
single space leading indentation and
|
||||
no hanging indentation.
|
||||
|
||||
* A list item with two-space indent
|
||||
starts a new list level.
|
||||
|
||||
A four-space indented block that follows
|
||||
is parsed as a paragraph within the **first-level**
|
||||
list item. Why not the second level?
|
||||
|
||||
*Indentation:* (2392 2 t 1) (2482 2 t 2) (2548 4 nil 1)
|
||||
|
||||
|
||||
## Case 7
|
||||
|
||||
* This is a list item with
|
||||
single space leading indentation and
|
||||
no hanging indentation.
|
||||
|
||||
* A list item with two-space indent
|
||||
starts a new list level.
|
||||
|
||||
A two-space indented block that follows
|
||||
is parsed as a paragraph within the **first-level**
|
||||
list item.
|
||||
|
||||
*Indentation:* (2761 1 t 1) (2851 2 t 2) (2917 2 nil 2)
|
||||
|
||||
|
||||
## Case 8
|
||||
|
||||
* This is a list item with
|
||||
single space leading indentation and
|
||||
no hanging indentation.
|
||||
|
||||
* A list item with two-space indent
|
||||
starts a new list level.
|
||||
|
||||
A five-space indented block that follows is parsed as a
|
||||
paragraph within the *second* list item. This indentation
|
||||
exceeds that required for the first item.
|
||||
|
||||
Finally, to get a pre block, we have to use 12 spaces.
|
||||
That's the third level of four-space indentation.
|
||||
We have to exceed the list level, which is two.
|
||||
|
||||
*Indentation:* (3096 1 t 1) (3186 2 t 2) (3252 5 nil 2) (3425 12 nil 2)
|
||||
|
||||
|
||||
## Case 9
|
||||
|
||||
- This is a list item with two paragraphs.
|
||||
|
||||
This is the second paragraph in the list item. You're
|
||||
only required to indent the first line. Lorem ipsum dolor
|
||||
sit amet, consectetuer adipiscing elit.
|
||||
|
||||
* Another item in the same list.
|
||||
|
||||
*Indentation:* (3700 0 t 1) (3746 4 nil 1) (3903 0 t 1)
|
||||
|
||||
|
||||
## Case 10
|
||||
|
||||
* A list item with a blockquote:
|
||||
|
||||
> This is a blockquote
|
||||
> inside a list item.
|
||||
|
||||
*Indentation:* (4009 0 t 1) (4045 4 nil 1)
|
4032
tests/markdown-test.el
Normal file
4032
tests/markdown-test.el
Normal file
File diff suppressed because it is too large
Load diff
25
tests/math.text
Normal file
25
tests/math.text
Normal file
|
@ -0,0 +1,25 @@
|
|||
A simple equation for a line in $\mathbb{R}^2$:
|
||||
|
||||
\[ y = mx + b \]
|
||||
|
||||
Again, but with dollar signs:
|
||||
|
||||
$$ y = mx + b $$
|
||||
|
||||
# Regarding $\vec g$ and its effects
|
||||
|
||||
Math in a heading
|
||||
|
||||
~~~~ {.haskell}
|
||||
f x = length $ tail x
|
||||
~~~~
|
||||
|
||||
$x + 1$
|
||||
|
||||
$e_{ik}$ in the statement the theorem about $V_k$
|
||||
|
||||
$**η = (-1)^{k(n-k)}sη$, where $**η$, is the Hodge star applied twice.
|
||||
|
||||
<!-- Local Variables: -->
|
||||
<!-- markdown-enable-math: t -->
|
||||
<!-- End: -->
|
57
tests/more-lists.text
Normal file
57
tests/more-lists.text
Normal file
|
@ -0,0 +1,57 @@
|
|||
Ordered, without paragraphs:
|
||||
|
||||
1. Foo
|
||||
2. Bar
|
||||
|
||||
Unordered, with paragraphs:
|
||||
|
||||
* A list item.
|
||||
|
||||
With multiple paragraphs.
|
||||
|
||||
* Bar
|
||||
|
||||
Nested lists:
|
||||
|
||||
* Bubbles
|
||||
1. bunk
|
||||
2. bupkis
|
||||
* BELITTLER
|
||||
3. burper
|
||||
* Abacus
|
||||
* answer
|
||||
* Cunning
|
||||
|
||||
A complex, multiply-nested list:
|
||||
|
||||
* Unordered stuff
|
||||
with overhang
|
||||
|
||||
4. fourth nested
|
||||
|
||||
2. second nested
|
||||
|
||||
0. zeroth nested
|
||||
|
||||
* More unordered stuff
|
||||
|
||||
0. zeroth nested
|
||||
2. second nested
|
||||
4. fourth nested
|
||||
|
||||
Nested ordered lists:
|
||||
|
||||
1. first
|
||||
|
||||
0. zeroth nested
|
||||
2. second nested
|
||||
4. fourth nested
|
||||
|
||||
2. second
|
||||
|
||||
1. first nested
|
||||
3. third nested
|
||||
|
||||
3. third
|
||||
|
||||
4. fourth
|
25
tests/nested-list.text
Normal file
25
tests/nested-list.text
Normal file
|
@ -0,0 +1,25 @@
|
|||
- List level 1 item 1
|
||||
- List level 1 item 2
|
||||
|
||||
Second paragraph of item 2
|
||||
|
||||
Nested pre block in item 2
|
||||
Four spaces past the marker
|
||||
|
||||
Another paragraph of item 2
|
||||
|
||||
- List level 1 item 3
|
||||
|
||||
- List level 2 item 1
|
||||
Four spaces from higher-level the marker.
|
||||
More indentation in the same block
|
||||
does not trigger a pre block!
|
||||
|
||||
Nested pre block
|
||||
Four spaces past the previous marker
|
||||
|
||||
- List level 2 item 2
|
||||
|
||||
- List level 3 item 1
|
||||
|
||||
Nested pre block
|
17
tests/outline-code.text
Normal file
17
tests/outline-code.text
Normal file
|
@ -0,0 +1,17 @@
|
|||
# Level one
|
||||
|
||||
* A list item
|
||||
with some overhang
|
||||
+ and a sublist
|
||||
|
||||
## Level two
|
||||
|
||||
~~~ {.bash}
|
||||
#!/bin/bash
|
||||
|
||||
# In a code block, this shouldn't be a header
|
||||
~~~
|
||||
|
||||
# Level one again
|
||||
|
||||
some body text
|
44
tests/outline.text
Normal file
44
tests/outline.text
Normal file
|
@ -0,0 +1,44 @@
|
|||
Pre-header text.
|
||||
|
||||
# A top-level header
|
||||
|
||||
followed by some body text
|
||||
|
||||
## A second-level header
|
||||
|
||||
followed by some body text
|
||||
|
||||
### Third level ###
|
||||
|
||||
* A list item
|
||||
* and another
|
||||
with some overhang
|
||||
+ and a sublist
|
||||
with overhang
|
||||
- And a third with a different marker
|
||||
|
||||
### Third level number two ###
|
||||
|
||||
### Level two again
|
||||
|
||||
followed by some body text
|
||||
|
||||
An underline-style header
|
||||
=========================
|
||||
|
||||
With some text
|
||||
|
||||
And a level two underline header
|
||||
--------------------------------
|
||||
|
||||
* With
|
||||
* an unordered
|
||||
* list
|
||||
|
||||
# Level one
|
||||
|
||||
foo
|
||||
|
||||
## Level two
|
||||
|
||||
bar
|
30
tests/r-markdown-test.text
Normal file
30
tests/r-markdown-test.text
Normal file
|
@ -0,0 +1,30 @@
|
|||
% Test example
|
||||
% Mathieu Basille
|
||||
% September 11, 2013
|
||||
|
||||
# First section
|
||||
|
||||
## And a sub-section
|
||||
|
||||
```{r sum}
|
||||
2+2
|
||||
```
|
||||
|
||||
Some text...
|
||||
|
||||
|
||||
## Second sub-section
|
||||
|
||||
Some more text, and the faulty chunk with comments:
|
||||
|
||||
```{r comments}
|
||||
2+2
|
||||
## Wait, still 4?
|
||||
```
|
||||
|
||||
And text you will never see again!
|
||||
|
||||
|
||||
# Second section
|
||||
|
||||
More text...
|
897
tests/syntax.text
Normal file
897
tests/syntax.text
Normal file
|
@ -0,0 +1,897 @@
|
|||
Markdown: Syntax
|
||||
================
|
||||
|
||||
<ul id="ProjectSubmenu">
|
||||
<li><a href="/projects/markdown/" title="Markdown Project Page">Main</a></li>
|
||||
<li><a href="/projects/markdown/basics" title="Markdown Basics">Basics</a></li>
|
||||
<li><a class="selected" title="Markdown Syntax Documentation">Syntax</a></li>
|
||||
<li><a href="/projects/markdown/license" title="Pricing and License Information">License</a></li>
|
||||
<li><a href="/projects/markdown/dingus" title="Online Markdown Web Form">Dingus</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
* [Overview](#overview)
|
||||
* [Philosophy](#philosophy)
|
||||
* [Inline HTML](#html)
|
||||
* [Automatic Escaping for Special Characters](#autoescape)
|
||||
* [Block Elements](#block)
|
||||
* [Paragraphs and Line Breaks](#p)
|
||||
* [Headers](#header)
|
||||
* [Blockquotes](#blockquote)
|
||||
* [Lists](#list)
|
||||
* [Code Blocks](#precode)
|
||||
* [Horizontal Rules](#hr)
|
||||
* [Span Elements](#span)
|
||||
* [Links](#link)
|
||||
* [Emphasis](#em)
|
||||
* [Code](#code)
|
||||
* [Images](#img)
|
||||
* [Miscellaneous](#misc)
|
||||
* [Backslash Escapes](#backslash)
|
||||
* [Automatic Links](#autolink)
|
||||
|
||||
|
||||
**Note:** This document is itself written using Markdown; you
|
||||
can [see the source for it by adding '.text' to the URL][src].
|
||||
|
||||
[src]: /projects/markdown/syntax.text
|
||||
|
||||
* * *
|
||||
|
||||
<h2 id="overview">Overview</h2>
|
||||
|
||||
<h3 id="philosophy">Philosophy</h3>
|
||||
|
||||
Markdown is intended to be as easy-to-read and easy-to-write as is feasible.
|
||||
|
||||
Readability, however, is emphasized above all else. A Markdown-formatted
|
||||
document should be publishable as-is, as plain text, without looking
|
||||
like it's been marked up with tags or formatting instructions. While
|
||||
Markdown's syntax has been influenced by several existing text-to-HTML
|
||||
filters -- including [Setext] [1], [atx] [2], [Textile] [3], [reStructuredText] [4],
|
||||
[Grutatext] [5], and [EtText] [6] -- the single biggest source of
|
||||
inspiration for Markdown's syntax is the format of plain text email.
|
||||
|
||||
[1]: http://docutils.sourceforge.net/mirror/setext.html
|
||||
[2]: http://www.aaronsw.com/2002/atx/
|
||||
[3]: http://textism.com/tools/textile/
|
||||
[4]: http://docutils.sourceforge.net/rst.html
|
||||
[5]: http://www.triptico.com/software/grutatxt.html
|
||||
[6]: http://ettext.taint.org/doc/
|
||||
|
||||
To this end, Markdown's syntax is comprised entirely of punctuation
|
||||
characters, which punctuation characters have been carefully chosen so
|
||||
as to look like what they mean. E.g., asterisks around a word actually
|
||||
look like \*emphasis\*. Markdown lists look like, well, lists. Even
|
||||
blockquotes look like quoted passages of text, assuming you've ever
|
||||
used email.
|
||||
|
||||
|
||||
|
||||
<h3 id="html">Inline HTML</h3>
|
||||
|
||||
Markdown's syntax is intended for one purpose: to be used as a
|
||||
format for *writing* for the web.
|
||||
|
||||
Markdown is not a replacement for HTML, or even close to it. Its
|
||||
syntax is very small, corresponding only to a very small subset of
|
||||
HTML tags. The idea is *not* to create a syntax that makes it easier
|
||||
to insert HTML tags. In my opinion, HTML tags are already easy to
|
||||
insert. The idea for Markdown is to make it easy to read, write, and
|
||||
edit prose. HTML is a *publishing* format; Markdown is a *writing*
|
||||
format. Thus, Markdown's formatting syntax only addresses issues that
|
||||
can be conveyed in plain text.
|
||||
|
||||
For any markup that is not covered by Markdown's syntax, you simply
|
||||
use HTML itself. There's no need to preface it or delimit it to
|
||||
indicate that you're switching from Markdown to HTML; you just use
|
||||
the tags.
|
||||
|
||||
The only restrictions are that block-level HTML elements -- e.g. `<div>`,
|
||||
`<table>`, `<pre>`, `<p>`, etc. -- must be separated from surrounding
|
||||
content by blank lines, and the start and end tags of the block should
|
||||
not be indented with tabs or spaces. Markdown is smart enough not
|
||||
to add extra (unwanted) `<p>` tags around HTML block-level tags.
|
||||
|
||||
For example, to add an HTML table to a Markdown article:
|
||||
|
||||
This is a regular paragraph.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>Foo</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
This is another regular paragraph.
|
||||
|
||||
Note that Markdown formatting syntax is not processed within block-level
|
||||
HTML tags. E.g., you can't use Markdown-style `*emphasis*` inside an
|
||||
HTML block.
|
||||
|
||||
Span-level HTML tags -- e.g. `<span>`, `<cite>`, or `<del>` -- can be
|
||||
used anywhere in a Markdown paragraph, list item, or header. If you
|
||||
want, you can even use HTML tags instead of Markdown formatting; e.g. if
|
||||
you'd prefer to use HTML `<a>` or `<img>` tags instead of Markdown's
|
||||
link or image syntax, go right ahead.
|
||||
|
||||
Unlike block-level HTML tags, Markdown syntax *is* processed within
|
||||
span-level tags.
|
||||
|
||||
|
||||
<h3 id="autoescape">Automatic Escaping for Special Characters</h3>
|
||||
|
||||
In HTML, there are two characters that demand special treatment: `<`
|
||||
and `&`. Left angle brackets are used to start tags; ampersands are
|
||||
used to denote HTML entities. If you want to use them as literal
|
||||
characters, you must escape them as entities, e.g. `<`, and
|
||||
`&`.
|
||||
|
||||
Ampersands in particular are bedeviling for web writers. If you want to
|
||||
write about 'AT&T', you need to write '`AT&T`'. You even need to
|
||||
escape ampersands within URLs. Thus, if you want to link to:
|
||||
|
||||
http://images.google.com/images?num=30&q=larry+bird
|
||||
|
||||
you need to encode the URL as:
|
||||
|
||||
http://images.google.com/images?num=30&q=larry+bird
|
||||
|
||||
in your anchor tag `href` attribute. Needless to say, this is easy to
|
||||
forget, and is probably the single most common source of HTML validation
|
||||
errors in otherwise well-marked-up web sites.
|
||||
|
||||
Markdown allows you to use these characters naturally, taking care of
|
||||
all the necessary escaping for you. If you use an ampersand as part of
|
||||
an HTML entity, it remains unchanged; otherwise it will be translated
|
||||
into `&`.
|
||||
|
||||
So, if you want to include a copyright symbol in your article, you can write:
|
||||
|
||||
©
|
||||
|
||||
and Markdown will leave it alone. But if you write:
|
||||
|
||||
AT&T
|
||||
|
||||
Markdown will translate it to:
|
||||
|
||||
AT&T
|
||||
|
||||
Similarly, because Markdown supports [inline HTML](#html), if you use
|
||||
angle brackets as delimiters for HTML tags, Markdown will treat them as
|
||||
such. But if you write:
|
||||
|
||||
4 < 5
|
||||
|
||||
Markdown will translate it to:
|
||||
|
||||
4 < 5
|
||||
|
||||
However, inside Markdown code spans and blocks, angle brackets and
|
||||
ampersands are *always* encoded automatically. This makes it easy to use
|
||||
Markdown to write about HTML code. (As opposed to raw HTML, which is a
|
||||
terrible format for writing about HTML syntax, because every single `<`
|
||||
and `&` in your example code needs to be escaped.)
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
|
||||
<h2 id="block">Block Elements</h2>
|
||||
|
||||
|
||||
<h3 id="p">Paragraphs and Line Breaks</h3>
|
||||
|
||||
A paragraph is simply one or more consecutive lines of text, separated
|
||||
by one or more blank lines. (A blank line is any line that looks like a
|
||||
blank line -- a line containing nothing but spaces or tabs is considered
|
||||
blank.) Normal paragraphs should not be indented with spaces or tabs.
|
||||
|
||||
The implication of the "one or more consecutive lines of text" rule is
|
||||
that Markdown supports "hard-wrapped" text paragraphs. This differs
|
||||
significantly from most other text-to-HTML formatters (including Movable
|
||||
Type's "Convert Line Breaks" option) which translate every line break
|
||||
character in a paragraph into a `<br />` tag.
|
||||
|
||||
When you *do* want to insert a `<br />` break tag using Markdown, you
|
||||
end a line with two or more spaces, then type return.
|
||||
|
||||
Yes, this takes a tad more effort to create a `<br />`, but a simplistic
|
||||
"every line break is a `<br />`" rule wouldn't work for Markdown.
|
||||
Markdown's email-style [blockquoting][bq] and multi-paragraph [list items][l]
|
||||
work best -- and look better -- when you format them with hard breaks.
|
||||
|
||||
[bq]: #blockquote
|
||||
[l]: #list
|
||||
|
||||
|
||||
|
||||
<h3 id="header">Headers</h3>
|
||||
|
||||
Markdown supports two styles of headers, [Setext] [1] and [atx] [2].
|
||||
|
||||
Setext-style headers are "underlined" using equal signs (for first-level
|
||||
headers) and dashes (for second-level headers). For example:
|
||||
|
||||
This is an H1
|
||||
=============
|
||||
|
||||
This is an H2
|
||||
-------------
|
||||
|
||||
Any number of underlining `=`'s or `-`'s will work.
|
||||
|
||||
Atx-style headers use 1-6 hash characters at the start of the line,
|
||||
corresponding to header levels 1-6. For example:
|
||||
|
||||
# This is an H1
|
||||
|
||||
## This is an H2
|
||||
|
||||
###### This is an H6
|
||||
|
||||
Optionally, you may "close" atx-style headers. This is purely
|
||||
cosmetic -- you can use this if you think it looks better. The
|
||||
closing hashes don't even need to match the number of hashes
|
||||
used to open the header. (The number of opening hashes
|
||||
determines the header level.) :
|
||||
|
||||
# This is an H1 #
|
||||
|
||||
## This is an H2 ##
|
||||
|
||||
### This is an H3 ######
|
||||
|
||||
|
||||
<h3 id="blockquote">Blockquotes</h3>
|
||||
|
||||
Markdown uses email-style `>` characters for blockquoting. If you're
|
||||
familiar with quoting passages of text in an email message, then you
|
||||
know how to create a blockquote in Markdown. It looks best if you hard
|
||||
wrap the text and put a `>` before every line:
|
||||
|
||||
> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
|
||||
> consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
|
||||
> Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.
|
||||
>
|
||||
> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse
|
||||
> id sem consectetuer libero luctus adipiscing.
|
||||
|
||||
Markdown allows you to be lazy and only put the `>` before the first
|
||||
line of a hard-wrapped paragraph:
|
||||
|
||||
> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
|
||||
consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
|
||||
Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.
|
||||
|
||||
> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse
|
||||
id sem consectetuer libero luctus adipiscing.
|
||||
|
||||
Blockquotes can be nested (i.e. a blockquote-in-a-blockquote) by
|
||||
adding additional levels of `>`:
|
||||
|
||||
> This is the first level of quoting.
|
||||
>
|
||||
> > This is nested blockquote.
|
||||
>
|
||||
> Back to the first level.
|
||||
|
||||
Blockquotes can contain other Markdown elements, including headers, lists,
|
||||
and code blocks:
|
||||
|
||||
> ## This is a header.
|
||||
>
|
||||
> 1. This is the first list item.
|
||||
> 2. This is the second list item.
|
||||
>
|
||||
> Here's some example code:
|
||||
>
|
||||
> return shell_exec("echo $input | $markdown_script");
|
||||
|
||||
Any decent text editor should make email-style quoting easy. For
|
||||
example, with BBEdit, you can make a selection and choose Increase
|
||||
Quote Level from the Text menu.
|
||||
|
||||
|
||||
<h3 id="list">Lists</h3>
|
||||
|
||||
Markdown supports ordered (numbered) and unordered (bulleted) lists.
|
||||
|
||||
Unordered lists use asterisks, pluses, and hyphens -- interchangably
|
||||
-- as list markers:
|
||||
|
||||
* Red
|
||||
* Green
|
||||
* Blue
|
||||
|
||||
is equivalent to:
|
||||
|
||||
+ Red
|
||||
+ Green
|
||||
+ Blue
|
||||
|
||||
and:
|
||||
|
||||
- Red
|
||||
- Green
|
||||
- Blue
|
||||
|
||||
Ordered lists use numbers followed by periods:
|
||||
|
||||
1. Bird
|
||||
2. McHale
|
||||
3. Parish
|
||||
|
||||
It's important to note that the actual numbers you use to mark the
|
||||
list have no effect on the HTML output Markdown produces. The HTML
|
||||
Markdown produces from the above list is:
|
||||
|
||||
<ol>
|
||||
<li>Bird</li>
|
||||
<li>McHale</li>
|
||||
<li>Parish</li>
|
||||
</ol>
|
||||
|
||||
If you instead wrote the list in Markdown like this:
|
||||
|
||||
1. Bird
|
||||
1. McHale
|
||||
1. Parish
|
||||
|
||||
or even:
|
||||
|
||||
3. Bird
|
||||
1. McHale
|
||||
8. Parish
|
||||
|
||||
you'd get the exact same HTML output. The point is, if you want to,
|
||||
you can use ordinal numbers in your ordered Markdown lists, so that
|
||||
the numbers in your source match the numbers in your published HTML.
|
||||
But if you want to be lazy, you don't have to.
|
||||
|
||||
If you do use lazy list numbering, however, you should still start the
|
||||
list with the number 1. At some point in the future, Markdown may support
|
||||
starting ordered lists at an arbitrary number.
|
||||
|
||||
List markers typically start at the left margin, but may be indented by
|
||||
up to three spaces. List markers must be followed by one or more spaces
|
||||
or a tab.
|
||||
|
||||
To make lists look nice, you can wrap items with hanging indents:
|
||||
|
||||
* Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
|
||||
Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
|
||||
viverra nec, fringilla in, laoreet vitae, risus.
|
||||
* Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
|
||||
Suspendisse id sem consectetuer libero luctus adipiscing.
|
||||
|
||||
But if you want to be lazy, you don't have to:
|
||||
|
||||
* Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
|
||||
Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
|
||||
viverra nec, fringilla in, laoreet vitae, risus.
|
||||
* Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
|
||||
Suspendisse id sem consectetuer libero luctus adipiscing.
|
||||
|
||||
If list items are separated by blank lines, Markdown will wrap the
|
||||
items in `<p>` tags in the HTML output. For example, this input:
|
||||
|
||||
* Bird
|
||||
* Magic
|
||||
|
||||
will turn into:
|
||||
|
||||
<ul>
|
||||
<li>Bird</li>
|
||||
<li>Magic</li>
|
||||
</ul>
|
||||
|
||||
But this:
|
||||
|
||||
* Bird
|
||||
|
||||
* Magic
|
||||
|
||||
will turn into:
|
||||
|
||||
<ul>
|
||||
<li><p>Bird</p></li>
|
||||
<li><p>Magic</p></li>
|
||||
</ul>
|
||||
|
||||
List items may consist of multiple paragraphs. Each subsequent
|
||||
paragraph in a list item must be indented by either 4 spaces
|
||||
or one tab:
|
||||
|
||||
1. This is a list item with two paragraphs. Lorem ipsum dolor
|
||||
sit amet, consectetuer adipiscing elit. Aliquam hendrerit
|
||||
mi posuere lectus.
|
||||
|
||||
Vestibulum enim wisi, viverra nec, fringilla in, laoreet
|
||||
vitae, risus. Donec sit amet nisl. Aliquam semper ipsum
|
||||
sit amet velit.
|
||||
|
||||
2. Suspendisse id sem consectetuer libero luctus adipiscing.
|
||||
|
||||
It looks nice if you indent every line of the subsequent
|
||||
paragraphs, but here again, Markdown will allow you to be
|
||||
lazy:
|
||||
|
||||
* This is a list item with two paragraphs.
|
||||
|
||||
This is the second paragraph in the list item. You're
|
||||
only required to indent the first line. Lorem ipsum dolor
|
||||
sit amet, consectetuer adipiscing elit.
|
||||
|
||||
* Another item in the same list.
|
||||
|
||||
To put a blockquote within a list item, the blockquote's `>`
|
||||
delimiters need to be indented:
|
||||
|
||||
* A list item with a blockquote:
|
||||
|
||||
> This is a blockquote
|
||||
> inside a list item.
|
||||
|
||||
To put a code block within a list item, the code block needs
|
||||
to be indented *twice* -- 8 spaces or two tabs:
|
||||
|
||||
* A list item with a code block:
|
||||
|
||||
<code goes here>
|
||||
|
||||
|
||||
It's worth noting that it's possible to trigger an ordered list by
|
||||
accident, by writing something like this:
|
||||
|
||||
1986. What a great season.
|
||||
|
||||
In other words, a *number-period-space* sequence at the beginning of a
|
||||
line. To avoid this, you can backslash-escape the period:
|
||||
|
||||
1986\. What a great season.
|
||||
|
||||
|
||||
|
||||
<h3 id="precode">Code Blocks</h3>
|
||||
|
||||
Pre-formatted code blocks are used for writing about programming or
|
||||
markup source code. Rather than forming normal paragraphs, the lines
|
||||
of a code block are interpreted literally. Markdown wraps a code block
|
||||
in both `<pre>` and `<code>` tags.
|
||||
|
||||
To produce a code block in Markdown, simply indent every line of the
|
||||
block by at least 4 spaces or 1 tab. For example, given this input:
|
||||
|
||||
This is a normal paragraph:
|
||||
|
||||
This is a code block.
|
||||
|
||||
Markdown will generate:
|
||||
|
||||
<p>This is a normal paragraph:</p>
|
||||
|
||||
<pre><code>This is a code block.
|
||||
</code></pre>
|
||||
|
||||
One level of indentation -- 4 spaces or 1 tab -- is removed from each
|
||||
line of the code block. For example, this:
|
||||
|
||||
Here is an example of AppleScript:
|
||||
|
||||
tell application "Foo"
|
||||
beep
|
||||
end tell
|
||||
|
||||
will turn into:
|
||||
|
||||
<p>Here is an example of AppleScript:</p>
|
||||
|
||||
<pre><code>tell application "Foo"
|
||||
beep
|
||||
end tell
|
||||
</code></pre>
|
||||
|
||||
A code block continues until it reaches a line that is not indented
|
||||
(or the end of the article).
|
||||
|
||||
Within a code block, ampersands (`&`) and angle brackets (`<` and `>`)
|
||||
are automatically converted into HTML entities. This makes it very
|
||||
easy to include example HTML source code using Markdown -- just paste
|
||||
it and indent it, and Markdown will handle the hassle of encoding the
|
||||
ampersands and angle brackets. For example, this:
|
||||
|
||||
<div class="footer">
|
||||
© 2004 Foo Corporation
|
||||
</div>
|
||||
|
||||
will turn into:
|
||||
|
||||
<pre><code><div class="footer">
|
||||
&copy; 2004 Foo Corporation
|
||||
</div>
|
||||
</code></pre>
|
||||
|
||||
Regular Markdown syntax is not processed within code blocks. E.g.,
|
||||
asterisks are just literal asterisks within a code block. This means
|
||||
it's also easy to use Markdown to write about Markdown's own syntax.
|
||||
|
||||
|
||||
|
||||
<h3 id="hr">Horizontal Rules</h3>
|
||||
|
||||
You can produce a horizontal rule tag (`<hr />`) by placing three or
|
||||
more hyphens, asterisks, or underscores on a line by themselves. If you
|
||||
wish, you may use spaces between the hyphens or asterisks. Each of the
|
||||
following lines will produce a horizontal rule:
|
||||
|
||||
* * *
|
||||
|
||||
***
|
||||
|
||||
*****
|
||||
|
||||
- - -
|
||||
|
||||
---------------------------------------
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
<h2 id="span">Span Elements</h2>
|
||||
|
||||
<h3 id="link">Links</h3>
|
||||
|
||||
Markdown supports two style of links: *inline* and *reference*.
|
||||
|
||||
In both styles, the link text is delimited by [square brackets].
|
||||
|
||||
To create an inline link, use a set of regular parentheses immediately
|
||||
after the link text's closing square bracket. Inside the parentheses,
|
||||
put the URL where you want the link to point, along with an *optional*
|
||||
title for the link, surrounded in quotes. For example:
|
||||
|
||||
This is [an example](http://example.com/ "Title") inline link.
|
||||
|
||||
[This link](http://example.net/) has no title attribute.
|
||||
|
||||
Will produce:
|
||||
|
||||
<p>This is <a href="http://example.com/" title="Title">
|
||||
an example</a> inline link.</p>
|
||||
|
||||
<p><a href="http://example.net/">This link</a> has no
|
||||
title attribute.</p>
|
||||
|
||||
If you're referring to a local resource on the same server, you can
|
||||
use relative paths:
|
||||
|
||||
See my [About](/about/) page for details.
|
||||
|
||||
Reference-style links use a second set of square brackets, inside
|
||||
which you place a label of your choosing to identify the link:
|
||||
|
||||
This is [an example][id] reference-style link.
|
||||
|
||||
You can optionally use a space to separate the sets of brackets:
|
||||
|
||||
This is [an example] [id] reference-style link.
|
||||
|
||||
Then, anywhere in the document, you define your link label like this,
|
||||
on a line by itself:
|
||||
|
||||
[id]: http://example.com/ "Optional Title Here"
|
||||
|
||||
That is:
|
||||
|
||||
* Square brackets containing the link identifier (optionally
|
||||
indented from the left margin using up to three spaces);
|
||||
* followed by a colon;
|
||||
* followed by one or more spaces (or tabs);
|
||||
* followed by the URL for the link;
|
||||
* optionally followed by a title attribute for the link, enclosed
|
||||
in double or single quotes, or enclosed in parentheses.
|
||||
|
||||
The following three link definitions are equivalent:
|
||||
|
||||
[foo]: http://example.com/ "Optional Title Here"
|
||||
[foo]: http://example.com/ 'Optional Title Here'
|
||||
[foo]: http://example.com/ (Optional Title Here)
|
||||
|
||||
**Note:** There is a known bug in Markdown.pl 1.0.1 which prevents
|
||||
single quotes from being used to delimit link titles.
|
||||
|
||||
The link URL may, optionally, be surrounded by angle brackets:
|
||||
|
||||
[id]: <http://example.com/> "Optional Title Here"
|
||||
|
||||
You can put the title attribute on the next line and use extra spaces
|
||||
or tabs for padding, which tends to look better with longer URLs:
|
||||
|
||||
[id]: http://example.com/longish/path/to/resource/here
|
||||
"Optional Title Here"
|
||||
|
||||
Link definitions are only used for creating links during Markdown
|
||||
processing, and are stripped from your document in the HTML output.
|
||||
|
||||
Link definition names may consist of letters, numbers, spaces, and
|
||||
punctuation -- but they are *not* case sensitive. E.g. these two
|
||||
links:
|
||||
|
||||
[link text][a]
|
||||
[link text][A]
|
||||
|
||||
are equivalent.
|
||||
|
||||
The *implicit link name* shortcut allows you to omit the name of the
|
||||
link, in which case the link text itself is used as the name.
|
||||
Just use an empty set of square brackets -- e.g., to link the word
|
||||
"Google" to the google.com web site, you could simply write:
|
||||
|
||||
[Google][]
|
||||
|
||||
And then define the link:
|
||||
|
||||
[Google]: http://google.com/
|
||||
|
||||
Because link names may contain spaces, this shortcut even works for
|
||||
multiple words in the link text:
|
||||
|
||||
Visit [Daring Fireball][] for more information.
|
||||
|
||||
And then define the link:
|
||||
|
||||
[Daring Fireball]: http://daringfireball.net/
|
||||
|
||||
Link definitions can be placed anywhere in your Markdown document. I
|
||||
tend to put them immediately after each paragraph in which they're
|
||||
used, but if you want, you can put them all at the end of your
|
||||
document, sort of like footnotes.
|
||||
|
||||
Here's an example of reference links in action:
|
||||
|
||||
I get 10 times more traffic from [Google] [1] than from
|
||||
[Yahoo] [2] or [MSN] [3].
|
||||
|
||||
[1]: http://google.com/ "Google"
|
||||
[2]: http://search.yahoo.com/ "Yahoo Search"
|
||||
[3]: http://search.msn.com/ "MSN Search"
|
||||
|
||||
Using the implicit link name shortcut, you could instead write:
|
||||
|
||||
I get 10 times more traffic from [Google][] than from
|
||||
[Yahoo][] or [MSN][].
|
||||
|
||||
[google]: http://google.com/ "Google"
|
||||
[yahoo]: http://search.yahoo.com/ "Yahoo Search"
|
||||
[msn]: http://search.msn.com/ "MSN Search"
|
||||
|
||||
Both of the above examples will produce the following HTML output:
|
||||
|
||||
<p>I get 10 times more traffic from <a href="http://google.com/"
|
||||
title="Google">Google</a> than from
|
||||
<a href="http://search.yahoo.com/" title="Yahoo Search">Yahoo</a>
|
||||
or <a href="http://search.msn.com/" title="MSN Search">MSN</a>.</p>
|
||||
|
||||
For comparison, here is the same paragraph written using
|
||||
Markdown's inline link style:
|
||||
|
||||
I get 10 times more traffic from [Google](http://google.com/ "Google")
|
||||
than from [Yahoo](http://search.yahoo.com/ "Yahoo Search") or
|
||||
[MSN](http://search.msn.com/ "MSN Search").
|
||||
|
||||
The point of reference-style links is not that they're easier to
|
||||
write. The point is that with reference-style links, your document
|
||||
source is vastly more readable. Compare the above examples: using
|
||||
reference-style links, the paragraph itself is only 81 characters
|
||||
long; with inline-style links, it's 176 characters; and as raw HTML,
|
||||
it's 234 characters. In the raw HTML, there's more markup than there
|
||||
is text.
|
||||
|
||||
With Markdown's reference-style links, a source document much more
|
||||
closely resembles the final output, as rendered in a browser. By
|
||||
allowing you to move the markup-related metadata out of the paragraph,
|
||||
you can add links without interrupting the narrative flow of your
|
||||
prose.
|
||||
|
||||
|
||||
<h3 id="em">Emphasis</h3>
|
||||
|
||||
Markdown treats asterisks (`*`) and underscores (`_`) as indicators of
|
||||
emphasis. Text wrapped with one `*` or `_` will be wrapped with an
|
||||
HTML `<em>` tag; double `*`'s or `_`'s will be wrapped with an HTML
|
||||
`<strong>` tag. E.g., this input:
|
||||
|
||||
*single asterisks*
|
||||
|
||||
_single underscores_
|
||||
|
||||
**double asterisks**
|
||||
|
||||
__double underscores__
|
||||
|
||||
will produce:
|
||||
|
||||
<em>single asterisks</em>
|
||||
|
||||
<em>single underscores</em>
|
||||
|
||||
<strong>double asterisks</strong>
|
||||
|
||||
<strong>double underscores</strong>
|
||||
|
||||
You can use whichever style you prefer; the lone restriction is that
|
||||
the same character must be used to open and close an emphasis span.
|
||||
|
||||
Emphasis can be used in the middle of a word:
|
||||
|
||||
un*frigging*believable
|
||||
|
||||
But if you surround an `*` or `_` with spaces, it'll be treated as a
|
||||
literal asterisk or underscore.
|
||||
|
||||
To produce a literal asterisk or underscore at a position where it
|
||||
would otherwise be used as an emphasis delimiter, you can backslash
|
||||
escape it:
|
||||
|
||||
\*this text is surrounded by literal asterisks\*
|
||||
|
||||
|
||||
|
||||
<h3 id="code">Code</h3>
|
||||
|
||||
To indicate a span of code, wrap it with backtick quotes (`` ` ``).
|
||||
Unlike a pre-formatted code block, a code span indicates code within a
|
||||
normal paragraph. For example:
|
||||
|
||||
Use the `printf()` function.
|
||||
|
||||
will produce:
|
||||
|
||||
<p>Use the <code>printf()</code> function.</p>
|
||||
|
||||
To include a literal backtick character within a code span, you can use
|
||||
multiple backticks as the opening and closing delimiters:
|
||||
|
||||
``There is a literal backtick (`) here.``
|
||||
|
||||
which will produce this:
|
||||
|
||||
<p><code>There is a literal backtick (`) here.</code></p>
|
||||
|
||||
The backtick delimiters surrounding a code span may include spaces --
|
||||
one after the opening, one before the closing. This allows you to place
|
||||
literal backtick characters at the beginning or end of a code span:
|
||||
|
||||
A single backtick in a code span: `` ` ``
|
||||
|
||||
A backtick-delimited string in a code span: `` `foo` ``
|
||||
|
||||
will produce:
|
||||
|
||||
<p>A single backtick in a code span: <code>`</code></p>
|
||||
|
||||
<p>A backtick-delimited string in a code span: <code>`foo`</code></p>
|
||||
|
||||
With a code span, ampersands and angle brackets are encoded as HTML
|
||||
entities automatically, which makes it easy to include example HTML
|
||||
tags. Markdown will turn this:
|
||||
|
||||
Please don't use any `<blink>` tags.
|
||||
|
||||
into:
|
||||
|
||||
<p>Please don't use any <code><blink></code> tags.</p>
|
||||
|
||||
You can write this:
|
||||
|
||||
`—` is the decimal-encoded equivalent of `—`.
|
||||
|
||||
to produce:
|
||||
|
||||
<p><code>&#8212;</code> is the decimal-encoded
|
||||
equivalent of <code>&mdash;</code>.</p>
|
||||
|
||||
|
||||
|
||||
<h3 id="img">Images</h3>
|
||||
|
||||
Admittedly, it's fairly difficult to devise a "natural" syntax for
|
||||
placing images into a plain text document format.
|
||||
|
||||
Markdown uses an image syntax that is intended to resemble the syntax
|
||||
for links, allowing for two styles: *inline* and *reference*.
|
||||
|
||||
Inline image syntax looks like this:
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
That is:
|
||||
|
||||
* An exclamation mark: `!`;
|
||||
* followed by a set of square brackets, containing the `alt`
|
||||
attribute text for the image;
|
||||
* followed by a set of parentheses, containing the URL or path to
|
||||
the image, and an optional `title` attribute enclosed in double
|
||||
or single quotes.
|
||||
|
||||
Reference-style image syntax looks like this:
|
||||
|
||||
![Alt text][id]
|
||||
|
||||
Where "id" is the name of a defined image reference. Image references
|
||||
are defined using syntax identical to link references:
|
||||
|
||||
[id]: url/to/image "Optional title attribute"
|
||||
|
||||
As of this writing, Markdown has no syntax for specifying the
|
||||
dimensions of an image; if this is important to you, you can simply
|
||||
use regular HTML `<img>` tags.
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
|
||||
<h2 id="misc">Miscellaneous</h2>
|
||||
|
||||
<h3 id="autolink">Automatic Links</h3>
|
||||
|
||||
Markdown supports a shortcut style for creating "automatic" links for URLs and email addresses: simply surround the URL or email address with angle brackets. What this means is that if you want to show the actual text of a URL or email address, and also have it be a clickable link, you can do this:
|
||||
|
||||
<http://example.com/>
|
||||
|
||||
Markdown will turn this into:
|
||||
|
||||
<a href="http://example.com/">http://example.com/</a>
|
||||
|
||||
Automatic links for email addresses work similarly, except that
|
||||
Markdown will also perform a bit of randomized decimal and hex
|
||||
entity-encoding to help obscure your address from address-harvesting
|
||||
spambots. For example, Markdown will turn this:
|
||||
|
||||
<address@example.com>
|
||||
|
||||
into something like this:
|
||||
|
||||
<a href="mailto:addre
|
||||
ss@example.co
|
||||
m">address@exa
|
||||
mple.com</a>
|
||||
|
||||
which will render in a browser as a clickable link to "address@example.com".
|
||||
|
||||
(This sort of entity-encoding trick will indeed fool many, if not
|
||||
most, address-harvesting bots, but it definitely won't fool all of
|
||||
them. It's better than nothing, but an address published in this way
|
||||
will probably eventually start receiving spam.)
|
||||
|
||||
|
||||
|
||||
<h3 id="backslash">Backslash Escapes</h3>
|
||||
|
||||
Markdown allows you to use backslash escapes to generate literal
|
||||
characters which would otherwise have special meaning in Markdown's
|
||||
formatting syntax. For example, if you wanted to surround a word
|
||||
with literal asterisks (instead of an HTML `<em>` tag), you can use
|
||||
backslashes before the asterisks, like this:
|
||||
|
||||
\*literal asterisks\*
|
||||
|
||||
Markdown provides backslash escapes for the following characters:
|
||||
|
||||
\ backslash
|
||||
` backtick
|
||||
* asterisk
|
||||
_ underscore
|
||||
{} curly braces
|
||||
[] square brackets
|
||||
() parentheses
|
||||
# hash mark
|
||||
+ plus sign
|
||||
- minus sign (hyphen)
|
||||
. dot
|
||||
! exclamation mark
|
||||
|
454
tests/test-cases.text
Normal file
454
tests/test-cases.text
Normal file
|
@ -0,0 +1,454 @@
|
|||
markdown-mode Test Cases
|
||||
========================
|
||||
|
||||
1. Lists
|
||||
--------
|
||||
|
||||
Unordered lists:
|
||||
|
||||
- This is a bullet point.
|
||||
- This is a sub bullet point.
|
||||
- This is another bullet point.
|
||||
|
||||
Ordered lists:
|
||||
|
||||
1. This is an ordered list
|
||||
2. With a second element.
|
||||
44. And a forty-fourth element.
|
||||
3. Remember, Markdown doesn't care which number you use.
|
||||
|
||||
List items with bold and italic:
|
||||
|
||||
> * This is a list item *in italics*, just a test.
|
||||
> * *List item in italics.*
|
||||
> * This is a list item **in bold**, just a test.
|
||||
> * **List item in bold.**
|
||||
|
||||
Bold and italic phrases at the beginning of lines:
|
||||
|
||||
*not a list*
|
||||
**also not a list**
|
||||
|
||||
|
||||
2. Blockquotes
|
||||
--------------
|
||||
|
||||
> this is a test
|
||||
> of the blockquote mechanism
|
||||
|
||||
|
||||
3. Two Inline Links on One Line
|
||||
-------------------------------
|
||||
|
||||
*Contributed by Ryan Barrett on 2007-07-02*
|
||||
|
||||
thanks! the new version 1.4 works great. very cool.
|
||||
|
||||
i did notice a minor bug. if there are two inline links in the same line, e.g.
|
||||
[foo](bar) baz [foo](bar), it colors the text between the links (baz) as well.
|
||||
|
||||
i'm guessing this is because the inline link regexp is greedy. if you switch
|
||||
it to non-greedy - if elisp can do that - or to something like '\[[^]]+\]' if
|
||||
not, that might do the trick.
|
||||
|
||||
|
||||
4. Empty Inline Links
|
||||
---------------------
|
||||
|
||||
[]()
|
||||
[](asdf)
|
||||
[asdf]()
|
||||
|
||||
|
||||
5. Bold and Italics on the Same Line
|
||||
------------------------------------
|
||||
|
||||
*Contributed by Conal Elliott on 2007-08-27*
|
||||
|
||||
By the way, here are two syntax-highlighting glitches I've seen so far:
|
||||
|
||||
**foo and doo** or *ziddle zop*
|
||||
Oh -- what's happening here?
|
||||
|
||||
|
||||
6. Reverse Order Italic then Bold
|
||||
---------------------------------
|
||||
|
||||
Why doesn't the bold part get picked up?
|
||||
*ziddle zop* or **foo and doo**
|
||||
|
||||
|
||||
7. Two Inline Links in One Line
|
||||
-------------------------------
|
||||
|
||||
*Contributed by Alastair Rankine on 2007-09-10*
|
||||
|
||||
Thanks for this, I have been waiting for an emacs markdown mode for ages!
|
||||
|
||||
One minor quibble is in the highlighting of inline links. As currently
|
||||
(1.4) implemented the presence of a close paren on the same line as an
|
||||
inline link will highlight the link and the subsequent text:
|
||||
|
||||
[blah](this bit will be highlighted) and so (will this bit)
|
||||
|
||||
I think this is because of greedy regexes. Here is a simple patch to address.
|
||||
|
||||
|
||||
8. Reference-Style Link with a Space
|
||||
------------------------------------
|
||||
|
||||
Here's a [link] [1] with a space between the components.
|
||||
|
||||
[1]: http://daringfireball.net/projects/markdown/syntax
|
||||
|
||||
|
||||
9. Inline Code
|
||||
--------------
|
||||
|
||||
Single `backtick code` fragments as well as ``double`backtick`` fragments are
|
||||
supported.
|
||||
|
||||
|
||||
10. Single Underscore and Asterisk
|
||||
----------------------------------
|
||||
|
||||
This is a _ single underscore and a * single asterisk.
|
||||
They should not trigger font locking.
|
||||
|
||||
|
||||
11. Double Underscores and Asterisks
|
||||
------------------------------------
|
||||
|
||||
Neither should a double **asterisk and double__ underscore!
|
||||
|
||||
12. List-Like Strings in Preformatted Text
|
||||
------------------------------------------
|
||||
|
||||
To make lists look nice, you can wrap items with hanging indents:
|
||||
|
||||
* Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
|
||||
Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
|
||||
viverra nec, fringilla in, laoreet vitae, risus.
|
||||
* Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
|
||||
Suspendisse id sem consectetuer libero luctus adipiscing.
|
||||
|
||||
13. Multi-Line Italic and Bold
|
||||
------------------------------
|
||||
|
||||
bold **phrase spanning
|
||||
two lines** asdf **same line** test
|
||||
|
||||
italic *phrase spanning
|
||||
two lines* italic *same line* test
|
||||
|
||||
|
||||
14. Reference Links
|
||||
-------------------
|
||||
|
||||
This document was created in GNU Emacs using [markdown-mode][]. It provides
|
||||
syntax highlighting for [Markdown][] documents which allows reference-style
|
||||
links like these. The reference definitions can even contain alternate
|
||||
text such as [this one][id].
|
||||
|
||||
[markdown-mode]: http://jrblevin.freeshell.org/software/markdown-mode
|
||||
[Markdown]: http://daringfireball.net/projects/markdown "Markdown Homepage"
|
||||
[id]: http://reference-link.com/with/alt "Alternate Text"
|
||||
|
||||
|
||||
15. Escaping
|
||||
------------
|
||||
|
||||
ab \*literal asterisks\* asdf *inside \* literal asterisks* asd lkj
|
||||
|
||||
ab \**this should be italic\** yz
|
||||
ab \**this should be italic*\* yz
|
||||
ab *\*this should be italic\** yz
|
||||
ab *\*this should be italic*\* yz
|
||||
|
||||
|
||||
16. Single Letter and Word on Same Line
|
||||
---------------------------------------
|
||||
|
||||
a single **a** bold letter and bold word **test** asdf
|
||||
a single _a_ italic letter and italic word _test_ asdf
|
||||
a single __a__ bold letter and bold word __test__ asdf
|
||||
a single *a* italic letter italic word *test* asdf
|
||||
|
||||
|
||||
17. Hanging Indents
|
||||
-------------------
|
||||
|
||||
* An exclamation mark: `!`;
|
||||
* followed by a set of square brackets, containing the `alt`
|
||||
attribute text for the image;
|
||||
|
||||
|
||||
18. Links in Preformatted Text
|
||||
------------------------------
|
||||
|
||||
Here's an example of reference links in action:
|
||||
|
||||
This document was created in GNU Emacs using [markdown-mode][]. It
|
||||
provides syntax highlighting for [Markdown][] documents which allows
|
||||
reference-style links like these. The reference definitions can even
|
||||
contain alternate text such as [this one][id].
|
||||
|
||||
[markdown-mode]: http://jrblevin.freeshell.org/software/markdown-mode
|
||||
[Markdown]: http://daringfireball.net/projects/markdown
|
||||
[id]: http://reference-link.com/with/alt "Alternate Text"
|
||||
|
||||
|
||||
19. Slash-Star in Preformatted Text
|
||||
-----------------------------------
|
||||
|
||||
svn commit -m "Imported RCS project"
|
||||
svn add image.png binaries/*
|
||||
svn commit -m "Imported additional project files"
|
||||
|
||||
This text gets counted as part of the block quote too. But it can be ended
|
||||
by a star-slash: */ It is as if `markdown-mode` is using C++ style comments.
|
||||
|
||||
Fixed by commit d81138d.
|
||||
|
||||
|
||||
20. Underscores in Code Blocks
|
||||
------------------------------
|
||||
|
||||
*Contributed by shindo on 2008-01-20*
|
||||
|
||||
get_something_by_name()
|
||||
|
||||
|
||||
21. Escaped Characters
|
||||
----------------------
|
||||
|
||||
Escaped backticks: \`not code\`
|
||||
|
||||
Escaped underscores: don't\_italicize\_this
|
||||
|
||||
Escaped asterisks: \*also not italic\*
|
||||
|
||||
Escaped hash marks:
|
||||
\# This is not a heading
|
||||
|
||||
|
||||
22. Adjacent Wiki Links
|
||||
-----------------------
|
||||
|
||||
[[Two]] [[WikiLinks]] [[InARow]]
|
||||
|
||||
|
||||
23. SmartyPants
|
||||
---------------
|
||||
|
||||
This is a test of "SmartyPants," a progrm written by John Gruber for
|
||||
generating typographically correct HTML entities--ones such as
|
||||
the em-dash and elipsis...
|
||||
|
||||
|
||||
24. Horizontal Rules
|
||||
--------------------
|
||||
|
||||
* * * * *
|
||||
|
||||
- - - --- - - -
|
||||
|
||||
* *** * * *** * * *
|
||||
|
||||
|
||||
25. Asterisks and Underscores Across Blocks
|
||||
-------------------------------------------
|
||||
|
||||
Asterisks *should
|
||||
|
||||
not match across* block boundaries.
|
||||
|
||||
Underscores _should
|
||||
|
||||
not match across_ block boundaries.
|
||||
|
||||
Double Asterisks **should
|
||||
|
||||
not match across** block boundaries.
|
||||
|
||||
Double underscores __should
|
||||
|
||||
not match across__ block boundaries.
|
||||
|
||||
But, *this should still match*.
|
||||
|
||||
So should _this_.
|
||||
|
||||
Addressed by commit d81138d.
|
||||
|
||||
|
||||
26. Underscores Within Words
|
||||
----------------------------
|
||||
|
||||
Code fragments `can_have_underscores_inside_like` this.
|
||||
|
||||
|
||||
27. Code Blocks Spanning Lines
|
||||
------------------------------
|
||||
|
||||
Markdown allows `code
|
||||
fragments` to span across lines.
|
||||
|
||||
Let's make sure that ``double`
|
||||
backtick`code fragments`` work
|
||||
this way too.
|
||||
|
||||
However, they should `not
|
||||
|
||||
match` across blocks.
|
||||
|
||||
Here's another `valid` one.
|
||||
|
||||
|
||||
28. Pre Blocks and Nested Lists
|
||||
-------------------------------
|
||||
|
||||
- List level 1 item 1
|
||||
- List level 1 item 2
|
||||
|
||||
This is a second paragraph, part of item 2.
|
||||
|
||||
This nested pre block should match
|
||||
|
||||
So should this
|
||||
|
||||
Now we move back to the list.
|
||||
|
||||
- List level 1 item 3
|
||||
|
||||
- List level 2 item 1
|
||||
|
||||
Nested pre block
|
||||
|
||||
- List level 2 item 2
|
||||
|
||||
- List level 3 item 1
|
||||
|
||||
Nested pre block
|
||||
|
||||
|
||||
29. Colon After Wiki Link
|
||||
-------------------------
|
||||
|
||||
[[AnotherLink]]:note
|
||||
|
||||
|
||||
30. Incorrect Parsing of List Paragraph
|
||||
---------------------------------------
|
||||
|
||||
*Contributed by Luciano Gerber <garopaba_uk@yahoo.co.uk> on April 4, 2012.*
|
||||
|
||||
It is interesting to see what happens when one queries
|
||||
`social upheaval` and `protopalatial era`.
|
||||
|
||||
* `social upheaval`: the follwing queries have been tried:
|
||||
|
||||
social upheaval subClassOf
|
||||
|
||||
The preceding text should not be matched as a preformatted block.
|
||||
|
||||
|
||||
31. Footnotes
|
||||
-------------
|
||||
|
||||
This is a footnote marker,[^1] but this is not.[^]
|
||||
|
||||
[^1]: And the definition of the footnote is here.
|
||||
|
||||
[^2]: but this is preformatted text.
|
||||
|
||||
|
||||
32. Carat as Implicit Reference Link
|
||||
------------------------------------
|
||||
|
||||
This is a valid markdown link: [^][]
|
||||
|
||||
[^]: http://jblevins.org/ "And this is a valid reference defintion!"
|
||||
|
||||
|
||||
33. Email Address Inside Bold and Italic Spans
|
||||
----------------------------------------------
|
||||
|
||||
*Lorem <ipsum@dolor.sit> amet.*
|
||||
|
||||
**Lorem <ipsum@dolor.sit> amet.**
|
||||
|
||||
|
||||
34. URL Inside Bold and Italic Spans
|
||||
------------------------------------
|
||||
|
||||
*markdown-mode homepage http://jblevins.org/projects/markdown-mode/*
|
||||
|
||||
**markdown-mode homepage http://jblevins.org/projects/markdown-mode/**
|
||||
|
||||
35. Complex Preformatted Code Block
|
||||
-----------------------------------
|
||||
|
||||
class Employee < ActiveRecord::Base
|
||||
attr_accessible :github_username, :name
|
||||
|
||||
def self.syncify!
|
||||
begin
|
||||
employee_sync = GitOrganized::GithubEmployeeSync.new(
|
||||
GitOrganized::Organization.new(
|
||||
GitOrganized.config.default_org,
|
||||
["employees-pull", "employees-push"]
|
||||
),
|
||||
Sources.new
|
||||
)
|
||||
|
||||
employee_sync.sync
|
||||
rescue Github::Error::ServiceError => e
|
||||
retry
|
||||
end
|
||||
end
|
||||
|
||||
after_save do |employee| Employee.syncify! end
|
||||
after_destroy do |employee| Employee.syncify! end
|
||||
end
|
||||
|
||||
36. Fenced Code Blocks
|
||||
----------------------
|
||||
|
||||
Fenced code blocks begin with three or more tildes and end with a line
|
||||
with at least as many tildes.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
program hello
|
||||
implicit none
|
||||
print '(a)', 'Hello, world!'
|
||||
end program hello
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
They may also have a `lang` attribute.
|
||||
|
||||
~~~~~~~~~~~~~{: lang=fortran }
|
||||
program hello
|
||||
implicit none
|
||||
print '(a)', 'Hello, world!'
|
||||
end program hello
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In Kramdown, one specifies the language identifier as follows:
|
||||
|
||||
~~~ fortran
|
||||
program hello
|
||||
implicit none
|
||||
print '(a)', 'Hello, world!'
|
||||
end program hello
|
||||
~~~
|
||||
|
||||
or with a Maruku-style inline attribute list
|
||||
|
||||
~~~
|
||||
program hello
|
||||
implicit none
|
||||
print '(a)', 'Hello, world!'
|
||||
end program hello
|
||||
~~~
|
||||
{: .language-fortran}
|
25
tests/wiki-links.text
Normal file
25
tests/wiki-links.text
Normal file
|
@ -0,0 +1,25 @@
|
|||
Line 1
|
||||
[[Wiki Link]] at point 8.
|
||||
|
||||
Here's a second link, an aliased link [[first|second]], at point 73.
|
||||
The first two links are invalid. This third link, [[inline]], is a
|
||||
valid link since the file `inline.text` exists. The last link is at
|
||||
point 155.
|
||||
|
||||
Bracketed expressions in code blocks should not be matched as wiki
|
||||
links:
|
||||
|
||||
```
|
||||
{
|
||||
:user {
|
||||
:repositories [["clojars" {:sign-releases false}]]
|
||||
:plugins [
|
||||
[lein-cloverage "1.0.6"]
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- Local Variables: -->
|
||||
<!-- markdown-enable-wiki-links: t -->
|
||||
<!-- End: -->
|
49
webpage.sh
Executable file
49
webpage.sh
Executable file
|
@ -0,0 +1,49 @@
|
|||
#!/bin/sh
|
||||
|
||||
STARTRE='^;;; Commentary:$'
|
||||
STOPRE='^$'
|
||||
DATE=$(date +"%B %e, %Y %H:%M %Z")
|
||||
|
||||
echo "title: Emacs Markdown Mode
|
||||
description: A major mode for GNU Emacs for editing Markdown-formatted text files.
|
||||
markup: markdown
|
||||
icon: emacs
|
||||
city: Columbus
|
||||
created: May 24, 2007 23:47 GMT
|
||||
modified: $DATE" > index.text
|
||||
|
||||
echo "# Emacs Markdown Mode [![MELPA badge][melpa-badge]][melpa-link] [![MELPA stable badge][melpa-stable-badge]][melpa-stable-link] [![Travis CI Build Status][travis-badge]][travis-link]
|
||||
|
||||
[melpa-link]: https://melpa.org/#/markdown-mode
|
||||
[melpa-stable-link]: https://stable.melpa.org/#/markdown-mode
|
||||
[melpa-badge]: https://melpa.org/packages/markdown-mode-badge.svg
|
||||
[melpa-stable-badge]: https://stable.melpa.org/packages/markdown-mode-badge.svg
|
||||
[travis-link]: https://travis-ci.org/jrblevin/markdown-mode
|
||||
[travis-badge]: https://travis-ci.org/jrblevin/markdown-mode.svg?branch=master
|
||||
|
||||
<!-- This file is autogenerated by webpage.sh from the comments at the top of
|
||||
markdown-mode.el. Make edits there, not here. -->" > README.md
|
||||
|
||||
cat markdown-mode.el |\
|
||||
# Keep only the Commentary section
|
||||
awk "/$STARTRE/,/$STOPRE/" |\
|
||||
# Remove the start and step regexps
|
||||
grep -v "$STARTRE" | grep -v "$STOPRE" |\
|
||||
# Convert headers
|
||||
sed -e 's/^;;; \(.*\):$/## \1/' |\
|
||||
# Remove leading spaces (but don't disturb pre blocks)
|
||||
sed -e 's/^;;[ ]\{0,1\}//' |\
|
||||
# Escape wiki links
|
||||
#sed -e 's/\(\[\[[^]\n]*\]\]\)/\\\1/g' |\
|
||||
# Use Markdown-style backticks for single-quoted lisp code
|
||||
sed -e 's/`\([^'\'']*\)'\''/`\1`/g' |\
|
||||
# Use <kbd> tags for single character, unprefixed keybindings
|
||||
sed -e 's/`\([^`]\)`/<kbd>\1<\/kbd>/g' |\
|
||||
# Use <kbd> tags for TAB and RET keys
|
||||
sed -e 's/`TAB`/<kbd>TAB<\/kbd>/g' |\
|
||||
sed -e 's/`RET`/<kbd>RET<\/kbd>/g' |\
|
||||
# Use <kbd> tags for keybindings prefixed by C, M, or S
|
||||
sed -e 's/`\([CMS]-[^`]*\)`/<kbd>\1<\/kbd>/g' |\
|
||||
# Remove email addresses
|
||||
sed -e 's/ <[^>]*@[^<]*> / /g' \
|
||||
| tee -a README.md >> index.text
|
Loading…
Add table
Reference in a new issue