Re: [O] [RFC] Fixing link encoding once and for all
Hello, Neil Jerram writes: > Do you mean Windows file names in existing Org files? I.e. the > back-compatibility concern? > > If so, yes, I confess I didn't think at all about back-compatibility, > with my suggestion above. So perhaps that rules my idea out. > > If we were starting from scratch, however, > - I believe it would technically be fine; i.e. it's a complete and > unambiguous encoding > - it might be considered awkward for Windows users to have to write > c:\\system32\\mydoc.txt instead of c:\system32\mydoc.txt, but I don't > know how big a concern that would be. Thinking a bit more about it, we don't need to escape /all/ square brackets, only "]]" and "][" constructs. Therefore, we don't need to escape every backslash either. The regexp for bracket links could be, in its simple (!) form: \[\[\(.*?[^\\]\(?:\\\)*\)\]\(?:\[\([^\000]+?\)\]\)?\] Most links would need no change. I see one notable exception: directories in Windows: [[c:\system32\\]] for "c:\system32\" Some further notes: 1. Macros already use backslashes to escape commas in arguments, so it is at least consistent with this part of Org. 2. The description part of the link, like most parts of Org, does not use backslash escaping. If needed, we can implement an entity for a square bracket. 3. There will be some backward compatibility issues. We can add a checker in Org Lint to catch most of those. For example, we could look at URI where every percent is followed only by 25, 5B, and 5D. WDYT? Regards, -- Nicolas Goaziou
Re: [O] Multiple Indices
Hi Robert, * Robert Love [2019-02-28; 23:52]: > I’m using Org mode to document some software. When I see > Texinfo used for this, I see that you can have a subject index > and a variable index. How do I achieve the same thing in Org > mode? Can someone point to examples of this? I don't know anything about texinfo, but the Org-mode manual has three indices. You may have a look at doc/org-manual.org. Ciao; Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [O] [RFC] Fixing link encoding once and for all
Nicolas Goaziou writes: > The regexp for bracket links could be, in its simple (!) form: > > \[\[\(.*?[^\\]\(?:\\\)*\)\]\(?:\[\([^\000]+?\)\]\)?\] Small update, in its string form now: "\\[\\[\\([^\000]*?[^\\]\\(\\)*\\)\\]\\(?:\\[\\([^\000]+?\\)\\]\\)?\\]"
Re: [O] [RFC] Fixing link encoding once and for all
On Fri, Mar 1, 2019 at 9:15 AM Nicolas Goaziou wrote: > Thinking a bit more about it, we don't need to escape /all/ square > brackets, only "]]" and "][" constructs. Therefore, we don't need to > escape every backslash either. Brilliant!
Re: [O] [RFC] Fixing link encoding once and for all
Hi there, I like this proposal. On 2019-03-01, Nicolas Goaziou wrote: > 3. There will be some backward compatibility issues. We can add >a checker in Org Lint to catch most of those. For example, we could >look at URI where every percent is followed only by 25, 5B, and 5D. I do not understand this point. What is special about URIs where *only* those occur? Might compatibility issues not arise if those occur at all (while others such as %28 and %29 for parentheses might occur without problems as well)? Best wishes Jens
Re: [O] [RFC] Fixing link encoding once and for all
Hello, Jens Lechtenboerger writes: > On 2019-03-01, Nicolas Goaziou wrote: > >> 3. There will be some backward compatibility issues. We can add >>a checker in Org Lint to catch most of those. For example, we could >>look at URI where every percent is followed only by 25, 5B, and 5D. > > I do not understand this point. What is special about URIs where > *only* those occur? Might compatibility issues not arise if those > occur at all (while others such as %28 and %29 for parentheses might > occur without problems as well)? If a URI seems percent encoded, but only uses %25, %5B and %5D as escape combinations, there is a high chance that it is Org-encoded, and therefore uses a deprecated syntax. We could send a warning to the user in this case; they might want to clean the URI. OTOH, if there is %28, or %29, we are sure it isn't Org-encoded, and therefore, the percent-encoding was intended right from the start (like in your Wikipedia link). Regards, -- Nicolas Goaziou
Re: [O] [RFC] Fixing link encoding once and for all
On 2019-03-01, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> On 2019-03-01, Nicolas Goaziou wrote: >> >>> 3. There will be some backward compatibility issues. We can add >>>a checker in Org Lint to catch most of those. For example, we could >>>look at URI where every percent is followed only by 25, 5B, and 5D. >> >> I do not understand this point. What is special about URIs where >> *only* those occur? Might compatibility issues not arise if those >> occur at all (while others such as %28 and %29 for parentheses might >> occur without problems as well)? > > If a URI seems percent encoded, but only uses %25, %5B and %5D as escape > combinations, there is a high chance that it is Org-encoded, and > therefore uses a deprecated syntax. We could send a warning to the user > in this case; they might want to clean the URI. > > OTOH, if there is %28, or %29, we are sure it isn't Org-encoded, and > therefore, the percent-encoding was intended right from the start (like > in your Wikipedia link). Thanks for the clarification. Makes sense. Best wishes Jens
[O] bug#34684: 26.1; Strange characters when inserting date
Eli Zaretskii writes: >> Iʼm assuming thereʼs an issue with buffer-file-coding-system or >> similar. > > Unlikely: buffer-file-coding-system has no effect whatsoever on the > text that is inserted into a buffer, it only has effect when you want > to save the buffer or send it to some sub-process. > > It could be some snafu in Org, though, e.,g. if it doesn't know how to > support that value of $LANG. In any case, should be reported to Org > developers first. org-time-stamp just calls essentially (insert (format-time-string "<%Y-%m-%d %a>" (current-time))) so itʼs hard to see how this could be an issue in Org. Does this happen when running 'emacs -Q'? Robert
[O] bug#34684: 26.1; Strange characters when inserting date
> From: Robert Pluim > Cc: Eli Zaretskii , 34...@debbugs.gnu.org > Date: Fri, 01 Mar 2019 11:00:01 +0100 > > > It could be some snafu in Org, though, e.,g. if it doesn't know how to > > support that value of $LANG. In any case, should be reported to Org > > developers first. > > org-time-stamp just calls essentially > > (insert (format-time-string "<%Y-%m-%d %a>" (current-time))) > > so itʼs hard to see how this could be an issue in Org. That's only so if the above produces the same garbled result as in the original report. Does it?
[O] bug#34684: 26.1; Strange characters when inserting date
Robert Pluim writes: > Eli Zaretskii writes: > >>> From: Robert Pluim >>> Cc: Eli Zaretskii , 34...@debbugs.gnu.org >>> Date: Fri, 01 Mar 2019 11:00:01 +0100 >>> >>> > It could be some snafu in Org, though, e.,g. if it doesn't know how to >>> > support that value of $LANG. In any case, should be reported to Org >>> > developers first. >>> >>> org-time-stamp just calls essentially >>> >>> (insert (format-time-string "<%Y-%m-%d %a>" (current-time))) >>> >>> so itʼs hard to see how this could be an issue in Org. >> >> That's only so if the above produces the same garbled result as in the >> original report. Does it? > > Didnʼt I send this yesterday? > > $ LANG=zh_HK src/emacs -Q -l ss.el > (require 'org) > (org-time-stamp) > <2019-03-01 五> > > I think '五' is 'Five', but donʼt quote me on that. > > So at least for me itʼs working correctly (in both *scratch* and an > Org-mode buffer), which means thereʼs something wrong in the > reporter's configuration somewhere. And also (insert (format-time-string "<%Y-%m-%d %a>" (current-time))) produces the same result for me.
[O] bug#34684: 26.1; Strange characters when inserting date
Eli Zaretskii writes: >> From: Robert Pluim >> Cc: Eli Zaretskii , 34...@debbugs.gnu.org >> Date: Fri, 01 Mar 2019 11:00:01 +0100 >> >> > It could be some snafu in Org, though, e.,g. if it doesn't know how to >> > support that value of $LANG. In any case, should be reported to Org >> > developers first. >> >> org-time-stamp just calls essentially >> >> (insert (format-time-string "<%Y-%m-%d %a>" (current-time))) >> >> so itʼs hard to see how this could be an issue in Org. > > That's only so if the above produces the same garbled result as in the > original report. Does it? Didnʼt I send this yesterday? $ LANG=zh_HK src/emacs -Q -l ss.el (require 'org) (org-time-stamp) <2019-03-01 五> I think '五' is 'Five', but donʼt quote me on that. So at least for me itʼs working correctly (in both *scratch* and an Org-mode buffer), which means thereʼs something wrong in the reporter's configuration somewhere. Robert
[O] bug#34684: 26.1; Strange characters when inserting date
> From: Robert Pluim > Cc: philip.w...@warwick.ac.uk, 34...@debbugs.gnu.org > Date: Fri, 01 Mar 2019 14:47:21 +0100 > > > That's only so if the above produces the same garbled result as in the > > original report. Does it? > > Didnʼt I send this yesterday? > > $ LANG=zh_HK src/emacs -Q -l ss.el > (require 'org) > (org-time-stamp) > <2019-03-01 五> > > I think '五' is 'Five', but donʼt quote me on that. This is not garbage by any measure. Please compare with what the OP reported. In any case, the original report was for Thursday, not Friday. the former should AFAIU display 四. But neither is nowhere close to the sequence the OP reported, not even if I break the correct character into individual bytes, so some other factor is at work here. > So at least for me itʼs working correctly (in both *scratch* and an > Org-mode buffer), which means thereʼs something wrong in the > reporter's configuration somewhere. What, if anything, is wrong with the OP's configuration is exactly the issue here. There's no question that current-time and format-time-string work in general.
[O] bug#34684: 26.1; Strange characters when inserting date
Eli Zaretskii writes: >> From: Robert Pluim >> Cc: philip.w...@warwick.ac.uk, 34...@debbugs.gnu.org >> Date: Fri, 01 Mar 2019 14:47:21 +0100 >> >> > That's only so if the above produces the same garbled result as in the >> > original report. Does it? >> >> Didnʼt I send this yesterday? >> >> $ LANG=zh_HK src/emacs -Q -l ss.el >> (require 'org) >> (org-time-stamp) >> <2019-03-01 五> >> >> I think '五' is 'Five', but donʼt quote me on that. > > This is not garbage by any measure. Please compare with what the OP > reported. We are miscommunicating. I was demonstrating that in my setup, org-time-stamp produces the correct output => itʼs a configuration issue. > What, if anything, is wrong with the OP's configuration is exactly the > issue here. Right. Robert
[O] bug#34684: 26.1; Strange characters when inserting date
> From: Robert Pluim > Cc: philip.w...@warwick.ac.uk, 34...@debbugs.gnu.org > Date: Fri, 01 Mar 2019 15:25:04 +0100 > > We are miscommunicating. I was demonstrating that in my setup, > org-time-stamp produces the correct output => itʼs a configuration > issue. I'm not yet sure it's a configuration issue. It could be some bug specific to Windows.
Re: [O] Bug: HTTP links that contain %20 get malformed to %2520 - affects ODT export [9.2.1 (9.2.1-dist @ /home/ehere/emacs-scripts/org-9.2.1/lisp/)]
Hello, Edmund Christian Herenz writes: > Consider the following HTTP link: > http://skyserver.sdss.org/dr14/en/tools/quicklook/summary.aspx?ra=11%2054%2048.85&dec=+24%2043%2033.0 > > I have this link in the kill-ring, mark 'some text' in an org-mode buffer > and run org-insert-link (C-c C-l). Then I yank the link (C-y) in the > minibuffer, and hit enter twice (since the marked text is what I want > for the description). > > Now, this is what I get in the org-mode buffer: > [[http://skyserver.sdss.org/dr14/en/tools/quicklook/summary.aspx?ra=11%252054%252048.85&dec=+24%252043%252033.0][some > text]] > > As you can see the %20 gets encoded again to %2520. %25 is the % sign > defined in RFC 3986. I think we run into the problem that is mentioned > in this RFC in Sect 2.4 https://tools.ietf.org/html/rfc3986 - > i.e. encoding an decoding the % sign in URIs when it is not required, as > the URI is already formed. It is not an issue per se. For historical reasons, Org needs to escape % characters, and uses percent encoding to do so. So you have two layers of percent encoding. > > Th expected behavoiour would be that the link gets inserted as is. It does not work that way at the moment. However, that might change in a next release. This is being discussed at the moment in this ML. > However, when exporting to ODT, no such decoding happens - and I got > malformed URL (i.e. with %2520 instead of %20) in my ODT document. This should now be fixed. Thank you. Regards, -- Nicolas Goaziou
[O] New bug in org-agenda?
Using Org mode version 9.2.1 (9.2.1-33-g029cf6-elpaplus), I get an error
message when I run org-agenda:
Debugger entered--Lisp error: (error "Wrong number of arguments")
propertize("WAITING" nil face org-warning)
org-agenda-get-restriction-and-command(nil)
org-agenda(nil)
funcall-interactively(org-agenda nil)
call-interactively(org-agenda record nil)
command-execute(org-agenda record)
execute-extended-command(nil "org-agenda" #("org-agenda" 0 1 (fontified t) 1
2 (fontified t) 2 3 (fontified t) 3 4 (fontified t) 4 5 (fontified t) 5 6
(fontified t) 6 7 (fontified t) 7 8 (fontified t) 8 9 (fontified t) 9 10
(fontified nil)))
funcall-interactively(execute-extended-command nil "org-agenda"
#("org-agenda" 0 1 (fontified t) 1 2 (fontified t) 2 3 (fontified t) 3 4
(fontified t) 4 5 (fontified t) 5 6 (fontified t) 6 7 (fontified t) 7 8
(fontified t) 8 9 (fontified t) 9 10 (fontified nil)))
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
This has only started in the last few days and my init.el file has not changed,
so it seems to be something in the latest update.
Richard Stanton
Re: [O] New bug in org-agenda?
Hello,
Richard Stanton writes:
> Using Org mode version 9.2.1 (9.2.1-33-g029cf6-elpaplus), I get an error
> message when I run org-agenda:
>
> Debugger entered--Lisp error: (error "Wrong number of arguments")
> propertize("WAITING" nil face org-warning)
> org-agenda-get-restriction-and-command(nil)
> org-agenda(nil)
> funcall-interactively(org-agenda nil)
> call-interactively(org-agenda record nil)
> command-execute(org-agenda record)
> execute-extended-command(nil "org-agenda" #("org-agenda"
> 0 1 (fontified t) 1 2 (fontified t) 2 3 (fontified t) 3 4 (fontified
> t) 4 5 (fontified t) 5 6 (fontified t) 6 7 (fontified t)
> 7 8 (fontified t) 8 9 (fontified t) 9 10 (fontified nil)))
> funcall-interactively(execute-extended-command nil "org-agenda"
> #("org-agenda" 0 1 (fontified t) 1 2 (fontified t) 2 3 (fontified t)
> 3 4 (fontified t) 4 5 (fontified t) 5 6 (fontified t) 6 7 (fontified
> t) 7 8 (fontified t) 8 9 (fontified t) 9 10 (fontified nil)))
> call-interactively(execute-extended-command nil nil)
> command-execute(execute-extended-command)
>
> This has only started in the last few days and my init.el file has not
> changed, so it seems to be something in the latest update.
This was fixed a few days ago.
Regards,
--
Nicolas Goaziou
Re: [O] Mutually-exclusive Org tags still inherit each other
Well, I think it’s unreasonable to ask users to reinforce manually and
continuously something they’ve already specified in their settings.
Besides, my example was intentionally trivial—imagine managing a large
tree and having to remember which tags are mutually exclusive to what,
all the time.
But, no matter! I have created a patch! It works great, even for edge
cases like when an entry has two tags that are set as mutually
exclusive to each other.
First, we have two new functions: one which returns the tags currently
defined as mutually exclusive, and one which checks for tags that
conflict with the given tag (with the help of the cl-loop “if” clause
and cl-set-difference).
(defun org-get-exclusive-tags (&optional alist)
"Return a list of mutually exclusive tags occuring in ALIST.
ALIST defaults to `org-current-tag-alist'. The result is a list
of lists of strings, where each string represents a tag, and each
list of strings represents a group of mutually exclusive tags."
;; Most of this code was culled from `org-fast-tag-selection'
(let ((alist (or alist org-current-tag-alist))
groups ingroup intaggroup tag)
(dolist (e alist groups)
(cond
((eq (car e) :startgroup)
(push '() groups) (setq ingroup t))
((eq (car e) :endgroup)
(setq ingroup nil))
((eq (car e) :startgrouptag)
(setq intaggroup t))
((eq (car e) :endgrouptag)
(setq intaggroup nil))
((equal e '(:newline))) ; do nothing
((equal e '(:grouptags))) ; do nothing
(t
(setq tag (copy-sequence (car e)))
(when ingroup (push tag (car groups
(defun org-get-conflicting-tags (tags &optional alist)
"For list TAGS, return tags which would conflict according to ALIST.
ALIST defaults to `org-current-tag-alist'. For more information
on mutually exclusive tags, see Info node `(org)Tag Hierarchy'."
(let* ((alist (or alist org-current-tag-alist))
(groups (org-get-exclusive-tags alist)))
(cl-loop for group in groups
if (cl-some (lambda (x) (member x group)) tags)
append (cl-set-difference group tags :test 'equal
Then, we redefine org-get-tags slightly to remove conflicting tags
from the list of inherited tags.
(defun org-get-tags (&optional pos local)
;; "the usual docstring, skipped here for email brevity"
(if (and org-trust-scanner-tags
(or (not pos) (eq pos (point)))
(not local))
org-scanner-tags
(org-with-point-at (or pos (point))
(unless (org-before-first-heading-p)
(org-back-to-heading t)
(let ((ltags (org--get-local-tags)) itags)
(if (or local (not org-use-tag-inheritance)) ltags
(let* ((conflicting-tags (org-get-conflicting-tags ltags))
(ct-predicate (lambda (x) (member x conflicting-tags
(while (org-up-heading-safe)
(nconc conflicting-tags
(org-get-conflicting-tags itags
org-current-tag-alist))
(setq itags (append (mapcar #'org-add-prop-inherited
(cl-remove-if ct-predicate
(org--get-local-tags)))
itags)))
(setq itags (append
(cl-remove-if ct-predicate org-file-tags)
itags)))
(delete-dups
(append (org-remove-uninherited-tags itags) ltags
If everything looks good, I’ll figure out how to submit it as a proper
Git patch (right now it’s just “code that’s been sitting in my config
for weeks”), and do the copyright-assignment thing so we can get it
merged. I hope you like it!
—Tina
On Sat, Feb 9, 2019 at 10:03 AM Nicolas Goaziou wrote:
>
> Hello,
>
> Tina Russell writes:
>
> > So, according to the Org documentation: “You can also group together tags
> > that are mutually exclusive by using braces … Selecting a tag in a group of
> > mutually exclusive tags will turn off any other tags from that group.
> >
> > But, if I do this…
> >
> > #+TAGS: { place(c) container(c) object(o) }
> >
> > * Room :place:
> > ** Box :container:
> > *** Toy :object:
> >
> > …and then use (org-get-tags) on “Toy,” it reports that it has the tags
> > “place”, “container”, and “object”, even though these tags are all defined
> > to be mutually exclusive! This is a problem,
>
> Not really. `org-get-tags' is a low-level function, i.e., it has no
> knowledge about tag groups or mutually exclusive tags.
>
> > since turning off tag
> > inheritance (for a document or for specific tags) seems to be an
> > all-or-nothing affair. That means if I wanted to do this:
> >
> > * Room :place:
> > ** Bookcase
> > ** Dresser
> > ** Desk
> > ** Nightstand
> > ** Closet
> > *** Box :container:
> > Toy :object:
> >
> > …and then search for all headings with the tag “place,” either (with
[O] Positioning of Tags on Header ?
How does Org position the Tags on the Header line when it reads in an Org file with Tags? It seems that the Tags move from time to time and that can actually cause the file to be viewed as "changed" by the change control system (CVS). I would've thought that the Tags are positioned when inserted and then left alone. Is something else happening? -- David
Re: [O] [Proposal] Make header argument :mkdirp yes work for other header arguments not just :tangle
Christopher M. Miles writes:
> I hope `:mkdirp` header argument can also work for other related header
> arguments like `:dir`, `:file` etc not just `:tangle`. Like following
> example.
>
> #+begin_src sh :mkdirp yes :dir "data/code/mkdirp/dir" :file "test" :results
> file link
> echo "hello"
> #+end_src
>
> Do you have any idea about this?
I made a patch for make ~:mkdir~ support for ~:dir~ header argument. But I
still got
some issues. I added patch in attachment.
>From 708cc9a1fba5869941bcff0cefcaf47f64838ce3 Mon Sep 17 00:00:00 2001
From: stardiviner
Date: Sat, 2 Mar 2019 12:11:47 +0800
Subject: [PATCH] ob-core.el: Make :mkdirp work for :dir too
* lisp/ob-core.el (org-babel-execute-src-block): make directory if :dir
path does not exist when :mkdirp yes exist.
* doc/org-manualo.rg (mkdirp): declare new change in manual.
* etc/ORG-NEWS: declare changes in ORG-NEWS.
* testing/lisp/test-ob-core.el: Add a specific testing file for
ob-core.el, and add a testing for :mkdir yes work with :dir header
argument usage.
---
doc/org-manual.org | 7 ---
etc/ORG-NEWS | 6 ++
lisp/ob-core.el | 9 +++--
testing/lisp/test-ob-core.el | 30 ++
4 files changed, 47 insertions(+), 5 deletions(-)
create mode 100644 testing/lisp/test-ob-core.el
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 00e5e1072..30c797ad7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17476,9 +17476,10 @@ to source file(s).
location. Example: =:tangle FILENAME=.
#+cindex: @samp{mkdirp}, header argument
-The =mkdirp= header argument creates parent directories for tangled
-files if the directory does not exist. =yes= enables directory
-creation and =no= inhibits directory creation.
+The =mkdirp= header argument creates parent directories for =dir=
+header argument specified path and tangled files if the directory does
+not exist. =yes= enables directory creation and =no= inhibits
+directory creation.
#+cindex: @samp{comments}, header argument
The =comments= header argument controls inserting comments into
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 057440a71..cd5e4d900 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -157,6 +157,12 @@ A call of ~org-set-tags-command~ with prefix argument C-u C-u avoids
the fast tag selection interface and instead offers the plain
interface.
+*** ~:mkdirp~ now supports create directory for ~:dir~ path
+
+The ~:mkdirp~ header argument used to only work for ~:tangle~ tangle
+files. Now ~:mkdirp~ works for ~:dir~ too. This is more convenient for
+specify default directory and with ~:file~ header argument.
+
* Version 9.2
** Incompatible changes
*** Removal of OrgStruct mode mode and radio lists
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index e6f0edba5..6baa11de4 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -678,8 +678,13 @@ block."
(org-src-coderef-regexp coderef) "" expand nil nil 1
(dir (cdr (assq :dir params)))
(default-directory
- (or (and dir (file-name-as-directory (expand-file-name dir)))
- default-directory))
+ ;; Possibly create the parent directories for file.
+ (let ((mkdirp (cdr (assq :mkdirp params)))
+ (fnd (file-name-as-directory (expand-file-name dir
+ (if (and (string= mkdirp "yes") fnd)
+ (make-directory fnd 'parents))
+ (or (and dir (file-name-as-directory (expand-file-name dir)))
+ default-directory)))
(cmd (intern (concat "org-babel-execute:" lang)))
result)
(unless (fboundp cmd)
diff --git a/testing/lisp/test-ob-core.el b/testing/lisp/test-ob-core.el
new file mode 100644
index 0..c601e44eb
--- /dev/null
+++ b/testing/lisp/test-ob-core.el
@@ -0,0 +1,30 @@
+;;; test-ob-core.el --- tests for ob-core.el
+
+;; Copyright (c) 2018-2022 Free Software Foundation, Inc.
+;; Authors: stardiviner
+
+;; 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
