Thomas S. Dye writes:
I recently pushed a change to the Babel languages table on Worg, but it
doesn't show up. Magit didn't complain about the push, so I'm thinking
Worg might not be updating?
Press $ in the magit buffer to see what the post-commit hook sent back.
BTW, looking at the
Thomas S. Dye writes:
Let's add this link to the footnote, then. I don't understand the
implications of including selected contrib files in the installation
using the build system. Is it the case that using this process means
that it is possible to use org-babel-do-load-languages to load,
Thomas S. Dye writes:
However, the package manager doesn't (yet) recognize this package and
when I download ob-* packages, org-2015* is also downloaded.
Did you restart Emacs? The package files need not be byte-compiled (and
shouldn't, IMHO).
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305
Thomas S. Dye writes:
I do have a technical question that you or someone else on the list
might be able to answer for me. When I downloaded the Babel languages
from melpa just now, the elpa version of Org mode was also downloaded
and installed, even though I didn't ask for it. Why is this?
Thomas S. Dye writes:
Excellent. Thanks! Would it be useful to distribute org-21991231 on
elpa?
No, not at all… Unless you want to make sure that noone ever gets an
update until the next millenium starts.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk
Rasmus writes:
Done. I was very busy this week.
No worries. Now, if Bastien would make up his mind if we generate an
org.el to facade for the file that will have the content (what will we
name this?)… However, this would have to be done on maint, so there's
the question of whether and when we
Nicolas Goaziou writes:
I think Org ELPA's release is updated at least every week.
The last update was published with a wrong version number (that package
manager will not consider as an update) and no further updates will be
published at all I suspect unless the version header in org.el gets
Bastien writes:
Here is my decision on this issue:
- the Org 8.x series will be Emacs 23+ compatible.
…and we should maybe do an 8.4 final release before it is frozen, but
not drag it along furhter like you suggested in emacs-devel.
- the Org 9.x series will be Emacs 24.3+ compatible.
Rasmus writes:
Is there any issues with adding a version header to org.el in maint and
master?
I don't think so. It may require to update README_maintainer
accordingly.
Done.
Please revert that change. It's messing with the version numbers on
ELPA since (as I suspected) the idea of using
Bastien writes:
So there would be two org.el, one bare, non-generated version, with no
Version: header, and another one, generated, with all relevant info?
Of course the non-generated version, being in the same directory, would
need to have a different name. But otherwise, yes.
Regards,
Bastien writes:
So my suggestion still stands:
- let's keep master in the current compatibility state since the
question you asked still needs to be answer (it's just 10 days
since it was asked).
- let's use a dedicated branch for commits requiring Emacs 24.3+.
I'm with Nicolas on this
Bastien Guerry writes:
The redefinition already happened (i.e. the master branch is about
Org+Emacs 24.3+) and it happened before we could reach a consensus
about it, or simply take the time to really discuss it as we need.
I'm trying to find the best conditions to move forward here.
Well,
Nicolas Goaziou writes:
Just to be sure, can we require Emacs 24.4 for development version
(a.k.a. Org 8.4)? As a data point, Debian stable provides it.
Debian Squeeze LTS or whatever they call it doesn't w/o backports.
RHEL6 doesn't have it w/o epel (RHEL7 has 24.3 IIRC).
RaspberryPi doesn't
Rasmus writes:
I don't really see the issue... Can we add a proper Version headers in
the make process for ELPA packages.
We don't generate org.el; while it would not be impossible to do, I
don't really see why we should just to drop some comment in there.
Besides, it would be perfectly
Rasmus writes:
Is there any issues with adding a version header to org.el in maint and
master? Maybe 8.4 or 8.4-dev or 8.4-pre for master...
Yes, we don't want to have to commit this nonsense when we have a proper
VCS. Now, instead of simply tagging a release you're back to having to
remember
Scott Randby writes:
While I've used Org's development version in the past, I stopped doing
that due to my failure to learn how to use git (no time) and other
issues. Now, I only use the stable releases. But the latest 8.3
release doesn't seem so stable to me, so I'd like some clarification
Kyle Meyer writes:
Just restarting emacs will still use the compiled files. Did you try
'C-u M-x org-reload' (the C-u prefix loads the *.el files instead of
*.elc)?
The org-reload uncompiled command is in the Org menu in Emacs under
Refresh/Reload and bound to C-u C-c C-x !.
Regards,
Achim.
Sharon Kimble writes:
So I'm now running with org-mode -
╭
│Org-mode version 8.2.10 (release_8.2.10 @
/usr/local/share/emacs/24.5.50/lisp/org/)
╰
How can I remove this version please?
How can I install the package manager version of org without the
'org-babel-etc' error message
Bastien Guerry writes:
Org 8.3 is now out. Here is the list of changes:
Yay!
http://orgmode.org/Changes.html
Just a few statistics: these are 2936 commits since the 8.2 release 23
months ago, 2390 commits on top of 8.2.10 and 1361 of those after the
8.3beta release 13 months ago.
Thanks to
azubi writes:
The version of org-mode I use is:
Org-mode version 8.2.4 (8.2.4-dist @
/home/azubi/.emacs.d/elpa/org-20150720/)
Can you please explain me what I've done wrong ?
That looks like a mixed installation to me. Somewhere you seem to have
installed an Org version 8.2.4 from a
Marcin Borkowski writes:
I'm preparing a tutorial on writing Org-mode exporters. To this end,
I'm writing a (simplistic) Oddmuse/WikiCreole exporter. Rather
obviously, I'm modeling it on existing exporters (mainly ox-latex),
which seem to share a lot of structure (function names and
Rasmus writes:
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
That leads me to the next question: should we really mess with this?
Maybe not. Perhaps there's a reason for the current implementation.
Agreed. However, it seems a good opportunity to alert the user to the
fact that Org didn't
Rainer M Krug Rainer at krugs.de writes:
M-x occur RET Exa RET
Ah - occur is nice - very nice. I like the output and also that it shows
me all hits - I'll use this more often!
It even has a key binding: M-s o. If you like a function and wonder if it
has a key binding: C-h w function name
Richard Y. Kim writes:
# server.mk has the elpaplus makefile target
echo include mk/server.mk Makefile
[…]
# Undo the change made above
git checkout Makefile
You know, local.mk was introduced specifically so you wouldn't have to
do anything like that.
Regards,
Achim.
--
+[Q+ Matrix-12
Steinar Bang writes:
Isn't this what's MELPA is for?
http://www.emacswiki.org/emacs/MELPA
MELPA is unable to provide a correctly installable package for Org since
they just pull down the tree and don't do the necessary build steps.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron
T.F. Torrey writes:
The package manager can only handle one version of a package *per
archive*, so instead use one archive per version.
The version of package manager that people most likely use today always
choses the latest version from _any_ archive available when you update.
You can't tell
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
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
Nicolas Goaziou writes:
This looks like valid HTML code to me. Also it exports fine to HTML. Is
there any restriction related to this specific to FreeMind?
Valid HTML, maybe (I've not checked). Valid XML, no.
http://freemind.sourceforge.net/wiki/index.php/File_format
Regards,
Achim.
--
+[Q+
Mark A. Flacy writes:
In particular (comparing the org-plus-contrib-20150202 package against
today's http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp):
You are looking at the master branch. The packages are made from maint:
Phillip Lord writes:
Can anyone tell me where the source code for org-info at
http://orgmode.org/org-info.js
is? This verison if minified.
There are these:
https://github.com/SebastianRose/org-info-js/
A copy of this version is on Worg under code/org-info-js, the plain
source is
Pascal Fleury writes:
Here is a patch that will figure out the version of bash in a less
fork-y way. It keeps the result in a variable after having gotten it
the first time by indeed forking to bash.
I still think this should be a defcustom instead with a setter function
that checks for the
abonnements writes:
PS: sorry to be curious but I can't figure out is the language behind
2014ko abenudak 22an, abonnements-ek idatzi zuen ( :-) )
Basque.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf rackAttack V1.04R1:
Fabrice Niessen writes:
On Cygwin (I'm on Windows), that does not seem to work:
kill -10 PID
kill -USR2 PID
Cygwin kill only works with Cygwin processes, while your backtrace is
from a Windows Emacs. The problem of the incomplete traces might also
be related to your attempt to attach a
Yuri Niyazov writes:
I'd like to hire a programmer to hack on some things in org-mode for
my use. If these improvements are contributed back the main org-mode
repository, would the copyright assignment have to come from me, or
from the programmer?
IANAL… you'd normally own the resulting
Karl Voit writes:
echo testing stderr with manual redirect 21 2
The last redirection 2 is nonsense, it only works because STDERR is
already reopened on STDOUT and redirection to the same file descriptor
is ignored.
And to solve your original problem:
#+BEGIN_SRC sh :results output
exec 21
echo
Karl Voit writes:
However with an additional echo at the end:
You need to understand what you're doing or at least copy the code
exactly. The last line in my example is a colon : so that the shell
exit code is always zero. If not, Babel will ignore the output since it
interprets any non-zero
Am 26.12.2014 um 23:47 schrieb Ken Mankoff:
People here might be interested in a publication from [2014-12-19 Fri]
available at http://dx.doi.org/10.1371/journal.pone.0115069
Title: An Efficiency Comparison of Document Preparation Systems Used
in Academic Research and Development
Summary: Word
Nicolas Goaziou writes:
Applied (with a minor change in `org-timer--get-timer-title'). Thank you.
The new tests don't work on Emacs23, mainly due to the use of cl-letf.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Waldorf MIDI Implementation
Nicolas Goaziou writes:
The new tests don't work on Emacs23, mainly due to the use of cl-letf.
I fixed the `cl-letf' issue, thank you. Is there anything else to do?
Not with respect to this change, the tests are now all passing.
However, Emacs master seems to have changed the signature for
Sharon Kimble writes:
My emacs version is in the sig, and my org-version is Org-mode
version 8.2.10 (8.2.10-23-g1ec416-elpaplus @
/home/boudiccas/.emacs.d/elpa/org-plus-contrib-20141208/) so we're
in agreement, but still it happens. I've checked everywhere in my
init.org and I don't have a
Achim Gratz writes:
Dima Kogan writes:
--- a/testing/lisp/test-org-table.el
[…]
+(condition-case
[…]
+ #+TBLFM: @1$2=5)
+ ('user-error t)))
That part of the test, specifically the attempt to catch the error is
not working for me on Windows, most likely because I use an older
Achim Gratz Stromeko at NexGo.DE writes:
The right thing to do is to make the maintainers that will commit your code
aware of that fact. I see you are already listed as a contributor to
Orgmode w/ assigned copyright.
Sorry, slip of fingers. You are still listed as a contributor w/o assigned
Michael Brand writes:
What is the reason that make check does not stop at the first
compilation error with a non-zero exit status?
Emacs doesn't behave like a compiler.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf Blofeld
Andreas Leha writes:
recently make clean-install leaves the files htmlize.el[c] left in my
installation directory while I'd expect them to be removed by
clean-install.
Stop adding it to the installation in the first place.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb
Marco Wahl writes:
Is there any reason not bringing your new version into the master
branch?
I'm not certain about the current maintainer policy w.r.t. backwards
compatibility for older Emacsen, but this patch would work with Emacs 24
only due to its use of lexical binding.
Regards,
Achim.
--
Marco Wahl writes:
Since the fix is small and clear (AFAICT) and the tests pass I try to
push it directly to maint.
Please keep maint merged into master.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Factory and User Sound Singles for Waldorf Blofeld:
Marco Wahl writes:
Sorry for that. I was not aware that fixes should go to maint. I just
naively took the first best branch (which was master) for applying the
change. BTW: It looks like a good soul already merged the patch into
the maint branch.
The general rule is that bugfixes for bugs
Dima Kogan writes:
--- a/testing/lisp/test-org-table.el
[…]
+(condition-case
[…]
+ #+TBLFM: @1$2=5)
+ ('user-error t)))
That part of the test, specifically the attempt to catch the error is
not working for me on Windows, most likely because I use an older
version of Emacs there
Marco Wahl writes:
Bastien b...@gnu.org writes:
The patch has shrunk considerably and hopefully is worth for the push
now.
The patch looks good, please go ahead. Thanks!
Patch pushed!
It looks like that patch should have gone to maint rather than master
and please use a properly
Rasmus writes:
Could you please rebase or cherry-pick your changes onto the
then-current master before committing them?
Yes, I am very happy to!
However, can you please elaborate on what exactly I did wrong? I have
checked for the following to understand your criticism:
1. When I do $
Rasmus writes:
In the future you should sent minimal examples. In this case it did
not matter and the mentioned commit was indeed to blame. It should be
fixed in master @ 004332b.
Could you please rebase or cherry-pick your changes onto the
then-current master before committing them? Also,
Rasmus writes:
Please also apply this patch to make make test pass.
Applied. Please always run all tests before committing.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Factory and User Sound Singles for Waldorf Blofeld:
Martin Gürtler writes:
I'm using Org-mode version 8.2.7c (8.2.7c-74-gd2ecbe-elpa, org-plus-contrib
package).
That doesn't seem to be the case, the org-plus-contrib package would
advertise itself with the -elpaplus suffix.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb
Omid writes:
In any case, could you (Achim Gratz) please share with us the final
patch that you and Nicolas Goaziou agreed upon?
That is commit 4ed554196b on master.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf rackAttack
Achim Gratz writes:
Oleh writes:
#+RESULTS:
:
: 3
Well, that would still be an empty line too many. But aside from that,
what I'm actually getting with a recent Emacs and inf-ruby is:
#+RESULTS:
:
: irb(main):003:0 irb(main):004:0 irb(main):005:0 3
So either comint-mode has
Oleh writes:
#+RESULTS:
:
: 3
Well, that would still be an empty line too many. But aside from that,
what I'm actually getting with a recent Emacs and inf-ruby is:
#+RESULTS:
:
: irb(main):003:0 irb(main):004:0 irb(main):005:0 3
So either comint-mode has developed some problem in the
Nick Dokos writes:
First thing I would do is delete the org-publish.elc file and try with
uncompiled org-publish.el. That should at least give you a better
backtrace.
You could just do C-u C-c C-x ! (reload Org uncompiled) and then get
that backtrace.
Regards,
Achim.
--
+[Q+ Matrix-12
Eric Schulte writes:
Ernesto Durante stobos...@gmail.com writes:
+ First patch, modify org-babel-eval to load compilation-mode in case
of errors
Applied.
These are missing a proper changelog so Bastien will be less happy.
org-babel-eval: compilation-mode to deal with errors in (C/C++/D)
Aaron Ecay writes:
Can you say more about the corner cases?
It's been quite some time since I looked at this, but inline calls were
quirky for instance since their point of call is ill-defined.
As to the non-scalability, that should be fixed by some combination of
the parser cache and
Rainer M Krug writes:
If this is the case, I would opt, in addition to the + operator, to
have a - operator, which *removes* properties from the property set
:header-args.
Properties don't work that way, they're just strings.
Initially I thought, to use :header-args+ instead of :header-args
Steven Arntson writes:
I updated some packages through the package manager, including org and
org-plus-contrib, and now M-x ly- gives [no match] in the
minibuffer. I didn't mess with my .emacs at all, which contains these
lines:
The prefix has been changed from ly- to org-babel-lilypond- in
Steven Arntson writes:
org-babel-lilypond-compile-lilyfile: Searching for program: no such file
or directory, /usr/bin/lilypond
because I installed lilypond into /usr/local/lilypond/usr/bin. I tried
M-x customize-group lilypond RET and M-x describe function but
couldn't solve the problem.
Rainer M Krug writes:
Aaron Ecay aarone...@gmail.com writes:
I have a question concerning the property :header-args:. In addition
to :header-args: there is also :header-args+:.
Since essentially you're asking about property syntax, please read the
corresponding chapter of the manual.
1) If I
Aaron Ecay writes:
Eric Schulte has said http://mid.gmane.org/87wqce0w9n@gmail.com
that the deprecation of this feature is “premature”. I didn’t realize
at the time that the deprecation was also included in the manual rather
than just a code comment. Possibly it should be un-deprecated.
Jeff Kowalczyk writes:
Thanks. My load-path seems to put Org from git first. Moving that
checkout back to 288ffa fixes, newer versions have the problem
behaviors. Am I overlooking something that could still lead to a
mixed Org version?:
Yes, you may not use anything from Org before the
Sharon Kimble writes:
I'm sorry Achim, but what do you mean by that?
Giving that command on the command line.
'site-lisp'? Where’s that then please? Its not in the org-mode that
comes with the git output, and I don't have one in my bog-standard emacs
in my /home directory at ~/.emacs.d/
On
Sharon Kimble writes:
How do I drop the debian version and stick with the git version please?
make up2
(setq load-path (cons /home/boudiccas/.emacs.d/lisp load-path))
You shouldn't need this unless you really have some stuff in there
that's just for you. I'd suggest moving those things to
Pascal Fleury writes:
Please forget about the previous patch I submitted, I have a new one
that should work now on all platforms.
Let me know if it should be formatted differently.
You don't really want to fork into bash each time you're about to run a
shell code block just to find out if it
Nicolas Goaziou writes:
FWIW, I think prefix conformance should go to maint.
Patch has been split and just the prefix conformance committed to maint
in b8bd2147cb.
Introduction of defcustom, some code cleanups and associated tests
committed to master in 64821bd967.
Regards,
Achim.
--
+[Q+
Nicolas Goaziou writes:
FWIW, I think prefix conformance should go to maint.
OK.
Also, you shouldn't use `pcase' as Org preserves compatibility with
Emacs 23.
Thanks for the reminder. In any case, these will need to become
defcustoms as well.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305
Achim Gratz writes:
Thanks for the reminder. In any case, these will need to become
defcustoms as well.
Improved patch now with defcustom. I hope I did get that defcustom
stuff right, please check.
From 35c3be896c159fcd9fb727b39273750fc0264592 Mon Sep 17 00:00:00 2001
From: Achim Gratz strom
Aaron Ecay writes:
R is capable of installing packages to a user-specified directory,
without requiring root or any other special privileges. So IT cannot
literally prevent R users from installing their own packages;
They can, all they have to do is to take away the ability to connect to
the
Aaron Ecay writes:
The user would need to install it in her private directory if it
is not on the system; some shops actually discourage this.
^^^
That’s ... special. Do you have experience with such environments?
I take it you've
Steven Arntson writes:
I reverted the change to ob-lilypond.el and did as you suggested, adding
(setq ly-nix-ly-path /usr/local/lilypond)
I don't think that path points to an actual lilypond executable, but is
rather an installation directory. Since it would seem you have lilypond
in PATH on
on master.
From b7dd71aa6bb15a31eecf794c6f1c07dd38b834cd Mon Sep 17 00:00:00 2001
From: Achim Gratz strom...@stromeko.de
Date: Sun, 17 Aug 2014 10:29:24 +0200
Subject: [PATCH] ob-lilypond: Code cleanup
* lisp/ob-lilypond.el: Change ly- prefix to org-babel-lilypond
throughout.
(ly-OSX-ly-path
Steven Arntson writes:
I've stumbled straight into another issue. ly-tangle now works, but when
I try to invoke lilypond-mode in my org document by typing C-c ' in a
code block, I now get:
Language mode `lilypond-mode' fails with: Cannot open load file
This tells you that you haven't
Marcelo de Moraes Serpa writes:
I've updated org to 8.2.5 (by checking out the release_8.2.5 tag) from
7.9.4. After updating remote and checking out the mentioned branch, I
ran make and then make install.
The latest release version is 8.2.7c and if you install from Git anyway
you should just
Kenneth Jacker writes:
For me, there is a little confusion on just which version I'm using ...
I changed to the org-mode git managed directory, and entered:
$ make update
{ Do I need to do more? I followed the above with
make and make install ... necessary? }
Noah Hoffman writes:
This is particularly problematic for python code
blocks since leading whitespace is meaningful.
The problem you imagine doesn't exist because the leading whitespace is
stripped before the code is sent to the interpreter.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305
Salome Soedergran writes:
#1 was at fault. I just deleted my ELPA installation of Org and
reinstalled it as decribed by Achim. Now everything's fine.
Thanks for letting us know.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Factory and User Sound
Vicente Vera writes:
Yes, i had an old makeinfo (4.13) that lives in the debian wheezy
repository. Just now got the latest version and it worked. Didn't
thought about this since some commits ago the documentation was built
just fine with makeinfo 4.13.
Glad you've solved it, but makeinfo 4.13
Salome Södergran\ writes:
Indeed! I find an older org-version (7.x) in /usr/share/emacs. I have
now changed the order in the load-path-list to load the local
installations first.
When you install from ELPA, leave load-path alone (remove any
alterations in respect to Org or any other package
Vicente Vera writes:
Hello. Started another clean cloned local repository to try building
the documentation again and the errors persist.
The error is quite likely on your side. What is the output of
which makeinfo
file `which makeinfo`
makeinfo --version
as I suspect that you pick up some
Alan Schmitt writes:
Has this been applied? I'm still seeing a failing test for ob-shell.
1 unexpected results:
FAILED ob-shell/bash-uses-assoc-arrays
That's to be expected if you use a version of bash that doesn't support
assoc arrays. WHat is the backtrace from the test? Babel (and
John Lusk writes:
You probably already know about this problem, but here's a thousand
words:
That has nothing to do with Org. Your font (or any of the fallback
fonts that are tried instead) doesn't provide a single-width glyph for
the unicode codepoint you're using. Emacs usually gets this
Malcolm Purvis malcolm at purvis.id.au writes:
Thanks. Things are just as fast with this regexp.
Thanks for the confirmation.
Regards,
Achim.
Ista Zahn writes:
I've made the suggested changes, with the exception of the part of
Emacs bit, as this should go in contrib not core.
I asked Bastien privately about getting access to the git repository,
but will ask here as well: When I run 'git clone
orgm...@orgmode.org:org-mode.git' I
Nicolas Goaziou writes:
+ \\(?:^\\|[^-[:alnum:]]\\)\\(src_\\([^ \f\t\n\r\v\\[]+\\)
I think [^ \f\t\n\r\v[] is enough.
Yes. But looking at the original regex has me wondering if the need for
the extra '[' isn't an indication of something more fundamentally wrong
with it. Where does that
Sharon Kimble writes:
The 'master' branch is the development/unstable branch. The stable
branch is called 'maint'.
Ok, so what is the command for the maint branch then please?
You'd say
git checkout maint
on the command line or just define
GIT_BRANCH=maint
in your local.mk and keep
Bastien writes:
2. Demote the whole subtree to toplevel before encryption and promote
into the correct level on decryption, (much in the same way that
includes are handled).
By correct level on decryption you mean toplevel? This would really
circumvent the problem.
Not sure what you mean
Malcolm Purvis writes:
I use the master version of org, and some months ago the time required
to generate my custom agenda view sky rocketed. I've found that 90% of
the time was being spent in the call to re-search-forward in
org-refresh-category-properties. The patch below speeds up the
Miguel Ruiz writes:
git reset --hard origin/master # warning: removes local changes
Not only that, but it is an extremely bad idea to use a detached head
like that. If you must do this, please do at least keep such
instructions to yourself. Everybody else please
git checkout master
which
Nick Dokos ndokos at gmail.com writes:
Apparently these tests assume that the org info file can be found, but
the `make clea'n that is done at the beginning of make test wipes it
out. That's probably because I'm working out of the cloned git tree, but
if possible, I would like `make test' to
Jorge A. Alfaro-Murillo writes:
Why? emacs/lisp points to org-mode/lisp, if I update org it updates in
its org-mode repo, what can I break?
All the derivative files that were lifted out of this directory into
other places, like cus-load and loaddefs. Again, Emacs doesn't treat
any of its
Vicente Vera writes:
- M-x info shows the updated info manual which now resides in
/usr/local/share/info (I think it replaced the built-in manual?).
That depends on where your system installation put it originally. But
even if it was originally installed someplace else, it would now find
the
Vicente Vera writes:
Thanks for your reply. Which one is the default install method? If
it's 'make install',
I'd go for make up2 (which ends up doing make install if the tests are
passing) if you want minimum involvement, but it's your choice.
do i need to tweak local.mk because of the
Miguel Ruiz writes:
Minimal sequence for me is: make clean git pull make autoloads
make info
You can simplify this to a just make by defining your own default
target in local.mk like this:
my_default_target: up0 uncompiled info
(that's a tab after the colon).
Regards,
Achim.
--
+[Q+
Jorge A. Alfaro-Murillo writes:
For org, I once read a discussion in this list about not doing this but
that a lot of people do it, it keeps working for me, so I keep doing it.
It doesn't work, you just haven't run into a problem that you can
positively identify with that habit yet. You'd need
101 - 200 of 1679 matches
Mail list logo
