Re: Bug: Org-drill defines advice causing infinite recursion [9.3.6 (release_9.3.6-465-g4fde1c @ /home/christoffer/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Hi,

Sorry for the slow reply.

Christoffer Stjernlöf  writes:

> Org-drill defines the following advice:
>
> (when (version< org-version "9.2")
>  (advice-add 'org-get-tags :around #'org-drill-get-tags-advice))
>
> (defun org-drill-get-tags-advice (orig-fun  args)
>  ;; the two arg call obsoletes get-local-tags
>   (if (= 2 (length args))
>  ;; and we don't want any byte compile errors
>  (if (fboundp 'org-get-local-tags) (org-get-local-tags))
>;; the non-arg version doesn't return inherited tags, but
>;; get-tags-at does.
>(org-get-tags-at)))
>
> The function being called at the end, org-get-tags-at, has the unfortunate
> definition:
>
> (define-obsolete-function-alias 'org-get-tags-at 'org-get-tags "Org
> 9.2")

Hmm, but the advice is being added only if the Org version is before
9.2, and in that case org-get-tags-at is a separate function, not an
alias.  So that seems like that should be fine.  However ...

> This results in the advice calling the function it advises, leading to
> infinite recursion.
>
> Is the version check around the advice addition accidentally inverted? Or
> is there anything else I'm missing?

... if you're actually hitting into an infinite recursion, then I of
course trust that more than my reasoning.  Because you don't explicitly
say that you are and based on your reported Org version being after 9.2,
I'm guessing your conclusion was based solely on reading the code.

If there is an issue, though, note that org-drill.el is no longer in the
Org tree as of 2c8e8b4a1 (contrib: Remove Org Drill, 2019-07-11).  I
believe it's maintained at .

Re: [PATCH] org-agenda.el: Complete multiple todo keywords

[Kyle Meyer]

Applied (d23bd9187).

Re: $LR in Table Formula

[Marco Wahl]

Carsten Dominik  writes:

>> If the Org code shall iterate towards clarity then the question would be
>> resurrection or elimination of the Last Row (LR) feature AFAICS.
>
> Elimination should be fine in this case since it does not work anymore
> anyway.

Okay, I eliminated the LR parts from the code.


Thanks,
-- Marco

Re: Bug: open pdfview link causes severe memory allocation

[Firmin Martin]

> 1. Follow a *file link* doesn't open pdf with pdfview mode anymore,
>instead, it opens the pdf using the default system's pdf reader. 
> 2. Open *pdfview link* now causes severe memory allocation which freezes
>quickly my PC. 

I found the reason behind it: I was trying to open a djvu. By default, a
djvu is opened by my system's pdf reader. So, the first point is fine.

> N.B. I just noticed that there is a relatively new package
>  "org-pdftools" which may fix this behavior. But this is a severe bug
>  that shouldn't happen.

But the second point is still relevant. I reported this issue to
~org-pdftools~ which inherit the issue from the unmaintained ~org-pdfview~ :

https://github.com/fuxialexander/org-pdftools/issues/35

Best,

Firmin Martin

Re: [PATCH] org-agenda.el: Complete multiple todo keywords

[akater]

Kyle Meyer  writes:

> Is akater the name you prefer
> listed on that site and in the commit message?

Yes.

I will use git-am complaint patch formatting next time; thank you for
the guidelines.


signature.asc
Description: PGP signature

TODO or checkboxes in org tables

[Uwe Brauer]

Hi

I have an orgtable with a lot of useful information, I would like to add
a column either for TODOS or checkboxes but it seems not work any idea
whether such an addon package exist or any change that such a feature
will be implemented?

Regards

Uwe Brauer 

Re: Self-sufficient Org file with customised export? :eval-when?

[Berry, Charles]

> On Apr 30, 2020, at 11:55 AM, akater  wrote:
> 

[deleted - discussion of html export]

> -
> 
> 
> If I may prematurely offer my vision: Common Lisp has special operator
> eval-when which specifies when the enclosed code is to be evaluated (or
> compiled).  Example:
> 
> (eval-when (:compile-toplevel) (defun f () ..))
> 
> specifies that function f should be defined during compilation only.
> 
> I believe it would be neat if Org-mode widely supported :eval-when
> header argument inspired by Common Lisp's eval-when.  Usage examples
> would be:
> 
> #+begin_src emacs-lisp :eval-when compile load
> ..
> #+end_src
> 

You can effectively do this by using an elisp expression for the value of an 
:eval arg like this:


#+begin_src emacs-lisp :eval (or (bound-and-true-p my-eval-flag) "no")
"done"
#+end_src

which honors the value of `my-eval-flag' if there is one.

You can also use a call to a src block. e.g. `:eval my-src-block(a=1,b=2)'

HTH,

Chuck

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Fri, May 1, 2020 at 1:38 PM Richard Lawrence
 wrote:
>
> "Bruce D'Arcus"  writes:
>
> >> > My understanding, though, is that org "cite" would default to your
> >> > last example I quote above (in natibib, citep); that there's no need
> >> > for a dedicated "cite/paren" command, either reserved or not.
> >>
> >> Not necessarily. "cite" means default value, whatever that is. It could,
> >> for example, mean: "cite/text" for every citation, if that is what you
> >> use the most. In that case, "cite/paren" is necessary, to override it
> >> locally. It could also be, e.g., "cite/footnote", then both "cite/text"
> >> and "cite/paren" could be of some use. That was suggested by Richard
> >> Lawrence in this thread, if my memory serves me right.
> >>
> >> Does that make sense?
> >
> > I think so. I'll defer to Richard on this, since he was making this point.
>
> Sorry to take so long to reply. The point I made earlier was that, as
> far as I understand, the choice of CSL stylesheet is the main factor
> determining how a given citation gets rendered into the output (assuming
> you process citations with CSL). So yes, it makes sense to have "cite"
> mean default value as determined by the choice of stylesheet.

I was trying to not assume CSL in this discussion, but certainly
that's how I was thinking.

> I've been skimming the CSL documentation, and I'm realizing that I
> actually don't have a very good understanding of how these different
> types of commands would be represented at the level of a CSL processor.

Yes, because it's currently silent on this issue. In part because of
this conversation, we've decided to add a section that deals with this
in the context of a generic API.

> Bruce, is it possible to have a CSL stylesheet that would be able to
> accommodate both e.g. "cite/paren" and "cite/footnote" in the same
> document?

No. We could extend CSL to do that, but I don't actually recall ever
getting that request.

> Can a stylesheet support an arbitrary numbers of different
> citation types like this, and can a CSL processor choose among those
> types based on their *names*?

CSL currently has a single citation template, so effectively one
system, defined in that style file.

CSL is silent on the rest, since we wanted to see how the ecosystem
evolved to respond to user needs. We left it up to the implementers on
how to address integrating.

But per above, we have enough information at this point to make the
silent explicit.

Based on that, what we have seen is what I've described here: two core
commands (cite and suppress-author), and now a third iteration of that
which we will add explicitly to the spec and schema in the next
release: the equivalent of citet.

This turns out relatively simple to implement by building on existing
CSL concepts, where output becomes, for example, "[author-only] " +
"([suppress-author])".

This is already supported in CSL, but we will add a new "intext"
element to allow one to define the author-only rendering for styles
(like APA) where the output is different than it is in the citation.

So to sum up, I expect we will explicitly define three commands:
default (the one defined in the citation template of the style),
suppress-author (which need not be explicitly defined in the style,
since the processor knows how to achieve this), and cite-text.

> If so, then I think Nicolas' proposal to have "cite" mean default and
> make non-default citations available as "cite/xxx" makes sense
> (especially with the other syntax supporting suppress-author, etc.).
>
> If not, then the "cite/xxx" syntax makes less sense to me; it just sort
> of looks like a different way of writing BibLaTeX commands, and will be
> hard to support when LaTeX is not the output format. I would be hesitant
> in that case to make "cite/xxx" the standard way to express "this
> citation should be rendered in manner xxx, instead of the default".
>
> Best,
> Richard

Bug: open pdfview link causes severe memory allocation [9.3.6 (9.3.6-60-gf3c137-elpaplus @ /home/firmart/.emacs.d/elpa/org-plus-contrib-20200427/)]

[Firmin Martin]

Hello,

After a package update (especially org-mode and pdf-tools), I remark two
changes about *pdfview links* :

1. Follow a *file link* doesn't open pdf with pdfview mode anymore,
   instead, it opens the pdf using the default system's pdf reader. 
2. Open *pdfview link* now causes severe memory allocation which freezes
   quickly my PC. 

I tested if it's pdftools issue, but it's not: editing a pdf opens
successfully the pdf with pdfview mode.

Emacs: GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.8, cairo 
version 1.16.0) of 2020-01-13
Packages:
- Org mode version 9.3.6 (9.3.6-60-gf3c137-elpaplus @ 
/home/firmart/.emacs.d/elpa/org-plus-contrib-20200427/)
- pdf-tools version: 20200427.2136
- org-pdfview version: 20180225.1006

N.B. I just noticed that there is a relatively new package
 "org-pdftools" which may fix this behavior. But this is a severe bug
 that shouldn't happen.  

Best,

Firmin Martin

Re: wip-cite status question and feedback

[Richard Lawrence]

"Bruce D'Arcus"  writes:

>> > My understanding, though, is that org "cite" would default to your
>> > last example I quote above (in natibib, citep); that there's no need
>> > for a dedicated "cite/paren" command, either reserved or not.
>>
>> Not necessarily. "cite" means default value, whatever that is. It could,
>> for example, mean: "cite/text" for every citation, if that is what you
>> use the most. In that case, "cite/paren" is necessary, to override it
>> locally. It could also be, e.g., "cite/footnote", then both "cite/text"
>> and "cite/paren" could be of some use. That was suggested by Richard
>> Lawrence in this thread, if my memory serves me right.
>>
>> Does that make sense?
>
> I think so. I'll defer to Richard on this, since he was making this point.

Sorry to take so long to reply. The point I made earlier was that, as
far as I understand, the choice of CSL stylesheet is the main factor
determining how a given citation gets rendered into the output (assuming
you process citations with CSL). So yes, it makes sense to have "cite"
mean default value as determined by the choice of stylesheet.

I've been skimming the CSL documentation, and I'm realizing that I
actually don't have a very good understanding of how these different
types of commands would be represented at the level of a CSL processor.

Bruce, is it possible to have a CSL stylesheet that would be able to
accommodate both e.g. "cite/paren" and "cite/footnote" in the same
document? Can a stylesheet support an arbitrary numbers of different
citation types like this, and can a CSL processor choose among those
types based on their *names*?

If so, then I think Nicolas' proposal to have "cite" mean default and
make non-default citations available as "cite/xxx" makes sense
(especially with the other syntax supporting suppress-author, etc.).

If not, then the "cite/xxx" syntax makes less sense to me; it just sort
of looks like a different way of writing BibLaTeX commands, and will be
hard to support when LaTeX is not the output format. I would be hesitant
in that case to make "cite/xxx" the standard way to express "this
citation should be rendered in manner xxx, instead of the default".

Best,
Richard

Re: [ANN] faster org-table-to-lisp

[Nicolas Goaziou]

tbanelwebmin  writes:

> I realized that not calling `org-table-end' may cause a corner case:
>
> | 2 | b |
> | c | d |
>
> #+TBLFM: @1$1=2||3

Indeed. I also realized this, and fixed it a couple of hours ago. You
will notice I shamelessly used your "\\="© trick! :)

> I do agree. We can expect callers to be on a table. If they are not,
> they will get `nil', and instantly notice it.

Great. I removed the check and added an entry in ORG-NEWS. It shouldn't
make any speed difference in your monster table, because it is located
right after a headline. It will, however, help tremendously in tables
buried deep within a section.

Re: [ANN] faster org-table-to-lisp

[tbanelwebmin]

Le 01/05/2020 à 12:15, Nicolas Goaziou a écrit :

> Hello,
>
> tbanelwebmin  writes:
>
>> Nicolas, how did you do that? Your version is 25% faster than mine,
>> and the code is 33% shorter! Very elegant.
> Thank you. There's nothing fancy, really.
>
> The main difference is that it does not call `org-table-end'. Minor
> tweaks are:
>
> - use simpler regexps,
> - call `skip-chars-forward' whenever possible.

I realized that not calling `org-table-end' may cause a corner case:

| 2 | b |
| c | d |
#+TBLFM: @1$1=2||3

is read as:
(("2" "b") ("c" "d") ("" "3"))
because of the "|" just below the table.

This can be fixed by changing the ending condition from
  (while (search-forward "|" (line-end-position) t)
to
  (while (re-search-forward "^[ \t]*|" (line-end-position) t)

Not a big deal.

>> Sorry, I may not understood what you said:
>> = Since you're changing the signature, I suggest to provide the table
>> = element instead of ORG-AT-TABLE-P. AFAICT, `org-babel-read-element',
>> = through `org-babel-read-table', would greatly benefit from this.
>>
>> Could you elaborate (if still relevant)?
> If you know the table ELEMENT, you don't need to check if you're at
> a table, nor do you need to compute table boundaries. We could have made
> use of this information to avoid a call to `org-at-table-p', much like
> your initial intent.
>
> Thinking about it, we don't even need to call `org-at-table-p' at all.
> Indeed, this is a low-level, non-interactive, function. We can
> reasonably expect the callers to check if they are really at a table in
> the first place.
>
> It would increase speed for this function noticeably, and the ELEMENT
> argument would not be relevant anymore.
>
> WDYT?

I do agree. We can expect callers to be on a table. If they are not,
they will get `nil', and instantly notice it.

>> The side effect of `re-search-forward' was to advance point, while
>> `looking-at' don't move.
> Ah true. I overlooked that.
>
> Regards,
> -- 
> Nicolas Goaziou
>
Have fun,
Thierry Banel

Re: [ANN] faster org-table-to-lisp

[Nicolas Goaziou]

Hello,

tbanelwebmin  writes:

> Nicolas, how did you do that? Your version is 25% faster than mine,
> and the code is 33% shorter! Very elegant.

Thank you. There's nothing fancy, really.

The main difference is that it does not call `org-table-end'. Minor
tweaks are:

- use simpler regexps,
- call `skip-chars-forward' whenever possible.

> Sorry, I may not understood what you said:
> = Since you're changing the signature, I suggest to provide the table
> = element instead of ORG-AT-TABLE-P. AFAICT, `org-babel-read-element',
> = through `org-babel-read-table', would greatly benefit from this.
>
> Could you elaborate (if still relevant)?

If you know the table ELEMENT, you don't need to check if you're at
a table, nor do you need to compute table boundaries. We could have made
use of this information to avoid a call to `org-at-table-p', much like
your initial intent.

Thinking about it, we don't even need to call `org-at-table-p' at all.
Indeed, this is a low-level, non-interactive, function. We can
reasonably expect the callers to check if they are really at a table in
the first place.

It would increase speed for this function noticeably, and the ELEMENT
argument would not be relevant anymore.

WDYT?

> The side effect of `re-search-forward' was to advance point, while
> `looking-at' don't move.

Ah true. I overlooked that.

Regards,

-- 
Nicolas Goaziou

Re: [ANN] faster org-table-to-lisp

[tbanelwebmin]

Nicolas, how did you do that? Your version is 25% faster than mine,
and the code is 33% shorter! Very elegant.

Le 01/05/2020 à 00:35, Nicolas Goaziou a écrit :

> tbanelwebmin  writes:
>
>> I found a way to ensure full backward compatibility. I keep the same
>> signature. When a table is given as a string parameter, it is inserted
>> into a temporary buffer, which is then parsed. Overall, the resulting
>> speed is quite satisfactory.
> A, you didn't like my ELEMENT suggestion.

Sorry, I may not understood what you said:
= Since you're changing the signature, I suggest to provide the table
= element instead of ORG-AT-TABLE-P. AFAICT, `org-babel-read-element',
= through `org-babel-read-table', would greatly benefit from this.

Could you elaborate (if still relevant)?

>
>> I also made the function more tolerant to ill-formed tables: missing
>> "|" or excess of spaces at the end of a row are now gracefully
>> accepted.
> Great!
>
>> (while (not (re-search-forward "\\=\\s-*\n" end t))
> (re-search-forward "\\=..." ...) -> (looking-at "..." ...)

The side effect of `re-search-forward' was to advance point, while
`looking-at' don't move. This does not matter anymore.

>
> Note that Org does not use \\s- but the simpler [ \t].
>
> Also, the regexp assumes the table end with a newline character, which
> may not be the case.
>
>>   (unless (re-search-forward "\\=\\s-*\\([^|\n]*\\)\\(|?\\)" end 
>> t)
>> (user-error "Malformed table at char %s" (point)))
> This cannot happen. The regexp above matches anything, i.e., the empty
> string.

Right! I didn't noticed...

>
>>   (goto-char (match-end 1))
>>   (skip-chars-backward " \t" (match-beginning 1))
>>   (push
>>(buffer-substring-no-properties (match-beginning 1) (point))
>>row)
>>   (goto-char (match-end 2)))
>> (push (nreverse row) table)))
>> (nreverse table)
> I applied your suggestion, with a few simplifications. Hopefully, it
> squeezed a bit more the execution time. Let me know!

Yes! 25%
My two unit tests give correct results.

>
>> The new implementation can be more than 100 times faster. This enhances
>> responsiveness of Babel or Gnuplot blocks handling thousands long
>> tables.
> Looks good. However, we didn't change the signature, so I didn't add
> this to ORG-NEWS. It is in the commit message, tho.
>
> Thank you!
>
Nice team work, thank you too!
Thierry Banel