Re: [O] Bug: Matching tags: results incomplete when mixing group tags and their ancestors [9.1.7 (9.1.7-12-g74f6ed-elpaplus @ /home/martin/.emacs.d/elpa/org-plus-contrib-20180305/)]

[Bastien]

Hi Martin,

Martin Kampas  writes:

> This seems to fix the bug.

I applied the patch, thanks!  If you have time to add tests,
that'd be great, as Nicolas suggested.

Best,

-- 
 Bastien

Re: [O] [ANN] ob-elvish: org-babel support for Elvish code

[Bastien]

Hi Diego,

Diego Zamboni  writes:

> If you want to take a look: https://github.com/zzamboni/ob-elvish

I didn't know Elvish... thanks for contributing this!

-- 
 Bastien

Re: [O] cautionary tale: avoid creating/using a macro called "title"

[Bastien]

Hi Eric,

Eric S Fraga  writes:

> I have, until now, used a macro
>
>   #+macro title The title of the document
>
> to be subsequently used in the actual #+title line, as in
>
>   #+title: @@latex:...@@ {{{title}}} @@latex:...@@
>
> (LaTeX details not important, I think.)

just out of curiosity, I tried to reproduce this error but it works
fine here.  Do you still have this error?

Thanks,

-- 
 Bastien

Re: [O] [PATCH] org-global-tags-completion-table does not include tags from buffers

[Bastien]

Hi Matt,

Matt Lundin  writes:

> Attached is a patch that fixes the issue.

Thanks a lot, applied -- together with some other fixes related to
group tags.  Can you check and report any problems?

-- 
 Bastien

Re: [O] column view with display-line-numbers-mode

[Bastien]

Hi Eric,

Eric S Fraga  writes:

> Not a major problem but I thought I would mention it.  Affects the
> æsthetic in me.  :-)

can you try the attached patch against master?

There is still a problem with big .org files, because we cannot
recompute the colview header format depending on the width reserved
for the line number... but it goes in the right direction.

Thanks for testing,

