Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Eric Schulte gmail.com> writes: > > and where do you set load-path? > > No load path customization, just those two lines above are enough to > cause the error. How do you expect Emacs to recognize that you'll want to use a different Org? > alright, starting with emacs -Q, evaluate the following in your scratch > buffer. > > (load-file "~/.emacs.d/src/org-mode/lisp/org.el") You must set the load-path to start with the expansion of ~/.emacs.d/src/org-mode/lisp/ first. > it may complain (void-function org-define-obsolete-function-alias), in > which case evaluate the following in your scratch buffer > > (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el") Don't know what you're trying to achieve there. This should be absolutely uneccesary. > (load-file "~/.emacs.d/src/org-mode/lisp/org.el") Ditto (we're still talking about 'emacs -Q', yes?). > The above works prior to the offending commit, but now it throws an > error. As it should; and I remark that it didn't work before, you've just not been getting an error. Your load-path points to Emacs' core, and then you're trying to load a single out-of-core file from a later version of Org. Start Emacs with -Q, make sure the autoloads have been generated in the Git worktree (org-loaddefs.el must exist). Then evaluate step-by-step the following lines in *scratch* (C-j at the end of each sexp): features load-history (symbol-file 'org-release) (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp") (load-library "org-loaddefs") (org-version t t) features load-history (symbol-file 'org-release) (org-reload) Please post the output in *scratch* and *Messages*. Thanks, Achim.
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Eric Schulte gmail.com> writes: > Alright, after adding the autoload declaration to the above function, > and running "make autoloads" in the checked out Org-mode directory, I am > able to load org.el successfully. I just committed this change. You are getting ahead of yourself, there is no need to do this. > I guess we inherited the need to run "make autoloads" when we got rid of > org-install.el? No, it is way older than that. Regards, Achim.
[O] [BUG] org-open-at-point fails with multiple links in entry
Hi all,
recently a common workflow of mine broke: I have an entry, and in the
text are several links to websites. I can go to the heading or its line
in an agenda and do `org-open-at-point', and I get a list of links
inside the entry. But selecting them all with RET gives an error now:
emacs -Q -nw
-
(setq package-user-dir "~/src/elpa"
package-enable-at-startup nil)
(package-initialize)
(require 'org) ;checked org-version is 7.9.3a
(org-mode)
insert
-
* test heading
http://www.google.com
http://www.sz.de
go to headline, do `org-open-at-point', and select all..
org-open-at-point: Wrong type argument: stringp, (#("http://www.google.com"; 0 6
(fontified t...LONGISH.
Bottom line: It gets a list of propertized strings and expect a single
one. Any help what broke this? I do not have much time to dig into the
code right now, unfortunately.
Regards,
Ingo
[O] LaTeX preview
Hi, Is there an #+STARTUP parameter to automatically display LaTeX fragments? If not, where do I have to look to add it? -- Daimrod/Greg pgpwOUfDZhYGv.pgp Description: PGP signature
Re: [O] BBDB(3) or org-contacts
* Michael Strey wrote: > On Tue, Jan 08, 2013 at 05:14:43PM +0100, Daniel Clemente wrote: > > [...] > >> Therefore I use its infrastructre (because I like it) but I don't run its >> code. I'll explain myself: >> I keep this structure in an .org file: >> ** John von Neumann >> :mathematic: >>:PROPERTIES: >>:EMAIL: j...@neumann.com >>:END: >> - some info > > 1+ > > I've more than 1000 contacts 1012 at my side. No speed issues so far. > and this system works well and with > reasonable speed. For integration with mutt, I use Karl Voit's lbdb > module for org-contact [fn:1]. To be fair, the perl-script did not originate from me. lbdb works like charm. With the script mentioned, I can query any kind of (sub-)string of a contact. This is quite nice since I can query things like «vacation2012» or «orgmode» to get contacts. > I've defined a set of properties derived from the VCard specification > and like Daniel, I have a Capture template to create new organisations > and contacts below them. You might also want to read: http://article.gmane.org/gmane.emacs.orgmode/47478/ -- Karl Voit
[O] #+STARTUP: content question
Hi, I'd like to have my org files to show the contents of all the nodes that have (sub)items not marked as completed/done. Therefore the following: * FIRST ** second *** TODO blah *** DONE blah ** third *** DONE blah *** DONE blah should be shown when visiting the file as follows: * FIRST ** second *** TODO blah *** DONE blah ** third ... Is that possible using the #+STARTUP or org-startup-folded variable? Thanks, Luca
[O] Bug: bug in batch-execution example [7.8.11]
Hey all. I'm not sure where the original file is, and it's only a tiny change, so I'm not sure if this patch is useful, BUT... On this page: http://orgmode.org/manual/Batch-execution.html The example script is missing backticks around the pwd. Patch follows. diff --git a/tangle.el b/tangle.el index 0391f64..e7693cd 100755 --- a/tangle.el +++ b/tangle.el @@ -3,7 +3,7 @@ # # tangle files with org-mode # -DIR=pwd +DIR=`pwd` FILES="" # wrap each argument in the code required to call tangle on it
Re: [O] [BUG] org-open-at-point fails with multiple links in entry
Hi Ingo,
Ingo Lohmar writes:
> recently a common workflow of mine broke: I have an entry, and in the
> text are several links to websites. I can go to the heading or its line
> in an agenda and do `org-open-at-point', and I get a list of links
> inside the entry. But selecting them all with RET gives an error now:
>
> emacs -Q -nw
> -
> (setq package-user-dir "~/src/elpa"
> package-enable-at-startup nil)
> (package-initialize)
> (require 'org) ;checked org-version is 7.9.3a
> (org-mode)
>
> insert
> -
> * test heading
> http://www.google.com
> http://www.sz.de
>
> go to headline, do `org-open-at-point', and select all..
>
> org-open-at-point: Wrong type argument: stringp,
> (#("http://www.google.com"; 0 6 (fontified t...LONGISH.
Fixed, thanks a lot.
--
Bastien
Re: [O] LaTeX preview
Hi Daimrod, Daimrod writes: > Is there an #+STARTUP parameter to automatically display LaTeX > fragments? Nope, sorry. -- Bastien
Re: [O] #+STARTUP: content question
Hi Luca, Luca Ferrari writes: > Is that possible using the #+STARTUP or org-startup-folded variable? No. You can play with the :VISIBILITY: property but we need something more flexible, I agree. On my todo list. -- Bastien
[O] Agenda and tags position
Hi, is org-agenda-tags-column still working? After the last stable version, even if I change the value of this variable, the tags appear all the time at the same position. many thanks in advance! Igor -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido :::: pgpTGG5tMTM7E.pgp Description: PGP signature
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Hi Eric, actually, digging your problem further, I finally committed this patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=db7ece Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is asking for troubles. I removed this. Thanks for the time spent on this, -- Bastien
Re: [O] Agenda and tags position
Hi Igor, Igor Sosa Mayor writes: > is org-agenda-tags-column still working? After the last stable version, > even if I change the value of this variable, the tags appear all the > time at the same position. This has been fixed in 7.9.3a -- let me know if you find out you still have this problem with 7.9.3a. Best, -- Bastien
Re: [O] Bug: bug in batch-execution example [7.8.11]
Hi Michal, Michal Wallace writes: > On this page: > > http://orgmode.org/manual/Batch-execution.html > > The example script is missing backticks around the pwd. You must have an old cached version of this page, please refresh the webpage. Thanks, -- Bastien
Re: [O] Agenda and tags position
Am Fri, Jan 11, 2013 at 01:29:41PM +0100, Bastien wrote: > This has been fixed in 7.9.3a -- let me know if you find out you still > have this problem with 7.9.3a. Hi Bastien, thanks a lot. Of course it is working. I am using the AUR package of archlinux and thought it is version 7.9.3a but it was still 7.9.3... thanks again! -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido :::: pgpLdlb1ucf9K.pgp Description: PGP signature
[O] org agenda extensions
Dear all with the aim to show properties in custom match views, I have been experimenting with new variables: org-agenda-overriding-agenda-format org-agenda-property-list then, tweaking the function org-scan-tags this enables custom format for the agenda lines, optionally showing properties (without invoking org-columns). you can test this here http://192.38.117.59/~tag/download/org-agenda-overriding-format-snps.el using the dummy org-file http://192.38.117.59/~tag/download/test.org this should not break any current functionality? so, how about including these changes of org-scan-tags? Best Thomas ps: I have now subscribed to the mailing list also with my current email address. but, I posted this message once before ... so, dear mailing list maintainers, please accept my appologies for the inconvenience ! -- sent from Nil
Re: [O] LaTeX preview
Bastien writes:
> Hi Daimrod,
>
> Daimrod writes:
>
>> Is there an #+STARTUP parameter to automatically display LaTeX
>> fragments?
>
> Nope, sorry.
Here is a patch to add `org-startup-with-latex-preview'. It should work
like `org-startup-with-inline-images'.
diff --git a/doc/org.texi b/doc/org.texi
index 030eaf8..a13d565 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -9752,6 +9752,19 @@ some aspects of the preview. In particular, the @code{:scale} (and for HTML
export, @code{:html-scale}) property can be used to adjust the size of the
preview images.
+@vindex org-startup-with-latex-preview
+You can turn on the previewing of all @LaTeX{} fragments of a file with
+
+@example
+#+STARTUP: latexpreview
+@end example
+
+To disable it, simply use
+
+@example
+#+STARTUP: nolatexpreview
+@end example
+
@node CDLaTeX mode, , Previewing @LaTeX{} fragments, Embedded @LaTeX{}
@subsection Using CD@LaTeX{} to enter math
@cindex CD@LaTeX{}
diff --git a/lisp/org.el b/lisp/org.el
index effb231..2e7f3a4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -580,6 +580,16 @@ the following lines anywhere in the buffer:
:version "24.1"
:type 'boolean)
+(defcustom org-startup-with-latex-preview nil
+ "Non-nil means preview LaTeX fragments when loading a new Org file.
+
+This can also be configured on a per-file basis by adding one of
+the followinglines anywhere in the buffer:
+ #+STARTUP: latexpreview
+ #+STARTUP: nolatexpreview"
+ :group 'org-startup
+ :type 'boolean)
+
(defcustom org-insert-mode-line-in-empty-file nil
"Non-nil means insert the first line setting Org-mode in empty files.
When the function `org-mode' is called interactively in an empty file, this
@@ -4509,6 +4519,8 @@ After a match, the following groups carry important information:
("noalign" org-startup-align-all-tables nil)
("inlineimages" org-startup-with-inline-images t)
("noinlineimages" org-startup-with-inline-images nil)
+("latexpreview" org-startup-with-latex-preview t)
+("nolatexpreview" org-startup-with-latex-preview nil)
("customtime" org-display-custom-times t)
("logdone" org-log-done time)
("lognotedone" org-log-done note)
@@ -5154,6 +5166,8 @@ The following commands are available:
(set-buffer-modified-p bmp)))
(when org-startup-with-inline-images
(org-display-inline-images))
+(when org-startup-with-latex-preview
+ (org-preview-latex-fragment))
(when org-startup-indented
(require 'org-indent)
(org-indent-mode 1))
--
Daimrod/Greg
pgpgs1Ek3Eswb.pgp
Description: PGP signature
Re: [O] Fixes for org-capture-templates-contexts
By a great coincidence I just discovered org-capture-templates-contexts yesterday but could not make it work yet (didn't have much time to investigate it). Is it possible to have capture templates that do not appear in any buffer but can be called from lisp? The idea is that I'm implementing some org-capture templates right now that I only intend to call via "(org-capture nil 'some letter')" and never via "C-c c". Maybe today is my luck day and it is exactly this new "not-in-buffer" context you have just added? ps: this rule affecting all sub-templates will also be very userful. -- Darlan At Thu, 10 Jan 2013 21:04:54 + (UTC), Paul Sexton wrote: > > org-capture-templates-contexts currently appears not to work. The structure > that the function 'org-contextualize-validate-key' expects to find in the > variable seems quite different from the structure described in the docstring. > > Here are fixed versions of the functions 'org-contextualize-validate-key' > and 'org-contextualize-keys', both from org.el. I have also added some > functionality: > - new context specifiers in-buffer and not-in-buffer > - in-mode and not-in-mode expect a symbol, not a regexp. > - if a rule specifies a template that has 'sub-templates', those sub-templates > will also be affected by the rule. For example if you have templates 't', > 'ta', 'tb' and 'tc', you can specify a rule for 't' which will affect > all of them. > > I have also rewritten the docstring for org-capture-templates-contexts, > from org-capture.el. > > > > > (defcustom org-capture-templates-contexts nil > "Alist of capture templates and valid contexts. > > Each entry in the alist takes the form: >(KEY [USUAL-KEY] CONTEXT [CONTEXT...]) > > Where: >KEY :: a string of one or more letters, identifying a >capture template. >USUAL-KEY :: if supplied, this is the string that identifies >the capture template in `org-capture-templates', while KEY >becomes the string which will be used to select the >template only in the present context (see below). >CONTEXT :: a context definition. > > Each context definition (CONTEXT) takes the form: >FUNCTION >or (SPECIFIER . ARGUMENT) > > Where: >FUNCTION :: either a lambda form or a symbol naming a function. > The function must take no arguments. >SPECIFIER :: a symbol matching one of the context specifiers listed > below. >ARGUMENT :: either a string regular expression (for in-file and > in-buffer), or a symbol (for in-mode). > > Here are the available context specifiers: > > in-file: command displayed in files matching regex > in-buffer: command displayed in buffers matching regex > in-mode: command displayed if major mode matches symbol > not-in-file: command not displayed in files matching regex > not-in-buffer: command not displayed in buffers matching regex > not-in-mode: command not displayed when major mode matches symbol > > For example, if you have a capture template \"c\" and you want > this template to be accessible only from `message-mode' buffers, > use this: > >'((\"c\" (in-mode . message-mode))) > > If you include several context definitions, the agenda command > will be accessible if at least one of them is valid. > > If the template specified by KEY has sub-templates, they will also > be affected by the rule (unless they have their own rules). For > example, if you have a template `t' and sub-templates `ta', `tb' > and `tc', then a rule for `t' will affect whether all of those > contexts are accessible. > > You can also bind a key to another agenda custom command > depending on contextual rules. > > '((\"c\" \"d\" (in-file . \"\\.el$\") (in-buffer \"scratch\"))) > > Here it means: in files ending in `.el' and in buffers whose > name contains `scratch', use \"c\" as the > key for the capture template otherwise associated with \"d\". > \(The template originally associated with \"q\" is not displayed > to avoid duplicates.)" > :version "24.3" > :group 'org-capture > :type '(repeat (list :tag "Rule" > (string :tag "Capture key") > (string :tag "Replace by template") > (repeat :tag "Available when" > (choice > (cons :tag "Condition" >(choice > (const :tag "In file" in-file) > (const :tag "Not in file" not-in-file) > (const :tag "In mode" in-mode) > (const :tag "Not in mode" not-in-mode)) >(regexp)) > (function :tag "Custom function")) > > > (defun org-contextualize-validate-key (key contexts) > "Check CONTEXTS for agenda or capture KEY." > (let (clause context res) >
[O] Bug: org-mode tables and orgtbl-mode [7.9.2 (7.9.2-166-g40cb44-elpaplus @ /home/vdyadov/Work/Tools/emacs/share/emacs/24.2/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. The bug is easily reproducible with folowing algorithm: 1. I have an org file with verilog code embedded in #+begin_src verilog ... #+end_src 2. Then I hit C-' to edit this verilog code in separate buffer 3. During editing code I shwitch on orgtbl-mode to edit some tables in verilog comments, then I switch off orgtbl-mode 4. Then I hit C-' again to return to the org file 5. And I discover that I cannot edited tables in org file anymore 5a. orgtbl-mode could not be run in org file 6. I hit C-' again on verilog code 7. Switch on orgtbl-mode in buffer with verilog code 8. Hit C-' again to return to org file (without switching off orgtbl-mode) 9. Now editing of tables in org file works as it should to Emacs : GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.9) of 2012-12-25 on canopus-pc.elvees.com Package: Org-mode version 7.9.2 (7.9.2-166-g40cb44-elpaplus @ /home/vdyadov/Work/Tools/emacs/share/emacs/24.2/lisp/org/)
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Bastien writes: > Hi Eric, > > actually, digging your problem further, I finally committed this > patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=db7ece > Great, thank you for running this to ground. After my last email I ran into the problem again, but didn't have the energy to continue debugging. > > Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is > asking for troubles. I removed this. > Makes sense. > > Thanks for the time spent on this, To follow up on the instillation instructions. Those in the manual look pretty good (I'm speaking specifically of org.texi in the master branch of the repository, not the online version of the manual which seems to be out of date and quickly dives into "make help" specifics). My only suggestion would be that they include the following step. ;; emacs-lisp (require 'org) (org-reload) Additionally, I think the attached change to the home page would be helpful for those who want to get started quickly. >From 783ea172b6a89ef5022f41f6cc3936dce522bab5 Mon Sep 17 00:00:00 2001 From: Eric Schulte Date: Fri, 11 Jan 2013 08:36:12 -0700 Subject: [PATCH] quick activation instructions on the front page --- index.org | 7 +++ 1 file changed, 7 insertions(+) diff --git a/index.org b/index.org index 0d65fa5..c79bd00 100644 --- a/index.org +++ b/index.org @@ -37,6 +37,13 @@ Development version ([[http://orgmode.org/cgit.cgi/org-mode.git/][cgit]]): Daily snapshots: [[http://orgmode.org/org-latest.tar.gz][tar.gz]] or [[http://orgmode.org/org-latest.zip][zip]] +To activate manual installs. +#+begin_src emacs-lisp + (add-to-list 'load-path "~/path/to/orgdir/lisp") + (require 'org) + (org-reload) ;; <- on newer Emacs which already include Org +#+end_src + - [[file:features.org][List of features]] - [[#docs][Manuals and tutorials]] - [[file:talks.org][Talks about Org mode]] -- 1.8.1 -- Eric Schulte http://cs.unm.edu/~eschulte
[O] bug#10125: RFE: require and load-path-shadowing
Stefan Monnier writes: >I guess we could fork Emacs early on and keep this second process >around as a "process from which to generate new clean slates". I've been thinking about something like this for a while… if it worked at least as well as starting a new Emacs instance on all platforms, I'd favor this approach. > - outdated .elc file taking precedence over the new .el file can do > the same. Yes, but you get a warning and can already arrange for this (by binding the appropriate variables) to be no problem in practise. See the way org-reload works in current master (of the Org repo). > - bytecompiling a file affects the running session by side-effects such > as requiring packages. If that problem was finally solved that would be very welcome. > I suggested a quick&dirty solution: >> > E.g. we could add to bytecomp.el the ability to force `require' to >> > reload a package if it's not already loaded from the file that >> > locate-library returns. > > I still think it's not a bad option. Would an advice work in this situation (given that require is a primitive)? If yes, I'd like to give it a try over the weekend. If not, I don't really see why require, more specifically the part that checks features needs to be a primitive, so maybe it could be moved partly to elisp. > Of course, we'd still get trouble when the loading is not performed via > `require' but via autoload (maybe we could try and attack this problem > by allowing `autoload' to override an already existing definition, but > that could be delicate). That I'd like to split off from the discussion about require. > I don't see why that would introduce a difficulty. As long as the package is properly namespaced, why not allow for removing all definitions pertaining to that entire namespace (features, autoloads, definitions, …)? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] LaTeX preview
Hi, Daimrod writes: > Here is a patch to add `org-startup-with-latex-preview'. It should work > like `org-startup-with-inline-images'. Thanks for the patch. Did you already sign a FSF copyright assignment or do you plan to sign one? http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt I cannot apply/accept the patch otherwise :( Thanks, -- Bastien
Re: [O] org agenda extensions
Hi Thomas, Thomas Alexander Gerds writes: > with the aim to show properties in custom match views, I have been > experimenting with new variables: > > org-agenda-overriding-agenda-format > org-agenda-property-list > > then, tweaking the function org-scan-tags this enables custom format for > the agenda lines, optionally showing properties (without invoking > org-columns). > > you can test this here Thanks for experimenting with this -- could you send your code as a patch against current maint or master branch? That's easier for me to read/check/test... otherwise I'll have a look later on next week at best. Thanks, -- Bastien
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Hi Eric, Eric Schulte writes: > Great, thank you for running this to ground. After my last email I ran > into the problem again, but didn't have the energy to continue > debugging. Yeah, I know how depressing this can be.. > To follow up on the instillation instructions. Those in the manual look > pretty good (I'm speaking specifically of org.texi in the master branch > of the repository, not the online version of the manual which seems to > be out of date and quickly dives into "make help" specifics). My only > suggestion would be that they include the following step. > > ;; emacs-lisp > (require 'org) > (org-reload) Both lines slow down Emacs startup quite a lot (especially the second one!) and they are not necessary once the load-path is correct. (require 'org) is only necessary when your are calling an org function from within your .emacs.el, because we need to get the proper autoloads before calling this function... I could add a note about this if you think it's useful. But normally, again, the load-path is enough. As for (org-reload) I simply would like to get rid of it one day :) -- Bastien
Re: [O] Bug: org-mode tables and orgtbl-mode [7.9.2 (7.9.2-166-g40cb44-elpaplus @ /home/vdyadov/Work/Tools/emacs/share/emacs/24.2/lisp/org/)]
Hi, vdya...@elvees.com (Дядов Васил Стоянов) writes: > The bug is easily reproducible with folowing algorithm: > > 1. I have an org file with verilog code embedded in >#+begin_src verilog >... >#+end_src > 2. Then I hit C-' to edit this verilog code in separate buffer > 3. During editing code I shwitch on orgtbl-mode to edit some tables in >verilog comments, then I switch off orgtbl-mode > 4. Then I hit C-' again to return to the org file > 5. And I discover that I cannot edited tables in org file anymore > 5a. orgtbl-mode could not be run in org file > 6. I hit C-' again on verilog code > 7. Switch on orgtbl-mode in buffer with verilog code > 8. Hit C-' again to return to org file (without switching off orgtbl-mode) > 9. Now editing of tables in org file works as it should to Thanks for the detailed recipe -- I cannot reproduce the bug here with Org 7.9.3a, I tried with emacs-lisp instead of verilog... Maybe you can share a minimal file? If not, I hope someone else can try to reproduce. Best, -- Bastien
Re: [O] Inherited tags not visible in agenda
Hi Karl, Karl Voit writes: > What is my problem that prevents inherited tags being visible in my > agenda? Please pull again -- I restored the default behavior. I'm a bit on a headache, so perhaps I've lost myself in the possibilities, and forgot to handle a case. If that's so just let me know! Thanks for testing, -- Bastien
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Bastien writes: > Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is > asking for troubles. I removed this. However, in a situation where this is indeed the problem, you actually don't solve it and it will just appear slightly later. Also, this change again breaks installs where the autoloads file is compressed (that was the reason for introduction of the more complicated way to load this file that led to the introduction of the new macro). In particular, when there is another org-loaddefs.el later on in the loadpath, it will happily load that file, creating just the very problem we were trying to avoid. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] LaTeX preview
Bastien writes: > Hi, > > Daimrod writes: > >> Here is a patch to add `org-startup-with-latex-preview'. It should work >> like `org-startup-with-inline-images'. > > Thanks for the patch. Did you already sign a FSF copyright assignment > or do you plan to sign one? > > http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt > > I cannot apply/accept the patch otherwise :( > > Thanks, I've sent a request. I will tell you when it's done, I hope this won't take too much time. -- Daimrod/Greg pgpKi4EPvKFx2.pgp Description: PGP signature
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Eric Schulte writes: > My only suggestion would be that they include the following step. > > ;; emacs-lisp > (require 'org) > (org-reload) These are both not necessary in the general case and should probably not be attempted to be solved this way even in special circumstances. I'll say it again: if you do use Org from Git, then the correct thing to do is to set the load-path before anything else in your init sequence. This can be difficult when you have something creative in site-lisp for instance, but you can always add to load-path on the command line (set up a wrapper script or alias if you must) and then make sure you have the correct autoloads: (load "org-loaddefs") Nothing else should need to be changed. If that doesn't work, please post the information I asked you for so we can figure out where it goes wrong — it should not happen. 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] LaTeX preview
Daimrod writes: > I've sent a request. I will tell you when it's done, I hope this won't take > too much time. Thanks!! -- Bastien
[O] bug#10125: RFE: require and load-path-shadowing
>> I guess we could fork Emacs early on and keep this second process >> around as a "process from which to generate new clean slates". > I've been thinking about something like this for a while… if it worked > at least as well as starting a new Emacs instance on all platforms, I'd > favor this approach. IIUC "fork" is not really an option for w32. >> I suggested a quick&dirty solution: >>> > E.g. we could add to bytecomp.el the ability to force `require' to >>> > reload a package if it's not already loaded from the file that >>> > locate-library returns. >> I still think it's not a bad option. > Would an advice work in this situation (given that require is a > primitive)? Yes, this subroutine is never directly called from C, so placing an advice should work just fine. > If yes, I'd like to give it a try over the weekend. If not, I don't > really see why require, more specifically the part that checks > features needs to be a primitive, so maybe it could be moved partly > to elisp. AFAICT the only part of `require' which can't be written in Elisp right now is the part that handles Vautoload_queue because that variable is not exposed to Elisp (IIRC this variable is used to undo the effects of a partially loaded file when the load bumps into an error midway through; FWIW I'm not convinced this feature works reliably nowadays). >> I don't see why that would introduce a difficulty. > As long as the package is properly namespaced, why not allow for > removing all definitions pertaining to that entire namespace (features, > autoloads, definitions, …)? We could try that, as well, but it would only work for those packages that are "properly namespaced" (and there's no way to detect that AFAIK). Along the same lines, we could try to use unload-feature. Stefan
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Achim Gratz writes: > Also, this change again breaks installs where the autoloads file is > compressed (that was the reason for introduction of the more complicated > way to load this file that led to the introduction of the new > macro). There is this line at the end of org-loaddefs.el: ;; no-byte-compile: t So my understanding is that org-loaddefs.el is never compressed. Under which conditions is it compressed? > In particular, when there is another org-loaddefs.el later on in the > loadpath, it will happily load that file, creating just the very problem > we were trying to avoid. That's why the user needs to add the correct load-path in his .emacs.el when using a tarball or a git clone. I made it clear in the docs. This correct load-path is shadowed by the one of an ELPA install if the user does not take care of (package-initialize) at the very beginning of his .emacs.el, but I also made it clear that users should avoid mixing two installation methods. So I think we're fine here. -- Bastien
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Bastien writes: > There is this line at the end of org-loaddefs.el: > > ;; no-byte-compile: t > > So my understanding is that org-loaddefs.el is never compressed. Byte-compiled != compressed. > Under which conditions is it compressed? When calling gzip on it. >> In particular, when there is another org-loaddefs.el later on in the >> loadpath, it will happily load that file, creating just the very problem >> we were trying to avoid. > > That's why the user needs to add the correct load-path in his > .emacs.el when using a tarball or a git clone. I made it clear > in the docs. No, it will load the wrong file even if the load-path is correct. Try it if you don't believe me — gotta run now. 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] Fixes for org-capture-templates-contexts
Hi Paul, Paul Sexton writes: > org-capture-templates-contexts currently appears not to work. The structure > that the function 'org-contextualize-validate-key' expects to find in the > variable seems quite different from the structure described in the docstring. indeed, there are some bugs here -- thanks for looking into this, and I'm glad people use/test capture templates. May I ask you to send me two patches, one with the fix and one with the new feature(e)? Also, please don't use destructuring-bind, I'd rather not use cl.el functions. Thanks for the (renewed) effort if you can, otherwise just let me know and I'll fix things myself. Best, -- Bastien
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Achim Gratz writes: > Bastien writes: >> There is this line at the end of org-loaddefs.el: >> >> ;; no-byte-compile: t >> >> So my understanding is that org-loaddefs.el is never compressed. > > Byte-compiled != compressed. Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and not ".elc" files, right? My question is: when is it necessary? >> Under which conditions is it compressed? > > When calling gzip on it. Er... I'm not Spinoza, considering things "sub specie aeternitatis". I'm trying to consider real use-cases, with a sense of "real" close to "not so improbable". I don't see why Org should take care of users who are pervert enough to gzip their org-loaddefs.el... but maybe I lack imagination, as usual :) >>> In particular, when there is another org-loaddefs.el later on in the >>> loadpath, it will happily load that file, creating just the very problem >>> we were trying to avoid. >> >> That's why the user needs to add the correct load-path in his >> .emacs.el when using a tarball or a git clone. I made it clear >> in the docs. > > No, it will load the wrong file even if the load-path is correct. Try > it if you don't believe me — gotta run now. emacs -Q M-: (add-to-list 'load-path "~/git/org-mode/lisp") M-: (find-library "org") M-: (buffer-file-name) => "~/git/org-mode/lisp/org.el" emacs -Q M-: (add-to-list 'load-path "~/git/org-mode/lisp" t) M-: (find-library "org") M-: (buffer-file-name) => "/usr/local/share/emacs/24.3.50/lisp/org/org.el" But I know your answer, `find-library' does not give the library from which functions have been autoloaded. -- Bastien
[O] habits don't get re-scheduled (was: Inherited tags not visible in agenda)
* Bastien wrote: > Hi Karl, Hi! > Karl Voit writes: > >> What is my problem that prevents inherited tags being visible in my >> agenda? > > Please pull again -- I restored the default behavior. > > I'm a bit on a headache, so perhaps I've lost myself in the > possibilities, and forgot to handle a case. If that's so just > let me know! Inherited tags now visible again at my agenda. Thank you very much! Another strange issue that I recognized today though: my habits do not work any more: Whenever I mark an habit as DONE, it does not get re-scheduled as is was before your recent changes. A CLOSED time-stamp is added instead. Is there something I overlooked in the list of changes that I have to adopt or do I face a bug? Before marking as done: *** TODO do this :reward:lp: SCHEDULED: <2013-01-08 Tue .+1m -0d> :LOGBOOK: - State "DONE" from "TODO" [2012-12-31 Mon 12:42] :END: :PROPERTIES: :STYLE: habit :LAST_REPEAT: [2011-11-17 Thu 20:41] :END: after marking as done: *** TODO do this :reward:lp: CLOSED: [2013-01-11 Fri 18:45] SCHEDULED: <2013-01-08 Tue .+1m -0d> :LOGBOOK: - State "DONE" from "TODO" [2013-01-11 Fri 18:45] - State "DONE" from "TODO" [2012-12-31 Mon 12:42] :END: :PROPERTIES: :STYLE: habit :LAST_REPEAT: [2011-11-17 Thu 20:41] :END: Headache? :-( Get well soon :-) -- Karl Voit
[O] mobileorg and encryption
I have the following in emacs config: (setq org-mobile-use-encryption t) (setq org-mobile-encryption-password "password") I installed android privacy guard on the phone, and can verify that staged files are encrypted... but I don't see how to decrypt in the app. The documentation states (https://github.com/matburt/mobileorg-android/wiki): - Decrypting encrypted org files via integration with Android Privacy Guard. Encrypted files must end in one of three file extensions: gpg, enc, or pgp. - But doesn't this imply that org-mode needs to change the file extensions from .org to .gpg when staging the files? Mine still end in .org, but are indeed encrypted. Or do I need to change my actual org files in my main computer repository to be .gpg's as well and this will result in staged files having .gpg extensions? Thanks, John
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Bastien writes: > Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and > not ".elc" files, right? My question is: when is it necessary? The 'mustsuffix argument prevents consideration of the filename without the extensions listed in load-suffixes. In other words, when you are trying to load feature 'x, a file named just "x" does not satisfy the requirement as it otherwise would. On the other hand, it does not prevent using "x.el.gz" instead of "x.el" as 'nosuffix does. > I'm trying to consider real use-cases, with a sense of "real" close to > "not so improbable". I don't see why Org should take care of users > who are pervert enough to gzip their org-loaddefs.el... but maybe I > lack imagination, as usual :) This is a real use case. Installation with compression is a standard feature of Emacs and just currently not supported by the build system, mainly due to "little" problems like the above. Emacs' current installer itself compresses the source files only when there's a byte-compiled file around, so any recent Emacs would automatically have a file "org-loaddefs.el" in load-path, although some packagers have their own ideas about this. You should generally expect that the installed files, whether sources or byte-compiled files could have been compressed. Now if someone decides to compress the lisp folder for their own org installation and aren't taking care to exclude the autoload files, then this is what they get from 'emacs -Q": --8<---cut here---start->8--- (require 'find-func) => find-func (find-library-name "org-loaddefs.el") => "/usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el" (add-to-list 'load-path "~/lisp/org-mode/lisp") => (~/lisp/org-mode/lisp …) (find-library-name "org-loaddefs.el") "/home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz" (load "org-loaddefs.el" t nil t) => Loading /usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el (source)...done --8<---cut here---end--->8--- This is decidedly not what you wanted to achieve and outright devious, given that you don't even get the hint from *Messages* what file actually got loaded when the second argument to load is also "t". --8<---cut here---start->8--- (require 'org-macs) (let ((load-suffixes (list ".el"))) (org-load-noerror-mustsuffix "org-loaddefs")) => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz... => uncompressing org-loaddefs.el.gz...done => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...done --8<---cut here---end--->8--- This on the other hand is what was intended to happen. The problem is that for the previous discussion "(require 'org-macs)" was effectively a NOP because 'org-macs was already loaded from a different place. If you want to fix it, then that's where the effort should be directed (org-reload already does that and it's not difficult to do here either). […] > But I know your answer, `find-library' does not give the library from > which functions have been autoloaded. I might harp too much about this, but it's not the answer to this question. But see above how find-library can fool you when you are actually using load with optional arguments instead. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
[O] bug#10125: RFE: require and load-path-shadowing
Stefan Monnier writes: >>> I guess we could fork Emacs early on and keep this second process >>> around as a "process from which to generate new clean slates". >> I've been thinking about something like this for a while… if it worked >> at least as well as starting a new Emacs instance on all platforms, I'd >> favor this approach. > > IIUC "fork" is not really an option for w32. For the intended application spawn should work as well? > Yes, this subroutine is never directly called from C, so placing an > advice should work just fine. OK, I'll give it a try. >> As long as the package is properly namespaced, why not allow for >> removing all definitions pertaining to that entire namespace (features, >> autoloads, definitions, …)? > > We could try that, as well, but it would only work for those packages > that are "properly namespaced" (and there's no way to detect that > AFAIK). True, but a package might indicate if it is "one of those" and get the appropriate treatment from package manager. > Along the same lines, we could try to use unload-feature. I thought this was potentially dangerous, but reading the docstring again maybe not. Let me try that as well. 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
Re: [O] mobileorg and encryption
John Hendy writes: > I installed android privacy guard on the phone, and can verify that > staged files are encrypted... but I don't see how to decrypt in the > app. The documentation states > (https://github.com/matburt/mobileorg-android/wiki): > - > Decrypting encrypted org files via integration with Android Privacy > Guard. Encrypted files must end in one of three file extensions: gpg, > enc, or pgp. Not what you asked, but in the iphone client, the files are encrypted in place with the same name, with no Gnupg/etc. used. It seems the android version is different, and I would think one would need to specify the flavor on the emacs side. pgpO6NcQoua_k.pgp Description: PGP signature
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Achim Gratz writes: > Bastien writes: >> Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and >> not ".elc" files, right? My question is: when is it necessary? > > The 'mustsuffix argument prevents consideration of the filename without > the extensions listed in load-suffixes. In other words, when you are > trying to load feature 'x, a file named just "x" does not satisfy the > requirement as it otherwise would. On the other hand, it does not > prevent using "x.el.gz" instead of "x.el" as 'nosuffix does. > >> I'm trying to consider real use-cases, with a sense of "real" close to >> "not so improbable". I don't see why Org should take care of users >> who are pervert enough to gzip their org-loaddefs.el... but maybe I >> lack imagination, as usual :) > > This is a real use case. Installation with compression is a standard > feature of Emacs and just currently not supported by the build system, > mainly due to "little" problems like the above. Emacs' current > installer itself compresses the source files only when there's a > byte-compiled file around, so any recent Emacs would automatically have > a file "org-loaddefs.el" in load-path, although some packagers have > their own ideas about this. You should generally expect that the > installed files, whether sources or byte-compiled files could have been > compressed. > > Now if someone decides to compress the lisp folder for their own org > installation and aren't taking care to exclude the autoload files, then > this is what they get from 'emacs -Q": > > --8<---cut here---start->8--- > (require 'find-func) > => find-func > (find-library-name "org-loaddefs.el") > => "/usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el" > (add-to-list 'load-path "~/lisp/org-mode/lisp") > => (~/lisp/org-mode/lisp …) > (find-library-name "org-loaddefs.el") > "/home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz" > (load "org-loaddefs.el" t nil t) > => Loading /usr/local/share/emacs/24.2/lisp/org/org-loaddefs.el > (source)...done > --8<---cut here---end--->8--- > > This is decidedly not what you wanted to achieve and outright devious, > given that you don't even get the hint from *Messages* what file > actually got loaded when the second argument to load is also "t". > > --8<---cut here---start->8--- > (require 'org-macs) > (let ((load-suffixes (list ".el"))) > (org-load-noerror-mustsuffix "org-loaddefs")) > => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz... > => uncompressing org-loaddefs.el.gz...done > => Loading /home/gratz/lisp/org-mode/lisp/org-loaddefs.el.gz...done > --8<---cut here---end--->8--- > > This on the other hand is what was intended to happen. > > The problem is that for the previous discussion "(require 'org-macs)" > was effectively a NOP because 'org-macs was already loaded from a > different place. If you want to fix it, then that's where the effort > should be directed (org-reload already does that and it's not difficult > to do here either). > > […] >> But I know your answer, `find-library' does not give the library from >> which functions have been autoloaded. > > I might harp too much about this, but it's not the answer to this > question. But see above how find-library can fool you when you are > actually using load with optional arguments instead. > These sounds like a Emacs-wide (or possibly find-library) issues, rather than anything specific to Org, outlining, agendas or plain text notes. Shouldn't this sort of discussion and development be taking place on emacs-dev and in non-org Emacs libraries. In my opinion the only reason to try to solve these issues in Org-mode proper is if we are testing out new functionality which will eventually be adopted by core Emacs. Otherwise I would argue that such development within Org-mode is a waste of Org-mode development time, effort and code complexity. At the least perhaps such load/require mechanisms should be extracted into a separate library with no Org-mode specific code. Then Org-mode could make use of these libraries, but so could other large systems distributed with Emacs but developed independently (e.g., gnus). Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Eric Schulte writes: > These sounds like a Emacs-wide (or possibly find-library) issues, rather > than anything specific to Org, outlining, agendas or plain text notes. > > Shouldn't this sort of discussion and development be taking place on > emacs-dev and in non-org Emacs libraries. I've already taken this problem to emacs-devel since it is indeed a general problem. > In my opinion the only reason to try to solve these issues in Org-mode > proper is if we are testing out new functionality which will eventually > be adopted by core Emacs. Otherwise I would argue that such development > within Org-mode is a waste of Org-mode development time, effort and code > complexity. I might still propose a workaround for Org since it is unlikely that Emacs 24.3 will already ship with an improved package manager and in any case older Emacsen would not have it. Also, Org is in a somewhat unique position right now, being both in Emacs' core and ELPA at the same time and this is what made the problem so highly visible (as I'm sure you're painfully aware of by now). > At the least perhaps such load/require mechanisms should be extracted > into a separate library with no Org-mode specific code. Then Org-mode > could make use of these libraries, but so could other large systems > distributed with Emacs but developed independently (e.g., gnus). Yes, the plan (yet to be fully developed) is to add some basic infrastructure to Emacs that an updated package manager can then use — or individual libraries if they desire to do this, although I'd be happy to leave it to package manager. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] org agenda extensions
sure, here it comes (attached to this mail). to try my example you need to evaluate the file test.el (also attached) and the following expression: (test-overriding-format "~/saved-attachments/test.org") after saving test.org (also attached) in folder ~/saved-attachments/ does this work for you? Bastien writes: > Hi Thomas, > > Thomas Alexander Gerds writes: > >> with the aim to show properties in custom match views, I have been >> experimenting with new variables: >> >> org-agenda-overriding-agenda-format >> org-agenda-property-list >> >> then, tweaking the function org-scan-tags this enables custom format for >> the agenda lines, optionally showing properties (without invoking >> org-columns). >> >> you can test this here > > Thanks for experimenting with this -- could you send your code as a > patch against current maint or master branch? > > That's easier for me to read/check/test... otherwise I'll have a look > later on next week at best. > > Thanks, -- Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics University of Copenhagen, Øster Farimagsgade 5, 1014 Copenhagen, Denmark Office: CSS-15.2.07 (Gamle Kommunehospital) tel: 35327914 (sec: 35327901) patch-agenda-overriding-format-org.el Description: application/emacs-lisp test.el Description: application/emacs-lisp ** a test entry :PROPERTIES: :filename: [[bla.txt]] :birthday: <2013-01-11 Fri> :END: ** another test entry :PROPERTIES: :filename: [[blub.txt]] :birthday: <2013-01-11 Fri 8:38> :END:
Re: [O] [PATCH] Introduce a new variable for x11idle
Hi Yasushi, Yasushi SHOJI writes: > Debian and other OSes already have a program called 'xprintidle', > which does the same thing as x11idle. It also handles the DPMS bug[1] > some version of X servers have. > > In order to use an alternative, introduce a customizable variable > 'org-clock-x11idle-program-name' to hold the actual command name. > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502226 Applied, thanks! -- Bastien
[O] bug#10125: RFE: require and load-path-shadowing
I guess we could fork Emacs early on and keep this second process around as a "process from which to generate new clean slates". >>> I've been thinking about something like this for a while… if it worked >>> at least as well as starting a new Emacs instance on all platforms, I'd >>> favor this approach. >> IIUC "fork" is not really an option for w32. > For the intended application spawn should work as well? Could be: depends on the precise semantics of spawn, which I don't know. >> Along the same lines, we could try to use unload-feature. > I thought this was potentially dangerous, but reading the docstring > again maybe not. Let me try that as well. It's fundamentally tricky just in the same way as your proposed "namespace cleanup": if you undefine a function that's still registered on some hook, process filter, ... you may get subsequent errors, some of which may render Emacs completely unusable. So it's risky to call unload-feature on a random package, but it's not too hard for a package to make sure it survives unload-feature. Tho currently, there are some significant shortcomings (IIRC there are cases where the package's autoloads aren't re-instated, for example). Stefan
[O] different color for calculated cells in tables
Hi, I would like to easily view which table cells are calculated, that is, which values would be overwritten if I updated the table (C-u C-u C-u C-c C-c) We can use a different cell background color (maybe with overlays?) for the automatic cells, and the normal one for „manual entry“ cells. This coloring would happen on load and after each table update; no need to do it in real time. A table example: | a |b | percent |m | multiple | |---+--+---+--+--| |15 | 112 | 16.80 |2 | 33.6 | | 2 | 15 | 0.30 | 2.1 | 0.63 | | 1.2 |7 | 0.08 | 12.5 | 1. | |---+--+---+--+--| | max%→ | 16.8 | 5.727 |1 |0 | #+TBLFM: $3=($1/100.0)*$2;%.2f::$5=$3*$4::@5$2=vmax(@-I$3..@I$3)::@5$3=vmean(@-I..@I)::@5$4=$3>5.2::@5$5=0 The „automatic“ cells (and thus highlighted) would be: 16.80, 33.6, 0.30, 0.63, 0.08, 1, 16.8, 5.727, 1, 0. But I had to look at the TBLFM to find it, and that's not easy. This is an idea, but the code's missing. A similar code exists for cell highlighting from the formula editor window (C-c '); this would help. Any comments on the difficulty of this? Daniel
Re: [O] [New exporter] org-export-latex-verbatim-wrap
Hello,
Ista Zahn writes:
> Does the new exporter have any equivalent of
> org-export-latex-verbatim-wrap? I've looked but don't see anything.
> How can I format verbatim output when using the new exporter?
Add a filter to `org-export-filter-fixed-width-functions'. E.g.:
#+begin_src emacs-lisp
(defun my-latex-fixed-width-filter (fixed-width backend info)
(when (org-export-derived-backend-p backend 'e-latex)
(replace-regexp-in-string
"\\(begin\\|end\\){\\(verbatim\\)}"
"something" fixed-width nil nil 2)))
(add-to-list 'org-export-filter-fixed-width-functions
'my-latex-fixed-width-filter)
#+end_src
Regards,
--
Nicolas Goaziou
Re: [O] [BUG]HTML export convert line-break into a space
Hi Bastien, Thanks! That would be great! -- Rocky Zhang >Hi Rocky, > >163(rockyzhz) writes: > >> This result is natural and good in English, but in Chinese >> these is NOT any space among words typically, the extra space >> converted from line-break would seem weird and somewhat ugly. >> >> So could you provide an option for Chinese to avoid the extra space? > >This is not feasible with the current exporter. > >But we might do this with the exporter for 8.0, I'll add >this on my TODO list. > >Thanks, > >-- > Bastien >
Re: [O] org bingo
updated. thanks guys and gals :) https://gist.github.com/4343164 tony day tonyday...@gmail.com On 7 Jan 2013, at 18:16, Achim Gratz wrote: > Yasushi SHOJI writes: >> + (org-agenda-buffer (if (buffer-live-p org-agenda-buffer) >> + org-agenda-buffer)) > --^ > > This should be a "when" form since there's no else clause. > > > 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] emacs initialization files in org mode
On 7 Jan 2013, at 04:41, Alan Schmitt wrote: > The bare minimum one can do is: > - rename the current init.el into myinit.org > - add the lines "#+begin_src emacs-lisp" as the first line, and > "+end_src" as the last line > - adapt the init.el from emacs-starter-kit as follows > #+BEGIN_SRC emacs-lisp > (add-hook 'after-init-hook > `(lambda () >;; remember this directory >(setq emacsd-dir > ,(file-name-directory (or load-file-name (buffer-file-name >;; load up the starter kit >(require 'org) >(org-babel-load-file (expand-file-name "myinit.org" emacsd-dir > #+END_SRC > When emacs boots its expectations for an init.el are hardwired in. It doesn't know about org-mode goodness yet. So my minimum init.el is: #+Begin_src emacs-lisp :tangle init.el :var tangled-in=(buffer-file-name) (setq user-emacs-directory (file-name-directory (or load-file-name user-emacs-directory "~/.emacs.d/"))) (defvar org-dir "site-lisp/org-mode/lisp" "location of the directory containing org-mode") (add-to-list 'load-path (expand-file-name org-dir user-emacs-directory)) (defvar dotemacs-org-file "dotemacs.org" "Name of the org file containing the main startup code") (if (boundp 'tangled-in) (setq dotemacs-org-file tangled-in)) (org-babel-load-file (expand-file-name dotemacs-org-file user-emacs-directory)) #+end_src And this has to be tangled before emacs loads or it will load the old version of init.el. It's a good idea to tell emacs straight away where your org directory is or you might end up with the nasty split org version hassle where half of org is the old emacs version and half is the shiny new repository. https://github.com/tonyday567/dotemacs.org for my messy orgish dot files, which are mostly orgified https://github.com/jwiegley/dot-emacs, or eric's orgified starter kit: https://github.com/eschulte/emacs24-starter-kit Tony
Re: [O] habits don't get re-scheduled
Hi Karl, Karl Voit writes: > Another strange issue that I recognized today though: my habits do > not work any more: Whenever I mark an habit as DONE, it does not get > re-scheduled as is was before your recent changes. A CLOSED > time-stamp is added instead. > > Is there something I overlooked in the list of changes that I have > to adopt or do I face a bug? I tried to reproduce the issue but couldn't ... perhaps I need more info from your config file? If you can go and bisect, that'd be great. Thanks! -- Bastien
Re: [O] different color for calculated cells in tables
Hi Daniel, Daniel Clemente writes: > This is an idea, but the code's missing. I agree this would be a nice feature. > Any comments on the difficulty of this? I'd say "quite difficult". :) -- Bastien
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Achim Gratz writes: > Bastien writes: >> Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and >> not ".elc" files, right? My question is: when is it necessary? > > The 'mustsuffix argument prevents consideration of the filename without > the extensions listed in load-suffixes. In other words, when you are > trying to load feature 'x, a file named just "x" does not satisfy the > requirement as it otherwise would. On the other hand, it does not > prevent using "x.el.gz" instead of "x.el" as 'nosuffix does. (load "org-loaddefs.el" t t t) will *not* load gzipped version of org-loaddefs.el. >> I'm trying to consider real use-cases, with a sense of "real" close to >> "not so improbable". I don't see why Org should take care of users >> who are pervert enough to gzip their org-loaddefs.el... but maybe I >> lack imagination, as usual :) > > This is a real use case. Installation with compression is a standard > feature of Emacs and just currently not supported by the build system, > mainly due to "little" problems like the above. Emacs' current > installer itself compresses the source files only when there's a > byte-compiled file around, so any recent Emacs would automatically have > a file "org-loaddefs.el" in load-path, although some packagers have > their own ideas about this. You should generally expect that the > installed files, whether sources or byte-compiled files could have been > compressed. Please point at one distribution that actually distributes gzipped autoloads files like loaddefs.el. > Now if someone decides to compress the lisp folder for their own org > installation Then we will tell him not to. Can we stop *imagining* people shouting themselves in the foot for free? I don't have time to build an hospital for them. -- Bastien
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Eric Schulte writes: > Shouldn't this sort of discussion and development be taking place on > emacs-dev and in non-org Emacs libraries. Yes, it does. -- Bastien
Re: [O] org agenda extensions
Hi Thomas, I've reviewed the proposed change. `org-scan-tags' already does many things beyond its name, because a "tag" here is really a "match", which can include properties -- see `org-make-tags-matcher' for how the "tags match" is built from properties). This is handy for tags view and `org-sparse-tree'. In agenda, we don't need to display the properties that are part of the tag match, as they are part of the agenda headline already. I don't think we should let the user add properties to the agenda lines this way, as (1) it would make the name `org-scan-tags' even more confusing and (2) it would probably slow down agenda creating a lot -- `org-scan-tags' is the bottleneck for speed here. Also, the whole purpose of `org-agenda-columns' is precisely to see properties in agenda, so I'd rather let the user interactively decide if he wants to take the extra mile (and time) or not. 'hope this sounds reasonable enough. And thanks anyway for this! -- Bastien
[O] About `org-insert-heading' in Org's manual
In (info "(org) Plain lists"): `M-' (`org-insert-heading') Insert new item at current level. With a prefix argument, force a new heading (*note Structure editing::). If this command is used in the middle of an item, that item is _split_ in two, and the second part becomes the new item(7). If this command is executed _before item's body_, the new item is created _before_ the current one. Why is `before item's body' emphasized? As far as I'm concerned, only `before' should be emphasized. BTW, why is the node name `Plain lists'? In Emacs manuals, all the node name are made of capitalized words, for example: (info "(emacs) Saving Emacs Sessions") (info "(elisp) Syntax Tables") (info "(widget) Widget Wishlist") ... -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] org agenda extensions
Hi Bastien thanks for looking into this! I understand your general point of view. however, the proposed changes would only slow down agenda creating if org-agenda-property-list is set, right? also, it certainly requires some insights to write org-agenda-overriding-agenda-format which could display non-special properties. hence only a user who knows what she/he is doing would run into this problem. anyway, could you propose a different approach to get this extension? I could write a new function org-scan-properties, but that would require several changes in org-agenda ... thanks again, Thomas ps: one limitation of org-agenda-columns seems to be that columns cannot be activated in two different agenda buffers simulaneously. Bastien writes: > Hi Thomas, > > I've reviewed the proposed change. > > `org-scan-tags' already does many things beyond its name, because > a "tag" here is really a "match", which can include properties -- > see `org-make-tags-matcher' for how the "tags match" is built from > properties). > > This is handy for tags view and `org-sparse-tree'. > > In agenda, we don't need to display the properties that are part of > the tag match, as they are part of the agenda headline already. > > I don't think we should let the user add properties to the agenda > lines this way, as (1) it would make the name `org-scan-tags' even > more confusing and (2) it would probably slow down agenda creating > a lot -- `org-scan-tags' is the bottleneck for speed here. > > Also, the whole purpose of `org-agenda-columns' is precisely to see > properties in agenda, so I'd rather let the user interactively decide > if he wants to take the extra mile (and time) or not. > > 'hope this sounds reasonable enough. > > And thanks anyway for this! -- Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics University of Copenhagen, Øster Farimagsgade 5, 1014 Copenhagen, Denmark Office: CSS-15.2.07 (Gamle Kommunehospital) tel: 35327914 (sec: 35327901)
Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b
Bastien writes: > (load "org-loaddefs.el" t t t) will *not* load gzipped version of > org-loaddefs.el. That's what I was trying to tell you and I consider that a bug. > Please point at one distribution that actually distributes gzipped > autoloads files like loaddefs.el. Why should I? People have been recusively compressing their lisp folders for years. It's supposed to work and it does, why do you need to break it? >> Now if someone decides to compress the lisp folder for their own org >> installation > > Then we will tell him not to. > > Can we stop *imagining* people shouting themselves in the foot for > free? I don't have time to build an hospital for them. It is not at all illegal to do this, so we shouldn't be putting out code that actively prevents this option. That Emacs currently doesn't do this has different reasons and looking at the code Emacs uses makes it abundantly clear that they've gone to great lengths to enable this for all files. Currently it usually is faster to read non-compressed files from disk if they aren't larger than a single allocation unit of the underlying file system (which is why the files Emacs uses most often, that is .elc files and autoloads are kept uncompressed), but there are situations were there is a clear advantage of using compression and there are also situations where compressing _all_ files is the only thing left to do. 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/Downloads.html#KorgSDada
