Re: [O] ATTN: Bernt Hansen, regarding org-mode.org
On Fri, Nov 01, 2013 at 04:52:20PM +, Loyall, David wrote: Hello, Bernt. According to your famous org-mode.org document (thank you!) this file: http://doc.norang.ca/org-mode.org.html ...should be a colorized version of the org source. Please take a look at it. The total filesize seems lower than I'd expect. ;) Looks okay to me. -- Suvayu Open source is the future. It sets us free.
Re: [O] FAQ or manual suggestion: customizing HTML export
Hello Harry,
On Thu, Nov 07, 2013 at 12:00:32PM -0500, Rockefeller, Harry wrote:
NOTE: This is not an information request.
I searched google, orgmode.org FAQ, org manual, and ran a search on this
mailing list but
could not find this useful information. Since it took me a few days
to figure it out, I thought it might be worth documenting somewhere.
I wanted to customize HTML export.
1) to reduce the amount of empty space in org tables, and to put lines around
all cells since
white space was now minimal, I finally found adding this gets the job done:
#+ATTR_HTML: :options border=2 rules=all frame=border cellpadding=0
cellspacing=0
2) to change the color of the title on a per-org-file basis I found this
works:
#+HTML: style.title {color: blue;}/style
If I want to change the color of the title for all org files then adding this
to
my ~/.emacs file worked:
(setq org-export-html-style-extra style.title {color: blue;}/style)
Something is off here. This variable should not be present unless you
are using an older Org version. AFAICK, if this is true, your solution
(1) should not work. Maybe it works by accident? It would be helpful
if you could provide the org-version and how you install Org.
That said, I do not think the HTML backend supports the :options
property in an #+attr_html line. The manual lists it under LaTeX
specific attributes (disclaimer: I use the HTML backend sparringly).
http://orgmode.org/manual/LaTeX-specific-attributes.html#LaTeX-specific-attributes
OK go ahead and flame me if stuff like this is 'hidden' in plain sight.
We don't do that here. IMO, this community is one of the most accepting
and friendly out there. ;)
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
[O] [RFC] ox-ascii.el: fixing variable width character handling
Hi, I've been trying to fix ASCII export back-end for variable width chars. It is basically replacing `length' with `string-width', but the behavior of those two functions differ when you give nil as an argument; `length' returns 0, `string-width' yields a type error: eval: Wrong type argument: stringp, nil While I came up with the following experimental patch, I have a few questions: - What is the lisp idiom to handle type error? In the following patch, I've created a new wrapper function `org-ascii--string-width', it's a thin wrapper with if-then-else. I thought placing if-then-else clause in the original place clutter the code. - If wrapped string-width is good idea, would it be also a good idea to merge it with `org-string-width' in org.el? Because it is not ox-ascii specific. The current `org-string-width' does not handle nil, neither. - The width of the underline for headlines should be checked with string-width. As defined in Unicode Standard Annex #41[1], character width is environment dependent. So, the calculation of character width at export time might not be sufficient enough. We can check to see the exported document contains cjk chars more than some thresholds or not, I haven't gone that far. - Does anyone using ox-ascii.el depends on the clipped marker `=' for fixed width columns? I thought `...' would be much readable. - BTW, while looking at table handling, I noticed fixed column width doesn't work with the code at the current git HEAD. That's because width calculation is mixed with `length' and `string-width', and pass out-of-range arguments to `add-text-properties'. [1]: http://www.unicode.org/reports/tr41/ diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el index 8e75007..35d58fc 100644 --- a/lisp/ox-ascii.el +++ b/lisp/ox-ascii.el @@ -630,7 +630,8 @@ possible. It doesn't apply to `inlinetask' elements. org-ascii-underline) (and under-char (concat \n - (make-string (length first-part) under-char + (make-string (/ (string-width first-part) (char-width under-char)) + under-char (defun org-ascii--has-caption-p (element info) Non-nil when ELEMENT has a caption affiliated keyword. @@ -1704,7 +1705,7 @@ are ignored. (org-element-map table 'table-row (lambda (row) (setq max-width -(max (length +(max (string-width (org-export-data (org-element-contents (elt (org-element-contents row) col)) @@ -1714,6 +1715,11 @@ are ignored. max-width)) cache +(defun org-ascii--string-width (str) + (if str + (string-width str) +0)) + (defun org-ascii-table-cell (table-cell contents info) Transcode a TABLE-CELL object from Org to ASCII. CONTENTS is the cell contents. INFO is a plist used as @@ -1724,16 +1730,18 @@ a communication channel. ;; each cell in the column. (let ((width (org-ascii--table-cell-width table-cell info))) ;; When contents are too large, truncate them. -(unless (or org-ascii-table-widen-columns (= (length contents) width)) - (setq contents (concat (substring contents 0 (- width 2)) =))) +(unless (or org-ascii-table-widen-columns + (= (org-ascii--string-width contents) width)) + (setq contents (truncate-string-to-width contents width nil ?. t))) ;; Align contents correctly within the cell. (let* ((indent-tabs-mode nil) (data (when contents (org-ascii--justify-string contents width - (org-export-table-cell-alignment table-cell info) - (setq contents (concat data (make-string (- width (length data)) ? + (org-export-table-cell-alignment table-cell info + (trailing-space (make-string (- width (org-ascii--string-width data)) ? ))) + (setq contents (concat data trailing-space))) ;; Return cell. (concat (format %s contents) (when (memq 'right (org-export-table-cell-borders table-cell info))
Re: [O] org-store-link BUG for notmuch message
On Mon, Nov 04, 2013 at 01:17:24PM +0100, Bastien wrote: Hi Ingo, what version of Org and notmuch are you using? I use a recent Emacs/Org and a recent notmuch and I can store link without problem. Same here. -- Suvayu Open source is the future. It sets us free.
[O] libxml-parse-xml-region: Raise runtime error, don't return nil
Christof Christof Spitz christof.sp...@gmail.com writes: I found the bug: Windows-Emacs was missing the libxml2 library. I got the libxml2-2.7.8.-w32-bin.zip, copied the content of /bin into Emacs' /bin directory and now the formatting works. This should have been very difficult to track down. ox-freemind.el does invoke `libxml-parse-xml-region'. I think Emacs should raise a runtime error (and not return nil) if the above API is called but libxml is unavailable. ps: This bug is a good excuse to audit other such wrapper calls (if there are any) and make sure that they don't fall silently.
Re: [O] libxml-parse-xml-region: Raise runtime error, don't return nil
Christof Spitz christof.sp...@gmail.com writes: Emacs did return a runtime error This is what Emacs does. From xml.c: 96 message1 (libxml2 library not found); and message1 (based on other uses elsewhere) seems to be used for ordinary echo area messages (like prompt strings etc) as opposed to an error message. It is easy to check though. I don't have access to a Windows machine. It should really be an error and not a simple informative message. Try this: 1. Remove libxml 2. M-x toggle-debug-on-error RET 3. Export to freemind Do you now get a backtrace buffer?
Re: [O] [RFC] ox-ascii.el: fixing variable width character handling
Hello, Yasushi SHOJI ya...@atmark-techno.com writes: I've been trying to fix ASCII export back-end for variable width chars. It is basically replacing `length' with `string-width', but the behavior of those two functions differ when you give nil as an argument; `length' returns 0, `string-width' yields a type error: eval: Wrong type argument: stringp, nil Thank you for your patch. While I came up with the following experimental patch, I have a few questions: - What is the lisp idiom to handle type error? In the following patch, I've created a new wrapper function `org-ascii--string-width', it's a thin wrapper with if-then-else. I thought placing if-then-else clause in the original place clutter the code. You only use `org-ascii--string-width' in two places. You can write (string-width (or contents )) instead, it will be less intrusive. BTW, what about `org-ascii--current-text-width'? This function also uses `length' instead of `string-width'. - If wrapped string-width is good idea, would it be also a good idea to merge it with `org-string-width' in org.el? Because it is not ox-ascii specific. The current `org-string-width' does not handle nil, neither. That would be a good idea, but in a distinct patch. - The width of the underline for headlines should be checked with string-width. As defined in Unicode Standard Annex #41[1], character width is environment dependent. So, the calculation of character width at export time might not be sufficient enough. We can check to see the exported document contains cjk chars more than some thresholds or not, I haven't gone that far. I don't think there's much to do about it. Hopefully one can always re-export the Org file in its own environment. - Does anyone using ox-ascii.el depends on the clipped marker `=' for fixed width columns? I thought `...' would be much readable. I have no opinion about it. Though, if we switch to ..., we also need to provide the utf-8 equivalent when using this charset. - BTW, while looking at table handling, I noticed fixed column width doesn't work with the code at the current git HEAD. That's because width calculation is mixed with `length' and `string-width', and pass out-of-range arguments to `add-text-properties'. I guess your patch also fixed that. Regards, -- Nicolas Goaziou
[O] [BUG] ox-info: incorrect @documentencoding
Hi, For the Texinfo exporter, I noticed that the @documentencoding macro is derived from the buffer-file-coding-system. At the moment it is translated like this: us-ascii-unix to US-ASCII-UNIX. This makes makeinfo complain like so: org-syntax.texi:5: warning: encoding `US-ASCII-UNIX' is not a canonical texinfo encoding org-syntax.texi:5: warning: unrecognized encoding name `US-ASCII-UNIX' If I manually choose us-ascii as my coding system, Emacs sets it to us-ascii-unix. I'm guessing us-ascii is an alias of somekind for us-ascii-platform. Hand editing the US-ASCII-UNIX to US-ASCII in the exported file gets rid of the warning. Hope this helps, -- Suvayu Open source is the future. It sets us free.
[O] bug#15815: 24.3.50; distant-foreground face attribute and org-hide face
FWIW, hiding text by setting foreground == background is the wrong way to do it IMO. AFAIK there's no other way offered by Emacs. `invisible' actually removes the text from the output rather than leaving blank space, so it doesn't provide the same feature. Stefan
Re: [O] maintaining Org
On 7.11.2013, at 20:38, David david...@riseup.net wrote: El 05/11/13 11:56, Bastien escribió: Hi David, Carsten Dominikcarsten.domi...@gmail.com writes: do you have FSF papers? If so, write to Jason Dunsmore and send him your public key. Thanks you! I think org-license.el and org-effectiveness.el belong to contrib/ so you don't need to sign the FSF papers for this. I've signed the FSF papers and the FSF has accepted. I attach it in other email Thanks David. - Carsten Regards.
[O] clearing database thwarts calendar synchronization
Hi everyone! first of all thanks go to everyone out there making (mobile)org the great piece of software that it is! No here's my issue: When I clear the database in Mobileorg for Android and re-sync with the staged files, all entries that used to be synced with the Android system calendar vanish from the latter. Disabling/enabling the syncing in the settings doesn't change anything. In the following cases syncing with the calendar _does_ work: 1. New entries added to any of the affected files after clearing the DB do sync. 2. Changing the heading of one of the affected entries makes them sync again 3. Moving a whole affected file to a new name (e.g. mv Organizer.org organizer2.org) and adding that new file to org-mobile-files will make all the affected entries sync with the calendar again. However, clearing the database will again remove all entries from the system calendar. Any new file name synced prior to clearing, cannot ever be used as a new file name for case 3. Since purging all application data on the Android device doesn't help, my guess is that the problem is on org on my PC. One more remark that might be a hint for some of you: I do not get IDs on all of my entries anymore when pushing the file they're in, although org-mobile-force-id-on-agenda-items is non-nil. I'm running org-mode 7.8.02-1 on ubuntu 12.04 and MObileorg for Android 0.9.13 on a Samsung Galaxy S4. Any help will be greatly appreciated. Thanks in advance and greetings from Luxembourg Oliver -- Oliver Motz www.phylax-computerkunst.de
Re: [O] [bug] ox-org.el subtree export appears broken
Nicolas Goaziou n.goaz...@gmail.com writes: Eric Schulte schulte.e...@gmail.com writes: My initial thoughts are that inserting keywords *with* values while not inserting empty keywords would be the most intuitive. TITLE always have a value. When not specified, it defaults to buffer's name. Also, what keywords? Document keywords (DATE, AUTHOR, TITLE)? Or other export related keyword (CREATOR, DESCRIPTION, KEYWORDS, EMAIL)? Anything else (OPTIONS, LANGUAGE...)? Hmmm, I don't have a strong intuition here. I'm tempted to say that whatever the HTML export engine does would be a good starting place, plus any keyword explicitly set in subtree properties. I feel like this decision must have already been made in some other Org-mode function, so copying those decisions would be the best bet. Also, should these belong to the inner or outer template, i.e. should they be excluded unconditionally on a body-only export, or not? Outer template, excluded from body only. This is not very difficult to implement, but I'd rather have precise specifications first. And since you are the one making the request... Understood, and I do appreciate the implementation (and apologize for my delay in reply). I hope the above sound like a good starting place to you. For what it's worth, this need arose while lazily implementing current-subtree-only Emacs driven presentations with epresent [1]. Thanks, Regards, Footnotes: [1] https://github.com/eschulte/epresent/commit/c94f03027033b39082a4897625974f893a17434a -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] [ANN] Improved Flyspell check
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Schulte schulte.e...@gmail.com writes: I've been using this since it was sent, and I haven't noticed any bad behavior. Thanks for the feedback. BTW, I tried to add `org-self-insert-command' to `flyspell-delayed-commands', since `self-insert-command' belongs to `flyspell-default-delayed-commands', but I didn't notice any improvement. Does this change anything for you? I've tried this briefly but I don't see any effect. It seems like a safe default to add... Best, Regards, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
[O] BEAMER_act and special environments
Hi,
I'm not especially familiar with emacs-lisp and I haven't looked at the
functions for node properties at all. Unfortunately, I'm under a time
crunch today and I don't have the few hours it would take to get up to
speed (otherwise, I'd have a go at it myself).
It seems that everything in org-beamer-environments-default supports
overlay specifications, except beamercolorbox. OK... what about
org-beamer-environments-special? I found today that B_columns ignores any
overlay specification given in the heading's properties. That is:
Header :B_columns:
:PROPERTIES:
:BEAMER_env: columns
:BEAMER_act: 2-
:END:
(... with some BMCOL headings underneath...)
--
\begin{columns}
.. blah blah...
\end{columns}
.. where I would have hoped for \begin{columns}2-
I was able to work around the limitation by wrapping the columns
environments within onlyenv environments. But it seems to me that it
might be nicer to be able to write the overlay directly into the affected
environment.
I don't mind poking around the code, but I'd need some tips. I can see
where B_columns gets formatted, but I'm not clear how to check for a
BEAMER_act property.
Thanks,
hjh
