Re: [O] org-insert-heading rewritten from scratch
Hi Nicolas, On 31.8.2013, at 16:34, Nicolas Goaziou wrote: > Hello, > > Carsten Dominik writes: > >> On 8.8.2013, at 09:41, Eric Abrahamsen wrote: >> >>> Carsten Dominik writes: >>> Hi, I have rewritten org-insert-heading, because it had become an unmaintainable beast. Please follow up in this thread if you find problems with the new implementation. Very likely there will be bugs, but now I am at least confident they can be fixed. - Carsten >>> >>> Awesome! Thanks very much for doing this. Will report back with bugs. >> >> I take it none have been found? > > Not really a bug, but I find some behaviour surprising: when at a the > beginning of a regular text line, there is no way to create a headline > just above it. In the following example: > > XCursor is at "X" > > Neither M-RET, C-u M-RET, C-RET nor C-u C-RET can do it. Is it intended? Which behavior would you propose? I guess you mean that, at the beginning of a line, the result is so different for normal lines versus headlines? The way I was thinking about the behavior at the beginning of a non-headline is that it is the same as in the middle of a line: Take the rest of the line and turn it into a headline. To create a headline before a nonempty line, I use `C-o M-RET' To be sure: I am happy to change the behavior if that is what people want and if it makes logically sense. > Also in this case, I think C-RET should create the new headline _after_ > the subtree, since that's its whole point anyway, AFAIU. That is what happens for me. It does not for you? > > Eventually, it seems that behaviour towards empty lines is a bit > unpredictable. In the following example, M-RET will be behave > differently on each blank line between Paragraph and "H2". C-RET will be > consistent. Because it does what M-RET does in the last line of the subtree. > Note: I have `auto' as value for `heading' key in > `org-blank-before-new-entry'. > > * H1 > >Paragraph > > > > * H2 Hmm, I do find this behavior consistent. M-RET does not change the number of while lines after the current, only before, in order to either have an empty line or not. Which behavior would you propose? > > IMO, using M-RET and C-RET should be as smooth an experience as > possible. I fully agree. > > I also suggest to write function specifications as tests in test-org.el. Yes, I have yet to write my first test. Need to figure out how that works. - Carsten
Re: [O] org-insert-heading rewritten from scratch
Clarification: it is no more slow than the original and it fixes bugs. Just answering your question about whether there are any bugs. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] org-insert-heading rewritten from scratch
I've found four, but they are minor. In capture, you can create a blank line with m-ret at the top．Repeated invocation creates invalid headlines. There is no c-ret way to create a headline above the first child. M-ret is slow. On 8/31/13, Carsten Dominik wrote: > I take it none have been found? -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] org-insert-heading rewritten from scratch
Carsten Dominik writes: > On 8.8.2013, at 09:41, Eric Abrahamsen wrote: > >> Carsten Dominik writes: >> >>> Hi, >>> >>> I have rewritten org-insert-heading, because it had become an >>> unmaintainable beast. >>> Please follow up in this thread if you find problems with the new >>> implementation. >>> Very likely there will be bugs, but now I am at least confident they can be >>> fixed. >>> >>> - Carsten >> >> Awesome! Thanks very much for doing this. Will report back with bugs. > > I take it none have been found? > > - Carsten > Nope, I've been using this heavily and haven't seen anything surprising. I do confirm Nicolas' observations on whitespace, though... E
[O] Bug [w/patch]: TODO blocking doesn't work across files with different TODO keyword sets
Hi list, Some of my agenda files use custom TODO keywords (set through a #+SETUPFILE), and some use the standard TODO | DONE keywords. I recently discovered that TODO blocking is broken in the files which use custom keywords. It turns out the org-not-done-heading-regexps variable was global instead of buffer-local like the other *-regexp variables; this appears to be due to a typo in org.el. I think the blocker hook (org-block-todo-from-children-or-siblings-or-parent) was picking up the global value (set by one of the "factory-default" buffers, which got opened last) and applying it to buffers with my custom TODO keywords, so it was not correctly identifying some headlines as TODO headlines. The patch below corrects the typo and fixes TODO blocking in my custom-keyword files. I hope you find it useful. (BTW, I quickly ran through the other make-variable-buffer-local invocations in org.el, and didn't see any more typos of this nature.) Thanks, Josh diff --git a/lisp/org.el b/lisp/org.el index 97b5365..985dd74 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4602,7 +4602,7 @@ Otherwise, these types are allowed: (make-variable-buffer-local 'org-not-done-regexp) (defvar org-not-done-heading-regexp nil "Matches a TODO headline that is not done.") -(make-variable-buffer-local 'org-not-done-regexp) +(make-variable-buffer-local 'org-not-done-heading-regexp) (defvar org-todo-line-regexp nil "Matches a headline and puts TODO state into group 2 if present.") (make-variable-buffer-local 'org-todo-line-regexp)
[O] [bug] orgtbl-mode conflicts with ecomplete (a address completion of mesaage mode)
Dear org-mode Developers,
i followed the advice in the org-mode manual to use orgtbl-mode
in message-mode buffers (see: (info "(org)Orgtbl mode") or
[[info:org#Orgtbl%20mode][info:org#Orgtbl mode]] ), this is nice.
Since today i also want to use "ecompletion" for addresses in
email headers in message-mode as described in
(info "(message)Mail Aliases") or
[[info:message#Mail%20Aliases][info:message#Mail Aliases]].
Sadly orgtbl-mode somehow disables ecomplete. Without
orgtbl-mode if one types a part of an email address in an address
header line ecomplete shows list of possible addresses which is
shrinking while one types. This does not happen if orgtbl-mode
is enabled.
How to reproduce:
1) save the attached file to ~/.ecompleterc
be sure not to overwrite your own ~/.ecompleterc!
2) do
emacs -q -nw --eval "(setq message-mail-alias-type 'ecomplete)" --eval
'(message-mail)'
cursor is in the To: -address header.
2a) type "e"
minibuffer shows three matching addresses. These are narrowed
down while you type "c" "h" "o". You might chosse one of the
matching addresses with M-n RET.
2b) kill Emacs.
3) do instead:
emacs -q -nw --eval "(setq message-mail-alias-type 'ecomplete)" --eval
"(add-hook 'message-mode-hook 'turn-on-orgtbl)" --eval '(message-mail)'
cursor is in the To: -address header.
3a) type "e"
minimuffer shows nothing...
3b) kill Emacs.
It would be great if this conflict could be fixed. Otherwise the
conflict could be documented in the Conflicts section of Org-mode
(info "(org)Conflicts") or [[info:org#Conflicts]] like this:
--- org.texi2013-09-01 00:41:15.125828086 +0200
+++ org.texi-Orgtbl-ecomplete-conflict-documented 2013-09-01
00:40:56.101430317 +0200
@@ -16414,6 +16414,18 @@
to have other replacement keys, look at the variable
@code{org-disputed-keys}.
+@item @file{ecomplete.el} by Lars Magne Ingebrigtsen @email{larsi@@gnus.org}
+@cindex @file{ecomplete.el}
+
+Ecomplete provides ``electric'' address completion in address header
+lines in message buffers. Sadly Orgtbl mode cuts ecompletes power
+supply: No completion happens when Orgtbl mode is enabled in message
+buffers while entering text in address header lines. If one wants to
+use ecomplete one should @emph{not} follow the advice to automagically
+turn on Orgtbl mode in message buffers (see @ref{Orgtbl mode}), but
+instead---after filling in the message headers---turn on Orgtbl mode
+manually when needed in the messages body.
+
@item @file{filladapt.el} by Kyle Jones
@cindex @file{filladapt.el}
Thanks for your attention, Gregor
((mail
("e...@tu-berlin.de" 1 1377964945.0 "Echo ")
("telegr...@gmx.net" 6 1377974143.0 "Gregor Zattler ")
("emacs-orgmode@gnu.org" 6 1377974143.0 "Org-mode mailing list
")
))
[O] Trouble with org-icalendar-combine-agenda-files
Since August 17, I have not been able to create a combined icalendar file. I can create single file withe C-c C-e c f. I can create multiple files with C-c C-e c a. But when I try C-c C-e c c, the process starts to save temp files and quietly dies. Output in messages looks like this: Saving file /tmp/orgics5457fkf... Wrote /tmp/orgics5457fkf (New file) Saving file /tmp/orgics5457sul... Wrote /tmp/orgics5457sul When I enable the debugger in options it does not trip when the process dies. There is an icalendar-errors buffer, but it is empty. I am using the following version of emacs on Debian Wheezy GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2013-08-22 on gkar, modified by Debian My org-mode version is as follows: Org-mode version 8.0.7 (release_8.0.7-415-g32bd54.dirty @ /home/billday/elisp/org-mode/lisp/) Any help or advice would be much appreciated. -- Bill Day williamson@gmail.com
[O] clocktable column order e.g. :properties at rightmost position?
Is there a way to configure column order in clocktable output? I have a
workable way to display TAGS now for clocked task now, but the width of
multiply-tagged items will make the clocktable output less usable. I'd
prefer to move it over to the right-most position:
: #+BEGIN: clocktable :maxlevel 2 :scope file :emphasize nil :block today
: :link nil :indent nil :properties ("TAGS")
: #+CAPTION: Clock summary at [2013-08-31 Sat 09:25],
:for Saturday, August 31, 2013.
: | TAGS | Headline | Time | |
: |---+++--|
: | | *Total time* | *1:05* | |
: |---+++--|
: | | <2013-08-31 Sat> | 1:05 | |
: | | TODO db query test || 0:18 |
: | | TODO time-tracking-tools || 0:26 |
: | :foo:bar: | DONE jsmith re: new idea || 0:15 |
: | :bar: | DONE article attack driven defense... || 0:06 |
: #+END:
The option:
: :formatter A function to format clock data and insert into the buffer.
sounds promising if it could advise the existing function without
reimplementing large parts of it. I'm searching for :formatter
documentation and examples, haven't found any direct references yet.
Secondary question: with the today and yesterday tracking clocktables
I'm using, can I configure formatting of the string:
"for Saturday, August 31, 2013." as a normal org timestamp:
"for [2013-08-31 Sat]."?
Thanks,
Jeff
Re: [O] #+CALL and remote execution
Kel Chan writes: > Hi list, > > I'm implementing an executable worksheet in org and wonder if I can call a > source block with a :dir arguments. > > It doesn't seem orgmode support this out of the box. I tried #+CALL: > ping-network()[:results values replace :dir /posiadmin@10.161.25.37:] > and noticed two problems: the :dir argument was ignored and only the > first row of output was shown in #+RESULT block. > > any ideas for workarounds? > Indeed it is possible to pass the :dir header argument through a call line. See the description of call line syntax in the manual. #+name: where #+begin_src sh pwd #+end_src #+RESULTS: where : /tmp Call the above from somewhere else. #+call: where[:dir /]() #+RESULTS: : / Cheers, > > cheers, > kel > -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] odt export version conflict on emacs for mac os x
Christian Moe writes: > Could you give a pointer to your code? I'd like to try it. Here it is again: --8<---cut here---start->8--- ;; ;; Kill any old org remnants ;; ;; clean load-path (setq load-path (delq nil (mapcar (function (lambda (p) (unless (string-match "lisp/org$" p) p))) load-path))) ;; remove property lists to defeat cus-load and remove autoloads (mapatoms (function (lambda (s) (let ((sn (symbol-name s))) (when (string-match "^\\(org\\|ob\\|ox\\)-?" sn) (setplist s nil) (when (autoloadp s) (unintern s))) --8<---cut here---end--->8--- After this Emacs should behave like it had never heard of Org at all. As I said, use at your own risk - the intention is to do this as early as possible, before any other initializations have taken place so that these then can set up Org on a clean slate. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [BUG] hline handling in ob-ruby
Sorry about the delay in replying, apparently gmail has decided to redirect large chunks of the Org-mode mailing list into my spam folder. Perhaps it would be better to not use my @gmx account in the future. Please do go ahead and apply this patch. Thanks for porting this solution over from ob-python, and sorry again about the delay! Rick Frankel writes: > Eric- > > There is a bug in ob-ruby --- if an literal 'hline is passed into > (e.g., :hline no) a ruby block, the execution fails due to an > incorrect datatype (this is not an issue in any other language). The > patch provided in > http://lists.gnu.org/archive/html/emacs-orgmode/2013-08/msg00316.html > (and reattached here), applies the solution used in ox-python to > handle the issue. An alternative solution is ok too :). > > I would be glad to apply the patch myself, but since you are the owner > of the file i would appreciate you ok before proceeding. > > tia, > rick > > From 4ae86a04680bcf671d43bb0b70bfddd083b743b2 Mon Sep 17 00:00:00 2001 > From: Rick Frankel > Date: Thu, 15 Aug 2013 14:43:51 -0400 > Subject: [PATCH] Handle literal 'hline arguments passed to ruby. Solution > shamelessly copied from ob-python. > > * lisp/ob-ruby.el: New customizations `org-babel-ruby-hline-to' and > `org-babel-ruby-nil-to' > (org-babel-ruby-var-to-ruby): Convert incoming 'hlines. > (org-babel-ruby-table-or-string): Convert outgoing nils. > --- > lisp/ob-ruby.el | 26 -- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el > index 20fb418..d15d288 100644 > --- a/lisp/ob-ruby.el > +++ b/lisp/ob-ruby.el > @@ -50,6 +50,20 @@ > (defvar org-babel-ruby-command "ruby" >"Name of command to use for executing ruby code.") > > +(defcustom org-babel-ruby-hline-to "nil" > + "Replace hlines in incoming tables with this when translating to ruby." > + :group 'org-babel > + :version "24.4" > + :package-version '(Org . "8.0") > + :type 'string) > + > +(defcustom org-babel-ruby-nil-to 'hline > + "Replace 'nil' in ruby tables with this before returning." > + :group 'org-babel > + :version "24.4" > + :package-version '(Org . "8.0") > + :type 'string) > + > (defun org-babel-execute:ruby (body params) >"Execute a block of Ruby code with Babel. > This function is called by `org-babel-execute-src-block'." > @@ -115,13 +129,21 @@ Convert an elisp value into a string of ruby source code > specifying a variable of the same value." >(if (listp var) >(concat "[" (mapconcat #'org-babel-ruby-var-to-ruby var ", ") "]") > -(format "%S" var))) > +(if (equal var 'hline) > + org-babel-ruby-hline-to > + (format "%S" var > > (defun org-babel-ruby-table-or-string (results) >"Convert RESULTS into an appropriate elisp value. > If RESULTS look like a table, then convert them into an > Emacs-lisp table, otherwise return the results as a string." > - (org-babel-script-escape results)) > + ((lambda (res) > + (if (listp res) > + (mapcar (lambda (el) (if (equal el 'nil) > + org-babel-ruby-nil-to el)) > + res) > + res)) > + (org-babel-script-escape results))) > > (defun org-babel-ruby-initiate-session (&optional session params) >"Initiate a ruby session. -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Some orgtbl doc issues
Well clearly the radio tables section reads better now. Further comments inline. Before that some general comments. The Python list thread starting here http://mail.python.org/pipermail/python-list/2013-July/653164.html As you will see some python programmers (including emacsers!) seem to have a need for something like this and dont seem to know about org. And by extension one may assume other languages than python also. In short this seems to be a general need. So what is written below should be taken less from my own pov -- I am hardly an org power-user but still a user -- than from the pov of a general emacser -- a programmer who uses emacs and knows next to nothing about org On Fri, Aug 30, 2013 at 10:16 PM, Carsten Dominik wrote: > Hi Rustom, > > thanks for this. > > On 16.8.2013, at 16:30, Rustom Mody wrote: > > > Ive recently been poking around in orgtbl mode and encountered some > > issues. Not sure how much is my own lack of understanding and how > > much there are some little doc issues. > > > > 1 Option names dont match > > = > > > > - Its orgtbl-radio-table-templates in emacs > > - Its orgtbl-radio-tables in doc Appendix A.6.2 > > Fixed, thanks. > > > > > > > 2 Receiving string > > == > > > > - Seems to be "RECEIVE ORGTBL" > > It is BEGIN RECEIVE ORGTBL followed by a table name. As the example in > the manual shows. Does this have to be more explicit? > > > - String seems to be hardwired. Which may be ok if its by design. > > Yes, hardwired by design. > Not a problem in itself. It becomes a problem in connection with the dfault value of org-radio-table-templates which contains many instances of BEGIN RECEIVE ORGTBL %n and thereby suggests that that is changeable > > - Not clear what is the relation of this string and > >orgtbl-radio-templates > > The templates insert a BEGIN RECEIVE/END RECEIVE table template with > *proper commenting* around it in different programming modes. > I improved this in the docs. > > > - I find 1 space is fixed between RECEIVE and ORGTBL. Multiple > > allowed between ORGTBL and table-name > > OK, I have removed this restriction. > > > - Its not clear from the doc whether its "RECEIVE ORGTBL" or > > "/* RECEIVE ORGTBL" > > That depends on the programming mode. The documentation says that the > lines must be comments in the current mode, I would think that this is > clear enough. > Some languages (eg Python) have no multiline comment but have a multiline string which is also ok to use > > > - Subtle interaction between # in org and host mode comment char -- # > >in python, shell etc -- could do with some elaboration > > Can you propose something for the documentation? > > > > > > > 3 hook system > > = > > > > - What are the hooks for orgtbl? > > - How do the org hooks relate to the orgtbl hooks? > > - Note: orgtbl is for those who are not otherwise using orgmode > > What to you mean? Mode hooks, or hooks for specific functionality of the > table? If table commands run hooks, the corresponding orgtbl commands will > do so as well, because they simply call the table functions in an > environment where the proper keys bindings are not accessible. > As I said at start of this mail, we are looking at orgtbl for otherwise non-org users. For that audience I was exploring whether vanilla org would work OTB ie without any of my org-settings also not the latest but one bundled with emacs Since at that point I really could not understand orgtbl-radio-table-templates and thought it had to be set I asked. As it appears now, it works without any customization so the point is moot. Nevertheless the general question is: If a non-org user of orgtbl needs to set up minor-mode specific customization where is it to be done? > orgtbl-mode is a standard minor mode and has `orgtbl-mode-hook', similar > to all other minor modes. See the documentation of define-minor-mode. Do > you feel the manual should say so? It does not document many other hooks > in org either, because there are too many. > > > > > > 4 Long header line > > == > > > > I could not figure out how to split a long > > :#+ORGTBL: SEND... line > > It cannot be split. > There are programming related organizations for which something like 80-char lines is really not negotiable! So I hope this can be considered as a feature request of course a very minor one Regards > > - Carsten > Speaking generally, maybe someone should respond to that python list thread. It can be me however someone more org-knowledgeable may be more appropriate :-) Thanks and regards Rusi -- http://blog.languager.org
[O] [patch] Remove dependency on latexsym (was: [patch][org-entities] More symbols)
Hi,
> Nicolas Goaziou writes:
>
> As a rule of thumb, I think we should avoid requiring new packages for
> org-entities.
It's easy to remove the decency of latexsym as it only defines a very
limited number of symbols (see texdoc latexsym). Using amssymb
symbols will even look better IMO, but check this document:
#+BEGIN_SRC Org
#+latex:\Huge
- [ ] x
- [-] x
- [X] x
#+begin_latex
\begin{itemize}
\item $\square$ x
\item $\boxminus$ x
\item $\boxtimes$ x
\end{itemize}
#+end_latex
#+END_SRC
Obviously, it requires the removal of Diamond (my entity patch) and
Box (this patch)
–Rasmus
>From 613f28f3bc5d2a6e35093b0a6f33d9b6ec393458 Mon Sep 17 00:00:00 2001
From: rasmus
Date: Sat, 31 Aug 2013 18:15:12 +0200
Subject: [PATCH 2/2] Remove dependency on latexsym.
* ox-latex.el (org-latex-item): Use square as unchecked symbol.
* org.el (org-latex-default-packages-alist): Remove latexsym.
Use amssymb symbols to reduce required packages.
---
lisp/org.el | 5 ++---
lisp/ox-latex.el | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 572b797..90fdfee 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3832,7 +3832,6 @@ header, or they will be appended."
("" "textcomp" t)
("" "marvosym" t)
("" "wasysym" t)
-("" "latexsym" t)
("" "amssymb" t)
("" "amstext" nil)
("" "hyperref" nil)
@@ -3847,7 +3846,7 @@ Org mode to function properly:
- inputenc, fontenc: for basic font and character selection
- amstext: for subscript and superscript
-- textcomp, marvosymb, wasysym, latexsym, amssym: for various
+- textcomp, marvosymb, wasysym, amssymb: for various
symbols used for interpreting the entities in `org-entities'.
You can skip some of these packages if you don't use any of the
symbols in it.
@@ -7653,7 +7652,7 @@ This is important for non-interactive uses of the command."
(t
(goto-char (point-at-eol))
(insert "\n")))
-
+
;; Insert the new heading
(insert stars)
(just-one-space)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 1fe918a..e1173ef 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1561,7 +1561,7 @@ contextual information."
(1- count)
(checkbox (case (org-element-property :checkbox item)
(on "$\\boxtimes$ ")
- (off "$\\Box$ ")
+ (off "$\\square$ ")
(trans "$\\boxminus$ ")))
(tag (let ((tag (org-element-property :tag item)))
;; Check-boxes must belong to the tag.
--
1.8.4
--
If you can mix business and politics wonderful things can happen!
Re: [O] koma letter exporter: changing the priority of options
Hi Alan, Alan Schmitt writes: >>> I tried to fix it in the updated attached patch. I set a default value >>> of "foldmarks-not-set" to the predicate that detects if it is set in the >>> file, then I compare its contents. This assumes that the user will not >>> give this literal value to the option. >> >> The attached version is updated to apply cleanly on master (after >> applying your other patches). > > I've pushed this. Please don't hesitate to send suggestions to improve > it, or report if it does not work as expected. Great, it'll serve for now. It shouldn't case any breaks. –Rasmus -- C is for Cookie
Re: [O] [patch][org-entities] More symbols
Nicolas Goaziou writes:
>> 2. HTML symbols have been tested in Firefox. In a few cases I
>>couldn't find a pretty name (like "π") in which case I've
>>supplied the unicode number (like "&960;"). Is that OK? (E.g. can
>>Org produce non-uft8 HTML?)
>
> I think it can: see `org-html-coding-system'. It may be wiser to avoid
> these symbols altogether.
OK. The only ones remaining are
("smiley" "\\smiley{}" nil "☺" ":-)" ":-)" "☺")
("blacksmile" "\\blacksmiley{}" nil "☻" ":-)" ":-)" "☻")
("sad" "\\frownie{}" nil "☹" ":-(" ":-(" "☹")
> Any additional package needed must be added to
> `org-latex-default-packages-alist', which means that the package will be
> loaded in every LaTeX export. So, this is clearly not OK for packages
> like "kpfonts".
OK, they should all work.
>> I also fixed some
>>inconsistencies. E.g. loz was loaded diamond even though loz is
>>defined in amssymb and "~" and "\tilde" produced different results
>>(the latter produces the irritating "\~{}" often observed among
>>(social science?) university professors...).
>
> Sounds good.
>> + ("preccurlyeq" "\\preccurlyeq" t "≼" "[precedes or equal]"
>> "[precedes or equal]" "≼")
>
> This one is LaTeX specific, it may be more appropriate in
> `org-entities-user'.
There are many X-specific entities. . . E.g. lArr is html specific.
One important feature of entities is that unicode symbols can be
displayed in buffer. If you feel strongly about it, I can remove
them.
–Rasmus
>From 17c722aab3e94db069884cb8dba1103ff7b6c9a9 Mon Sep 17 00:00:00 2001
From: rasmus
Date: Sun, 18 Aug 2013 17:42:33 +0200
Subject: [PATCH] More org-entities.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* org-entities.el (org-entities): Add support for ell, imath, jmath,
varphi, varpi, aleph, gimel, beth, dalet, cdots, S (§), dag, ddag,
colon, therefore, because, triangleq, leq, geq, lessgtr, lesseqgtr,
ll, lll, gg, ggg, prec, preceq, preccurleyeq, succ, succeq,
succurleyeq, setminus, nexist(s), mho, check, frown, diamond. Changes loz,
vert, checkmark, smile and tilde.
---
lisp/org-entities.el | 59
1 file changed, 50 insertions(+), 9 deletions(-)
diff --git a/lisp/org-entities.el b/lisp/org-entities.el
index a1519b0..638da78 100644
--- a/lisp/org-entities.el
+++ b/lisp/org-entities.el
@@ -154,6 +154,9 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
("real" "\\Re" t "ℜ" "R" "R" "ℜ")
("image" "\\Im" t "ℑ" "I" "I" "ℑ")
("weierp" "\\wp" t "℘" "P" "P" "℘")
+("ell" "\\ell" t "ℓ" "ell" "ell" "ℓ")
+("imath" "\\imath" t "ı" "[dotless i]" "dotless i" "ı")
+("jmath" "\\jmath" t "ȷ" "[dotless j]" "dotless j" "ȷ")
"** Greek"
("Alpha" "A" nil "Α" "Alpha" "Alpha" "Α")
@@ -203,6 +206,7 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
("upsilon" "\\upsilon" t "υ" "upsilon" "upsilon" "υ")
("Phi" "\\Phi" t "Φ" "Phi" "Phi" "Φ")
("phi" "\\phi" t "φ" "phi" "phi" "φ")
+("varphi" "\\varphi" t "ϕ" "varphi" "varphi" "ɸ")
("Chi" "X" nil "Χ" "Chi" "Chi" "Χ")
("chi" "\\chi" t "χ" "chi" "chi" "χ")
("acutex" "\\acute x" t "´x" "'x" "'x" "𝑥́")
@@ -212,10 +216,15 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
("Omega" "\\Omega" t "Ω" "Omega" "Omega" "Ω")
("omega" "\\omega" t "ω" "omega" "omega" "ω")
("piv" "\\varpi" t "ϖ" "omega-pi" "omega-pi" "ϖ")
+("varpi" "\\varpi" t "ϖ" "omega-pi" "omega-pi" "ϖ")
("partial" "\\partial" t "∂" "[partial differential]" "[partial differential]" "∂")
"** Hebrew"
("alefsym" "\\aleph" t "ℵ" "aleph" "aleph" "ℵ")
+("aleph" "\\aleph" t "ℵ" "aleph" "aleph" "ℵ")
+("gimel" "\\gimel" t "ℷ" "gimel" "gimel" "ℷ")
+("beth" "\\beth" t "ℶ" "beth" "beth" "ב")
+("dalet" "\\daleth" t "ℸ" "dalet" "dalet" "ד")
"** Dead languages"
("ETH" "\\DH{}" nil "Ð" "D" "Ð" "Ð")
@@ -226,6 +235,7 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
"* Punctuation"
"** Dots and Marks"
("dots" "\\dots{}" nil "…" "..." "..." "…")
+("cdots" "\\cdots{}" t "⋯" "..." "..." "⋯")
("hellip" "\\dots{}" nil "…" "..." "..." "…")
("middot" "\\textperiodcentered{}" nil "·" "." "·" "·")
("iexcl" "!`" nil "¡" "!" "¡" "¡")
@@ -253,20 +263,23 @@ packages to be loaded, add these packages to `org-latex-packages-alist'."
"* Other"
"** Misc. (often used)"
("circ" "\\^{}" nil "ˆ" "^" "^" "ˆ")
-("vert" "\\vert{}" t "|" "|" "|" "|")
+("vert" "\\vert{}" t "|" "|" "|" "|")
("brvbar" "\\textbrokenbar{}" nil "¦" "|" "¦" "¦")
+("S" "\\S" nil "§" "paragraph" "§" "§")
("sect" "\\S" nil "§" "paragraph" "§" "§")
("amp" "\\&" nil "&" "&" "&" "&")
("lt" "\\textless{}" nil "<" "<" "<" "<")
("gt" "\\textgreater{}" nil ">" ">" ">" ">")
-("tilde" "\\~{}" nil "˜" "~
Re: [O] [patch][ox-latex] context-aware subscript
Rasmus writes:
> What I do in the patch is that I apply the filters within the
> function
Why is that? `org-export-data' already takes care of filters. These
calls are redundant.
> Also, filters using a regexp with "\text{whatever}" wouldn't work.
I don't get it.
>>> + (scripts '(subscript superscript)))
>>> +(if (not (org-element-property :latex-math-p entity)) ent
>>> + (concat
>>> + (if (and no-pre-blanks-p
>>> + (memq (org-element-type prev) scripts)
>>> + (not (eq (org-export-data prev info) "")))
>>> + "" "$")
>>> + ent
>>> + (if (and no-post-blanks-p
>>> + (memq (org-element-type next) scripts)
>>> + (not (eq (org-export-data next info) "")))
>>> + "" "$")
>>
>> I think this is problematic: if an entity needs to export both the
>> previous and the next object, what happens when we have two consecutive
>> entities? An infloop?
>
> I agree, but I haven't been able to cause any nasty behavior. I've
> probably neglected some case. These works fine
>
> 1. \alpha\beta_t : \alpha is not a subscript
> 2. \alpha\beta_\xi\nu : runs OK recursively.
There's still some infloop smell around this code. Perhaps with
something like the following (untested):
A_b^c
> On 2.: on my system I've tried with many entities (around 500). It
> works, but obviously it's slow due to the recursiveness.This is very
> nasty. I don't know if some other mechanism can be derived, tho. . .
`org-export-data' caches its results, so calling it more than once on
the same object/element isn't really costly.
> + (let* ((ent (org-element-property :latex entity))
> + (prev (org-export-get-previous-element entity info))
> + (next (org-export-get-next-element entity info))
> + (no-post-blanks-p (= (or (org-element-property :post-blank entity) 0)
> 0))
aka `zerop' (slightly easier to read).
> + (no-pre-blanks-p (= (or (org-element-property :post-blank prev) 0) 0))
Ditto.
> + (scripts '(subscript superscript)))
> +
> +(if (not (org-element-property :latex-math-p entity)) ent
> + (concat
> + (if (and no-pre-blanks-p
> + (memq (org-element-type prev) scripts)
> + ;; check if nil
> + (org-export-data prev info))
> +"" "$")
> + ent
> + (if (and no-post-blanks-p
> + (memq (org-element-type next) scripts)
> + ;; check if nil
> + (org-export-data next info))
You don't need to check for nil. `org-export-data' returns nil when the
element or object is ignored. But `org-export-get-previous-element'
never returns ignored objects or elements.
> +(let ((out (or (org-export-filter-apply-functions
> +org-export-filter-subscript-functions
> +(org-export-data obj info)
> +info) "")))
See above.
Thanks again.
Regards,
--
Nicolas Goaziou
Re: [O] koma letter exporter: changing the priority of options
Hi Rasmus, alan.schm...@polytechnique.org writes: > alan.schm...@polytechnique.org writes: > >> I tried to fix it in the updated attached patch. I set a default value >> of "foldmarks-not-set" to the predicate that detects if it is set in the >> file, then I compare its contents. This assumes that the user will not >> give this literal value to the option. > > The attached version is updated to apply cleanly on master (after > applying your other patches). I've pushed this. Please don't hesitate to send suggestions to improve it, or report if it does not work as expected. Best, Alan
Re: [O] org-insert-heading rewritten from scratch
Hello, Carsten Dominik writes: > On 8.8.2013, at 09:41, Eric Abrahamsen wrote: > >> Carsten Dominik writes: >> >>> Hi, >>> >>> I have rewritten org-insert-heading, because it had become an >>> unmaintainable beast. >>> Please follow up in this thread if you find problems with the new >>> implementation. >>> Very likely there will be bugs, but now I am at least confident they can be >>> fixed. >>> >>> - Carsten >> >> Awesome! Thanks very much for doing this. Will report back with bugs. > > I take it none have been found? Not really a bug, but I find some behaviour surprising: when at a the beginning of a regular text line, there is no way to create a headline just above it. In the following example: XCursor is at "X" Neither M-RET, C-u M-RET, C-RET nor C-u C-RET can do it. Is it intended? Also in this case, I think C-RET should create the new headline _after_ the subtree, since that's its whole point anyway, AFAIU. Eventually, it seems that behaviour towards empty lines is a bit unpredictable. In the following example, M-RET will be behave differently on each blank line between Paragraph and "H2". C-RET will be consistent. Note: I have `auto' as value for `heading' key in `org-blank-before-new-entry'. * H1 Paragraph * H2 IMO, using M-RET and C-RET should be as smooth an experience as possible. I also suggest to write function specifications as tests in test-org.el. Regards, -- Nicolas Goaziou
Re: [O] mac-message for Growl 2
Hi Iain,
org-mac-message has just been replaced by org-mac-link.
You you please re-evaluate if your problem still exists (probably yes - if so,
please provide a new patch).
Thank you!
- Carsten
On 4.8.2013, at 22:39, Iain Houston wrote:
> I encountered a few problems with org-mac-mail bundled with emacs 24.3.1;
> some errors interfacing with Growl (2.1) so the patch below works for me and
> I wondered whether it would be of use to anyone else.
>
> I adapted the insertion of flagged mail to look at all active mail accounts
> rather than having to name any particular one.
>
> This is how I use org-mac-message: and below is the patch.
>
> (require 'org)
> (load "org-mac-message")
> (global-set-key [(shift f10)] (lambda() (interactive)
>(progn
> (find-file-noselect
> "~/Dropbox/org/refile.org")
> (org-mac-message-insert-flagged "refile.org"
> "Flagged mail"
>
>
> diff --git a/org-mac-message.el b/org-mac-message.el
> index 5df68f5..be2a654 100644
> --- a/org-mac-message.el
> +++ b/org-mac-message.el
> @@ -95,86 +95,89 @@ This will use the command `open' with the message URL."
> "return theLinkList as string\n"
> "end tell")))
>
> -(defun as-get-flagged-mail ()
> - "AppleScript to create links to flagged messages in Mail.app."
> - (do-applescript
> - (concat
> -;; Is Growl installed?
> -"tell application \"System Events\"\n"
> -"set growlHelpers to the name of every process whose creator type
> contains \"GRRR\"\n"
> -"if (count of growlHelpers) > 0 then\n"
> -"set growlHelperApp to item 1 of growlHelpers\n"
> -"else\n"
> -"set growlHelperApp to \"\"\n"
> -"end if\n"
> -"end tell\n"
> -
> -;; Get links
> -"tell application \"Mail\"\n"
> -"set theMailboxes to every mailbox of account \"" org-mac-mail-account
> "\"\n"
> -"set theLinkList to {}\n"
> -"repeat with aMailbox in theMailboxes\n"
> -"set theSelection to (every message in aMailbox whose flagged status =
> true)\n"
> -"repeat with theMessage in theSelection\n"
> -"set theID to message id of theMessage\n"
> -"set theSubject to subject of theMessage\n"
> -"set theLink to \"message://\" & theID & \"::split::\" & theSubject &
> \"\n\"\n"
> -"copy theLink to end of theLinkList\n"
> -
> -;; Report progress through Growl
> -;; This "double tell" idiom is described in detail at
> -;; http://macscripter.net/viewtopic.php?id=24570 The
> -;; script compiler needs static knowledge of the
> -;; growlHelperApp. Hmm, since we're compiling
> -;; on-the-fly here, this is likely to be way less
> -;; portable than I'd hoped. It'll work when the name
> -;; is still "GrowlHelperApp", though.
> -"if growlHelperApp is not \"\" then\n"
> -"tell application \"GrowlHelperApp\"\n"
> -"tell application growlHelperApp\n"
> -"set the allNotificationsList to {\"FlaggedMail\"}\n"
> -"set the enabledNotificationsList to allNotificationsList\n"
> -"register as application \"FlaggedMail\" all notifications
> allNotificationsList default notifications enabledNotificationsList icon of
> application \"Mail\"\n"
> -"notify with name \"FlaggedMail\" title \"Importing flagged message\"
> description theSubject application name \"FlaggedMail\"\n"
> -"end tell\n"
> -"end tell\n"
> -"end if\n"
> -"end repeat\n"
> -"end repeat\n"
> -"return theLinkList as string\n"
> -"end tell")))
> +(defun as-get-flagged-mail ()
> + "AppleScript to create links to flagged messages in all Mail.app
> accounts"
> + ;; Revised use of Growl interface and no need for variable
> org-mac-mail-account
> + (do-applescript
> + (concat
> + ;; Is Growl running? Use API as recommended at
> http://growl.info/documentation/applescript-support.php
> + "tell application \"System Events\"\n"
> + "set growlIsRunning to (count of (every process whose bundle
> identifier is \"com.Growl.GrowlHelperApp\")) > 0\n"
> + "end tell\n"
> +
> + "set theLinkList to {}\n"
> + "set isNotRegisteredToGrowl to true\n"
> + "tell application \"Mail\"\n"
> + "set theAccountList to the name of every account\n"
> + "repeat with theMailAccount in theAccountList\n"
> + "set theMailboxes to every mailbox of account theMailAccount\n"
> + "repeat with aMailbox in theMailboxes\n"
> + "set theSelection to (every message in aMailbox whose flagged status
> = true)\n"
> + "repeat with theMessage in theSelection\n"
> + "set theID to message id of theMessage\n"
> + "set theSubject to subject of theMessage\n"
> + "set theLink to \"message://\" & theID & \"::split::\" & theSubject &
> \"\n\"\n"
> + "copy theLink to end of theLinkList\n"
> +
> + "if growlIsRunning then\n"
> + "tell application id \"com.Growl.GrowlHelperApp\
Re: [O] org-attach should detect git also higher in the filesystem
Hi Thomas, I think this has been fixed today with http://orgmode.org/w/org-mode.git?p=org-mode.git;a=commit;h=2c38c3acc0b5d1cb3bb26f45829d711bb6f4009c Could you please check if this is correct? Thank you. - Carsten On 5.8.2013, at 23:58, Thomas Koch wrote: > Hi, > > I tested org-attach with the org file being inside a git repo. I observed > that > the auto-commit feature of org-attach seems to work only if the data > directory > is the root of a git repo (detected by looking for a .git folder in the data > folder). > > I'd like however to have the org file in the git repo too and the data folder > being a sub-folder of the git repo. Actually I'd also like to use git-annex > here. > > Some options of git rev-parse might be helpful here instead of coding the > repo > detection check by hand in elisp: > > --show-toplevel > Show the absolute path of the top-level directory. > > --is-inside-work-tree > When the current working directory is inside the work tree of the > repository print "true", otherwise "false". > > What do you think? > > Regards, > > Thomas Koch, http://www.koch.ro >
Re: [O] org-insert-heading rewritten from scratch
On 8.8.2013, at 09:41, Eric Abrahamsen wrote: > Carsten Dominik writes: > >> Hi, >> >> I have rewritten org-insert-heading, because it had become an unmaintainable >> beast. >> Please follow up in this thread if you find problems with the new >> implementation. >> Very likely there will be bugs, but now I am at least confident they can be >> fixed. >> >> - Carsten > > Awesome! Thanks very much for doing this. Will report back with bugs. I take it none have been found? - Carsten > > E > >
Re: [O] [patch][ox-latex] context-aware subscript
Hi,
> Thanks for the patch. Here are a few comments.
Thanks for the comments.
>> filter replace all & $\beta_{\text{}}$ & \texttimes{}$_{\text{}}$ \\
>
> We might be able to handle it more nicely, i.e. by skipping \text when
> contents are empty.
Right, these should be removed due to spacing issues, it seems.
However, in this case the change is induced by a filter. As such, Ox
doesn't know the final output when in the subscript function. It's
not easy to predict the outcome of a filter before it's been applied.
What I do in the patch is that I apply the filters within the
function. I don't like this approach as the doc says that filters are
applied ex post so it seems like cheating... Also, filters using a
regexp with "\text{whatever}" wouldn't work.
So I'm not too optimistic about this particular apporach.
>> +(prev (org-export-get-previous-element entity info))
>> +(next (org-export-get-next-element entity info))
>> +(no-post-blanks-p (= (or (org-element-property :post-blank entity) 1)
>> 0))
>> +(no-pre-blanks-p (= (or (org-element-property :post-blank
>> +
>> (org-export-get-previous-element
>> +entity info)) 1) 0))
>
> A nil :post-blank property means 0, not 1. Also, you don't re-use PREV
> in NO-PRE-BLANKS-P.
Right. I wanted to check for the case where there is no next/previous
element. But I was wrong. Thanks.
>> +(scripts '(subscript superscript)))
>> +(if (not (org-element-property :latex-math-p entity)) ent
>> + (concat
>> + (if (and no-pre-blanks-p
>> +(memq (org-element-type prev) scripts)
>> +(not (eq (org-export-data prev info) "")))
>> + "" "$")
>> + ent
>> + (if (and no-post-blanks-p
>> +(memq (org-element-type next) scripts)
>> +(not (eq (org-export-data next info) "")))
>> + "" "$")
>
> I think this is problematic: if an entity needs to export both the
> previous and the next object, what happens when we have two consecutive
> entities? An infloop?
I agree, but I haven't been able to cause any nasty behavior. I've
probably neglected some case. These works fine
1. \alpha\beta_t : \alpha is not a subscript
2. \alpha\beta_\xi\nu : runs OK recursively.
On 2.: on my system I've tried with many entities (around 500). It
works, but obviously it's slow due to the recursiveness. This is very
nasty. I don't know if some other mechanism can be derived, tho. . .
>> +(not (org-element-property :latex-math-p prev))
>
> Sure, but I'd rather make a stricter check and also test PREV's type.
OK.
–Rasmus
Test file
#+BEGIN_SRC Org
* filters :noexport:
#+begin_src emacs-lisp
(defun test-filter (script backend info)
(when (org-export-derived-backend-p backend 'latex)
(if (string-match "a" script) "" script)))
(defun test-filter2 (script backend info)
(when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string "zz" "" script)))
(add-to-list 'org-export-filter-subscript-functions
'test-filter)
(add-to-list 'org-export-filter-subscript-functions
'test-filter2)
#+end_src
#+RESULTS:
| test-filter2 | test-filter |
* test 1
| | mathp | text |
|--+---+|
| merge maybe | \alpha\beta_t | \alpha\times_t |
| long merge maybe | \alpha\beta_tv\xi | \alpha\times_tv\xi |
| filter drop | \alpha\beta_abc | \alpha\times_abc |
| filter replace all | \alpha\beta_zz| \alpha\times_zz|
| filter replace parts | \alpha\beta_zz\xi | \alpha\times_zz\xi |
#+END_SRC
Approximate output
& mathp & text
=
merge maybe & $\alpha$$\beta_{\text{t}}$ &
$\alpha$\texttimes{}$_{\text{t}}$
long merge maybe & $\alpha$$\beta_{\text{tv}\xi}$ &
$\alpha$\texttimes{}$_{\text{tv}\xi}$
filter drop & $\alpha$$\beta$ & $\alpha$\texttimes{}
filter replace all & $\alpha$$\beta$ & $\alpha$\texttimes{}
filter replace parts & $\alpha$$\beta_{\xi}$ &
$\alpha$\texttimes{}$_{\xi}$
>From ebb7eb32b8ff18b9ff2c9d8686df1cdc6ed28bfb Mon Sep 17 00:00:00 2001
From: rasmus
Date: Thu, 29 Aug 2013 12:18:00 +0200
Subject: [PATCH] maybe merge subscript and mathp entity with some checks
---
lisp/ox-latex.el | 51 +++
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 1fe918a..cc8ac80 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1234,9 +1234,26
Re: [O] [PATCH] Org attach: use vc to find the git dir if it exists
Applied, thank you Remi. - Carsten On 12.8.2013, at 15:28, Rémi Vanicat wrote: > Org attach use to fail to commit the attached file in git or git annex > when the .git repository is not in the data sub-directory. > > This new code will use vc-git to find the .git file, and from this do > what is needed for committing file into git or git annex. > > --- > lisp/org-attach.el | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/lisp/org-attach.el b/lisp/org-attach.el > index faefa6b..9bf3cda 100644 > --- a/lisp/org-attach.el > +++ b/lisp/org-attach.el > @@ -261,14 +261,15 @@ the ATTACH_DIR property) their own attachment > directory." > (defun org-attach-commit () > "Commit changes to git if `org-attach-directory' is properly initialized. > This checks for the existence of a \".git\" directory in that directory." > - (let ((dir (expand-file-name org-attach-directory)) > - (changes 0)) > -(when (file-exists-p (expand-file-name ".git" dir)) > + (let* ((dir (expand-file-name org-attach-directory)) > + (git-dir (vc-git-root dir)) > + (changes 0)) > +(when git-dir > (with-temp-buffer > (cd dir) > (let ((have-annex > (and org-attach-git-annex-cutoff > - (file-exists-p (expand-file-name ".git/annex" dir) > + (file-exists-p (expand-file-name "annex" git-dir) > (dolist (new-or-modified > (split-string > (shell-command-to-string > -- > 1.8.4.rc2 > > >
[O] ATTENTION: Incompatible change
Hi all, I have now replaced both org-mac-message.el and org-mac-link-grabber.el with org-mac-link.el. So after the next pull, you will have to change your setup to use this module instead of the others and use the new commands as well. I would appreciate if you your try this soon, so that we can fix issue before the next release (very soon). Thank you, and in particular thanks to Anthony Lander for doing the work. - Carsten P.S. Anthony, you promised to update the documentation. It would be great if you could do that now. Thank you!
Re: [O] [PATCH] ox: add Simplified Chinese translations for `org-export-dictionary'
Hi, It seems that this has been applied. - Carsten On 2.7.2013, at 08:17, feng shu wrote: > > <0001-ox-add-Simplified-Chinese-translations-for-org-expor.patch>
Re: [O] Very minor bug in undo applied to org table
On 1.7.2013, at 19:24, Paul Stansell wrote: > Hello, > > This seems like a very minor bug, but I thought I'd report it anyway > in case it has wider ramifications that I'm unaware of. > > Create an org file with the following lines: > > | 1 | > #+TBLFM: $1=2 > > Open it and type C-c C-c on the TBLFM line. This replaces the '1' in > the table with a '2'. Now type C-_ (for undo). Not only does the > '2' revert to a '1', but a second line reading '#+TBLFM: $1=2' is > inserted directly under the first. An second C-_ removes this second > TBLFM line. Hi Paul, this just means that two separate editing event get into the undo list. I don't think I know how to fix it. - Carsten > > Regards, > > Paul > > PS. I'm using Emacs 24.2.1 and Org-mode release_8.0.3-331-gf7e6f1 and > I tested with the minimal org-mode set-up from > http://orgmode.org/manual/Feedback.html. >
Re: [O] Carriage return in macro
Hello, Jambunathan K writes: > In the context of the example below (i.e., the way #+ATTR_ODT are used > /within/ the list) is it fair to say this: > > A #+ATTR_ODT: can be attached only to a plain-list - Visually they > come before the first item of the top-level list or a nested list. > > Using an #+ATTR_ODT line before a second or subsequent item will > result in splitting of the original list. > > I just want to confirm my understanding of the /existing/ behaviour so > that I can extract maximum juice out of ox.el. That's correct: items cannot get affiliated keywords (see list of exceptions at line 32 in org-element.el). Regards, -- Nicolas Goaziou
Re: [O] Carriage return in macro
Nicolas In the context of the example below (i.e., the way #+ATTR_ODT are used /within/ the list) is it fair to say this: A #+ATTR_ODT: can be attached only to a plain-list - Visually they come before the first item of the top-level list or a nested list. Using an #+ATTR_ODT line before a second or subsequent item will result in splitting of the original list. I just want to confirm my understanding of the /existing/ behaviour so that I can extract maximum juice out of ox.el. To avoid confusion: Opinions surrounding how comments and meta lines influence the list structure doesn't bother me one way or the other. Jambunathan K writes: > #+ATTR_ODT: :style "OrgBulletedList" :p-style "Text_20_body_20_bold" > 1. N1 >1. N11 >2. N12 > 2. N2 >#+ATTR_ODT: :style "OrgNumberedList" :p-style "Preformatted_20_Text" >* B21 > >* B22 > - B221 > >First paragraph. > >#+ATTR_ODT: :style "OrgBibliographyList" :p-style "Text_20_body" >1. one >2. two >3. three > >#+ATTR_ODT: :style "Text_20_body_20_indent" >Second paragraph. > > - B222 >* B23 > 3. N3
Re: [O] odt export version conflict on emacs for mac os x
Best way to explain is with an example: 1. emacs -Q 2. eval this (add-to-list 'load-path "~/src/org-mode/lisp/") (require 'org-loaddefs) Ensure that there is org-loaddefs available from git path. 3. M-x load-library ox-odt.el 4. Ensure (featurep 'org-odt) reports nothing. 5. M-x customize-group org-export-odt. 6. See both legacy (org-export-odt-*) and new variables (org-odt-*) being reported. s/odt/latex/. The result will be the same What needs to happen: Put new things in new groups. I suggest org-export-ng or org-export-new prefix for new exporter and backends. Both the backend groups and the parent groups. Long winded explanation: --- Both the legacy and new exporters, declare SAME ":group 'org-export-backend" for but DIFFERENT user variables. Similar looking variables is NOT guaranteed to have same functionality. Vanialla Emacs "somehow" tracks the custom variables and it's group /even if/ legacy exporters are NOT in the load path. So when new exporter is loaded, the group displays BOTH the LEGACY and NEW variables. org-odt.el uses (defgroup org-export-odt nil "Options specific for ODT export of Org-mode files." :tag "Org Export ODT" :group 'org-export :version "24.1") (defcustom org-export-odt-content-template-file nil "Template file for \"content.xml\". The exporter embeds the exported content just before \"\" element. If unspecified, the file named \"OrgOdtContentTemplate.xml\" under `org-odt-styles-dir' is used." :type 'file :group 'org-export-odt :version "24.1") ) ox-odt.el uses (defgroup org-export-odt nil "Options for exporting Org mode files to ODT." :tag "Org Export ODT" :group 'org-export) (defcustom org-odt-content-template-file nil "Template file for \"content.xml\". The exporter embeds the exported content just before \"\" element. If unspecified, the file named \"OrgOdtContentTemplate.xml\" under `org-odt-styles-dir' is used." :type '(choice (const nil) (file)) :group 'org-export-odt :version "24.1") Carsten Dominik writes: > Hi, > > can someone please summarize this discussion for me and tell me what action > is required? > > Thank you! > > - Carsten > > On 29.8.2013, at 20:25, Skip Collins wrote: > >> Jambunathan K wrote: After I do an ODT export, many ox-odt variables are duplicated with old variable names: | [-]-\ Group Org Export ODT | | |--- Option Org Odt Schema Dir | | |--- Option Org Odt Content Template File >>> >>> Above ones come from NEW exporter, ox-odt.el >>> | | |--- Option Org Export Odt Schema Dir | | |--- Option Org Export Odt Content Template File >>> >>> Above ones come from LEGACY exporter. Not used by ox-odt.el. >>> >>> This is confusing but the behaviour is expected and NOT BUGGY. >> >> Thank you for clarifying a confusing situation. I am not sure why I >> assumed that the org-export-odt variables were the newer ones. >> >> Suggestion for maintainers: a new, separate customization group, with >> appropriate pointers in the documentation, would be helpful. >>
Re: [O] odt export version conflict on emacs for mac os x
Carsten Dominik writes: > On 31.8.2013, at 09:26, Achim Gratz wrote: >> There is nothing to do here. The new variables can and must be put in to a new groups. > Thank you very much Achim. If you cannot kill someone just ostracize them. Segregation CAN and MUST be done. Jambunathan K.
Re: [O] odt export version conflict on emacs for mac os x
On 31.8.2013, at 09:26, Achim Gratz wrote: > Carsten Dominik writes: >> can someone please summarize this discussion for me and tell me what action >> is required? > > There is nothing to do here. The "legacy" defcustoms are built into > Emacs and are not easy to remove as there is no official interface to do > this. I have code that tries to do clean things up, but it may have > unwanted side-effects depending on how the startup files are organized. > Eric Abrahamsen wanted to check some things but I haven't heard back. Thank you very much Achim. - Carsten > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: > http://Synth.Stromeko.net/Downloads.html#WaldorfSDada > >
Re: [O] odt export version conflict on emacs for mac os x
> There is nothing to do here. The "legacy" defcustoms are built into > Emacs and are not easy to remove as there is no official interface to do > this. I have code that tries to do clean things up, but it may have > unwanted side-effects depending on how the startup files are organized. Hi, Achim Could you give a pointer to your code? I'd like to try it. Yours, Christian
Re: [O] [patch][ox-latex] context-aware subscript
Hello,
Rasmus writes:
> I've just enclosed a quick patch (as in doesn't contain proper commit
> msg), but it's basically the previous patch minus the removal of \text
> in math plus some quick checks towards potential nasty filters.
>
> It works with the following test file, but let me know about more
> hair-pulling test cases, and/or filters.
Thanks for the patch. Here are a few comments.
> filter replace all & $\beta_{\text{}}$ & \texttimes{}$_{\text{}}$ \\
We might be able to handle it more nicely, i.e. by skipping \text when
contents are empty.
> + (prev (org-export-get-previous-element entity info))
> + (next (org-export-get-next-element entity info))
> + (no-post-blanks-p (= (or (org-element-property :post-blank entity) 1)
> 0))
> + (no-pre-blanks-p (= (or (org-element-property :post-blank
> +
> (org-export-get-previous-element
> + entity info)) 1) 0))
A nil :post-blank property means 0, not 1. Also, you don't re-use PREV
in NO-PRE-BLANKS-P.
> + (scripts '(subscript superscript)))
> +(if (not (org-element-property :latex-math-p entity)) ent
> + (concat
> + (if (and no-pre-blanks-p
> + (memq (org-element-type prev) scripts)
> + (not (eq (org-export-data prev info) "")))
> +"" "$")
> + ent
> + (if (and no-post-blanks-p
> + (memq (org-element-type next) scripts)
> + (not (eq (org-export-data next info) "")))
> +"" "$")
I think this is problematic: if an entity needs to export both the
previous and the next object, what happens when we have two consecutive
entities? An infloop?
This is the difficult part of the problem.
> + (not (org-element-property :latex-math-p prev))
Sure, but I'd rather make a stricter check and also test PREV's type.
Regards,
--
Nicolas Goaziou
Re: [O] odt export version conflict on emacs for mac os x
Carsten Dominik writes: > can someone please summarize this discussion for me and tell me what action > is required? There is nothing to do here. The "legacy" defcustoms are built into Emacs and are not easy to remove as there is no official interface to do this. I have code that tries to do clean things up, but it may have unwanted side-effects depending on how the startup files are organized. Eric Abrahamsen wanted to check some things but I haven't heard back. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
