Re: latex fragments compilation error when exporting to html
Hello,
Nick Dokos writes:
> Jeremie Juste writes:
>
>> Hello
>>
>> When I export test.org to html, the latex fragment fail to compile.
>> The reason is a star get added to the tabular environment. {tabular*}
>> (see tmpfile.tex).
>>
>> I don't know why the function insists in using the tabular* environment.
>>
>> From this point I would have two questions:
>>
>> How can I remove the star from the tabular environment ?
>> How can I can I find the culprit?
>> - I was hoping to provide a patch by finding the culprit but I got lost.
>> - I tried to debug-on-entry org-format-latex.
>>
>>
>> Best regards,
>> Jeremie
>>
>>> test.org
>>
>> #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t
>> tex:imagemagick title:nil author:nil date:nil
>> #+LATEX_HEADER: \usepackage{booktabs}
>>
>> \begin{tabular}{lll}
>> \toprule
>> 1 & 2 & 3 \\
>> 5 & 6 & 8 \\
>> \bottomrule
>> \end{tabular}
>>
>>> tmpfile.tex
>>
>> ...
>>
>> {\color{fg}
>> \begin{tabular*}{lll}
>> \toprule
>> 1 & 2 & 3 \\
>> 5 & 6 & 8 \\
>> \hline
>> \end{tabular*}
>> %
>> }
>>
>>
>
> I cannot reproduce it with Org mode version 9.3.7 (release_9.3.7-705-gea9463
> @ /home/nick/src/emacs/org/org-mode/lisp/).
> What version are you using?
Thanks for have taken the time to check.
The org-version I was using was
Org mode version 9.3.7 (9.3.7-13-ge62ca4-elpaplus @
/home/djj/.emacs.d/elpa/org-plus-contrib-20200713/)
I updated to the latest version on melpa but the issue persists
Org mode version 9.3.7 (9.3.7-24-g7b657c-elpa @
/home/djj/.emacs.d/elpa/org-20200831/)
Best regards,
Jeremie
Re: how to create next, previous, and up navigation links when exporting to html
Christopher W. Ryan writes: > how do I create next, previous, and up navigation links when exporting > to html, like in the org mode manual: > > https://orgmode.org/manual/HTML-specific-export-settings.html I think that's created in a two-step process: using org-texinfo-export-to-texinfo to generate a .texi file from org-manual.org and then feeding that result to makeinfo.
Re: [PATCH] ob-core: Avoid table conversion warning for empty results
Colin Baxter writes: > >> This patch would squelch the inappropriate warning you report > >> while not hiding other warnings. > > > Thank you. I'll apply the patch to my org-mode and report back. > > I have now applied the patch to my local org-mode git repository and it > works with no reported errors. Thanks again. Thanks for trying it out. Applied (7bc18ebbe).
Re: latex fragments compilation error when exporting to html
Jeremie Juste writes:
> Hello
>
> When I export test.org to html, the latex fragment fail to compile.
> The reason is a star get added to the tabular environment. {tabular*}
> (see tmpfile.tex).
>
> I don't know why the function insists in using the tabular* environment.
>
> From this point I would have two questions:
>
> How can I remove the star from the tabular environment ?
> How can I can I find the culprit?
> - I was hoping to provide a patch by finding the culprit but I got lost.
> - I tried to debug-on-entry org-format-latex.
>
>
> Best regards,
> Jeremie
>
>> test.org
>
> #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t
> tex:imagemagick title:nil author:nil date:nil
> #+LATEX_HEADER: \usepackage{booktabs}
>
> \begin{tabular}{lll}
> \toprule
> 1 & 2 & 3 \\
> 5 & 6 & 8 \\
> \bottomrule
> \end{tabular}
>
>> tmpfile.tex
>
> ...
>
> {\color{fg}
> \begin{tabular*}{lll}
> \toprule
> 1 & 2 & 3 \\
> 5 & 6 & 8 \\
> \hline
> \end{tabular*}
> %
> }
>
>
I cannot reproduce it with Org mode version 9.3.7 (release_9.3.7-705-gea9463 @
/home/nick/src/emacs/org/org-mode/lisp/).
What version are you using?
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
latex fragments compilation error when exporting to html
Hello
When I export test.org to html, the latex fragment fail to compile.
The reason is a star get added to the tabular environment. {tabular*}
(see tmpfile.tex).
I don't know why the function insists in using the tabular* environment.
>From this point I would have two questions:
How can I remove the star from the tabular environment ?
How can I can I find the culprit?
- I was hoping to provide a patch by finding the culprit but I got lost.
- I tried to debug-on-entry org-format-latex.
Best regards,
Jeremie
> test.org
#+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t
tex:imagemagick title:nil author:nil date:nil
#+LATEX_HEADER: \usepackage{booktabs}
\begin{tabular}{lll}
\toprule
1 & 2 & 3 \\
5 & 6 & 8 \\
\bottomrule
\end{tabular}
> tmpfile.tex
...
{\color{fg}
\begin{tabular*}{lll}
\toprule
1 & 2 & 3 \\
5 & 6 & 8 \\
\hline
\end{tabular*}
%
}
Re: [feature request] A new cookie type [!] showing the last note taken
Hello, Ihor Radchenko writes: > Instead of linking to the function, we can define the format used by > `org-add-note' as a formal format for notes. Currently `org-add-note' > uses the following format: > > - \\ > This is not specific enough to be considered as syntax. The risk of false positive is too high. This is the reason why notes were never considered as syntactically meaningful so far. > The is taken from `org-log-note-headings'. This is configurable, which is not a good idea for any new syntax. Regards, -- Nicolas Goaziou
org-format-outline-path fonts sizes in the minibuffer
*I’m not sure If this is actually a bug so I haven’t included any backtrace/debug information.* Forgive me I am not sure the exact terminology. I have, within the last two weeks, began to transition to emacs from vim, specifically for org mode. In addition I am not a developer by trade and my knowledge of elisp is limited. What exactly did you do? Move cursor to any header in a .org file. What did you expect to happen? An outline to appear within the “echo area,” which does not resize the minibuffer. What happened instead? I have set various headers to various faces and sizes, when I move my cursor over a header the outline appears to use all of the fonts information when displaying it in the minibuffer/echo area. What should happen? Of course this is subjective, but I believe that only the color should be passed on in the outline if anything. Or some variables exposed that can be set to change this behavior. (setq org-outline-echo OPTION) t - Defualt Behavior color-only - Passes the color of the headers to the outline in the echo area plain-text - just passes the text letting the fonts already set elsewhere display Or some kind of hook that lets us choose what fonts to use for which heading in the echo. You can see a picture of what is occurring here. https://preview.redd.it/2cgllvc9aak51.png?width=1638=png=webp=f7636f477b08aba5c0b34b3e49611de3fba82188 A fellow Redditor u/BulkyLoad87 proposed this solution, which appears to work, but I’m not sure what else this might effect. (defun org-format-outline-path (path width prefix separator) "Format the outline path PATH for display. WIDTH is the maximum number of characters that is available. PREFIX is a prefix to be included in the returned string, such as the file name. SEPARATOR is inserted between the different parts of the path, the default is \"/\"." (setq width (or width 79)) (setq path (delq nil path)) (unless (> width 0) (user-error "Argument `width' must be positive")) (setq separator (or separator "/")) (let* ((org-odd-levels-only nil) (fpath (concat prefix (and prefix path separator) (mapconcat (lambda (s) (replace-regexp-in-string "[ \t]+\\'" "" s)) (cl-loop for head in path for n from 0 for face = (nth (% n org-n-level-faces) org-level-faces) collect (org-add-props head nil 'face `(:foreground ,(face-foreground face nil t) :weight bold))) separator (when (> (length fpath) width) (if (< width 7) ;; It's unlikely that `width' will be this small, but don't ;; waste characters by adding ".." if it is. (setq fpath (substring fpath 0 width)) (setf (substring fpath (- width 2)) ".."))) fpath)) Very Respectfully, Brandon
Re: new feature for consideration: other-tab for org-agenda-window-setup
On Saturday, 29 Aug 2020 at 08:07, Kyle Meyer wrote: > Applied (e8ebf5d6c). Thank you. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-720-gbe5916
Re: [feature request] A new cookie type [!] showing the last note taken
> Make it easier perhaps -- once the tool has been changed to the new > syntax. But you might break current usage. And not everyone using such > tools has coding skills to make those tools work again. > Prof. Kitchin kindly gifted me with some code for a flash card learning > system. That code uses org-add-log-setup directly. Notes added like that > might not follow your newly added syntax. Note that the syntax I proposed is not new. It is already used by org-add-note (which is, by the way, calling org-add-log-setup -> org-add-log-note -> org-store-log-note. org-log-note-headings is only directly used in the last function). I do not propose to change the old behaviour. I just propose to take the de-facto used syntax and say "that's what org-mode calls a note". None of the existing org-mode functions need to be changed to conform with this formalised note syntax. However, we can implement a new set of functionality (like what I asked in this feature request) that will work assuming notes are created with the newly introduced syntax. Any old notes created using alternative syntax (which can be anything, since note syntax was never formalised) will simply not be recognised (as they are not recognised now because of lack of "note" definition). If external tools defined an alternative syntax for a note, notes created following that syntax will not be broken. Those external tools can keep using their own syntax. The only difference is that **new** org-mode functions supporting the new syntax will not be able to work with third-party notes. However, these new org-mode functions will not be possible if we keep the note syntax undefined. Best, Ihor Julius Müller writes: > Am 31.08.20 um 04:26 schrieb Ihor Radchenko: >> I would not call defining syntax for notes "a syntax change". Rather >> addition to syntax. Since there was no formal definition of notes in the >> past, introducing formal syntax for notes should not break any existing >> tool. If anything, it should make it easier for those tools to deal with >> notes. > > Make it easier perhaps -- once the tool has been changed to the new > syntax. But you might break current usage. And not everyone using such > tools has coding skills to make those tools work again. > > Prof. Kitchin kindly gifted me with some code for a flash card learning > system. That code uses org-add-log-setup directly. Notes added like that > might not follow your newly added syntax. > > Julius
Re: [PATCH] improve ol-man.el with occur searching
Hi, Nicolas, gentle ping about this patch. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Mon, Aug 17, 2020 at 11:22 AM numbch...@gmail.com wrote: > Thanks for reviewing my code and points. :) > Fixed in this attached patch. > > [stardiviner] GPG key ID: 47C32433 > IRC(freeenode): stardiviner Twitter: @numbchild > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 > Blog: http://stardiviner.github.io/ > > > On Sun, Aug 16, 2020 at 5:54 PM Nicolas Goaziou > wrote: > >> Hello, >> >> "numbch...@gmail.com" writes: >> >> > With this patch, ol-man.el link type can be a link like this: >> > ```org >> > [[man:grep::--extended-regexp][grep --extended-regexp]] >> > ``` >> > Occur will auto search "--extended-regexp" string in man page buffer. >> >> Thanks. >> >> > +PATH should be a topic that can be thrown at the man command. >> > +If PATH contains extra ::STRING which will use `occur' to search >> > +matched strings in man buffer." >> >> > + (string-match "\\(.*?\\)\\(?:::\\(.*\\)\\)?$" path) >> > + (let* ((command (match-string 1 path)) >> > + (search (match-string 2 path))) >> > +(funcall org-man-command command) >> > +(with-current-buffer (concat "*Man " command "*") >> >> This should only be called if search is non-empty. >> >> > + (occur search >> >> Why occur? Org uses `search-forward' for [[foo.org::text]] text links, >> and uses `occur' with [[foo.org::/text/]] links. >> >> Wouldn't it be more idiomatic to use a regular text search here? >> >> Regards, >> -- >> Nicolas Goaziou >> >
Re: [feature request] A new cookie type [!] showing the last note taken
Am 31.08.20 um 04:26 schrieb Ihor Radchenko: > I would not call defining syntax for notes "a syntax change". Rather > addition to syntax. Since there was no formal definition of notes in the > past, introducing formal syntax for notes should not break any existing > tool. If anything, it should make it easier for those tools to deal with > notes. Make it easier perhaps -- once the tool has been changed to the new syntax. But you might break current usage. And not everyone using such tools has coding skills to make those tools work again. Prof. Kitchin kindly gifted me with some code for a flash card learning system. That code uses org-add-log-setup directly. Notes added like that might not follow your newly added syntax. Julius