-- 
 Bastien
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index cb5c091..dd97499 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -424,6 +424,7 @@ for the duration of the command.")
   "Overlay the newline before the current line with the table title."
   (interactive)
   (let ((title "")
+	(linum-offset (line-number-display-width 'columns))
 	(i 0))
 (dolist (column org-columns-current-fmt-compiled)
   (pcase column
@@ -435,7 +436,7 @@ for the duration of the command.")
 (setq-local org-previous-header-line-format header-line-format)
 (setq org-columns-full-header-line-format
 	  (concat
-	   (org-add-props " " nil 'display '(space :align-to 0))
+	   (org-add-props " " nil 'display `(space :align-to ,linum-offset))
 	   (org-add-props (substring title 0 -1) nil 'face 'org-column-title)))
 (setq org-columns-previous-hscroll -1)
 (add-hook 'post-command-hook 'org-columns-hscroll-title nil 'local)))

Re: [O] Connecting to Org ELPA via an HTTP proxy from Emacs 25 and older

[Bastien]

Hi Keshav and Roland,

I was not aware the redirection could cause such a problem.

Both http://orgmode.org and https://orgmode.org should now
work, let me know if this fixes your issue.

Thanks for reporting this,

-- 
 Bastien

Re: [O] org-mode R using xtable produces strange output

[Brian Shine]

Brilliant!  Thank you so much.

Best wishes,
Brian


> On 20 Mar 2018, at 16:47, Berry, Charles  wrote:
> 
> 
> 
>> On Mar 19, 2018, at 4:44 PM, Brian Shine  wrote:
>> 
>> I am using xtable to produce summary tables of linear models, specifying the 
>> output as latex.  If I just run the code in R, I get the correct output.  
>> However, the latex output in the org document contains a lot of “|”s.  I 
>> think this is because the header of the table contains some code to make “p 
>> > |t|”, where the vertical lines are to indicate “absolute value of t”.  My 
>> guess is that when the output is written to the results section, org 
>> interprets the “|” signs as an org-table and tries to be helpful by adding 
>> more of them to make up the correct number of columns. 
> 
> 
> See
> 
>   (info "(org) results")
> 
> and note the difference between `:results output' and `:results value' (the 
> default).
> 
> Since you want the printed version of the R object, you should use 
> 
>   `:results output latex'
> 
> to pass the printed output to the org #+Results or 
> 
>   `:results raw :wrap export latex'
> 
> to pass the unadorned value.  In your use case they seem to produce the same 
> #+Results.
> 
> HTH,
> 
> Chuck

Re: [O] does this pandoc error look familiar to anybody?

[Samuel Wales]

thanks eric and nick.

i was able to look at the h levels in the org direct export html.
they were h7 or so.  dunno if there was an h1.  so i am going to try
to get them down to h4.

then who knows if that will fix it.

Re: [O] does this pandoc error look familiar to anybody?

[Nick Dokos]

Eric S Fraga  writes:

> On Monday, 19 Mar 2018 at 15:10, Samuel Wales wrote:
>> i will have to try this, but can i assume [i do hope] that
>> org->html->pandoc->pdf does not count clean view as approximately
>> doubling the number of levels?
>
> I do not understand this question.  Sorry.
>

IIUC, I don't think it's a problem: basically clean view doubles the
number of stars for each level, but logically speaking the levels
remain the same.

>> and that it does not count levels above the subtree that i am
>> exporting?  i.e. the olpath a/b/c/d/e/f/g/h/i/i am exporting
>> this/2/3/4 would be ok?
>
> Yes, this should be correct.

-- 
Nick

Re: [O] org-mode R using xtable produces strange output

[Berry, Charles]

> On Mar 19, 2018, at 4:44 PM, Brian Shine  wrote:
> 
> I am using xtable to produce summary tables of linear models, specifying the 
> output as latex.  If I just run the code in R, I get the correct output.  
> However, the latex output in the org document contains a lot of “|”s.  I 
> think this is because the header of the table contains some code to make “p > 
> |t|”, where the vertical lines are to indicate “absolute value of t”.  My 
> guess is that when the output is written to the results section, org 
> interprets the “|” signs as an org-table and tries to be helpful by adding 
> more of them to make up the correct number of columns. 


See

(info "(org) results")

and note the difference between `:results output' and `:results value' (the 
default).

Since you want the printed version of the R object, you should use 

`:results output latex'

to pass the printed output to the org #+Results or 

`:results raw :wrap export latex'

to pass the unadorned value.  In your use case they seem to produce the same 
#+Results.

HTH,

Chuck

Re: [O] Bug: Bug in svg generation from plantuml sources [9.1.7 (9.1.7-20-ge1f1ac-elpa @ /home/guertler/.emacs.d/elpa/org-20180319/)]

[Andy Moreton]

On Tue 20 Mar 2018, Martin Gürtler wrote:

> ob-plantuml wraps a plantuml source in @startuml/@enduml tags without
> checking whether they are already in the source code. This results in
> the creation of invalid SVG, at least for newer versions of plantuml,
> because the resulting SVG file contains then two XML documents ((I was
> using version 1.2018.2, it seems to work though for older plantuml
> versions <= 8059).
>
> So the following does not work
>
> #+BEGIN_SRC plantuml :file "out.svg"
> @startuml
> a->b
> @enduml
> #+END_SRC
>
>
> while this works:
>
> #+BEGIN_SRC plantuml :file "out.svg"
> a->b
> #+END_SRC
>
> Every plantuml example I found contains @startuml/@enduml so all my old
> org mode files do contain the tags... I feel the required change is not
> very difficult, but unfortunately I do not speak elisp at all...
>
> Emacs  : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.28)
>  of 2018-02-19, modified by Debian
> Package: Org mode version 9.1.7 (9.1.7-20-ge1f1ac-elpa @ 
> /home/guertler/.emacs.d/elpa/org-20180319/)
>
> Thanks for considering,
>
> Martin

Note that newer versions of plantuml supports additional diagram types, so
diagrams may need to use:
  @startuml   .. @enduml
  @startsalt  .. @endsalt
  @startdot   .. @enddot
  @startditaa .. @endditaa
  @startgantt .. @endgantt

It is expected that support for new diagram types will use keywords
starting with "@start" and "@end" as delimiters. See "Generalisation" at
http://plantuml.com/ditaa for more details.

AndyM

[O] Bug: Bug in svg generation from plantuml sources [9.1.7 (9.1.7-20-ge1f1ac-elpa @ /home/guertler/.emacs.d/elpa/org-20180319/)]

[Martin Gürtler]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Hi,

ob-plantuml wraps a plantuml source in @startuml/@enduml tags without
checking whether they are already in the source code. This results in
the creation of invalid SVG, at least for newer versions of plantuml,
because the resulting SVG file contains then two XML documents ((I was
using version 1.2018.2, it seems to work though for older plantuml
versions <= 8059).

So the following does not work

#+BEGIN_SRC plantuml :file "out.svg"
@startuml
a->b
@enduml
#+END_SRC

while this works:

#+BEGIN_SRC plantuml :file "out.svg"
a->b
#+END_SRC

Every plantuml example I found contains @startuml/@enduml so all my old
org mode files do contain the tags... I feel the required change is not
very difficult, but unfortunately I do not speak elisp at all...

Emacs  : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.28)
 of 2018-02-19, modified by Debian
Package: Org mode version 9.1.7 (9.1.7-20-ge1f1ac-elpa @ 
/home/guertler/.emacs.d/elpa/org-20180319/)

Thanks for considering,

Martin

-- 
Dr. Martin Gürtler 
 


signature.asc
Description: PGP signature

Re: [O] [BUG] org-sort-entries errors out when headline is empty

[Nicolas Goaziou]

Hello,

Sebastian Reuße  writes:

> An alternative is to guard inside ‘org-sort-entries’. I’m following up with an
> implementation of this.

Applied. Thank you!

I used `org-get-heading', which handles empty headlines without messing
with `org-complex-heading-regexp'.

> I was also wondering if it might make sense to tweak
> ‘org-complex-heading-regexp’ so that the respective capture group captures an
> empty string. This could be achieved by making the title group greedy again
> (reverting 9d334897e). Whether we want this probably depends on the motivation
> for 9d334897e. However, doing so would be more consistent with the 
> org-elements
> API, which does assign a tag list to the title property when the heading is
> otherwise empty.

How should we treat the following:

  * :something:

Is it an empty headline with a "something" tag, or a ":something:"
headline with no tag? All things being equal, it doesn't matter much,
whichever answer is chosen, we can get the other one with a zero-width
space or some such.

However, it is too early to answer this, because tags are handled
inconsistently across the code base. See, e.g., the number of
occurrences of ":[[:alnum:]_@#%:]+:" in "org.el". The tags regexp is
hard-coded in too many places. This is why, even though 9d334897e was an
answer to the initial question, it is incomplete. Reverting it would be
as incomplete.

IMO, we should first clarify tags definition. There's already
`org-get-tags-at' and `org-get-local-tags' (which could be optimized,
BTW), but we may need a proper tags-regexp, e.g.,

  (concat org-outline-regexp-bol ".*[ \t]\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$")

or use consistently `org-get-tags-at'.

Then we can answer the initial question.

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: [O] Regression in #+include behavior [master]

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> Though I didn't understand why it failed when exporting from the large
> file, but not when moving the relevant subtrees (where the #+include was
> called, and the included) to a separate file..

The code was fixing links in the whole document, not only in the subtree
you were including.

The problem lay somewhere else in the file, in the "* Hey! I have a link
[[https://example.org][here]] (Awesome!)" headline. There,
`org-element-context' needed to check the headline, by (looking-at
org-complex-heading-regexp). However, since the changes were happening
in Fundamental mode, the regexp was not set. Hence the error.

So, the fix implements the following changes:
- only modify links withing the included part of the document,
- do not modify anything if includer and includee both live in the same
  directory,
- switch to Org mode before proceeding with changes.

Regards,

-- 
Nicolas Goaziou

Re: [O] does this pandoc error look familiar to anybody?

[Eric S Fraga]

On Monday, 19 Mar 2018 at 15:10, Samuel Wales wrote:
> i will have to try this, but can i assume [i do hope] that
> org->html->pandoc->pdf does not count clean view as approximately
> doubling the number of levels?

I do not understand this question.  Sorry.

> and that it does not count levels above the subtree that i am
> exporting?  i.e. the olpath a/b/c/d/e/f/g/h/i/i am exporting
> this/2/3/4 would be ok?

Yes, this should be correct.
-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-303-g6cf5fc


signature.asc
Description: PGP signature