Re: [O] HTML export hides URLs in table of contents
Fix works like a charm. Thanks. On Sat, Oct 14, 2017 at 1:21 PM Nicolas Goaziou wrote: > ConcreteVitamin writes: > > > Thanks for your quick fix! When can I expect to see this in the next > > release? > > If there is no description, the path is inserted, without link > decoration. > > > (Alternatively, is there a way to patch in your commit for now? > > I'm using spacemacs.) > > The patch lands Monday on ELPA. > > Regards, >
[O] Merging Faces
Hello everyone,
how do you add custom face properties to an org buffer?
I want to generate org buffers automatically (displaying verious entries
and properties). Specifically, I want the resulting buffer in org mode
to handle links, equations, and export. But I want also to add custom
background or fonts to parts of the buffer.
The easiest way to see the problem is this:
(let ((entry
(concat
"any "
(propertize "link" 'font-lock-face '(:family "DejaVu Sans Mono"))
" like [[file:some-file]] or equations like
\\(\\sqrt{\\frac{1}{(x+y)^2\\), but also /italics/ and *bold text*
should be displayed correctly;")))
(switch-to-buffer-other-window
"*fb-merging-example")
(erase-buffer)
(insert (propertize (concat "1. " entry)
'font-lock-face '(:background "yellow")
'underline t))
(insert "\n2. other font:")
(insert (propertize entry 'font-lock-face '(:family "Symbola")))
(org-mode))
Two problems:
1. "link" has not the right font. I guess `propertize' doesn't merge
face. Is there a way to accomplish this?
2. Links and equations don't have the desired background.
Any help appreciated.
Re: [O] function for inserting a block
Eric Abrahamsen writes: [...] > #+BEGIN_SRC org > #+BEGIN_FOO > This is a paragraph. > > #+END_FOO > > This is another paragraph. > #+END_SRC Make that: #+BEGIN_FOO This is a paragraph #+END_FOO This is another paragraph
Re: [O] function for inserting a block
Nicolas Goaziou writes:
> Hello,
>
> Eric Abrahamsen writes:
>
>> How does this look?
>
> Thank you! I have some questions and remarks.
>
>> * etc/ORG-NEWS: Mention in news.
>
> This doesn't need to be added to the commit message.
>
>> +Do not be put off by having to remember the source block syntax. Org mode
>> +offers two ways of speeding up the creation of @samp{src} code blocks:
>
> src code blocks
>
> is enough, IMO. There are may of them across the manual, and it just
> makes reading more tedious.
>
>> +@findex org-insert-structure-template
>
> I would also add
>
> @kindex C-c C-x t
>
>> + (let ((s (copy-marker (if (use-region-p)
>> +(region-beginning)
>> + (point
>
> Does it really need to be a marker? AFAICT, nothing really changes this
> position.
>
>> +(back-to-indentation)
n>> +(insert (format "#+BEGIN_%s\n"
>> +type))
>> +(indent-to column)
>
> What about
>
> (beginning-of-line)
> (indent-to column)
> (insert (format "#+BEGIN_%s\n" type))
>
> ?
>
> It avoids `back-to-indentation'.
Cool, I will make all of the above changes, thanks for the notes.
>> +(if (bolp)
>> +(progn
>> + (skip-chars-backward " \n\t")
>> + (forward-char))
>> + (end-of-line)
>> + (insert "\n"))
>
> I don't understand this part. In particular, the `forward-char' looks
> wrong. Do you mean `forward-line' ? If so, do you handle the case where
> buffer doesn't end with a newline character?
This was a bit of finicky code mostly for aesthetic purposes. It has to
do with this case (the second clause in the test I added):
#+BEGIN_SRC org
This is a paragraph
This is another paragraph
#+END_SRC
If point is on the first paragraph and the region is not active,
`org-mark-element' will mark the paragraph and all following whitespace,
which means we end up with:
#+BEGIN_SRC org
#+BEGIN_FOO
This is a paragraph.
#+END_FOO
This is another paragraph.
#+END_SRC
Which just looked bad to me (even though it probably behaves perfectly
correctly). So if point is at bol, it skips back over the whitespace and
then moves forward one char, presumably leaving point right after the
marked element.
Maybe it should only skip back over newlines (though then indentation
will confuse it). Or maybe I should just not be so picky about
appearances...
Eric
[O] [PATCH] Use the same TODO keyword as the current heading
This makes org-insert-todo-heading-respect-content use the previous heading of the same level instead of the previous heading regardless of level. Given: * TODO some task ** WAITING other task The original code yields: * TODO some task ** WAITING other task * WAITING This commit yields: * TODO some task ** WAITING other task * TODO * lisp/org.el (org-insert-todo-heading): Use keyword of previous same level heading --- lisp/org.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index d6cd77bf9..100fe9a58 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7947,8 +7947,7 @@ unchecked check box." (org-insert-heading (or (and (equal arg '(16)) '(16)) force-heading)) (save-excursion - (org-back-to-heading) - (outline-previous-heading) + (org-forward-heading-same-level -1) (let ((case-fold-search nil)) (looking-at org-todo-line-regexp))) (let* ((new-mark-x (if (or (equal arg '(4)) -- 2.15.0.rc0.271.g36b669edcc-goog
[O] org-refile and Archive headings
The current default behavior for org-refile and org-reverse-note-order does not treat Archive headings specially. Consider a .org file: * Some projects ** Some item... ** Archive :ARCHIVE:... Refiling an entry to "Some projects" results in: * Some projects ** Some item... ** Archive :ARCHIVE:... ** New entry... Would it be desirable to instead append before the Archive heading? * Some projects ** Some item... ** New entry... ** Archive :ARCHIVE:... This could be configurable using a magic value for org-reverse-note-order.
Re: [O] [RFC] Exclude headlines from TOC, take 2
On Sun, Oct 15, 2017 at 3:41 PM Nicolas Goaziou wrote: > Nicolas Goaziou writes: > > > I attach a possible implementation, with documentation and tests. Note > > that this doesn't work with LaTeX export back-end, which still dutifully > > ignores any unnumbered headline. Patches welcome to improve this. > > Pushed. > Works great! Thank you! My brief test for C-c C-e h o #+TITLE: Test for new UNNUMBERED notoc feature * Org version =master= branch as of <2017-10-16 Mon> - http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=9b13e44ad795792afabb0623b58653bbf35bf040 * This heading will not be numbered, but will be present in TOC :PROPERTIES: :UNNUMBERED: t :END: Something ** Sub heading A * This heading will not be numbered, and also will be absent in TOC :PROPERTIES: :UNNUMBERED: notoc :END: Something ** Sub heading B * Regular heading Once again this is a regular heading and will appear numbered, and in the TOC too. ** Sub heading C -- Kaushal Modi
Re: [O] Special Characters in verbatim
Hello, Orm Finnendahl writes: > Hi, > > I can't get verbatim to work for me with special characters: > > I want to display a hashmark followed by a single quote in verbatim. I > publish to texinfo and from there to html (using makeinfo/texi2any). > > I tried this: =#'= which renders as is without removing the equality > characters. If I don't use any special characters it works well, > displaying the text between the equality chars with monospaced font in > the html document. > > I searched the web for quite some time now but none of the suggested > methods (escaping, using character entities, etc) work for me. > > Can someone help? I cannot reproduce your issue. You may want to update Org and try again. Regards, -- Nicolas Goaziou
Re: [O] Changing behavior of org-insert-todo-heading-respect-content
Hello, Allen Li writes: > Regarding the behavior of org-insert-todo-heading-respect-content, > bound to C-S-return, consider the following .org file: > > * TODO some task > ** WAITING other task > > If point is on the TODO line, pressing C-S-return yields > > * TODO some task > ** WAITING other task > * WAITING > > When I use C-S-return, I always desire > > * TODO some task > ** WAITING other task > * TODO > > Making C-S-return do this would break backward compatibility, but I > think this behavior is more intuitive. Thoughts? I think the current behaviour is more than likely a bug. The one you propose is indeed better. Would you want to provide a fix for that? Regards, -- Nicolas Goaziou
Re: [O] Org-specific completing-read-function
Hello, Allen Li writes: > Would it be acceptable to have an Org-specific > completing-read-function? My use case is that I would like to use a > different completing-read function like ido of ivy for Org mode, > especially for refiling, but I don't want to modify > completing-read-function globally. I don't think so. Org shouldn't implement it's own completing-read function but instead allow other packages, or even users, implement their own. We removed Ido and Iswitchb specific functions for the same reason. Regards, -- Nicolas Goaziou
