Re: [O] New headline after no content (empty headline)
Bastien gnu.org> writes: > > Hi Brady, > > Brady Trainor uw.edu> writes: > > (when respect-content > > (and (looking-at "[ \t]+") (replace-match "")) > > I thought to try substituting "[ \t]+" with "[\t]+", and byte compiled the > > file. But this did not solve. > What you want is not to remove only tabs, but to prevent removing > whitespaces when the string before the point matches "^\*+" -- so > that's what I did with this patch: > > http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=afffe03d Thank you much for taking the time to fix my fix and add the patch. However, my fix was wrong, I should not have been looking inside the =respect content= case. My original intention was to modify the =insert-org-heading=, not =org-insert-heading-respect-content=. I was that lost. Your help and encouragement pushed me to find the `source` of my problem. For this, I looked for ways to step through the code, ala some type of debugger, and I fell upon Emacs' default, Edebugger. (Simply reading org.el was, um, not efficient by itself.) So, I "instrumented" the =defun=s, in the end both of =org-insert-heading= and =org-N-empty-lines-before-current= (via =C-u C-M-x=) and deleting org.elc. This way, testing =M-RET= in an org file, I could =SPACE= through org.el while watching the org file buffer for changes (and *Messages*, though that was more or less awkward for me). So, here are my changes that give me my desired behavior, modifying in the function =org-N-empty-lines-before-current= which follows right after function =org-insert-heading=. Originally (if (looking-back "\\s-+" nil 'greedy) (replace-match "")) (or (bobp) (insert "\n")) I changed this to (unless (looking-back "\* \n") ; don't damage empty headlines (if (looking-back "\\s-+" nil 'greedy) (replace-match "")) (or (bobp) (insert "\n")) ) This feels a bit ad-hoc, as I don't completely understand all the stuff even in =defun org-insert-heading...=, and likely a fix should be made taking into account all desired functionality (but I'd worry to break something else). Let's call it organic! /Someday/, I'd like to understand the org.el better. I haven't learned how to patch, I've barely started gitting about a month ago for backing up files. I guess I should clone the Org-mode source soon, for starters. Thanks again! Brady
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
one option might be to keep what we have for emphasis, ossify it, and create a backend-independent nestable, multiline [and so on] markup for emphasis. but not just any syntax [because that would clutter us with more syntax]. this time it would be $[extensible :pretty-nicely t], and it will work for non-emphasis features and for emphasis sub-features we need later. thus, after this, new features and sub-features do not require new syntax. this keeps our syntax issues to a minimum. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
[O] [PATCH] org-mac-link: Improve grabbing behavior for Chrome.
* contrib/lisp/org-mac-link.el (org-as-mac-chrome-get-frontmost-url):
Improve AppleScript used for grabbing information from Chrome. Now
it's shorter and doesn't require switching to the app. Also,
starting and ending quote are trimmed only when necessary.
---
contrib/lisp/org-mac-link.el | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/contrib/lisp/org-mac-link.el b/contrib/lisp/org-mac-link.el
index ef46171..d1687e0 100644
--- a/contrib/lisp/org-mac-link.el
+++ b/contrib/lisp/org-mac-link.el
@@ -349,26 +349,18 @@ applications and inserting them in org documents"
(defun org-as-mac-chrome-get-frontmost-url ()
(let ((result (do-applescript
-(concat
- "set oldClipboard to the clipboard\n"
- "set frontmostApplication to path to frontmost
application\n"
- "tell application \"Google Chrome\"\n"
- " activate\n"
- " delay 0.15\n"
- " tell application \"System Events\"\n"
- " keystroke \"l\" using command down\n"
- " keystroke \"c\" using command down\n"
- " end tell\n"
- " delay 0.15\n"
- " set theUrl to the clipboard\n"
- " set the clipboard to oldClipboard\n"
- " set theResult to (get theUrl) & \"::split::\" & (get
name of window 1)\n"
- "end tell\n"
- "activate application (frontmostApplication as text)\n"
- "set links to {}\n"
- "copy theResult to the end of links\n"
- "return links as string\n"
-(substring (car (split-string result "[\r\n]+" t)) 1 -1)))
+(concat
+ "set frontmostApplication to path to frontmost application\n"
+ "tell application \"Google Chrome\"\n"
+ "set theUrl to get URL of active tab of first window\n"
+ "set theResult to (get theUrl) & \"::split::\" & (get
name of window 1)\n"
+ "end tell\n"
+ "activate application (frontmostApplication as text)\n"
+ "set links to {}\n"
+ "copy theResult to the end of links\n"
+ "return links as string\n"
+(replace-regexp-in-string "^\"\\|\"$" ""
+ (car (split-string result "[\r\n]+" t)
(defun org-mac-chrome-get-frontmost-url ()
(interactive)
--
1.9.1
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Dnia 2014-03-22, o godz. 16:30:31
Nicolas Goaziou napisał(a):
> > Also, there is no "backward-compatibility squad", only users who
> > care about what they like.
>
> That is what they want us to believe! :)
Ninja'd!
Re: topic: one idea that is maybe not very Org-ish, but seems
reasonable: Org already uses LaTeX syntax for sub/superscripts, and
accepts LaTeX snippets etc. Why not allow \textbf{something} parallel
to *something*? Would it break something? When using the LaTeX
exporter, currently it seems (from very few simple experiments), that
\textbf{whatever} copies "whatever" verbatim to the file (I tried LaTeX
and HTML exporters).
Of course, one problem would be nesting - regexen won't help in this.
But it could be restricted to just letters or something (yes, I know,
very inelegant hack - but let's brainstorm a little, maybe someone
could come up with a better idea).
> Regards,
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] Org is awesome
On Sat, Mar 22, 2014 at 08:52:11AM +0100, Bastien wrote: > James Harkins writes: > > > After 243 commits to a constellation of org files, producing 10849 > > lines of LaTeX code from the Beamer exporter, which render into 229 > > pages of beamerarticle print-ready material, including 156 captioned > > code listings (and a handful of un-numbered ones) and 27 pages of > > fully indexed glossary entries (whose LaTeX code comes from > > emacs-lisp source blocks processing org tables), I think I'm in a > > position to state with confidence: > > Nice use-case ! > > > ORG IS AWESOME. > > Tell it to the world with a blog entry :) Or with a little bit more effort maybe a nice Worg article ;) -- Suvayu Open source is the future. It sets us free.
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Hello,
On Mar 22, 2014 7:06 PM, "Nicolas Richard"
wrote:
> I'd go even a little further : assuming it makes sense to underline
> within a section header, does it also make sense to propagate that
> formatting to the toc and/or header of the document ? If not, I suggest
> exporting as:
> \section[not-so-plain text]{\uline{not-so-plain} \textbf{text}}
>
I think it sometimes does make sense to highlight in the TOC, for instance
if the highlight was intended to emphasize a specific word.
Also I don't know why there was underlining in the first place. If we're
> asking to underline all section titles, then it might make sense to
> redefine e.g. \section to do so (packages titlesec might help).
>
There was underlining because I wanted to emphasize a single word in the
heading (the example I posted was minimal for demonstration purposes), not
because all exported sections are underlined.
Cheers,
Kosta
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Nicolas Richard writes:
> Nicolas Goaziou writes:
>> It is technically possible to use \underline (hard-coded) in sections
>> and \uline (or whatever is defined in`org-latex-text-markup-alist')
>> everywhere else.
>>
>> Is there any downside to this proposal?
>
> Disclaimer : While I do use LaTeX, I rarely use the exporter, and never
> underline in sections.
>
> (The shed should be green, obviously.)
>
> I don't know why \uline doesn't work, but while \underline works, it
> does so with many warnings. I think the reason is that hyperref tries to
> add the text to the PDF TOC (usually a pane in the pdf viewer), and that
> supports very little to no formatting.
>
> Rasmus' suggestion seemed good, i.e.
> \texorpdfstring{\uline{SECTION}}{SECTION}
>
> I'd go even a little further : assuming it makes sense to underline
> within a section header, does it also make sense to propagate that
> formatting to the toc and/or header of the document ? If not, I suggest
> exporting as:
> \section[not-so-plain text]{\uline{not-so-plain} \textbf{text}}
This we cannot know before hand and for all cases. I cannot think of
any case where you would use any kind of styling—other than math—in
section titles. Yet others might and I think this suggestion is too
strong of an "assumption".
Perhaps it could be provided as an option.
> Also I don't know why there was underlining in the first place. If we're
> asking to underline all section titles, then it might make sense to
> redefine e.g. \section to do so (packages titlesec might help).
Yeah, that would be a better approach if the underlines are not
one-off. . .
Rasmus
--
C is for Cookie
Re: [O] org-export-latex-hyperref-options-format
Aloha Nick,
Nick Dokos writes:
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Aloha Nick,
>>
>> Nick Dokos writes:
>>
>>> #+BIND is supposed to bind the variable *during export*. The test is to
>>> run the export and see if the hyperref stuff is gone from the tex file.
>>>
>>> Nick
>>
>> I did run the export and the hyperref stuff was still in the tex file.
>>
>> I'm exporting asynchronously--perhaps that's the problem? The old
>> #+OPTIONS: texht:nil worked for asynchronous export, though, so I was
>> expecting that BIND would do the same.
>>
>
> I tried both with and without async (deleting the tex file before
> starting each time - I also used the default latex class, since I don't
> have plos-devel): either way the hyperref stuff was gone.
It is part of an Org mode template for the open access journal PLOS
One. You can find it here, if need be:
http://orgmode.org/worg/exporters/plos-one-template-worg.html
The template is set up to produce two pdf files, one with hyperref and
the other without. I suspect this is the root of the problem I'm
having. The old option used to suppress the hyperref stuff in one of
the tex files, but kept it available for the other tex file.
Somehow, the logic of that has changed and I suspect I'm going to have
to find a way to set up hyperref for the document that needs it, rather
than shutting it off for the document that doesn't need it.
I had a look at ox-latex and the PLOS One template this morning over
coffee, but wasn't able to find a smoking gun.
Your simple test case works as expected here.
All the best,
Tom
>
> Here's the org file:
>
> #+TITLE: Structure and Growth of the Leeward Kohala Field System: An Analysis
> with Directed Graphs
> #+DATE:
> #+LANGUAGE: en
> #+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t ':t
> ^:{}
> #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:nil pri:nil tags:not-in-toc
> #+BIND: org-latex-hyperref-template ""
> #+STARTUP: entitiespretty
> #+PROPERTY: header-args:sh :eval no-export
>
> * foo
>
> bar
>
>
> Org-mode version 8.2.5h (release_8.2.5h-782-g040ec4 @
> /home/nick/elisp/org-mode/lisp/)
>
> Nick
>
>
>
>
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Org is awesome
I would really like to see the resulting paper too! On Sat, Mar 22, 2014 at 5:35 PM, Dave Taht wrote: > On Sat, Mar 22, 2014 at 4:31 PM, Grant Rettke > wrote: > > Thank you for sharing. > > > > We all benefit greatly from others monumental efforts of others. > > > > Thanks, to them. > > > > > > On Fri, Mar 21, 2014 at 11:58 PM, James Harkins > > wrote: > >> > >> After 243 commits to a constellation of org files, producing 10849 lines > >> of LaTeX code from the Beamer exporter, which render into 229 pages of > >> beamerarticle print-ready material, including 156 captioned code > listings > >> (and a handful of un-numbered ones) and 27 pages of fully indexed > glossary > >> entries (whose LaTeX code comes from emacs-lisp source blocks > processing org > >> tables), I think I'm in a position to state with confidence: > >> > >> ORG IS AWESOME. > >> > >> "Thanks to all the developers" is insufficient. > >> > >> hjh > > Share the resulting paper? > > > > > > > > > > -- > > Grant Rettke | ACM, AMA, COG, IEEE > > g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ > > “Wisdom begins in wonder.” --Socrates > > ((λ (x) (x x)) (λ (x) (x x))) > > “Life has become immeasurably better since I have been forced to stop > taking > > it seriously.” --Thompson > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > >
Re: [O] Is there an environment for Org syntax?
Hi Bastien, > The indentation of the exported HTML looks correct to me: > "some text" is right below "*** Third level" > The HTML color of the leading stars is taken from the org-hide face. > When your background is black, the org-hide face is black, hence the > color you see in the HTML output. Let me reformulate. I'm looking for a way to tell the HTML exporter how to format Org syntax. I was expecting it to format it according to my own preferences. For example, I usually set org-indent-mode to t since it is cleaner. But this is not taken into account by the HTML exporter: it produces a 'standard' Org syntax, the one you get by default without any configuration, with visible leading stars and no indentation. Is it possible to change that? Two other minor observations. 1. I changed the org-hide face to other colors, like red (just for trying, since I didn't know about that possibility). As soon as I export an Org buffer to HTML, the org-hide face comes back to its initial value: the leading stars are back from red to invisible. This might be anormal. 2. About the black leading stars in my previous posts, I found the problem: when org-indent-mode is activated by setting org-startup-indented to t, it produces black leading stars in my HTML output. This doesn't happen when it is activated using the org-indent-mode function or when '#+STARTUP: indent' is in the file. This might be a bug too. Thanks for your time, FC
Re: [O] preview and default class [8.2.5h (release_8.2.5h-677-g55b0a3 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Bastien writes: > Thanks, applied on master, with a slight change in the Changelog > entry. Ok thanks. For my information, did C-x 4 a work for you in adding the section name or did you add it manually ? -- Nico.
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Nicolas Goaziou writes:
> It is technically possible to use \underline (hard-coded) in sections
> and \uline (or whatever is defined in`org-latex-text-markup-alist')
> everywhere else.
>
> Is there any downside to this proposal?
Disclaimer : While I do use LaTeX, I rarely use the exporter, and never
underline in sections.
(The shed should be green, obviously.)
I don't know why \uline doesn't work, but while \underline works, it
does so with many warnings. I think the reason is that hyperref tries to
add the text to the PDF TOC (usually a pane in the pdf viewer), and that
supports very little to no formatting.
Rasmus' suggestion seemed good, i.e.
\texorpdfstring{\uline{SECTION}}{SECTION}
I'd go even a little further : assuming it makes sense to underline
within a section header, does it also make sense to propagate that
formatting to the toc and/or header of the document ? If not, I suggest
exporting as:
\section[not-so-plain text]{\uline{not-so-plain} \textbf{text}}
Also I don't know why there was underlining in the first place. If we're
asking to underline all section titles, then it might make sense to
redefine e.g. \section to do so (packages titlesec might help).
--
Nico.
Re: [O] preview and default class [8.2.5h (release_8.2.5h-677-g55b0a3 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Hi Nicolas, Nicolas Richard writes: > Done Thanks, applied on master, with a slight change in the Changelog entry. -- Bastien
Re: [O] Org is awesome
On Sat, Mar 22, 2014 at 4:31 PM, Grant Rettke wrote: > Thank you for sharing. > > We all benefit greatly from others monumental efforts of others. > > Thanks, to them. > > > On Fri, Mar 21, 2014 at 11:58 PM, James Harkins > wrote: >> >> After 243 commits to a constellation of org files, producing 10849 lines >> of LaTeX code from the Beamer exporter, which render into 229 pages of >> beamerarticle print-ready material, including 156 captioned code listings >> (and a handful of un-numbered ones) and 27 pages of fully indexed glossary >> entries (whose LaTeX code comes from emacs-lisp source blocks processing org >> tables), I think I'm in a position to state with confidence: >> >> ORG IS AWESOME. >> >> "Thanks to all the developers" is insufficient. >> >> hjh Share the resulting paper? > > > > -- > Grant Rettke | ACM, AMA, COG, IEEE > g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ > “Wisdom begins in wonder.” --Socrates > ((λ (x) (x x)) (λ (x) (x x))) > “Life has become immeasurably better since I have been forced to stop taking > it seriously.” --Thompson -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
Re: [O] Org is awesome
Thank you for sharing. We all benefit greatly from others monumental efforts of others. Thanks, to them. On Fri, Mar 21, 2014 at 11:58 PM, James Harkins wrote: > After 243 commits to a constellation of org files, producing 10849 lines > of LaTeX code from the Beamer exporter, which render into 229 pages of > beamerarticle print-ready material, including 156 captioned code listings > (and a handful of un-numbered ones) and 27 pages of fully indexed glossary > entries (whose LaTeX code comes from emacs-lisp source blocks processing > org tables), I think I'm in a position to state with confidence: > > ORG IS AWESOME. > > "Thanks to all the developers" is insufficient. > > hjh > -- Grant Rettke | ACM, AMA, COG, IEEE g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] preview and default class [8.2.5h (release_8.2.5h-677-g55b0a3 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Hello Bastien,
Bastien writes:
> Just add a missing full-stop at the end of the Changelog sentence "in
> its own section.",
Done
> and perhaps use `C-x 4 a' from within the diff to
> include the section's name in the Changelog too.
I tried that in both parts of the diff, but then I get :
* org.texi (used, lines):
(The lines 'used:' and 'lines:' appear in that file.)
I guess that's not the intended result so I left that as is.
> PS: I didn't check carefully because I don't use `C' from magit, but
> I assume magit may be wrong in creating Changelogs. We should report
> this to magit maintainers if this is true.
In this case it seems that nothing was better than doing what C-x 4 a
did, so I didn't check further.
Here's the new patch :
>From cf5246c5f44fe637cb2000cf92b2f47499d7b8d2 Mon Sep 17 00:00:00 2001
From: Nicolas Richard
Date: Thu, 6 Mar 2014 13:21:41 +0100
Subject: [PATCH] Keep documentation on "Previewing LaTeX" in its own section
* doc/org.texi: Keep documentation on "Previewing LaTeX" in its own
section.
---
doc/org.texi | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index e835022..2abfa66 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10147,19 +10147,13 @@ format sub- and superscripts in a WYSIWYM way.
Going beyond symbols and sub- and superscripts, a full formula language is
needed. Org mode can contain @LaTeX{} math fragments, and it supports ways
to process these for several export back-ends. When exporting to @LaTeX{},
-the code is obviously left as it is. When exporting to HTML, Org invokes the
-@uref{http://www.mathjax.org, MathJax library} (@pxref{Math formatting in
+the code is obviously left as it is. When exporting to HTML, Org can invoke
+the @uref{http://www.mathjax.org, MathJax library} (@pxref{Math formatting in
HTML export}) to process and display the math@footnote{If you plan to use
this regularly or on pages with significant page views, you should install
@file{MathJax} on your own server in order to limit the load of our server.}.
-Finally, it can also process the mathematical expressions into
-images@footnote{For this to work you need to be on a system with a working
-@LaTeX{} installation. You also need the @file{dvipng} program or the
-@file{convert}, respectively available at
-@url{http://sourceforge.net/projects/dvipng/} and from the @file{imagemagick}
-suite. The @LaTeX{} header that will be used when processing a fragment can
-be configured with the variable @code{org-format-latex-header}.} that can be
-displayed in a browser.
+It can also process the mathematical expressions into images that can be
+displayed in a browser (see @pxref{Previewing @LaTeX{} fragments}).
@LaTeX{} fragments don't need any special marking at all. The following
snippets will be identified as @LaTeX{} source code:
@@ -10217,11 +10211,21 @@ lines:
@cindex @LaTeX{} fragments, preview
@vindex org-latex-create-formula-image-program
-If you have @file{dvipng} or @file{imagemagick} installed@footnote{Choose the
-converter by setting the variable
+If you have a working @LaTeX{} installation and either @file{dvipng} or
+@file{convert} installed@footnote{These are respectively available at
+@url{http://sourceforge.net/projects/dvipng/} and from the @file{imagemagick}
+suite. Choose the converter by setting the variable
@code{org-latex-create-formula-image-program} accordingly.}, @LaTeX{}
-fragments can be processed to produce preview images of the typeset
-expressions:
+fragments can be processed to produce images of the typeset expressions to be
+used for inclusion while exporting to HTML (see @pxref{@LaTeX{} fragments}),
+or for inline previewing within Org mode.
+
+@vindex org-format-latex-options
+@vindex org-format-latex-header
+You can customize the variables @code{org-format-latex-options} and
+@code{org-format-latex-header} to influence some aspects of the preview. In
+particular, the @code{:scale} (and for HTML export, @code{:html-scale})
+property of the former can be used to adjust the size of the preview images.
@table @kbd
@kindex C-c C-x C-l
@@ -10237,12 +10241,6 @@ process the entire buffer.
Remove the overlay preview images.
@end table
-@vindex org-format-latex-options
-You can customize the variable @code{org-format-latex-options} to influence
-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 in a file with
--
1.9.1
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Nicolas Goaziou writes: > You call it extreme, I label it ambitious. > > Also, "getting rid of it" really means "no need to change it anymore". > I'd rather have a static complex regexp than a simple customizable one > for the sake of syntax consistency. Of course, a fixed simple regexp is > better (and no regexp at all is even better). Fully agreed. >> Also, there is no "backward-compatibility squad", only users who care >> about what they like. > > That is what they want us to believe! :) I don't know who is "us" ;) -- Bastien
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Bastien writes: > What I'm after is a bit different: Is it? > - keep single character markup; > > - simplify `org-emphasis-regexp-components' (getting it of it is the > extreme version of simplifying it); You call it extreme, I label it ambitious. Also, "getting rid of it" really means "no need to change it anymore". I'd rather have a static complex regexp than a simple customizable one for the sake of syntax consistency. Of course, a fixed simple regexp is better (and no regexp at all is even better). > - allow a more liberal multiline markup fontification where the user > does not have to tweak `org-emphasis-regexp-components'. Which is basically "getting rid of it". See above. > Midword markup is not a priority to me, but I understand how it could > be useful, this would certainly be a plus. I agree. This is not a priority, I wasn't clear on this point. > Also, there is no "backward-compatibility squad", only users who care > about what they like. That is what they want us to believe! :) Regards, -- Nicolas Goaziou
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hi Andreas, I'm also in favor of breaking backward compatibility when it benefits Org's users and developers. We should not consider changes only in terms of backward compatibility, we should also consider them by themselves. What I like with *this markup* is that it's non-intrusive: it's easy to type and it does not clutter the document. And in general, I'd rather fix problems then getting rid of them for maintainability purpose. What's the problems with *this markup*? It is difficult to get proper fontification in some cases, fontification of multiple lines is not reliable beyond a certain amout of lines, and we cannot nest markup. Until someone has taken the time to seriously try to fix those problems without changing the current feature, I don't think we should consider changing the feature itself. But of course, this is always a trade-off. -- Bastien
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hi all, Bastien writes: [ ...] > > Also, there is no "backward-compatibility squad", only users who care > about what they like. I have been part in threads that discuss backward-compatibility. As it looks, there is the feeling that this ML is too(?) much concerned about backward-compatibility -- even in favour over new features or cleaner implementation (both of which the proposed emphasis change would be an example of, IIUC). In a way, I am happy that backward-compatibility is now a major concern. But on the other hand, it is not my intention to block enhancements. For the case at hand, I would happily type double letter emphasis, if that helps to get a clean implementation. If it even allows more features, that would be a benefit. My point of writing is this: If a change like this was going to happen, it would be very nice if a function was provided to change from the old style to the new style. This was (at least) once the case for a major backward incompatible change in babel and even if it did not work flawlessly it was a big help. I guess it would be easy for the lisp-guru who removes the regexp to turn it into such a function. But it would take quite some time for me to dig that regexp somewhen later and produce a working translation function from it... Anyway, as it looks this is probably hypothetical for this particular change. Regards, Andreas
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hi Nicolas, Nicolas Goaziou writes: > In a nutshell, I don't think this will go past the active > "backward-compatibility" squad on the ML. What we're really after is > a way to > > - keep single character markup ; > - get rid of `org-emphasis-regexp-components' ; > - allow midword markup. What I'm after is a bit different: - keep single character markup; - simplify `org-emphasis-regexp-components' (getting it of it is the extreme version of simplifying it); - allow a more liberal multiline markup fontification where the user does not have to tweak `org-emphasis-regexp-components'. Midword markup is not a priority to me, but I understand how it could be useful, this would certainly be a plus. Also, there is no "backward-compatibility squad", only users who care about what they like. -- Bastien
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Bastien writes: > Nicolas Goaziou writes: > >> Here is the patch. b399ff0cba2382bf52d5bb6ef2b4a776fe0ac902 needs to be >> reverted first. > > Please go ahead, thanks, Done. Regards, -- Nicolas Goaziou
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Nicolas Goaziou writes: > Here is the patch. b399ff0cba2382bf52d5bb6ef2b4a776fe0ac902 needs to be > reverted first. Please go ahead, thanks, -- Bastien
Re: [O] [RFC] Creole-style / Support for **emphasis**__within__**a word**
Hello, Jambunathan K writes: > [RFC] Creole-style / Support for **emphasis**__within__**a word** > > The attached files should speak for themselves. Such an arrangement > > a) Does not change the status quo AT ALL. > b) Provide more rope. > > The patch is in the spirit of "show and tell". I will not provide a > formal patch. > > What about formalizing such an arrangement... FWIW I think is the idea is very interesting. This is more verbose, but it could allow us to get rid of the terrible `org-emphasis-regexp-components' variable. Unfortunately, this would introduce incompatibilities in old documents, unless that is, we keep checking `org-emphasis-regexp-components', but then, the change would become, IMO, much less desirable. In a nutshell, I don't think this will go past the active "backward-compatibility" squad on the ML. What we're really after is a way to - keep single character markup ; - get rid of `org-emphasis-regexp-components' ; - allow midword markup. Good luck. Regards, -- Nicolas Goaziou
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Bastien writes:
> I don't know but it looks good to me, because the shortcomings of
> \underline not being able to wrap are not a problem for sections.
Here is the patch. b399ff0cba2382bf52d5bb6ef2b4a776fe0ac902 needs to be
reverted first.
Regards,
--
Nicolas Goaziou
>From 7a6bcad9dea5dd8a7c8b15f942191046f63f262f Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Sat, 22 Mar 2014 14:23:23 +0100
Subject: [PATCH] ox-latex: Fix underline in sections
* lisp/ox-latex.el (org-latex-headline): Hard-code "\underline" in
sections because "\uline" ("ulem" package) returns an error and
"\ul" ("soul" package) doesn't support chinese characters.
See http://permalink.gmane.org/gmane.emacs.orgmode/83962 for the
related thread.
---
lisp/ox-latex.el | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3d51ce5..b49a157 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1344,7 +1344,16 @@ holding contextual information."
((= (length sec) 4)
(if numberedp (concat (car sec) "\n%s" (nth 1 sec))
(concat (nth 2 sec) "\n%s" (nth 3 sec)))
- (text (org-export-data (org-element-property :title headline) info))
+ ;; Create a temporary export back-end that hard-codes
+ ;; "\underline" within "\section" and alike.
+ (section-back-end
+ (org-export-create-backend
+ :parent 'latex
+ :transcoders
+ '((underline . (lambda (o c i) (format "\\underline{%s}" c))
+ (text
+ (org-export-data-with-backend
+ (org-element-property :title headline) section-back-end info))
(todo
(and (plist-get info :with-todo-keywords)
(let ((todo (org-element-property :todo-keyword headline)))
@@ -1397,8 +1406,9 @@ holding contextual information."
(let ((opt-title
(funcall org-latex-format-headline-function
todo todo-type priority
- (org-export-data
- (org-export-get-alt-title headline info) info)
+ (org-export-data-with-backend
+ (org-export-get-alt-title headline info)
+ section-back-end info)
(and (eq (plist-get info :with-tags) t) tags
(if (and numberedp opt-title
(not (equal opt-title full-text))
--
1.9.1
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Hi Nicolas, Nicolas Goaziou writes: > It is technically possible to use \underline (hard-coded) in sections > and \uline (or whatever is defined in`org-latex-text-markup-alist') > everywhere else. > > Is there any downside to this proposal? I don't know but it looks good to me, because the shortcomings of \underline not being able to wrap are not a problem for sections. -- Bastien
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Hello, Konstantin Kliakhandler writes: > If it matters, I think that it would be preferable to solve it in a way that > exports the intended emphasis, rather than deletes it (although I'm not > sure how to acheive thise). > > Surely there is a latex command that underlines stuff inside section > headings as well? It is technically possible to use \underline (hard-coded) in sections and \uline (or whatever is defined in`org-latex-text-markup-alist') everywhere else. Is there any downside to this proposal? Regards, -- Nicolas Goaziou
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Nicolas Goaziou writes: > This comes from commit 4fc03ec1fe23c6ddccffaa064a282b258ca8b6b8. > > See thread at: > > http://comments.gmane.org/gmane.emacs.orgmode/67741 If it matters, I think that it would be preferable to solve it in a way that exports the intended emphasis, rather than deletes it (although I'm not sure how to acheive thise). Surely there is a latex command that underlines stuff inside section headings as well? Regards, Kosta
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Nicolas Goaziou writes:
> Bastien writes:
>
>> Yes, maybe there is a better fix.
>>
>> If you can find why you used \uline instead of \ul that will help
>> spot possible problems with the current fix, of course.
>>
>> I'm not for getting rid of the problem before we can tell for sure
>> why the current solution is wrong.
>
> This comes from commit 4fc03ec1fe23c6ddccffaa064a282b258ca8b6b8.
>
> See thread at:
>
> http://comments.gmane.org/gmane.emacs.orgmode/67741
Another possible fix is to (i) check if hyperref is being used, and
(ii) escape using \texorpdfstring{\uline{SECTION}}{SECTION}. This
also works with stuff like $\bm{\beta}$. Sometimes it also helps to
pass the arguments 'unicode, psdextra' to hyperref, but it doesn't
work in this case.
--
ツ
Re: [O] Extending the Org syntax by a custom exporter - how to do it?
Hello, Marcin Borkowski writes: > I started to wonder and came to the conclusion that this might be > interesting for my "cloze" idea (with syntax as in one of my previous > messages). However, I can't really understand what is going on here. > It seems to me that the key function is > org-latex--wrap-latex-math-block; it is, however, a bit long and I'm a > bit afraid of studying it (and don't have enough time today for that > anyway). What would you suggest for grokking the idea of > "pseudo-objects"? In particular: > > - How do they get parsed? What portions of the source should I read > to understand that? They are not parsed. You create a new parsed object or element out of thin air, or alter existing markup under certain conditions, and insert it in the parse tree before it gets interpreted by an export back-end. > - Would it be a good idea to instrument one (or more) functions for > edebug to get the idea of what's going on there? Edebug will help only if you have a good mental representation of the parse tree (or at least a function to display it when it is short enough), but it is a valuable tool to understand what happens. Regards, -- Nicolas Goaziou
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Bastien writes: > Yes, maybe there is a better fix. > > If you can find why you used \uline instead of \ul that will help > spot possible problems with the current fix, of course. > > I'm not for getting rid of the problem before we can tell for sure > why the current solution is wrong. This comes from commit 4fc03ec1fe23c6ddccffaa064a282b258ca8b6b8. See thread at: http://comments.gmane.org/gmane.emacs.orgmode/67741 Regards, -- Nicolas Goaziou
Re: [O] [POLL] Do you need special entities in radio target?
Hello, Christian Moe writes: > But is this only about special entities, or about all Org syntax, the latter. > including subscripts/superscripts, emphasis...? That would be > limiting. As long as radio targets are visible parts of the text, I'd > like them to continue supporting such markup. So far, radio targets only support entities, subscript and superscript. Emphasis is not supported. I don't think it's a limitation, though, because radio targets can be contained within emphasis markup. Regards, -- Nicolas Goaziou
Re: [O] stderr patch
On 03/22/2014 02:43 AM, Michael Brand wrote: > > For two reasons I would much prefer if there would be not yet another > variable org-* but a header argument or a new value for e. g. > ":results": > - When someone would use org-babel-use-error-buffer then sharing Org > source blocks would be less easy. > - With a header argument it would be possible to have different > behaviors in different Org source blocks which is also a requirement > for backward compatibility of existing source blocks (I would want > them to let babel execution still fail in case of a problem). > > There are also use cases where I would want to capture stderr but let > babel execution fail when the exit status is non-zero, see [2]. I had the similar thoughts. I just wanted to share in case someone out there wanted to apply the patch for themselves until it's done right within org mode. I started on making a header argument, but it will be a while before I finish. - Ian
[O] how to produce right link for jekyll
hi, all
I Using org to Blog with Jekyll.
I want to get a right link to link to blog server's relative path after
publishing, the following is corressponding setting and source:
1. .emacs snippet
("org-static-dillon"
:base-directory "/study/doctor/note/org"
:base-extension
"css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf\\|php"
:publishing-directory "/study/doctor/note/myblog-jekyll/pdf"
:recursive t
:publishing-function org-publish-attachment)
2. org code snippet
[[pdf/sigmod05.demo.pdf][]]
I found 's link path was ,
but I hope it produce a path such as
"http://localhost:4000/pdf/sigmod05.demo.pdf";.
I know i must miss something, plsease any one help me, thanks in advance!
BEST REGARDS
Dillon
Re: [O] stderr patch
Hi Ian On Sat, Mar 22, 2014 at 4:59 AM, Ian Kelling wrote: > I use babel mostly for shell scripts. I wrote a patch to allow toggling the > handling of errors & std err. I prefer standard error just get printed with > everything else, the same as calling a script from a terminal. Doing this > properly > with header arguments etc. has been discussed before (google org-babel > stderr), > and just hasn't gotten done yet. Until then, this works great, so I'm putting > it > out there in case anyone wants to use it. I am generally concerned about respecting the exit status [1] and stderr of a process, also in Org babel [2]. Thank you for taking care of it. > +(defcustom org-babel-use-error-buffer t > + "When evaluating a code block, if nil and an error is returned > +,no error buffer is created and. Standard error > +is redirected to standard out." > +:group 'org-babel > +:version "24.1" > +:type 'boolean) For two reasons I would much prefer if there would be not yet another variable org-* but a header argument or a new value for e. g. ":results": - When someone would use org-babel-use-error-buffer then sharing Org source blocks would be less easy. - With a header argument it would be possible to have different behaviors in different Org source blocks which is also a requirement for backward compatibility of existing source blocks (I would want them to let babel execution still fail in case of a problem). There are also use cases where I would want to capture stderr but let babel execution fail when the exit status is non-zero, see [2]. Michael [1] My shell prompt ($PS1) contains the exit status ($?), my shell scripts contain "set -o errexit; set -o pipefail". [2] See my lengthy post here: http://thread.gmane.org/gmane.emacs.orgmode/45828/focus=46415
Re: [O] [POLL] Do you need special entities in radio target?
Excluding special entities would not interfere with anything I've done with radio targets so far. I can imagine future uses, but probably nothing I couldn't work around with Unicode. But is this only about special entities, or about all Org syntax, including subscripts/superscripts, emphasis...? That would be limiting. As long as radio targets are visible parts of the text, I'd like them to continue supporting such markup. Yours, Christian Bastien writes: > Hi all, > > the subject says it all -- see this thread for reference: > http://thread.gmane.org/gmane.emacs.orgmode/83648 > > Would you be okay if radio targets like <<>> > are limited to plain text? > > Thanks for your feedback,
Re: [O] stderr patch
Ian Kelling writes: > We've been in email contact less than a week ago. It shouldn't be > too long. Okay, this takes usually up to 6 weeks, so don't hold you breath! -- Bastien
Re: [O] stderr patch
> Was it more than a month ago? If so, I'll ping them. We've been in email contact less than a week ago. It shouldn't be too long.
Re: [O] stderr patch
Hi Ian, Ian Kelling writes: > I'd be happy to clean it up if there is interest in merging it. Also I've > done the > FSF paperwork a while ago, I'm just waiting on hearing confirmation. Was it more than a month ago? If so, I'll ping them. Let's wait for Eric's answer about whether the patch should be applied or not, but for me yes. -- Bastien
Re: [O] [bug] [babel] babel corrupts undo history
aha. yes, that's it. thank you.
Re: [O] stderr patch
On 03/22/2014 01:45 AM, Bastien wrote: > Hi Ian, > > the idea behind the patch looks good, although the patch needs > some clean-up (adding a Changelog entry, fixing the typos in the > docstring, etc.) > > Also, the patch goes beyond the 15 lines: we cannot accept it > until you sign the FSF copyright assignment. If you're willing > to do this, please fill this form: > > http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt > > Eric, can you have a look and let us know if this is good to > apply to master in a rewritten version? > > Thanks, > I'd be happy to clean it up if there is interest in merging it. Also I've done the FSF paperwork a while ago, I'm just waiting on hearing confirmation. - Ian
Re: [O] stderr patch
Hi Ian, the idea behind the patch looks good, although the patch needs some clean-up (adding a Changelog entry, fixing the typos in the docstring, etc.) Also, the patch goes beyond the 15 lines: we cannot accept it until you sign the FSF copyright assignment. If you're willing to do this, please fill this form: http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt Eric, can you have a look and let us know if this is good to apply to master in a rewritten version? Thanks, -- Bastien
Re: [O] [bug] [babel] babel corrupts undo history
Samuel Wales writes: > here is the fix for bug #3: There was a fix for this in master by Aaron. I assumed you were reporting errors on master. I've now cherry-pick the fix to maint, since it's a fix. If you find other problems, please first test the master branch to check if they have been fixed there. Thanks, -- Bastien
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Hi Nicolas, Nicolas Goaziou writes: > I don't think this is the right fix. IIRC, I replaced "\ul" with > "\uline" a while ago for some reason (maybe a problem with newline > or unicode, I cannot remember). This would go backwards. > > There are probably other solutions (e.g., remove all underline markup in > sections). Yes, maybe there is a better fix. If you can find why you used \uline instead of \ul that will help spot possible problems with the current fix, of course. I'm not for getting rid of the problem before we can tell for sure why the current solution is wrong. -- Bastien
Re: [O] Emacs freezes
Hello, Christopher Witte writes: > I'm getting a weird problem with orgmode and flyspell mode. Using the > latest version of org from git, open the attached file test.org and run M-x > flyspell-mode, emacs will lock up. It has something to do with tables. > > Alternatively, make a new (empty) org file, run flyspell-mode, and start > making a new table by writing |sdf|sdf|, and it will lock up emacs. > > Using an older version of org (7.9.3) this problem doesn't occur. > > I'm using Emacs 24.3.1 on Ubuntu 12.04. > > Any ideas what could be causing this? Yes, two entries with the same key in cache. Anyway it should be fixed now. Thank you for the detailed report, and sorry for the delay. Regards, -- Nicolas Goaziou
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Hello, Bastien writes: > Konstantin Kliakhandler writes: > >> It appears that org-mode produces invalid latex code. An example >> follows. > > Fixed, thanks, I don't think this is the right fix. IIRC, I replaced "\ul" with "\uline" a while ago for some reason (maybe a problem with newline or unicode, I cannot remember). This would go backwards. There are probably other solutions (e.g., remove all underline markup in sections). Regards, -- Nicolas Goaziou
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Thanks! On Sat, Mar 22, 2014 at 1:32 AM, Bastien wrote: > Hi Konstantin, > > Konstantin Kliakhandler writes: > > > It appears that org-mode produces invalid latex code. An example > > follows. > > Fixed, thanks, > > -- > Bastien >
Re: [O] Org is awesome
James Harkins writes: > After 243 commits to a constellation of org files, producing 10849 > lines of LaTeX code from the Beamer exporter, which render into 229 > pages of beamerarticle print-ready material, including 156 captioned > code listings (and a handful of un-numbered ones) and 27 pages of > fully indexed glossary entries (whose LaTeX code comes from > emacs-lisp source blocks processing org tables), I think I'm in a > position to state with confidence: Nice use-case ! > ORG IS AWESOME. Tell it to the world with a blog entry :) -- Bastien
Re: [O] Bug: performance of scrolling in large example blocks is poor
Hi Ian, Ian Kelling writes: > Testcase: 1 megabyte of text lines in an example block, drag the scrollbar to > a > location you haven't been to yet. > > It often freezes for a few seconds, and doing things while its frozen like > scrolling more can quickly make it freeze for a minute or so. Remove the > example > block enclosure, and it becomes totally interactive. Yes, there is room for improvement in the fontification engine of Org, but this requires a lot of rewrite. For now I suggest not to add 1 megabyte of text in a source code block... -- Bastien
