Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
t...@tsdye.com (Thomas S. Dye) writes: Bibtex.el is not that hard to configure. I think I have something like this to configure FIRSTAUTHOR-YY (without the hyphen): (setq bibtex-autokey-titlewords 0 bibtex-autokey-titlewords-stretch 0 bibtex-autokey-titleword-length 0 bibtex-autokey-edit-before-use nil) But this only works on new keys and I wouldn't want old .bib file not working. At this point I think the benefit of citation shortcuts is relatively modest and the limitation of requiring authors to ensure keys don't end in punctuation potentially onerous. On balance, I think strong consideration should be given to the option of not using shortcuts. But Org is also a format. I have for instance written limited Org support for texworks. For people who do not have the luxury of using Emacs easy syntax matters. Personally, I think the benefit of short citations is large. I think allowing different characters if the least bad solution. Inline footnotes are also limited compared to footnote-definitions, so perhaps it is not that bad... —Rasmus -- Bang bang
Re: [O] Bleeding edge in elpa
Nikolai Weibull writes: Is trying to manage it via git+make oneself less likely to cause incidents? There's a bunch of people who seem to manage it just fine. From the FAQ: The master branch of the git repository always contains the bleeding edge development code. This is important for Org's fast development, because code on master gets checked out by many people daily and we quickly receive bug reports if something is wrong. On rare occasions, this code may not function perfectly for a limited time while we are trying to fix things. It is therefore recommended to keep a known-good version of org-mode installed outside the source tree and always run the full test suite before using a new version from master. Yes, if the absolutely latest master doesn't work, people can just check out whatever version was working for them last and continue without waiting for the next snapshot from ELPA /which may or may not work). The more time that passes between releases, the harder it is to release a new version. And as this is the case here, having easy access to the latest “version” would lessen the effect of this. It would also allow more people to find bugs. It doesn't get any easier than it already is. Having both a stable and an unstable version of Org avilable via ELPA is a non-starter for the simple reason that the package manager can't deal with the versioning problems this would introduce. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Bleeding edge in elpa
On Sun, Mar 8, 2015 at 6:59 PM, Achim Gratz strom...@nexgo.de wrote: Nikolai Weibull writes: Is trying to manage it via git+make oneself less likely to cause incidents? There's a bunch of people who seem to manage it just fine. Did I say otherwise? Does this preclude making an alternative available, one that at least some would consider simpler to access? From the FAQ: The master branch of the git repository always contains the bleeding edge development code. This is important for Org's fast development, because code on master gets checked out by many people daily and we quickly receive bug reports if something is wrong. On rare occasions, this code may not function perfectly for a limited time while we are trying to fix things. It is therefore recommended to keep a known-good version of org-mode installed outside the source tree and always run the full test suite before using a new version from master. Yes, if the absolutely latest master doesn't work, people can just check out whatever version was working for them last and continue without waiting for the next snapshot from ELPA /which may or may not work). See below. The more time that passes between releases, the harder it is to release a new version. And as this is the case here, having easy access to the latest “version” would lessen the effect of this. It would also allow more people to find bugs. It doesn't get any easier than it already is. (How can this statement possibly be true?) Having both a stable and an unstable version of Org avilable via ELPA is a non-starter for the simple reason that the package manager can't deal with the versioning problems this would introduce. This could, I assume, and was sort of implied in my original e-mail, be solved by providing an “org” package as it is today (based off of maint) and an “org-edge” package that’d be based off of master.
Re: [O] Bleeding edge in elpa
A major benefit of an ELPA version of the bleeding edge version of Org is that it enables those of us who run Emacs and Org on machines where we can not install git (or just do not want to) to have the latest version of Org nonetheless. In a real-world situation, I want to collaborate on Org files with my wife and parents, and I want to use the current best version of Org (which has significant improvements to #+INCLUDE that I use), but I do not want to try to install git on their Windows machines, and I do not want to scare them off by introducing the world of Git in addition to Emacs. And it's not limited to #+INCLUDE. I've been using Org for many years, and no matter how good a release of Org has been, the version in maint has followed right behind with new killer features. Having that version in Elpa makes it easier for me to share the awesome. Aaron Ecay aarone...@gmail.com writes: IMO this is a bad idea. The bleeding edge version is expected to be somewhat unstable, and exposing it via ELPA will lead to foot-shooting incidents. I understand this concern in principle, but it is difficult for me to imagine how it would be validated in actual usage. Serious Org users are already forced to install and run git to use the master version, and whatever the dangers, the practice is almost completely without problems. A bleeding edge ELPA would merely make that simpler. I regularly use both the git master version of Org and the ELPA version of Org, and I do extensive elisp coding that interacts with both, and I do not remember a problem that could be described as foot-shooting. Any significant problems in a bleeding edge version would be resolved the same way they are in the master version of git, only with the solution packaged, delivered, and installed by the next day, except automatically. It is easy to imagine someone else unofficially packaging the bleeding edge version and making it available via ELPA, and hard to imagine that resulting in significant problems. Melpa is loaded with bleeding edge versions, but the problems I hear or see from it are very rare. Also, as noted before, if someone is unhappy with the bleeding edge version, switching back would be easy. On the other hand, it would be nice to have more regular releases from master to maint. AFAIK the last one was a year and a half ago (Org 8.2). However, this has traditionally required a lot of effort from Bastien and others, so it’s not a simple case of “wishing will make it so”. Very true, and no doubt there are benefits to having a stable version available. However, not providing the bleeding edge version on ELPA is not without cost. The mailing list is littered with responses from Nicolas saying that problem has been fixed in the master version One last thought: I think it would be better to name the versions stable and unstable, to match the meanings established by Debian. All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Achim Gratz strom...@nexgo.de writes: Rasmus writes: I agree. I have the same problem when I build documents (via CI) on a remote Debian server where I don't want to mess around with anything more than what comes with Emacs by default. You can use a tarball and the support for manual builds, described in: http://orgmode.org/worg/dev/org-build-system.html#sec-7 I have no desire to use anything more than what comes with emacs-24-nox on this system. I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple of other packages will move to GNU ELPA and thus separate release channels (these packages will still be bundled with Emacs). This means we can push out new versions easily, making more frequent releases more attractive. None of this is going to lift one core limitation of package manager: there can be only one. It doesn't support packages that subsume other packages, so org-whatever is totally different from org and would be installed together when referenced by dependencies even though it makes no sense. I'm arguing against org-whatever and for less time between Org version N and (1+ N). —Rasmus -- . . . The proofs are technical in nature and provides no real understanding
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Gregor Zattler telegr...@gmx.net writes: Sadly no: I reapplied `org-repair-property-drawers' on my org file with no customisation at all: emacs-snapshot -Q -nw -L /home/grfz/src/org-mode/lisp/ file.org ~/src/org-mode/etc/ORG-NEWS I loaded `org-repair-property-drawers' from ~/src/org-mode/etc/ORG-NEWS and executed it in file.org. Result is ’(nil nil nil nil nil nil nil nil nil nil nil nil ... )’ and the buffer file.org remains unmodified. Doesn't the function fix the anon file you sent? Is it possible to have access to the file? You might want to hide contents first with the following function (defun scramble-contents () (interactive) (let ((tree (org-element-parse-buffer))) (org-element-map tree '(code comment comment-block example-block fixed-width keyword link node-property plain-text verbatim) (lambda (obj) (cl-case (org-element-type obj) ((code comment comment-block example-block fixed-width keyword node-property verbatim) (let ((value (org-element-property :value obj))) (org-element-put-property obj :value (replace-regexp-in-string [[:alnum:]] x value (link (unless (string= (org-element-property :type obj) radio) (org-element-put-property obj :raw-link http://orgmode.org;))) (plain-text (org-element-set-element obj (replace-regexp-in-string [[:alnum:]] x obj) nil nil nil t) (let ((buffer (get-buffer-create *Scrambled text*))) (with-current-buffer buffer (insert (org-element-interpret-data tree)) (goto-char (point-min))) (switch-to-buffer buffer Regards,
Re: [O] Zotero csl file that uses parenthetical style for citations
Aloha Vaidheeswaran C, Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: On Sunday 08 March 2015 09:29 AM, Thomas S. Dye wrote: Is your doubt about his eventual success founded in a general skepticism about predicting the future (certainly warranted), or in some particular knowledge about the difficulty of the task? I have no such doubt or skepticism. Which means you either believe he will succeed or believe he will fail. Hopefully the former! If the latter, perhaps you could help Richard avoid potential problems? I would replace you with we. What I had in my palm is out on the table. What have you in your palms concerning in text and parenthetical styles in CSL. Thankfully, Richard demonstrated to his satisfaction that an off-the-shelf CSL style could be made to handle this situation. If this is the only potential problem you see, then this gives me hope that Richard will succeed in implementing an Org mode interface for an appropriate csl-based tool. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bleeding edge in elpa
Nikolai Weibull n...@disu.se writes: Having both a stable and an unstable version of Org avilable via ELPA is a non-starter for the simple reason that the package manager can't deal with the versioning problems this would introduce. This could, I assume, and was sort of implied in my original e-mail, be solved by providing an “org” package as it is today (based off of maint) and an “org-edge” package that’d be based off of master. As I think somebody said, the correct fix to this problem is more frequent released. I'm sure Bastien would appreciate help with this. Do you want to volunteer? —Rasmus -- One thing that is clear: it's all down hill from here
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Hi Nicolas, * Nicolas Goaziou m...@nicolasgoaziou.fr [08. Mar. 2015]: Unfortunately it doesn't ring a bell. Running `org-repair-property-drawers' on your file repairs it. Would it be related to `org-inlinetask' (i.e., different behaviour if the library is loaded or not)? Sadly no: I reapplied `org-repair-property-drawers' on my org file with no customisation at all: emacs-snapshot -Q -nw -L /home/grfz/src/org-mode/lisp/ file.org ~/src/org-mode/etc/ORG-NEWS I loaded `org-repair-property-drawers' from ~/src/org-mode/etc/ORG-NEWS and executed it in file.org. Result is ’(nil nil nil nil nil nil nil nil nil nil nil nil ... )’ and the buffer file.org remains unmodified. This is with: GNU Emacs 25.0.50.2 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-08 on boo Org-mode version 8.3beta (release_8.3beta-893-g1219b0 @/home/grfz/src/org-mode/lisp/) I rechecked with emacs24: GNU Emacs 24.4.91.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-08 on boo and same org-mode: same result. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [O] Bleeding edge in elpa
Hi, tftor...@tftorrey.com (T.F. Torrey) writes: I want to collaborate on Org files with my wife and parents, ^^^ Do you? It sounds cool! In a real-world situation, I want to collaborate on Org files with my wife and parents, and I want to use the current best version of Org (which has significant improvements to #+INCLUDE that I use), but I do not want to try to install git on their Windows machines, I agree. I have the same problem when I build documents (via CI) on a remote Debian server where I don't want to mess around with anything more than what comes with Emacs by default. Serious Org users are already forced to install and run git to use the master version, and whatever the dangers, the practice is almost completely without problems. A bleeding edge ELPA would merely make that simpler. I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple of other packages will move to GNU ELPA and thus separate release channels (these packages will still be bundled with Emacs). This means we can push out new versions easily, making more frequent releases more attractive. Again, if you want to help out with preparing releases just let the list and Bastien now. —Rasmus -- I feel emotional landscapes they puzzle me
Re: [O] Bleeding edge in elpa
Rasmus writes: I agree. I have the same problem when I build documents (via CI) on a remote Debian server where I don't want to mess around with anything more than what comes with Emacs by default. You can use a tarball and the support for manual builds, described in: http://orgmode.org/worg/dev/org-build-system.html#sec-7 I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple of other packages will move to GNU ELPA and thus separate release channels (these packages will still be bundled with Emacs). This means we can push out new versions easily, making more frequent releases more attractive. None of this is going to lift one core limitation of package manager: there can be only one. It doesn't support packages that subsume other packages, so org-whatever is totally different from org and would be installed together when referenced by dependencies even though it makes no sense. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] Bleeding edge in elpa
Rasmus writes: You can use a tarball and the support for manual builds, described in: http://orgmode.org/worg/dev/org-build-system.html#sec-7 I have no desire to use anything more than what comes with emacs-24-nox on this system. You can download any git commit directly from orgmode.org as a tarball (or use the daily snapshot), via Emacs. The rest of the installation doesn't need any outside tools either. To get the tip of master, try for instance: http://orgmode.org/cgit.cgi/org-mode.git/snapshot/org-mode-master.tar.gz Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Richard Lawrence richard.lawre...@berkeley.edu writes: Like I said, this seems like an edge case, and I don't see that it is necessarily Org's responsibility to accommodate the keys produced by Zotero in such edge cases. And there is a significant benefit to *not* accommodating such keys: namely, you can use in-text citations at the end of a sentence. +1 -- Until the next mail..., Stefan.
Re: [O] Small bug? org-narrow-to-subtree and open file link
James K. Lin james2k2...@yahoo.com writes: By default, Org mode does not work well with indirect buffers. You could get around this by rolling your own version of functions on your own to ignore the base buffer. This is no small feat because the link navigation commands are nested. I understand... thanks for your answer.
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Aloha Richard, Richard Lawrence richard.lawre...@berkeley.edu writes: Hi Tom and all, t...@tsdye.com (Thomas S. Dye) writes: As I see it, the choice boils down to the relative benefit of citation shortcuts vs. the limitation of requiring authors to configure the citation manager so it doesn't produce a key ending in punctuation (or your solution that uses different regexps for full citations and shortcuts). Yes, that's my understanding of the situation. I would just add that it may not even be *possible* to configure how some citation managers generate keys. So if there are citation managers that put punctuation at the end of keys in `normal' cases, that's something serious to consider. Another variable to keep in mind here is that we don't have to `bless'/support every citation manager. If a citation manager puts punctuation at the end of keys, and doesn't allow configuring that behavior or makes it difficult, that's a reason not to bless it, in my opinion. But my opinion probably shouldn't count for much on this point, because I don't use a citation manager myself (I use org-bibtex), and I write my own keys. Oh my. This is a lot to keep in your head as a bibliographic database grows. The one I've created with my colleagues over the last two decades has more than 5,000 entries. What citation managers are people on this list actually using? It would be very helpful to get an idea of what is actually needed before we make any changes to the syntax of keys. Richard and Stefan both see keys ending in punctuation marks as corner cases, so the burden imposed on the author to configure the citation manager is relatively infrequent. Yes, that is my sense. At any rate, I would like to see clear examples that are not corner cases before we throw out the shortcut syntax, because I personally think it is useful and readable. A large number of my own citations could be handled by just the shortcut syntax, I think, so I'd be sad to see it go away without good reason. At this point I think the benefit of citation shortcuts is relatively modest and the limitation of requiring authors to ensure keys don't end in punctuation potentially onerous. On balance, I think strong consideration should be given to the option of not using shortcuts. I don't disagree, but I think there is an empirical question that needs to be answered here: within the keys people actually use, how many do not conform to the syntax? Of those that don't, do they represent `normal' cases or not? A good friend of mine is a military historian who writes books describing how the Army habitually plans to fight the last war over again, then has to adapt hurriedly when the next war turns out to be different. It strikes me that basing core features of the citation syntax on the software users happen to be using today is a bit like this--at some point the design of the system will prove unprepared for new developments. I think Vaidheeswaran C's example of a citation scraped off the internet with Zotero should carry a lot of weight. This kind of thing is bound to happen more and more as authors increasingly harvest citation information on-line (my generation typically looks on this with horror, but we'll be swept aside). I kind of like Rasmus' idea to make the citation insertion routines aware of punctuation and use a full citation where a shortcut would introduce ambiguities. Of course, an old-schooler like me will eventually complain about wanting a variable =org-citation-always-full= that I can set non-nil. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Plotting in Python block won't over-write existing file
Date: Fri, 06 Mar 2015 14:21:54 -0500
From: Nick Dokos ndo...@gmail.com
To: emacs-orgmode@gnu.org
Subject: Re: [O] Plotting in Python block won't over-write existing
file
Message-ID: 87sidi9bjh@alphaville.usersys.redhat.com
Content-Type: text/plain; charset=utf-8
Richard Stanton stan...@haas.berkeley.edu writes:
Here?s a sample Python code block:
#+begin_src python :results file :exports both
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import pandas as pd
df = pd.DataFrame({'date': [1900, 1901, 1902], 'x1' : [3, 4, 5], 'x2' : [6,
7, 9]})
df.set_index('date', inplace=True, drop=True)
df.plot()
plt.savefig('x4.png')
return 'x4.png' # return filename to org-mode
#+End_src
When I run it, the graph appears on the screen and in the named file, as
desired.
However, if I go back, change one of the numbers, and rerun the block,
while it claims to have run OK, the graph is not updated. I only get a
new plot if I also change the file name (e.g., to x5.png). It looks
like it?s refusing to over-write an existing file. Is there a reason
for this, and is there a way to change this behavior?
By the way, this is with org-mode 8.3beta-884-g9ed426
IIUC, you eval the code, hit the resulting link (which opens a buffer with the
graph), change a number and reeval the code - do you hit the link again?
That should ask you whether you want to read the changed file again and
show the updated graph.
Thanks, Nick. After MUCH investigation, and a lot of help from John Kitchen, I
worked out that
a. The file was changing fine on disk, just not redisplaying in Emacs.
b. The problem seems to be related to the version of Emacs I'm using (24.4 for
OS X), downloaded from http://emacsformacosx.com/builds. After going back there
and downloading and installing Emacs 24.4.90 pretest, org-mode now updates
graphs just fine.
I don't know what the problem was, or why changing the Emacs version solved it
(with no other changes), but maybe this will be helpful to someone else.
Best,
RIchard Stanton
Re: [O] Zotero csl file that uses parenthetical style for citations
On Sunday 08 March 2015 11:04 PM, Thomas S. Dye wrote: Thankfully, Richard demonstrated to his satisfaction that an off-the-shelf CSL style could be made to handle this situation. If this is the only potential problem you see, then this gives me hope that Richard will succeed in implementing an Org mode interface for an appropriate csl-based tool. Do you share your good-will and words of encouragement equally to all participants? Say something cheerful to me (about me).
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
t...@tsdye.com (Thomas S. Dye) writes: Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: I'm asking because I haven't fully grasped uses for the shorthand. What is the use case? More readable, I guess. I agree. In time, org-reftex would insert @key if no notes are requested at the time of insertion. I think the OP has a valid point. After we teach org-reftex to insert @key if no notes are requested, are we going to convince all key generating software to prohibit keys that end in punctuation? So just to get it straight: are you advocating for only allowing [cite:@key]-like constructs to allow punctuation at the end of words? Perhaps it's a can of worms, but you can also match keys against a punctuation at end of word-regexp and use the fuller cite command then. I'm not too happy with having the regexps used in [cite:@·] and @· diverge too much, though... So /given support for end-of-word punctuation/, we'd either have two abandon a single org-element--citation-key-re (yes that's not entirely correct) or give up short citations. As I currently understand the problem, that seems like a tall order to me. It's also a tall order to support end of word punctuation cf. above. I think another important question is how easy is it to configure the citation manager in question not to insert punctuation marks at the end? —Rasmus -- This message is brought to you by the department of redundant departments
Re: [O] Multicite syntax
I have fixed up ox-jabref.el to support multicites. Only common prefixes and suffixes are handled. I don't know how to handle per-key prefix/suffix-es. If someone has any complaints about the output, please write to me. Attaching files that I have used for testing. (Author-Date file lacks year because of a bug in Chicago filters bundled with JabRef. JabRef style file uses 'year' field but biblatex-examples.bib provides only a 'date' field.) On Sunday 08 March 2015 11:59 AM, Vaidheeswaran C wrote: Note that, as a consequence, the new object is incompatible with the previous one, since every citation is a multi-cite citation. See commit message for details. Just a quick feedback. (:parenthetical nil :begin 807 :post-blank 0 :end 843 :references ((:key wilde :prefix nil :suffix nil) (:key moore :prefix nil :suffix nil) (:key westfahl:space :prefix nil :suffix nil)) :parent #3#) Having a plist for `reference' as opposed to a an Element proper gives me cognitive dissonance. How about replacing this (:key wilde :prefix nil :suffix nil) with this instead (reference :key wilde :prefix nil :suffix nil :parent ) ^^ Each `reference' is transcoded to it's contents in it's own right in ox-jabref. (a) Batch export all cites. In case of citeproc-java it would be batch export each multicite. http://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00262.html) (b) Map `reference' to `contents' with transcoding being done by the citation command line. Please confirm whether this change request is possible or not. You may also want to replace `citaiton' with a `citation-cluster'(or a multicite) and replace `reference' with a `citation'. In effect, a citation-cluster (or a multicite) is one or more citaitons. cite-chicago-fullnote.odt Description: application/vnd.oasis.opendocument.text cite-numeric.odt Description: application/vnd.oasis.opendocument.text cite.org Description: Lotus Organizer cite-chicago-author-date.odt Description: application/vnd.oasis.opendocument.text
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Hi Tom and all, t...@tsdye.com (Thomas S. Dye) writes: As I see it, the choice boils down to the relative benefit of citation shortcuts vs. the limitation of requiring authors to configure the citation manager so it doesn't produce a key ending in punctuation (or your solution that uses different regexps for full citations and shortcuts). Yes, that's my understanding of the situation. I would just add that it may not even be *possible* to configure how some citation managers generate keys. So if there are citation managers that put punctuation at the end of keys in `normal' cases, that's something serious to consider. Another variable to keep in mind here is that we don't have to `bless'/support every citation manager. If a citation manager puts punctuation at the end of keys, and doesn't allow configuring that behavior or makes it difficult, that's a reason not to bless it, in my opinion. But my opinion probably shouldn't count for much on this point, because I don't use a citation manager myself (I use org-bibtex), and I write my own keys. What citation managers are people on this list actually using? It would be very helpful to get an idea of what is actually needed before we make any changes to the syntax of keys. Richard and Stefan both see keys ending in punctuation marks as corner cases, so the burden imposed on the author to configure the citation manager is relatively infrequent. Yes, that is my sense. At any rate, I would like to see clear examples that are not corner cases before we throw out the shortcut syntax, because I personally think it is useful and readable. A large number of my own citations could be handled by just the shortcut syntax, I think, so I'd be sad to see it go away without good reason. At this point I think the benefit of citation shortcuts is relatively modest and the limitation of requiring authors to ensure keys don't end in punctuation potentially onerous. On balance, I think strong consideration should be given to the option of not using shortcuts. I don't disagree, but I think there is an empirical question that needs to be answered here: within the keys people actually use, how many do not conform to the syntax? Of those that don't, do they represent `normal' cases or not? Best, Richard
Re: [O] [ox-ascii, bug?] aligning text withing footnotes
Rasmus ras...@gmx.us writes: What I want to do is simpler. I want to subtract the length between [1] and [fn:1] from every line between :begin and :end of the footnote-definition. Differences other than the three character difference between [fn:1] and [1] I don't care about. This is not simpler. Exporting works on top of a parse tree, not the current buffer. Global indentation is removed before ox-ascii even sees it. Regards,
Re: [O] Bleeding edge in elpa
Hi Nikolai, IMO this is a bad idea. The bleeding edge version is expected to be somewhat unstable, and exposing it via ELPA will lead to foot-shooting incidents. On the other hand, it would be nice to have more regular releases from master to maint. AFAIK the last one was a year and a half ago (Org 8.2). However, this has traditionally required a lot of effort from Bastien and others, so it’s not a simple case of “wishing will make it so”. -- Aaron Ecay
Re: [O] Beamer Hello World Help Request
FWIW, I was a complete noob and was exporting to a Latex PDF (C-c C-e l p)
instead of a Beamer PDF (C-c C-e l P). Sorry for spamming the list!
On Sat, Mar 7, 2015 at 7:50 PM, Matthew Gidden gid...@wisc.edu wrote:
Hi folks,
I've been trying to follow the getting started tutorials
http://orgmode.org/worg/exporters/beamer/tutorial.html for making
beamer presentations and have hit a snag. Following the tutorial, I have a
minimum example of a pres.org file and the resulting pres.tex file as a
gist https://gist.github.com/gidden/46651818155f4267a016. The resulting
pdf is attached. The resulting tex file was generated from the C-c C-e l p
command after having added the following to my .emacs file:
(setq org-latex-to-pdf-process (list latexmk -pdf %f))
(require 'ox-latex)
(add-to-list 'org-latex-classes
'(beamer
\\documentclass\[presentation\]\{beamer\}
(\\section\{%s\} . \\section*\{%s\})
(\\subsection\{%s\} . \\subsection*\{%s\})
(\\subsubsection\{%s\} . \\subsubsection*\{%s\})))
I believe I should be getting a presentation with two frames; however, the
generated latex does not wrap subsections in frame tags, and I'm not sure
how to proceed from here based on the available tutorial material.
Some specs:
org-8.2.10
emacs-23.4.1
Any suggestions would be greatly appreciated! Please let me know if I can
provide additional information.
Cheers,
Matt
--
Matthew Gidden
Ph.D. Candidate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192
--
Matthew Gidden
Ph.D. Candidate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192
Re: [O] Multicite syntax
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: Note that, as a consequence, the new object is incompatible with the previous one, since every citation is a multi-cite citation. See commit message for details. Just a quick feedback. (:parenthetical nil :begin 807 :post-blank 0 :end 843 :references ((:key wilde :prefix nil :suffix nil) (:key moore :prefix nil :suffix nil) (:key westfahl:space :prefix nil :suffix nil)) :parent #3#) Having a plist for `reference' as opposed to a an Element proper gives me cognitive dissonance. How about replacing this (:key wilde :prefix nil :suffix nil) with this instead (reference :key wilde :prefix nil :suffix nil :parent ) ^^ Agreed. I introduced yet another syntax change in wip-cite branch. Now there are two separate objects citation and citation-reference. So the following multicite [cite:prefix; pre @a post; @b] is parsed like (citation (:prefix prefix :parenthetical nil) (citation-reference (:key a :prefix pre :suffix post)) (citation-reference (:key b))) The annoying thing is about bare-keys. When on a bare @key, `org-element-context' cannot grap the citation, only the reference. I don't think it is an issue for now. Regards, -- Nicolas Goaziou
[O] [ox-ascii, bug] TOC-keyword doesn't work
Hi, Consider the following file: #+OPTIONS: toc:nil author:nil * h1 #+TOC: headlines 2 * h2 ** h3 Expected output includes the TOC. Actual output is 1 h1 Table of Contents ─ 2 h2 2.1 h3 ── The TOC is there when #+OPTIONS: toc:t, but then you can't decide where it's printed. Thanks, Rasmus -- I feel emotional landscapes they puzzle me
Re: [O] [ox-ascii, bug] TOC-keyword doesn't work
Hello, Rasmus ras...@gmx.us writes: Consider the following file: #+OPTIONS: toc:nil author:nil * h1 #+TOC: headlines 2 * h2 ** h3 Expected output includes the TOC. Actual output is 1 h1 Table of Contents ─ 2 h2 2.1 h3 ── The TOC is there when #+OPTIONS: toc:t, but then you can't decide where it's printed. Fixed in fab7de578772e9ae88676f42ecb57794d99c40b7. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-habit treats all repeat tasks as .+ type [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
Leo He leodream2...@gmail.com writes: On the other hand, I am writing a shell script to move each entry's PROPERTIES drawer to its beginning. Though I think elisp can handle this more easily, I am not familiar with it (still learning :-) ). I wonder if there is an existing function or script to do this. See ORG-NEWS document in the development version. There's a function called `org-repair-property-drawers'. Regards,
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Hello, Gregor Zattler telegr...@gmx.net writes: I invoked org-repair-property-drawers on a fairly large org-mode file. It did sort some PROPERTIES drawers in front of LOGBOOK ones but not all. Since I do not understand the logic of org-repair-property-drawers I prepared a file with the structure of the org-mode file after running org-repair-property-drawers on it: egrep ^\*+|^ *:PROPERTIES:|^ *:LOGBOOK:|^ *:END: file.org |nl headings-properties-logbook-numbered sed -e s/\(^ \+[0-9]\+[[:space:]]*\*\+[[:space:]]*\)\(TODO\|INPROGRESS\|WAITING\|VERIFY\|DONE\|DELEGATED\|CANCELLED\|PUTOFF\|IDEA\)*\(.*$\)/\1\2/ headings-properties-logbook-numbered headings-properties-logbook-numbered.anon I don’t how to isolate the bug or the circumstances which trigger it. The file headings-properties-logbook-numbered.anon is attached to this email. I hope it might be useful to you to find the bug. Unfortunately it doesn't ring a bell. Running `org-repair-property-drawers' on your file repairs it. Would it be related to `org-inlinetask' (i.e., different behaviour if the library is loaded or not)? Regards, -- Nicolas Goaziou
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Aloha Rasmus, Rasmus ras...@gmx.us writes: t...@tsdye.com (Thomas S. Dye) writes: Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: I'm asking because I haven't fully grasped uses for the shorthand. What is the use case? More readable, I guess. I agree. In time, org-reftex would insert @key if no notes are requested at the time of insertion. I think the OP has a valid point. After we teach org-reftex to insert @key if no notes are requested, are we going to convince all key generating software to prohibit keys that end in punctuation? So just to get it straight: are you advocating for only allowing [cite:@key]-like constructs to allow punctuation at the end of words? Perhaps it's a can of worms, but you can also match keys against a punctuation at end of word-regexp and use the fuller cite command then. I'm not too happy with having the regexps used in [cite:@·] and @· diverge too much, though... So /given support for end-of-word punctuation/, we'd either have two abandon a single org-element--citation-key-re (yes that's not entirely correct) or give up short citations. As I currently understand the problem, that seems like a tall order to me. It's also a tall order to support end of word punctuation cf. above. I think another important question is how easy is it to configure the citation manager in question not to insert punctuation marks at the end? I'm not an advocate at this point. I'm just trying to be clear about a choice that apparently needs to be made. As I see it, the choice boils down to the relative benefit of citation shortcuts vs. the limitation of requiring authors to configure the citation manager so it doesn't produce a key ending in punctuation (or your solution that uses different regexps for full citations and shortcuts). Nicolas guessed that the benefit of citation shortcuts is that they are more readable than a full citation, and you agree with his guess. The shortcuts are certainly shorter, so in this sense are more readable. However, having two different representations of the same thing, a shortcut and a full citation, means that, for the author (and the software) recognition is more complex and thus, less readable. For this reason, IMHO the readability benefit is not particularly strong. Richard and Stefan both see keys ending in punctuation marks as corner cases, so the burden imposed on the author to configure the citation manager is relatively infrequent. They know more about this than I do, so I'm heartened by this information. However, in the event the citation manager has to be configured, the author faces a potentially daunting task. The algorithm for automatic key generation in bibtex-mode is summarized in 18 steps, including two near the end that allow arbitrary input! I strongly believe Org mode shouldn't send an author here, unless the corresponding benefits are great. I'm not capable of forming an opinion about your solution that uses different regexps. At this point I think the benefit of citation shortcuts is relatively modest and the limitation of requiring authors to ensure keys don't end in punctuation potentially onerous. On balance, I think strong consideration should be given to the option of not using shortcuts. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bleeding edge in elpa
On Sun, Mar 8, 2015 at 3:17 PM, Aaron Ecay aarone...@gmail.com wrote: IMO this is a bad idea. The bleeding edge version is expected to be somewhat unstable, and exposing it via ELPA will lead to foot-shooting incidents. Is trying to manage it via git+make oneself less likely to cause incidents? From the FAQ: The master branch of the git repository always contains the bleeding edge development code. This is important for Org's fast development, because code on master gets checked out by many people daily and we quickly receive bug reports if something is wrong. On rare occasions, this code may not function perfectly for a limited time while we are trying to fix things. It is therefore recommended to keep a known-good version of org-mode installed outside the source tree and always run the full test suite before using a new version from master. On the other hand, it would be nice to have more regular releases from master to maint. AFAIK the last one was a year and a half ago (Org 8.2). However, this has traditionally required a lot of effort from Bastien and others, so it’s not a simple case of “wishing will make it so”. The more time that passes between releases, the harder it is to release a new version. And as this is the case here, having easy access to the latest “version” would lessen the effect of this. It would also allow more people to find bugs.
