|
@@ -1,4 +1,4 @@
|
|
|
-#+OPTIONS: H:3 num:nil toc:t \n:nil @:t ::t |:t ^:nil -:t f:t *:t TeX:t LaTeX:t skip:nil d:(HIDE) tags:not-in-toc
|
|
|
+#+OPTIONS: H:3 num:nil toc:t \n:nil ::t |:t ^:nil -:t f:t *:t tex:t d:(HIDE) tags:not-in-toc ':t
|
|
|
#+STARTUP: align fold nodlcheck hidestars oddeven lognotestate
|
|
|
#+SEQ_TODO: TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
|
|
|
#+TAGS: Write(w) Update(u) Fix(f) Check(c)
|
|
@@ -76,7 +76,6 @@ it might be better to put an exercise example here if someone has one.
|
|
|
:END:
|
|
|
|
|
|
|
|
|
-#<<fireforg>>
|
|
|
* Fireforg, a Firefox extension for org interaction (EXPERIMENTAL)
|
|
|
|
|
|
#+index: Fireforg
|
|
@@ -528,22 +527,22 @@ The following notes should be taken into consideration before using Fireforg:
|
|
|
:Created: [2010-03-25 Do]
|
|
|
:END:
|
|
|
|
|
|
- - [[http://tools.ietf.org/html/rfc2046.html#section-5.1.1][RFC2046, 5.1.1]]
|
|
|
-
|
|
|
-#+BEGIN_QUOTE
|
|
|
- NOTE: Conspicuously missing from the "multipart" type is a notion of
|
|
|
- structured, related body parts. It is recommended that those wishing
|
|
|
- to provide more structured or integrated multipart messaging
|
|
|
- facilities should define subtypes of multipart that are syntactically
|
|
|
- identical but define relationships between the various parts. For
|
|
|
- example, subtypes of multipart could be defined that include a
|
|
|
- distinguished part which in turn is used to specify the relationships
|
|
|
- between the other parts, probably referring to them by their
|
|
|
- Content-ID field. Old implementations will not recognize the new
|
|
|
- subtype if this approach is used, but will treat it as
|
|
|
- multipart/mixed and will thus be able to show the user the parts that
|
|
|
- are recognized.
|
|
|
-#+END_QUOTE
|
|
|
+ - [[http://tools.ietf.org/html/rfc2046.html#section-5.1.1][RFC2046, 5.1.1]]
|
|
|
+
|
|
|
+ #+BEGIN_QUOTE
|
|
|
+ NOTE: Conspicuously missing from the "multipart" type is a notion of
|
|
|
+ structured, related body parts. It is recommended that those wishing
|
|
|
+ to provide more structured or integrated multipart messaging
|
|
|
+ facilities should define subtypes of multipart that are syntactically
|
|
|
+ identical but define relationships between the various parts. For
|
|
|
+ example, subtypes of multipart could be defined that include a
|
|
|
+ distinguished part which in turn is used to specify the relationships
|
|
|
+ between the other parts, probably referring to them by their
|
|
|
+ Content-ID field. Old implementations will not recognize the new
|
|
|
+ subtype if this approach is used, but will treat it as
|
|
|
+ multipart/mixed and will thus be able to show the user the parts that
|
|
|
+ are recognized.
|
|
|
+ #+END_QUOTE
|
|
|
*** MIME multipart: order of entities inside a multipart
|
|
|
:PROPERTIES:
|
|
|
:Created: [2010-03-25 Do]
|
|
@@ -551,47 +550,47 @@ The following notes should be taken into consideration before using Fireforg:
|
|
|
|
|
|
- [[http://tools.ietf.org/html/rfc2046.html#section-5.1.3][RFC2046, 5.1.3]]
|
|
|
|
|
|
-#+BEGIN_QUOTE
|
|
|
-5.1.3. Mixed Subtype
|
|
|
+ #+BEGIN_QUOTE
|
|
|
+ 5.1.3. Mixed Subtype
|
|
|
|
|
|
- The "mixed" subtype of "multipart" is intended for use when the body
|
|
|
- parts are independent and need to be bundled in a particular order.
|
|
|
- Any "multipart" subtypes that an implementation does not recognize
|
|
|
- must be treated as being of subtype "mixed".
|
|
|
+ The "mixed" subtype of "multipart" is intended for use when the body
|
|
|
+ parts are independent and need to be bundled in a particular order.
|
|
|
+ Any "multipart" subtypes that an implementation does not recognize
|
|
|
+ must be treated as being of subtype "mixed".
|
|
|
|
|
|
-#+END_QUOTE
|
|
|
+ #+END_QUOTE
|
|
|
|
|
|
- [[http://tools.ietf.org/html/rfc2046.html#section-5.1.4][RFC2046, 5.1.4]]
|
|
|
|
|
|
-#+BEGIN_QUOTE
|
|
|
-5.1.4. Alternative Subtype
|
|
|
-
|
|
|
- The "multipart/alternative" type is syntactically identical to
|
|
|
- "multipart/mixed", but the semantics are different. In particular,
|
|
|
- each of the body parts is an "alternative" version of the same
|
|
|
- information.
|
|
|
-
|
|
|
- Systems should recognize that the content of the various parts are
|
|
|
- interchangeable. Systems should choose the "best" type based on the
|
|
|
- local environment and references, in some cases even through user
|
|
|
- interaction. As with "multipart/mixed", the order of body parts is
|
|
|
- significant. In this case, the alternatives appear in an order of
|
|
|
- increasing faithfulness to the original content. In general, the
|
|
|
- best choice is the LAST part of a type supported by the recipient
|
|
|
- system's local environment.
|
|
|
-#+END_QUOTE
|
|
|
-
|
|
|
-#+BEGIN_QUOTE
|
|
|
- In general, user agents that compose "multipart/alternative" entities
|
|
|
- must place the body parts in increasing order of preference, that is,
|
|
|
- with the preferred format last. For fancy text, the sending user
|
|
|
- agent should put the plainest format first and the richest format
|
|
|
- last. Receiving user agents should pick and display the last format
|
|
|
- they are capable of displaying. In the case where one of the
|
|
|
- alternatives is itself of type "multipart" and contains unrecognized
|
|
|
- sub-parts, the user agent may choose either to show that alternative,
|
|
|
- an earlier alternative, or both.
|
|
|
-#+END_QUOTE
|
|
|
+ #+BEGIN_QUOTE
|
|
|
+ 5.1.4. Alternative Subtype
|
|
|
+
|
|
|
+ The "multipart/alternative" type is syntactically identical to
|
|
|
+ "multipart/mixed", but the semantics are different. In particular,
|
|
|
+ each of the body parts is an "alternative" version of the same
|
|
|
+ information.
|
|
|
+
|
|
|
+ Systems should recognize that the content of the various parts are
|
|
|
+ interchangeable. Systems should choose the "best" type based on the
|
|
|
+ local environment and references, in some cases even through user
|
|
|
+ interaction. As with "multipart/mixed", the order of body parts is
|
|
|
+ significant. In this case, the alternatives appear in an order of
|
|
|
+ increasing faithfulness to the original content. In general, the
|
|
|
+ best choice is the LAST part of a type supported by the recipient
|
|
|
+ system's local environment.
|
|
|
+ #+END_QUOTE
|
|
|
+
|
|
|
+ #+BEGIN_QUOTE
|
|
|
+ In general, user agents that compose "multipart/alternative" entities
|
|
|
+ must place the body parts in increasing order of preference, that is,
|
|
|
+ with the preferred format last. For fancy text, the sending user
|
|
|
+ agent should put the plainest format first and the richest format
|
|
|
+ last. Receiving user agents should pick and display the last format
|
|
|
+ they are capable of displaying. In the case where one of the
|
|
|
+ alternatives is itself of type "multipart" and contains unrecognized
|
|
|
+ sub-parts, the user agent may choose either to show that alternative,
|
|
|
+ an earlier alternative, or both.
|
|
|
+ #+END_QUOTE
|
|
|
* Org mode issue tracking library
|
|
|
|
|
|
A collection of helper functions to maintain the [[file:org-issues.org][Issue file]] from within
|
|
@@ -601,23 +600,23 @@ You can download a current version of this file [[file:code/elisp/org-issue.el][
|
|
|
|
|
|
Currently following commands are provided:
|
|
|
|
|
|
- - `org-issue-new' :: File a new issue for current message
|
|
|
+ - 'org-issue-new' :: File a new issue for current message
|
|
|
|
|
|
- Creates a new TODO in `org-issue-issue-file' below the headline
|
|
|
+ Creates a new TODO in 'org-issue-issue-file' below the headline
|
|
|
"New Issues" with keyword NEW. If customization variable
|
|
|
- `org-issue-message-flag' is non-nil and flagging messages is
|
|
|
+ 'org-issue-message-flag' is non-nil and flagging messages is
|
|
|
supported, the message of this issue is flagged.
|
|
|
|
|
|
- - `org-issue-close' :: Close issue of current message.
|
|
|
+ - 'org-issue-close' :: Close issue of current message.
|
|
|
|
|
|
- - `org-issue-tag' :: Tag issue of current message.
|
|
|
+ - 'org-issue-tag' :: Tag issue of current message.
|
|
|
|
|
|
- - `org-issue-update-message-flag' :: Update message flag according
|
|
|
+ - 'org-issue-update-message-flag' :: Update message flag according
|
|
|
to issue file.
|
|
|
|
|
|
If the issue for current message is closed, the message flag is
|
|
|
removed.
|
|
|
|
|
|
- - `org-issue-link-gmane' :: An Org mode web link pointing to current
|
|
|
+ - 'org-issue-link-gmane' :: An Org mode web link pointing to current
|
|
|
message on gmane is pushed to killring and clipboard.
|
|
|
|