D M German uvic.ca> writes:
> I think the issue is that, at least in my computer the variable $\
> returns empty (the record separator).
Thinko on my side, what I wanted was the input record separator "$/" (to avoid
specifying a literal newline for those systems where this is actually
multi-char
Stephen Eglen writes:
> Thanks Achim; if its just my installation, and not others, I'll try and
> debug this end. But just for the record, here's the output you asked
> for. I get the byte-compile error when doing "make" in the top-level.
This is puzzling, everything appears to be correct. Do
sj...@damtp.cam.ac.uk writes:
> With today's git I'm getting the following errors when compiling orgmode
>
> $ make
>
> ... org-w3m.el:44:1:Error: Symbol's value as variable is void:
> org-babel-temp-file
>
> Its stopping orgmode from working for me -- any clues?
Well, that doesn't make any sense:
D M German writes:
> There are some bugs. For example, the interpretation of :results table,
> vector and list.
You may misunderstand some things, or I don't understand what you are
asking. It is (at least currently) the responsibility of the Perl
program (or any other Babel language) to deliver
Eric Schulte writes:
> Are you familiar with `org-babel-expand-src-block' bound to C-c C-v v?
I wasn't, obviously, and neither was the OP.
> If I understand the desire correctly, it should be what you're after.
> Perhaps an option to raise the expanded source code buffer along with
> the error bu
Eric Schulte writes:
> I just added the variable `org-babel-perl-var-wrap', into ob-perl.el
>
> ;; emacs-lisp
> (defvar org-babel-perl-var-wrap "q(%s)"
> "Wrapper for variables inserted into Perl code.")
>
> This way we will get what sounds like improved wrapping by default, but
> use
r the code has run.
>From 7a668942b58dc94994b11e6ec0751ec36b07b196 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Sun, 24 Feb 2013 13:28:50 +0100
Subject: [PATCH 1/2] ob-perl: modify variable definition to be compatible with
strict and use non-interpolating quotes
* lisp/ob-perl.el (org-babel-variable-assignments:perl): Add &
Arun Persaud writes:
> Steps to reproduce:
>
> emacs -Q tmp.org
> move point to a lower heading, e.g. the "a" in "3a30" (5th line from the
> bottom)
> cycle with -TAB (I need to hit shift-tab 4 times to see the "..."
> at the top)
Yes, that is reproducible.
Regards,
Achim.
--
+<[Q+ Matrix-12 WA
D M German writes:
[…]
Please leave the formats alone, if you change the number of parameters
there folks that use their own definitions won't know what hit them.
What you want is to prepend something to the body that Babel gives you,
so let-bind that result and use it. You could even advise the
D M German writes:
> I see two ways to solve this. The first is simply to replace the output
> format of the variable from "%S" to "'%s'" (use quotes ').
I think that's the right thing to do. There shouldn't be anything in
the table that needs to be interpolated by Perl while the variable is
defi
Nicolas Goaziou writes:
> Note that filling/auto-filling will never put you in this situation,
> since Org has a protection mechanism. IOW, if you end up with a list
> marker at the beginning of a line, it's your fault.
I don't use auto-fill in formulas. And yes, I take responsibility for
my faul
t with-silent-modifications
does on top of what org-unmodified did. We might even copy the whole
macro definition from subr.el, but I think we're close enough with this.
>From 249b18ee13f2fbf041c081fa63b1ccd40d67dc27 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Sun, 24 Feb 2013 10:5
Bastien writes:
> I hereby declare that I want Org to be fully functional for Emacs 23
> and older, and I wish Org can be reasonably functional for Emacs <23
> and XEmacs.
If I may say so, XEmacs and Emacs up to 23.2 are missing
with-silent-modifications, preferring to make them loudly.
Compatibi
Nicolas Goaziou writes:
> True, that's why there's also inline \[...\]. But you have to accept
> paragraph limitations (no empty line, do not start a line with list
> markers...).
Now, given that difference and the fact that these things can span over
multiple lines and thus include the beginning
Nicolas Goaziou writes:
> I gave you a solution since the beginning of this thread: use a latex
> environment.
After a bit of searching: the answer was in another thread, not in
answer to my original question and I read that answer as "LaTeX blocks
are equivalent to LaTeX environments". I see now
Nicolas Goaziou writes:
>> Now I'll have to go and see what twisted ways it takes for the old
>> exporter defcustoms to show up in customize, they shouldn't have been
>> there at all.
>
> As I explained in my announcement for new export framework, this is due
> to customize autoloads from bundled O
Nicolas Goaziou writes:
> I gave you a solution since the beginning of this thread: use a latex
> environment.
It is not a solution because it does not export to HTML. If I need to
write the document mostly in LaTeX I can start with LaTeX and and then
use some LaTeX to HTML translation.
Regards
Nicolas Goaziou writes:
>> Not for LaTeX export AFAICS, ox-latex doesn't seem to use
>> org-export-coding-system. But that'd arguably be a bug in ox-latex,
>> then (more specifically org-latex-guess-inputenc),
>
> I don't understand your answer.
>
> My default coding system is utf-8 and inputenc o
Bastien writes:
>> No it's there, in gnus/time-date.elc ― maybe your versions are all
>> without Gnus?
>
> Yes, my versions come without Gnus. I directly downloaded them
> from xemacs.org (which is completely outdated by the way.)
Which means that our compatibility function doesn't provide
compa
Nicolas Goaziou writes:
> The parser parses Org syntax. If you see something else, unless there is
> an obvious bug, then you are expecting the Org syntax to be different
> from what it is. It's even the goal of the parser: to define the way to
> read Org syntax.
That's what I said. You also defi
Nicolas Goaziou writes:
> I think the cleanest way to implement this would be to _not_ modify Org
> syntax, because it is export back-end very specific. Something like:
>
> #+attr_html: :header-groups (1 3)
> | This | will |
> | be| a header |
> |---+---|
Nicolas Goaziou writes:
> IMO the parser already DTRT. In which case do you think it doesn't?
DTRT is what you define as DTRT, so yes it does that already. At the
very least it would be nice if the parser warned when it finds stray
syntax pieces that are missing their match (it took me quite a wh
Bastien writes:
> And time-to-seconds seems absent -- but it seems absent from
> *any* version of XEmacs I could check (21.4.1, 21.4.9, 21.5.9).
No it's there, in gnus/time-date.elc — maybe your versions are all
without Gnus?
> So yes, I think it's safe to remove this compat function. Let me kno
Nicolas Goaziou writes:
> Would the following patch work?
Not for LaTeX export AFAICS, ox-latex doesn't seem to use
org-export-coding-system. But that'd arguably be a bug in ox-latex,
then (more specifically org-latex-guess-inputenc), which is easily fixed
after that patch has been applied.
Reg
Nicolas Goaziou writes:
>> No it is not irrelevant, it simply gets set too late in the game: it
>> asks for the new coding system when it is time to save the buffer, while
>> the content of the buffer has been cobbled together while assuming a
>> different coding system. The only way I know (from
Bastien writes:
> Fixed, thanks!
Uh… no, you switched the wrong function in the second line (which
incidentally indicates that this branch of the conditional never sees
any testing). Fixed in master by using org-float-time. I checked in
XEmacs 21.5 and it has float-time, so maybe we wouldn't nee
Nicolas Goaziou writes:
>> The bug was that Babel blocks were evaluated during export when
>> org-export-babel-evaluate was explicitly set to nil (the default value
>> is t).
>
> AFAICT, they aren't.
So let's go back to the OP (Gregor Kappler, IIRC) and ask for a
reproducible recipe.
Regards,
Ac
Andreas Röhler writes:
> IMHO it would be great if Jay moves it already at place. As it's a
> doku basically, giving a nice entry into a lot of things. If exporting
> is not perfect yet, it's not at the core here, we may fix it step by
> step. Also we might gather bug-reports that way.
The thing
Nicolas Goaziou writes:
>> It creates this command in the .tex file:
>>
>> \#+begin$_\mathrm{multicols}$
>
> It works here. Difficult to say what is wrong in your buffer without
> more context.
That result looks exactly like my problem with multiline \[...\],
i.e. the parser found something it con
Nicolas Goaziou writes:
>> Depends on what language environment is set to, but with the default setting
>> of
>> my Emacs (German) it becomes iso-latin-1, independently of what the coding
>> system in the original Org buffer was.
>
> In this case, it should be `utf-8', shouldn't it?
I want it to
Rainer M Krug writes:
> Ok - that makes sense. I just checked in my contrib/lisp and I only have .el
> there, so none are
> compiled.
Look in lisp, not contrib/lisp.
>> If you set the load-path to include the "contrib/lisp/" directory, then you
>> don't need to
>> install org-notmuch, and (requ
Nicolas Goaziou writes:
> I'm just starting over because that wasn't a correct solution. I'm not
> even sure about what bug this patch fixed.
The bug was that Babel blocks were evaluated during export when
org-export-babel-evaluate was explicitly set to nil (the default value
is t).
> Anyway, it
Carsten Dominik writes:
>> I think the cleanest way to implement this would be to _not_ modify Org
>> syntax, because it is export back-end very specific. Something like:
>>
>> #+attr_html: :header-groups (1 3)
>> | This | will |
>> | be| a header |
>> |---+-
Bastien altern.org> writes:
> > Just for clarifications: is there any problem with adding
> >
> > ORG_ADD_CONTRIB = *
> >
> > to the local.mk file, apart from slightly longer compilation times?
>
> This should be okay, but it's not safe. If any non-emacs-lisp
> file gets added to contrib/lisp/ (
Bastien altern.org> writes:
> Thanks for reporting this. I removed *-source.\(orgx?|html\) files
> from ~/git/org-mode/ and orgmode.org/worg/.
It seems that only the subdirectories of worg/ were cleaned, but not files in
worg/ itself. Or maybe I need to wait longer for the sitemap to propagate
Suvayu Ali gmail.com> writes:
> I use LaTeX blocks. So your example would translate to:
Sure, but then the equation would only be exported for LaTeX
and I would need to copy the same thing just again for
HTML export.
I didn't put a [Bug] tag on the OP on purpose, since I don't
really know what'
Nicolas Goaziou gmail.com> writes:
> IIUC, there is no such thing as a coding system associated to a buffer.
> A coding system only kicks in when doing some I/O operation.
The coding system should be associated with the file the buffer is visiting, but
a fresh buffer still shows a coding system i
The Org fragment
\[
r = a
+ b
- c
\]
gets interpreted as something strange with a list inbetween. Thus it gets
exported as:
$\backslash$[
r = a
\begin{itemize}
\item b
\item c
\end{itemize}
$\backslash$]
How is one supposed to write (longer) equations out on multiple lines (leaving
the operato
Something seems to run amok when Worg gets published, if you look in the sitemap
under org-tools you'll find entries for index.html, index-source.html,
index-source-source.html and so on. The documents actually exist (not showing
the source of course). This seems to happen in a few other places a
I've ran into this before, but I guess I wasn't able to clearly explain what the
issue was at the time... so let's try again.
I'm exporting an Org file in UTF-8 to LaTeX. Unless I switch the coding system
in Emacs from "default" to "UTF-8" (which has the side effect that any new
buffer will have
23057a57b4 introduces a shadowed defvar org-clock-effort by copying the
definition from org-clock.el to org.el without deleting it in
org-clock.el. If a forward declaration was intended, then the defvar in
org.el should provide no initial value, otherwise (since org-clock.el
requires org.el anywa
Nicolas Goaziou writes:
> I confirm the problem. It is coming from
> 12d592b73223f3b0628e10f0f627447b1a312203. I reverted it.
Doesn't this throw the baby out with the bathtub? If anything that's an
indication that the evaluation and the exporting of a block should be
independently controllable.
Nicolas Goaziou writes:
> I confirm the problem. It is coming from
> 12d592b73223f3b0628e10f0f627447b1a312203. I reverted it.
Doesn't this throw the baby out with the bathtub? If anything that's an
indication that the evaluation and the exporting of a block should be
independently controllable.
Bastien writes:
> Fixed, thanks!
Confirmed, thanks!
:-)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
François Pinard writes:
> Any Makefile which lists dependencies while expecting them to be
> satisfied sequentially, one after another, is broken. Make does not
> (theoretically) guarantee the order, while in practice, all "make"
> programs I know satisfy dependencies from left to right.
Well, if
Achim Gratz writes:
> Nicolas Goaziou writes:
>> You only need to modify org-element if Org syntax has been changed.
>
> Yes, thats exactly what I want.
A new rule type was easy enough to implement:
http://repo.or.cz/w/org-mode/org-tablehead
The commit 5cdf84ea68 creates the following test failures:
[…]
Test test-org-babel/inline-src_blk-results-file condition:
(error "C-c C-c can do nothing useful at this location")
FAILED 152/363 test-org-babel/inline-src_blk-results-file
[…]
6 unexpected results:
FAILED test-org-babel
Nicolas Goaziou writes:
> You only need to modify org-element if Org syntax has been changed.
Yes, thats exactly what I want.
>> Also, it appears that each element can have only one property or did
>> I miss something? It seems that having a way to get the (main)
>> property and then asking if t
I've just looked at how to implement this using org-element and the new
exporter. Much to my dismay I found that table headers are not a
separate row or row group type and the new exporter is still using this
"everything before the first separator is a heading" kludge. It's easy
enough to introd
Bastien writes:
> Yes, that's the mistake I often did. Especially because make test
> compiles the file and do not deleted the compiled files.
>
> Maybe we can have make testclean = make test && make clean
>
> Achim, would that be useful?
We already have "make test-dirty" for testing without doin
Bastien writes:
> PS: I wonder if *any* of the menu item is used... as I don't use the
> menu myself, it's hard to tell.
These days I only ever use it for "Show All" which does have a menu
entry, but no key binding. But before I got used to where the keys are
I often used the menu to do things in
Bastien writes:
>> Reloading uncompiled is only useful for when you want to
>> create backtraces.
>
> ... which is why I always want, but users don't, I agree.
We could provide org-reload-uncompiled that calls org-reload with a
prefix argument, which would allow anyone so inclined to map "C-c C-
Gregory Benjamin writes:
> I did a 'git pull' just now, followed by 'make test'
Nothing to do with your problem, but "ake up1" would do this with less
typing. :-)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-80
Christopher Schmidt writes:
> I did that now.
>
> d6f69f5 org.el: Use let instead of progv in org-run-like-in-org-mode
> ea2d107 org.el: Declare orgstruct-mode
Thanks for fixing this.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation
Christopher Schmidt writes:
> This is in master now. The commit is a3f6570.
This introduces the following failures in compilation with Emacs 24.2
and has a high chance of not working at all in some setups:
--8<---cut here---start->8---
Compiling /home/gratz/li
Eric Abrahamsen writes:
> Yes, org-string-width eventually calls string-width, so that behaves
> "correctly" as far as it goes, but unfortunately that's not where the
> value in the text properties comes from...
>
> 《蛙》
> 123456
>
> Doesn't that line up for you? Those bracket characters come with t
Carsten Dominik gmail.com> writes:
> #table-of-contents timestamp {
> display:none;
> }
You want a class selector (".") there, not an ID selector ("#"). Also you
should probably mark this "!important" so it doesn't get overriden later.
Regards,
Achim.
Nicolas Goaziou writes:
> I found that inlining it was an overkill. So the change is intentional.
Thanks for the confirmation.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net
Nicolas Goaziou gmail.com> writes:
> On the other hand, `org-element-type' and al. from org.el are called
> less often. So, it is not a problem if they are compiled as function
> calls.
They are normally not compiled as function calls, only in single mode.
Regarding commit 6b7101b91, did you int
Nicolas Goaziou writes:
> Yes, I noticed this one too, but I don't know yet from where it could
> come from.
It comes from the two autoloads, or probably only the second one as the
first is later declare-function'ed anyway. If you declare these, then
the defsubst get sometimes compiled as functio
Nicolas Goaziou writes:
> Yes, I noticed this one too, but I don't know yet from where it could
> come from.
Hmm. If you don't know, then this is even more worrysome. Can't spend
more time on this now, unfortunately.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk
Hi Nicolas,
an oddity occurs since the new exporter moved into core (I don't think I
had seen this before, so maybe you can relate to what is different now):
--8<---cut here---start->8---
Compiling /lisp/org-mode/lisp/org.el...
Loading org-element...
Loading or
Bastien writes:
>> Nicolas, moving the old exporter files to contrib/lisp/ will create
>> problems for the org-plus-contrib ELPA archive. Can I move them to
>> contrib/oldexp/ instead?
>
> Yes, please go ahead.
Done, please check that I didn't miss any file.
Regards,
Achim.
--
+<[Q+ Matrix-12
Nicolas Goaziou writes:
[…]
Nicolas, moving the old exporter files to contrib/lisp/ will create
problems for the org-plus-contrib ELPA archive. Can I move them to
contrib/oldexp/ instead?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations fo
Suvayu Ali writes:
> Despite that, all the org-e-* files under org-mode/lisp were not removed
> after I did `make cleanall'. I need to do a `git clean -f -x -e
> local.mk' to get rid of them.
The easier way of dealing with this would have been to either check out
maint and then do a "make clean"
Suvayu Ali writes:
> In my local.mk I had `ORG_ADD_CONTRIB = org-e-*' before, but after the
> switch I removed it (as you had pointed it out in another thread :)).
> Despite that, all the org-e-* files under org-mode/lisp were not removed
> after I did `make cleanall'.
You would have needed to do
Suvayu Ali gmail.com> writes:
> I am encountering the following build failure when I do `make compile':
>
> make[1]: Entering directory `/path/build/org-mode/lisp'
> rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
> org-install.elc
> install -m 644 -p .
> install: missing d
42 147 writes:
> As for the rest, I didn't see some of the other replies, because the
> org-mode mailing list moves a little two fast for my mailbox, and I
> prefer to read selectively from the gmane archive.
>
> That said, it is my responsibility to check that website before
> responding to (some)
Bastien writes:
> You need to reload uncompiled files with C-u M-x org-reload RET
I don't see the relation to the original problem, which is caused by a
switch from master to maint. This will not work without at least
unloading Org or better, restarting Emacs.
> BTW, I think it should be the def
Thomas S. Dye writes:
> Then, I checkout maint:
>
> git checkout maint
I'm not sure what your starting point is, but you'd almost certainly
will want to create the correct autoloads. In fact, you'd have a much
better chance of this working correctly if you took the time (just once)
to set up an i
Thomas S. Dye writes:
> This is the problem. When I use /usr/bin/info (ver. 4.8), which shipped
> with my Mac, all is well. When I use /opt/local/bin/info (ver. 4.13)
> from MacPorts, then the file is truncated.
Could you re-create the info file with makeinfo-4.13, then?
Regards,
Achim.
--
+<[
Achim Gratz writes:
> Sebastien Vauban writes:
>> Though, I'm not sure to understand why that solves the issue... except if the
>> emacs-el package gets updated more often that Emacs, then?
>
> The original implementation of find-func looked explicitly for org.el,
So
Sebastien Vauban writes:
> Though, I'm not sure to understand why that solves the issue... except if the
> emacs-el package gets updated more often that Emacs, then?
The original implementation of find-func looked explicitly for org.el,
which wasn't ever working with either compressed or not-insta
Florian Beck writes:
> I cannot reproduce this. The code works for me and byte compiling
> doesn't generate any warning.
>
> GNU Emacs 24.3.50.7 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of
> 2013-01-28 on flo-laptop
Fail: 24.2 (unknown upattern),
23.[34] (malformed function),
22
Achim Gratz writes:
> Florian Beck writes:
>> I don't think so. The string evaluates to itself or am I missing
>> something?
>
> If it would fall under "SELFQUOTING" then yes (but I really don't
> understand what the doc string is trying to tell me t
Sebastien Vauban writes:
> You may be right, but I guess that I'm not alone using Windows 8, so my
> performance observations must be shared by others as well. It may even be
> worse for some who have more Org files, and a less powerful computer.
Take Emacs and Org out of the picture and check how
Florian Beck writes:
> I don't think so. The string evaluates to itself or am I missing
> something?
If it would fall under "SELFQUOTING" then yes (but I really don't
understand what the doc string is trying to tell me there and what would
be used for comparison). It seems that a string constant
Eric Schulte writes:
> What's the "best practice" for how to use a defconst defined in an
> external file (when you can't require that file because that file
> requires you)?
Putting all definitions into a separate "leaf" file that can then be
required from everywhere with impunity. Bastien doesn
Bastien writes:
> Hi Florian,
>
> Florian Beck writes:
>
>> I can live with setting `ly-gen-pdf', but maybe something like
>>
>> (pcase (file-name-extension out-file)
>> ("pdf" "--pdf ")
>> ("ps" "--ps ")
>> ("png" "--png ")
>> (t "--png "))
>>
>> would be even bett
Nicolas Goaziou writes:
> Could you try this test instead? I don't trust `org-map-entries'.
This works. Is this an indication that org-map-entries is buggy?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http:/
Sebastien Vauban writes:
> These are the means over a couple of tests. But the maximum variance (over
> that small number of tests) is only about 0.04 s -- in powered mode.
File operations on Windows _are_ slow to start with and since a virus
scanner is more or less required these days, opening a
Bastien writes:
>> Testing current Org fails with this backtrace (the culprit seems to be
>> calling looking-at with an argument of nil):
>
> FWIW I cannot reproduce the problem. Can you?
Aside from the fact that Eric's last commit broke compilation of all of
Org and I had to back it out, yes I
Nick Dokos writes:
> (untested) I believe you can enter dates in "european dot" notation:
>
> 2013.2.3
I don't know any place in Europe using such a format, the one that is
used at least here is D[D].M[M].[YY[YY]] (but it also suffers from the
same sort of potential ambiguity and confusio
Thomas S. Dye writes:
> (/Users/dk/.emacs.d/src/org-mode/doc/./org.texi
> (/Users/dk/.emacs.d/src/org-mode/doc/texinfo.tex
> Loading texinfo [version 2012-01-03.18]: pdf, fonts, page headings, tables,
> conditionals, indexing, sectioning, toc, environments, defuns, macros,
> cross references, inser
Thomas S. Dye tsdye.com> writes:
> >> Section 12.8.11.4 of the info version of the Org mode manual is
> >> truncated in the middle of an emacs-lisp code block.
>
> I see the full file in pdf and html.
I get the complete section shown in Emacs and standalone info reader no problem.
What version o
Testing current Org fails with this backtrace (the culprit seems to be
calling looking-at with an argument of nil):
Test test-org-export/before-parsing-hook backtrace:
(cl-block-wrapper (catch (quote --cl-block-nil--) (let* ((i 6) (fram
(block nil (let* ((i 6) (frame nil) (--cl-var-- nil)) (w
Leo Liu writes:
> In an empty org buffer, type
>
> #+tit
>
> Then M-TAB to complete. You should observe:
>
> org-mode fontification error
>
> Org-mode version 7.9.3d (release_7.9.3d-892-gdfa07a)
Does not reproduce, this must be dependent on some customization of
yours (completion etc.) — c
Eric Schulte writes:
> If you still experience the problem you may want to ensure that you
> aren't using `org-babel-execute-src-block' from an old version of
> Org-mode by executing the following from your scratch buffer
>
> ;; emacs-lisp
> (when (require 'find-func)
> (find-function
Sebastien Vauban writes:
> Wait, wait, wait...
>
> When reading the backtrace even more carefully, this 3rd observation is not
> what's said by the error message: "../contrib" is not (I guess Achim is right)
> the problem here, but the fact that `find-library-name' fails to find "org".
>
> So, the
Bastien writes:
> I don't like it for at least these reasons:
>
> - it introduces an advice in the code -- we should work toward
> removing them, not adding them.
That's the mechanism Emacs provides for dealing with those situations.
I could do it without an advice, but it would still do the sa
J. David Boyd writes:
> Sorry, I meant 'git fetch' from inside the org-mode directory.
That doesn't even try to touch your work-tree. You want "git pull", but
using the appropriate target from the build system is even better since
it will ensure that everything else is up-to-date, too.
Regards,
Bastien writes:
> Achim Gratz writes:
>> I happen to think that this suggestion goes too far (if you think nobody
>> should use OIrg from ELPA, then you'd need to stop making it available
>> there and hopefully we already agreed that this isn't an option).
>
Bastien writes:
> I already suggested to *not* use ELPA at all for now.
I happen to think that this suggestion goes too far (if you think nobody
should use OIrg from ELPA, then you'd need to stop making it available
there and hopefully we already agreed that this isn't an option). There
is actual
Sebastien Vauban writes:
> - `org-ditaa' and `org-exp-blocks' both expect that directory along where
> org.el resides
No they don't, this is only used as a fallback if they can't find the
expected files elsewhere. You need to configure where they should find
the JAR files.
Regards,
Achim.
--
Moritz Ulrich writes:
> Any hints? Googling just pointed me to a mail thread where removing,
> restarting Emacs and re-installing the package fixed everything - that
> doesn't work for me.
You read that wrong. What should work is installing, re-starting Emacs,
removing and re-installing the packa
Thomas S. Dye writes:
> I think you and I have different definitions of "problem". From my
> user's perspective, something I "get away with," i.e., that doesn't have
> an effect on my work and productivity, isn't a problem.
That may well be true. I'm firmly in the "fail fast and crash loudly"
cam
Bastien writes:
> So I'm seriously questioning the value of having Org as an ELPA
> package and I'm thinking of removing this possibility until Emacs
> package install is fixed (Achim is working on this, but it looks
> like the change will not be in Emacs anytime soon.)
I've to admit that I've ha
Thomas S. Dye writes:
> Interesting, this Emacs distribution removed Org a few days ago. I'm not
> certain why the distributor refers to this as "a rather drastic
> measure." From my perspective as a user, whose interests required using
> the git version of Org from the beginning, the Emacs distrib
Bastien writes:
> Achim Gratz writes:
>> Probably yes, although there are other variables that should probably be
>> bound in this case (and maybe others).
>
> If you can think of some others, please let us know.
The docstring of org-minutes-to-clocksum-string says:
&quo
Nick Dokos writes:
> I believe that just as with code changes, doc changes also need FSF
> copyright assignment.
The FSF owns the copyright to all of Org, including the documentation.
So yes, anything over 20 lines non-trivial chnages needs to be assigned
to FSF.
Regards,
Achim.
--
+<[Q+ Matri
701 - 800 of 1726 matches
Mail list logo
