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
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
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
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
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
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
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
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
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
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
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:
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
30 matches
Mail list logo
