Re: [O] CUSTOM_ID vs ID
On Sun, Jul 28, 2019 at 3:10 AM Nicolas Goaziou wrote: > Hello, > > Nathan Neff writes: > > > I've often been confused why org-mode has both a CUSTOM_ID > > and a ID property. I mean, why not just use one or the other name? > > Custom ID are user-defined, and only meaningful in the scope of the > document. Also, they may appear as-is when exported, e.g., as an anchor > in HTML. > > ID are (or should be) generated by Org, and are valid across files, > which means they need to be absolutely unique. > I have a lot of org files and one of the main purposes of links is to be able to link to different headings across documents. This seems to imply I should use the ID property. However, I usually *do* manually assign IDs (not CUSTOM_IDs) myself. The reason is so I can reasonably search for the ID within my org files and that the link ID makes some sense to me. For example, if I see a link to "id:keyboard_shortcuts" I can tell where it's going. Later on, if I want to insert a link to my keyboard shortcuts heading in another place in my org files, I can make a guess of the ID I want to link to. So, I guess I'm okay manually assigning ID properties, as long as I don't have conflicts. Thanks for the explanation! Thanks, --Nate > > Org keeps track of ID if `org-id-track-globally' is non-nil (the > default). If this is nil, there is almost no difference between ID and > custom ID. > > > When would I ever have both an ID and a CUSTOM_ID property for > > a heading? > > You may want to refer to a heading from anywhere with id:... but need > a clean anchor in HTML export, for example. > > FWIW, I never use ID property. > > Regards, > > -- > Nicolas Goaziou >
Re: [O] Org-mode latex pdf export issue: Underlined lines not breaking properly
On Mon, Jul 29 2019, Gustavo Barros wrote: But the ability to have line breaks is a clear edge of soul, and the reason of the original request which started this thread. I must correct myself, the difference between ulem and soul is not that one allows line breaks while the other does not. More precisely, both handle line breaks, but soul is able to honor hyphenation patterns, while ulem is not. If one wants a (underlined/stricken-through) word to break with ulem, the hyphenation has to be done manually. Best, Gustavo.
Re: [O] Org-mode latex pdf export issue: Underlined lines not breaking properly
Hi all,
On Fri, Jun 14 2013, Nicolas Goaziou wrote:
Nicolas Goaziou writes:
> 1. Does \underline{中文测试} work properly (notwithstanding the line
> breaks)?
\underline can show chinese, but the command can't resolve lines
breaking properly.
> 2. Does \uline from "ulem" package handle it correctly, including the
> line breaks?
\uline seem to work properly.
>>>
>>> Then, the best solution seems to add "ulem" package to
>>> `org-latex-default-packages-alist' and use \ulem for underline. "soul"
>>> will only be used for strike-through.
>>>
>>> Is there any objection to this change?
>>
>> May be \ulem should be used for strike-through too!
>
> Done.
>
I know this is a very old thread, and that perhaps this boat has sailed
definitely.
But it seems to me that the attempt to use soul back then eventually
backfired because soul does not handle utf8 properly, as Feng Shu’s
issue demonstrated. Indeed it does not. But there is a patch to soul,
by Heiko Oberdiek, to handle this precise issue, and it is the package
soulutf8.
I’ve checked the commit history around the time of this thread, and it
seems soul, rather than soulutf8, was the attempt
(https://code.orgmode.org/bzg/org-mode/commit/95eeefa9bca1b6c57fe62c248a0a35302cd7374d).
Neither soul nor ulem is very active nowadays, but are used quite
extensively, as far as I know (from following TeX.SX). And both have
their limitations. But the ability to have line breaks is a clear edge
of soul, and the reason of the original request which started this
thread.
So, if the only reason to prefer ulem back in 2013 was utf8 support,
perhaps soulutf8 might be worthy of your reconsideration.
Best regards,
Gustavo Barros.
[O] Case sensitivity of special block names in HTML export / class names
Hoi,
Org special block names (within Org) appear to be case-insensitive. That
is, I can write either:
#+BEGIN_NOTES
...
#+END_NOTES
or
#+begin_notes
...
#+end_notes
and Org is happy. I think the switch from Org 8 to 9 changed the default
templates to insert lower-case blocks instead of upper case blocks, so it's
natural now to have files that contain a mix of both cases.
This is a problem for HTML export, as they get converted to:
...
or
...
depending on the original case of the special block in the .org file. HTML
class element values are case sensitive in non-quirks mode browsers, so
this makes existing CSS for content exported by Org fail, as
div.NOTES { ... }
does not match a .
A quick local fix is:
(defun my/downcase-special-block (ohsb special-block contents info)
(let ((special-block-copy (org-element-copy special-block)))
(org-element-put-property
special-block-copy
:type
(downcase (org-element-property :type special-block)))
(funcall ohsb special-block-copy contents info)))
(advice-add #'org-html-special-block :around
#'my/downcase-special-block)
But I wanted to raise this in case there was any interest in a more general
solution (perhaps a configuration option to either (a) retain case (current
behaviour), (b) convert to lower case, (c) convert to upper case?
N
[O] Feature suggestion: #+toc figures
Currently, org-mode is able to produce (among other) tables, figures and listings, recognized and captioned/numbered as such. It can also produce a list of tables and a list of listings of a document. However, it currently /cannot/ produce a list of figures. Is that an oversight ? Or is there a more fundamental problem with this useful potential feature ? I am aware that I can get this in the \LaTeX export of the document by inserting ~\listoffigures~ at the right place. Bit this won't export to other formats. Thoughts ? -- Emmanuel Charpentier
[O] org-flag-region missing?
Could it be that the function org-flag-region is recently missing from org.el? I got some errors after narrowing to region because that function is not defined. After getting the source from somewhere else and adding it to scratch the errors disappeared. -- Mit freundlichen Grüssen / With kind regards: Jens Lange
Re: [O] export outside of emacs
On Sun, Jul 28, 2019 at 2:21 PM Kaushal Modi wrote: > Here's one example[1] (look at the "emacs-batch" target in there. > Great, this is a wonderful example to get started from! Thanks, Luca
