Re: Turn on org-num-mode in init?

[Eric S Fraga]

On Monday,  9 Mar 2020 at 23:31, Lawrence Bottorff wrote:
> I've tried a few variations of trying to turn on org-num-mode (which now
> comes standard in org, correct?) in my init, but I keep getting an error
> buffer upon a fresh startup

Maybe show us what you have right now instead of what others have done?

In any case, this one:

> (use-package org-num
>   :load-path "lisp/"
>   :after org
>   :hook (org-mode . org-num-mode))

should work, as far as I can tell although I don't use use-package at
all.  Have you tried with a reduced .emacs?

You could try the following:

(require 'org)
(require 'org-num)
(add-hook 'org-mode-hook #'org-num-mode)

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880

Turn on org-num-mode in init?

[Lawrence Bottorff]

I've tried a few variations of trying to turn on org-num-mode (which now
comes standard in org, correct?) in my init, but I keep getting an error
buffer upon a fresh startup

Error (use-package): org/:config: Cannot activate headline numbering
outside Org mode

although when I dismiss it with q and call up an org file, org-num-mode is
on. Any ideas what to do? I saw this

(use-package org-num
  :load-path "lisp/"
  :after org
  :hook (org-mode . org-num-mode))

but I assume he's using the github version. This

(use-package org
  :defer 2
  :ensure nil
  :hook
  ((org-mode . org-num-mode)
   (org-mode . (lambda () ;; this will make sure auto-fill works for
org-mode
 (setq-local comment-auto-fill-only-comments nil)
 (setq-local display-line-numbers-type 'absolute
...

All of these produce the error, but, again, org-num works.

LB

Re: Bug: org-agenda-tag-filter-preset not respected [9.3.6 (9.3.6-19-gf360f9-elpaplus @ /home/jorge/.config/emacs/elpa/27.0/develop/org-plus-contrib-20200302/)]

[Jorge P . de Morais Neto]

Em [2020-03-06 sex 09:06:35-0300], Jorge P. de Morais Neto escreveu:

> Hi.  Since version org-plus-contrib-20200302, my agenda is buggy.  The
> bug did not occur in previous versions.

Actually, I realized the bug occurs since org-plus-contrib-20200224.

Regards.
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- 
- 

Re: Bug: org-babel-expand-noweb-references: FIXEDCASE=nil

[Nicolas Goaziou]

Hello,

Sebastian Miele  writes:

> org-babel-expand-noweb-references in the current master branch ends with:
>
>   (replace-regexp-in-string noweb-re (lambda...) body nil t 2)
>
> I.e., the FIXEDCASE argument to replace-regexp-in-string is nil. This
> has the effect that in
>
>   #+BEGIN_SRC elisp :noweb-ref AA
> (ignore)
>   #+END_SRC
>
>   #+BEGIN_SRC elisp :noweb yes
> <>
>   #+END_SRC
>
> the second block is expanded as "(IGNORE)". That probably is a bug.
> FIXEDCASE should be t.

Indeed! Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: New org-store-link on headlines contains tags

[Nicolas Goaziou]

Hello,

stardiviner  writes:

> I found the new org-store-link on headlines contains tags. I don't think this 
> is
> a good way. Because some users like me might change tags. Will that caused Org
> open link failure in future if this open link function modified or others. I
> think just headline text is good. WDYT?

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Bug: HTML not formatted correctly from R source code block [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/opdfa/.emacs.d/elpa/org-plus-contrib-20200309/)]

[Steven Delean]

Hi,

HTML table produced from a source code block (using R code) does not display
because html code is not formatted correctly in the exported html output. The
source code block uses:

#+begin_src R :results output html :exports both
zd <- data.frame(a = 1:3, b = letters[1:3])
knitr:::kable(zd)
#+end_src

Each line in the html table that is produced is broken mid-line where a >
symbol is replaced with a line feed. The html code that is produced shows that
there is a line feed where there should be a > symbol after the ;" for each th
header tag in the table.


 
  
   
   
  
 

  
   
   
  
  
   
   
  
  
   
   
  



Thanks for your time,
Best regards,
Steve

Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of
2019-09-17 Package: Org mode version 9.3.6 (9.3.6-23-g01ee25-elpaplus @
/home/opdfa/.emacs.d/elpa/org-plus-contrib-20200309/)

Bug: org-babel-expand-noweb-references: FIXEDCASE=nil

[Sebastian Miele]

org-babel-expand-noweb-references in the current master branch ends with:

  (replace-regexp-in-string noweb-re (lambda...) body nil t 2)

I.e., the FIXEDCASE argument to replace-regexp-in-string is nil. This
has the effect that in

  #+BEGIN_SRC elisp :noweb-ref AA
(ignore)
  #+END_SRC

  #+BEGIN_SRC elisp :noweb yes
<>
  #+END_SRC

the second block is expanded as "(IGNORE)". That probably is a bug.
FIXEDCASE should be t.

Re: File Scoped Properties?

[Tim Visher]

On Fri, Mar 6, 2020 at 9:09 AM Tim Visher  wrote:

> Thanks for the response, Eric. :)
>
> On Fri, Mar 6, 2020 at 1:51 AM Fraga, Eric  wrote:
>
>> On Thursday,  5 Mar 2020 at 10:28, Tim Visher wrote:
>> > I _am_ able to get it to work by adding a file local variable like
>> >
>> > ```
>> > # Local Variables:
>> > # org-attach-id-dir: "~/.foo/data"
>> > # End:
>> > ```
>> >
>> > but then whenever I open the file it tells me it's possibly not safe to
>> set
>> > that.
>>
>> You've already received a more org-ish response but I'll give you an
>> Emacs response to this part of your post: Emacs is simply making sure
>> you are aware that a variable is being set when visiting a file.
>>
>
> My question was more around why I had to do it at all since based on my
> reading of the manual it seems like I should've been able to do this with
> some kind of file-wide property. Specifically, I've never been able to wrap
> my head around `(info "(org) Property Syntax")`.
>
> "Properties are key–value pairs. When they are associated with a single
> entry or with a tree…," for instance, seems to imply by "When they are
> associated with a single entry…" that they can be associated with all the
> entries (or a particular tree or node).
>
> Anyway, I think between you and Gustav I finally have this sorted.
>
>1. To set properties at the top level of a file you need to use the
>`#+PROPERTY:  ` syntax. I've been trying to
>figure out how I misinterpreted that in the past and I _think_ it was
>because I assumed that the `#+PROPERTY` was actually `#+` as in
>`#+DIR` rather than `#+PROPERTY: DIR`. It looks like to set a file local
>property in an org file you _must_ (at least on 9.3 or earlier) use the
>`#+PROPERTY:  ` syntax.
>
>2. Even then by default org-attach property inheritance is set to
>`'selective` and `org-use-property-inheritance` is set to off. I've now
>customized `org-use-property-inheritance` to `'("DIR")` which I believe
>says that I consider the `DIR` property to be a possible candidate for
>inheritance and no others. I'm a little concerned about performance
>implications as the manual gives me all kinds of scary warnings but we'll
>see about that.
>
> Anyway this appears to work as I expect it to. I don't have to set a
> file-local variable to anything. I'm using org properties. And
> `org-attach-dir` now returns the proper directory for this file.
>
> Thanks all! If you think I'm still misunderstanding something please
> correct me. :)
>

I'll go ahead and correct myself. (－‸ლ)

It turns out that I wasn't understanding what the `DIR` property actually
does. If `DIR` is set, it makes that the attachment directory, period. In
other words it's different than the default `./data/` prefix directory in
that ID paths are not then suffixed upon the end of it like
`./data/XX/X-XXX-XXX/` for each entry. Instead, if you have `DIR` set,
that headings attachment directory == `DIR`.

So the way to change the attachment directory prefix is just not to mess
with `DIR` at all. Instead, you must set the variable `org-attach-id-dir`,
and if you want that to be local to a file the natural way to do that is
with a file-local variable.

```
# Local Variables:
# org-attach-id-dir: "~/.foo/data"
# End:
```

Cheers. :)