Re: $LR in Table Formula

[Carsten Dominik]

On Sat, Apr 18, 2020 at 10:33 PM Marco Wahl  wrote:

> Carsten Dominik  writes:
>
> > This was an old way to refer to fields in the last row.  It was already
> > deprecated in 2011.  I also does not seem to work anymore.
> >
> > I had forgotten all about it and only found it back with
> >
> > git log -S \$LR --source --all | less
> >
> > which pointed me to commit 8237c9ae6d587a22646333e0315683675e2db538
>
> Thanks for the eludication!
>
> 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.

Carsen


>
>
> My 2 ct,
> -- Marco
>

Re: wip-cite status question and feedback

[Joost Kremers]

On Sat, Apr 18 2020, Bruce D'Arcus wrote:
The question, then: Is that what you're saying; we don't need 
suppress-author?


I think I actually agree, though will add a topic that came up 
in the
CSL implementation discussion for the author-in-text styles in 
the

past few days.

Here's a common way a citation might be integrated in a 
narrative text:


Doe, by contrast, found negative results (2017).


There are other constructions in with suppress-author is useful. 
For example, possessives:


Doe's (2017) results... 

or 


Doe's (2017) ground braking paper...

Such use is not uncommon in my field.

Also, consider languages that require a case ending on the author 
name. And who knows what quirks other languages may have?


So we have the author name in-text, than some text, then the 
year-only citation.


The traditional way to do that in pandoc is to use the 
suppress-author

command at the end.

Doe, by contrast, found negative results [-@doe17].

So the piece of information I refer to above is that one of the 
CSL

implementers (Frank Bennett) figured out  how to make the above
example an author-in-text variant, so that you don't need
suppress-author, and the entire sentence is the citation.

He did this by adding an optional "infix" variable to the 
citation.


I doubt that would work in every case. Consider e.g.,
;
In her original (2017) study, Doe argues that... 


[...]
This is arguably an edge case, but it does relate to the 
question of
whether we need two (standard and author-in-text) or three 
commands

(adding the suppress-author).


I would definitely say that a way to suppress the author is 
necessary. In fact, I would argue that there should also be a way 
to cite just the author name, if only to make sure it's not 
misspelled or written inconsistently. (I'm a regular user of 
\citeauthor in BibLaTeX... ;-) But I admit that's less of a 
necessity.



--
Joost Kremers
Life has its moments

Re: $LR in Table Formula

[Marco Wahl]

Carsten Dominik  writes:

> This was an old way to refer to fields in the last row.  It was already
> deprecated in 2011.  I also does not seem to work anymore.
>
> I had forgotten all about it and only found it back with
>
> git log -S \$LR --source --all | less
>
> which pointed me to commit 8237c9ae6d587a22646333e0315683675e2db538

Thanks for the eludication!  

If the Org code shall iterate towards clarity then the question would be
resurrection or elimination of the Last Row (LR) feature AFAICS.


My 2 ct,
-- Marco

Re: wip-cite status question and feedback

[denis . maier . lists]

> Bruce D'Arcus  hat am 18. April 2020 15:22 geschrieben:
> 
>  
> But ...
> 
> On Sat, Apr 18, 2020 at 9:17 AM Bruce D'Arcus  wrote:
> 
> ...
> 
> > I can't see that it's necessary to have a fourth, because I think the
> > result of that would be this, which doesn't make any sense.
> >
> > 4.  "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
> > author-in-text+suppress-author command
> 
> ... notwithstanding that, I think Nicolas' latest proposed syntax
> would support this anyway.
> 
> [citet:-@doe17]

Perhaps that can be used as author-only?

That would be:
[cite: @doe17] =>  (Doe 2017) [or a footnote, of course.)
[cite: -@doe17] =>  (2017)
[citet: @doe17] =>  Doe (2017)
[citet: -@doe17] =>  Doe

So we have like two basic citation types: One that is part of the narrative, 
one where the citation is set off from the main text. Both citations can be 
modified with a minus prefix. In one case this leads to "suppress author", in 
the other case this means "author only". (Using the same prefix for two 
different things can be considered problematic.)

Best,
Denis

Re: wip-cite status question and feedback

[Denis Maier]

> Bruce D'Arcus  hat am 18. April 2020 15:22 geschrieben:
> 
>  
> But ...
> 
> On Sat, Apr 18, 2020 at 9:17 AM Bruce D'Arcus  wrote:
> 
> ...
> 
> > I can't see that it's necessary to have a fourth, because I think the
> > result of that would be this, which doesn't make any sense.
> >
> > 4.  "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
> > author-in-text+suppress-author command
> 
> ... notwithstanding that, I think Nicolas' latest proposed syntax
> would support this anyway.
> 
> [citet:-@doe17]

Perhaps that can be used as author-only?

That would be:
[cite: @doe17] => (Doe 2017) [or a footnote, of course.)
[cite: -@doe17] => (2017)
[citet: @doe17] => Doe (2017)
[citet: -@doe17] => Doe

So we have like two basic citation types: One that is part of the narrative, 
one where the citation is set off from the main text. Both citations can be 
modified with a minus prefix. In one case this leads to "suppress author", in 
the other case this means "author only". (Using the same prefix for two 
different things can be considered problematic.)

Best,
Denis

Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines

[Nicolas Goaziou]

Hello,

stardiviner  writes:

> This sounds reasonable. (I deleted my patch on my local fork, I think your 
> solution is better.)

I pushed the changes. Now drawers folding is on par with blocks. You can
hide or show a drawer with `org-hide-drawer-toggle', which is similar to
`org-hide-block-toggle'. You may want to use it.

Now, visibility behaviour of drawers might be discussed. Currently, all
drawers are "mostly folded", which means that Org tries to fold them
whenever it can. OTOH, blocks are "mostly expanded", i.e., most
operations of the structure of the document opens the blocks. An
alternative would be to have property drawers "mostly folded" and
regular drawers "mostly expanded", i.e., like regular blocks. But that
would partly defeat the "tuck stuff away" feature from drawers.

Another (better?) option would be: "don't mess with folding state" for
regular drawers and blocks, i.e., what is open stays open, what is
closed stays closed. But that's more difficult to achieve. Any taker?

In any case, I think property drawers need to be "mostly folded".

Regards,

-- 
Nicolas Goaziou

Re: Overleaf equivalent for org-babel users?

[Ken Mankoff]

I've looked a bit more into what Joseph linked to. What about using Org
locally on your computer, and sharing an http://markup.rocks + DropBox
access to your Org files for non-emacs collaborators?

If CoCalc provides something you need that you don't have locally, you
could combine CoCalc + Markup.Rocks. I heard (and CoCalc repeats) here
https://doc.cocalc.com/howto/external-tools.html that DropBox won't work on
certain linux filesystems, but I have never run into this issue yet, so it
may work.

On Sat, Apr 18, 2020 at 8:17 AM Prof. Dr. Johanna May <
johanna@th-koeln.de> wrote:

> Dear Ken,
>
> thank you very much. I'm looking into cocalc now. I already got it to
> compile some test.org file as pdf. I also set up a test file there in
> order to start finding out how to do this. Next step, I guess, would be
> to see, if org-babel works. Unfortunately, it looks like
> a bit more work since for collaboration I need to find out about
> versioning and testing the stuff and also about how to get some very
> simple interface working there, maybe for small edits github is
> nicer. But I have to admit, my experience on tramp (what is that?) and
> git is very limited, so I don't yet have an idea of how to set that up
> in a good way.
>
> Jupyter Notebooks are not what I feel is right for lecture notes in that
> subject since they cannot display circuitikz and latex export is not the
> way it should be. It's not a programming class I'm teaching and many
> students do prefer the pdf they can either print out or annotate in some
> software on their tablets or just display on their smartphone. The exam
> is in writing and on paper.
>
> I do also provide some jupyter notebooks, but only for the interested
> part of the class and they surely can manage without that. As always,
> such options are rather taken up by the more skilled, and not so much by
> the weaker students, unfortunately.
>
> Cheers, have a good weekend!
>
> J
>
> Am Samstag, 18. April 2020 um 15:59 schrieb Ken Mankoff ...
> > Hi Dr. May,
> >
> > Unfortunately I have not found Emacs + Org to be the right tools when
> collaborating. What we need is a way for Org wrap/interface/edit Jupyter
> Notebooks, since that seems to be becoming the standard. Unfortunately.
> >
> > I have had some luck with a hybrid approach using the Sage Notebook
> server. That project is no longer active (perhaps due to the success of
> Jupyter Notebooks?), but I think you can do something similar with either
> Google Colab https://colab.research.google.com or more likely CoCalc
> https://cocalc.com/
> >
> > Google Collab is just an interface to Jupyter Notebooks.
> >
> > CoCalc can also just run Jupyter Notebooks, but also lets you have a
> full Linux environment, bash shell, ssh, git, etc. I think you may need to
> pay for this level of service, but you could then run emacs remotely via
> ssh, or locally and use tramp. If the backend is git you may be able to
> work locally and sync with the webserver interface to the tools that your
> colleagues would see.
> >
> > I still don't think your colleagues would be directly editing your Org
> source though, but you may be able to get close to what you're looking for
> on those sites. Good luck, and please do post back here if you come up with
> a good solution.
> >
> >   -k.
> >
> > On 2020-04-16 at 10:22 -07, Prof. Dr. Johanna May
> >  wrote...
> >> Hey there,
> >>
> >> I've been preparing lecture notes with org-mode and lualatex export
> >> that include python diagrams and so on for about more than a year. Now
> >> my colleagues and team start to get interested in tweaking the
> >> results. Therefore, we would need some kind of online collaboration
> >> solution similar to overleaf that can compile the latex including the
> >> python (org-babel) inserts. And, obviously, versioning would also come
> >> in handy, so that would rather be github / gitlab functionality.
> >>
> >> Does anyone know of a solution like overleaf that can be used for
> >> that? Could you point me at your description of any setup needed? Or,
> >> alternatively, do you have some good description of how to set up a
> >> server / virtual machine that can do that? (at best including a
> >> virtual emacs interface, so not all users have to do all the
> >> installations locally)? If so, that description would also interest
> >> me.
> >>
> >> I would like to either use some online platform like overleaf or
> >> explain to my university colleagues who already have servers running
> >> what they could do for me.
> >>
> >> The problem is, that the collaboration colleagues are not good friends
> >> with coding (they prefer word to latex, excel to python ... until now,
> >> at least), so I'm not very inclined to suggest them to start using
> >> emacs. I would very much prefer some web-based solution to get them
> >> started. Also, such a solution might provide ways of having students
> >> contribute smaller bits and pieces without having to go thru the whole
> >> 

Re: Bug: org-publish-sitemap messes absolute sitemap paths [9.3.6 (9.3.6-25-g685b2c-elpa @ c:/Users/juanj/OneDrive/Library/Emacs/elpa-26/org-20200316/)]

[Nicolas Goaziou]

Hello,

> The line
>
>   (sitemap-filename (concat root (or sitemap-filename "sitemap.org")))
>
> in ox-publish.el prevents the user from using an absolute path for the
> location of the sitemap. This is also not very good practice, because
> concatenation does not guarantee good pathnames. Instead it should read
>
>   (sitemap-filename (expand-file-name (or sitemap-filename
>   
>"sitemap.org")
>   
> root))

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: Fwd: Re: how to renumber footnotes?

[Kyle Meyer]

Joost Kremers  writes:

> Accidentally sent this message off-list. Trying again:

Hmm I didn't find any of the six messages in the References: header when
I searched .  I see
the same messages missing in the thread displayed at
.  So it
looks like a lot of this thread went off list, or at least is very
delayed in the pipeline.

I guess this thread was related but separate from Sharon's "Subject:
org-footnote renumbering" post at
.

Re: $LR in Table Formula

[Carsten Dominik]

This was an old way to refer to fields in the last row.  It was already
deprecated in 2011.  I also does not seem to work anymore.

I had forgotten all about it and only found it back with

git log -S \$LR --source --all | less

which pointed me to commit 8237c9ae6d587a22646333e0315683675e2db538

Carsten

On Sat, Apr 18, 2020 at 1:56 PM Eric S Fraga  wrote:

> Ignore my previous email/post.  I was obviously under the influence.  I
> see the LR references in the code.
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-492-gc990d4
>
>

Re: Overleaf equivalent for org-babel users?

[Prof. Dr. Johanna May]

Dear Ken,

thank you very much. I'm looking into cocalc now. I already got it to
compile some test.org file as pdf. I also set up a test file there in
order to start finding out how to do this. Next step, I guess, would be
to see, if org-babel works. Unfortunately, it looks like
a bit more work since for collaboration I need to find out about
versioning and testing the stuff and also about how to get some very
simple interface working there, maybe for small edits github is
nicer. But I have to admit, my experience on tramp (what is that?) and
git is very limited, so I don't yet have an idea of how to set that up
in a good way.

Jupyter Notebooks are not what I feel is right for lecture notes in that
subject since they cannot display circuitikz and latex export is not the
way it should be. It's not a programming class I'm teaching and many
students do prefer the pdf they can either print out or annotate in some
software on their tablets or just display on their smartphone. The exam
is in writing and on paper.

I do also provide some jupyter notebooks, but only for the interested
part of the class and they surely can manage without that. As always,
such options are rather taken up by the more skilled, and not so much by
the weaker students, unfortunately.

Cheers, have a good weekend!

J

Am Samstag, 18. April 2020 um 15:59 schrieb Ken Mankoff ...
> Hi Dr. May,
>
> Unfortunately I have not found Emacs + Org to be the right tools when 
> collaborating. What we need is a way for Org wrap/interface/edit Jupyter 
> Notebooks, since that seems to be becoming the standard. Unfortunately.
>
> I have had some luck with a hybrid approach using the Sage Notebook server. 
> That project is no longer active (perhaps due to the success of Jupyter 
> Notebooks?), but I think you can do something similar with either Google 
> Colab https://colab.research.google.com or more likely CoCalc 
> https://cocalc.com/
>
> Google Collab is just an interface to Jupyter Notebooks.
>
> CoCalc can also just run Jupyter Notebooks, but also lets you have a full 
> Linux environment, bash shell, ssh, git, etc. I think you may need to pay for 
> this level of service, but you could then run emacs remotely via ssh, or 
> locally and use tramp. If the backend is git you may be able to work locally 
> and sync with the webserver interface to the tools that your colleagues would 
> see.
>
> I still don't think your colleagues would be directly editing your Org source 
> though, but you may be able to get close to what you're looking for on those 
> sites. Good luck, and please do post back here if you come up with a good 
> solution.
>
>   -k.
>
> On 2020-04-16 at 10:22 -07, Prof. Dr. Johanna May
>  wrote...
>> Hey there,
>>
>> I've been preparing lecture notes with org-mode and lualatex export
>> that include python diagrams and so on for about more than a year. Now
>> my colleagues and team start to get interested in tweaking the
>> results. Therefore, we would need some kind of online collaboration
>> solution similar to overleaf that can compile the latex including the
>> python (org-babel) inserts. And, obviously, versioning would also come
>> in handy, so that would rather be github / gitlab functionality.
>>
>> Does anyone know of a solution like overleaf that can be used for
>> that? Could you point me at your description of any setup needed? Or,
>> alternatively, do you have some good description of how to set up a
>> server / virtual machine that can do that? (at best including a
>> virtual emacs interface, so not all users have to do all the
>> installations locally)? If so, that description would also interest
>> me.
>>
>> I would like to either use some online platform like overleaf or
>> explain to my university colleagues who already have servers running
>> what they could do for me.
>>
>> The problem is, that the collaboration colleagues are not good friends
>> with coding (they prefer word to latex, excel to python ... until now,
>> at least), so I'm not very inclined to suggest them to start using
>> emacs. I would very much prefer some web-based solution to get them
>> started. Also, such a solution might provide ways of having students
>> contribute smaller bits and pieces without having to go thru the whole
>> learning curve of learning the use of emacs, installing all the tools,
>> etc.pp. Any ideas?
>>
>> Thank you very much!
>>
>> Cheers,
>>
>> J. May


-- 
Prof. Dr. Johanna May
Stellvertretende Institutsleiterin CIRE
Fakultät für Informations-, Medien- und Elektrotechnik (F07)
Institut für Elektrische Energietechnik (IET)
Cologne Institute for Renewable Energy (CIRE)
Lehrgebiete: Energieeffizienz und Grundlagen Elektrotechnik

T: +49 221-8275-2697
M: +49 174 891 9002
E: johanna@th-koeln.de

Technische Hochschule Köln
Campus Deutz
Betzdorfer Str. 2
50679 Köln
Raum: HW2-40

www.th-koeln.de

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Marco Wahl]

Hi,

And thanks, Eric!

Eric S Fraga  writes:

> Now, I might be pushing my luck so apologies but: it would be nice if
> the kill row/column behaviour were also consistent.  Right now, if you
> kill a row, it leaves point where it was; if you kill a column, it moves
> point to the previous column.  That is, for instance, if point is in row
> 2 column 2, deleting a row will leave point in row 2, column 2. Deleting
> a column moves point to row 2 column 1.  The row killing behaviour seems
> more usable so I wonder whether we could have the column behaviour
> changed as well?

Indeed, why not?  I pushed a respective change.  I introduced a subtlety
when deleting from the rightmost column or from immediately right of the
table.  That was not needed with point moving to the left, as it has
been before.

The change is small, only two lines.  So this could be easily reverted.

Please check it out.


Thanks and best regards,
-- Marco

Re: Overleaf equivalent for org-babel users?

[Ken Mankoff]

Hi Dr. May,

Unfortunately I have not found Emacs + Org to be the right tools when 
collaborating. What we need is a way for Org wrap/interface/edit Jupyter 
Notebooks, since that seems to be becoming the standard. Unfortunately.

I have had some luck with a hybrid approach using the Sage Notebook server. 
That project is no longer active (perhaps due to the success of Jupyter 
Notebooks?), but I think you can do something similar with either Google Colab 
https://colab.research.google.com or more likely CoCalc https://cocalc.com/

Google Collab is just an interface to Jupyter Notebooks.

CoCalc can also just run Jupyter Notebooks, but also lets you have a full Linux 
environment, bash shell, ssh, git, etc. I think you may need to pay for this 
level of service, but you could then run emacs remotely via ssh, or locally and 
use tramp. If the backend is git you may be able to work locally and sync with 
the webserver interface to the tools that your colleagues would see.

I still don't think your colleagues would be directly editing your Org source 
though, but you may be able to get close to what you're looking for on those 
sites. Good luck, and please do post back here if you come up with a good 
solution.

  -k.

On 2020-04-16 at 10:22 -07, Prof. Dr. Johanna May
 wrote...
> Hey there,
>
> I've been preparing lecture notes with org-mode and lualatex export
> that include python diagrams and so on for about more than a year. Now
> my colleagues and team start to get interested in tweaking the
> results. Therefore, we would need some kind of online collaboration
> solution similar to overleaf that can compile the latex including the
> python (org-babel) inserts. And, obviously, versioning would also come
> in handy, so that would rather be github / gitlab functionality.
>
> Does anyone know of a solution like overleaf that can be used for
> that? Could you point me at your description of any setup needed? Or,
> alternatively, do you have some good description of how to set up a
> server / virtual machine that can do that? (at best including a
> virtual emacs interface, so not all users have to do all the
> installations locally)? If so, that description would also interest
> me.
>
> I would like to either use some online platform like overleaf or
> explain to my university colleagues who already have servers running
> what they could do for me.
>
> The problem is, that the collaboration colleagues are not good friends
> with coding (they prefer word to latex, excel to python ... until now,
> at least), so I'm not very inclined to suggest them to start using
> emacs. I would very much prefer some web-based solution to get them
> started. Also, such a solution might provide ways of having students
> contribute smaller bits and pieces without having to go thru the whole
> learning curve of learning the use of emacs, installing all the tools,
> etc.pp. Any ideas?
>
> Thank you very much!
>
> Cheers,
>
> J. May

Re: wip-cite status question and feedback

[Bruce D'Arcus]

But ...

On Sat, Apr 18, 2020 at 9:17 AM Bruce D'Arcus  wrote:

...

> I can't see that it's necessary to have a fourth, because I think the
> result of that would be this, which doesn't make any sense.
>
> 4.  "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
> author-in-text+suppress-author command

... notwithstanding that, I think Nicolas' latest proposed syntax
would support this anyway.

[citet:-@doe17]

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Sat, Apr 18, 2020 at 8:48 AM Richard Lawrence
 wrote:
>
> Hi Bruce and all,
>
> "Bruce D'Arcus"  writes:
>
> > Just to align what you're saying and what I'm saying:
> >
> > I see three commands in the pandoc syntax: standard/parenthetical,
> > author-in-text, and suppress-author; that look like so:
> >
> > [@doe17]
> > @doe17
> > -@doe17
> >
> > Implicit in what you wrote is the last one is not needed.
> >
> > The question, then: Is that what you're saying; we don't need 
> > suppress-author?
>
> Ah, no, I didn't intend it like that.

Glad I asked then!

> I am not very familiar with the
> implementation details of pandoc-citeproc and wasn't aware that
> suppress-author was a different type of citation command. I was
> (vaguely) thinking of the third case as a "variant" of an in-text
> citation type, rather than a separate type.
>
> Actually, the Pandoc example you give seems to support this way of
> thinking about it:
>
> > Doe, by contrast, found negative results [-@doe17].
>
> That is a fourth case, right? "[-@doe17]" is not equivalent to "-@doe17"?

I think, notwithstanding a mistake I think I made in my previous
message, the "-" wouldn't be relevant to a bare author-in-text
citation command; the latter case.

So I think that's still three commands. Hopefully the below explains
why, but please let me know.

> In other words, what we have here are two orthogonal distinctions:
> parenthetical vs. in-text, and normal vs. author-suppressed. So, at
> least on my funny way of counting ;), that's two citation "types", with
> two "variants" within each of those types.

Just for clarity, for the record, "parenthetical" is the language of
author-date citation styles.

But what we're talking about with citet-like citations is broader than this.

In a numeric style, for example, you could have "Doe [3]"; so this
really applies to any style type (including end/footnote-based).

What we're doing is putting the author in the sentence; and outside
the citation.

This is why I'm using the more general language of  "author-in-text."

So three output cases, in author-date/numeric, where I've placed
content output by the citation processor in braces to distinguish it
from content entered by the user:

1. "Blah blah {(Doe, 2017)}"/"Blah blah {[3]}" -> default cite command
2. "{Doe (2017)}"/"{Doe [3]}" -> author-in-text command
3. "Doe blah blah {(2017)}"/"Doe blah blah {[3]}" -> suppress-author command

I can't see that it's necessary to have a fourth, because I think the
result of that would be this, which doesn't make any sense.

4.  "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
author-in-text+suppress-author command

Let us know what you think?

Bruce

Re: [PATCH] Add support for trace and error output streams in Common Lisp

[akater]

To test the feature, please
- git clone https://gitlab.com/akater/org-mode.git
- checkout ob-lisp-traces-and-errors
- load lisp/ob-lisp.el and lisp/ob-core.el in a running Emacs
- M-: (defalias 'org-babel-execute:lisp 
'org-babel-execute:lisp--multiple-targets-support) RET

and also
- git clone https://github.com/akater/slime.git
- checkout grab-multiple-outputs
- load slime.el

Then start SLIME (this will load patched swank.lisp) and try examples in

https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00137.html

There is a defalias form in the patched ob-lisp.el but it refers to a future 
SLIME version .

Re: wip-cite status question and feedback

[Richard Lawrence]

Hi Bruce and all,

"Bruce D'Arcus"  writes:

> Just to align what you're saying and what I'm saying:
>
> I see three commands in the pandoc syntax: standard/parenthetical,
> author-in-text, and suppress-author; that look like so:
>
> [@doe17]
> @doe17
> -@doe17
>
> Implicit in what you wrote is the last one is not needed.
>
> The question, then: Is that what you're saying; we don't need suppress-author?

Ah, no, I didn't intend it like that. I am not very familiar with the
implementation details of pandoc-citeproc and wasn't aware that
suppress-author was a different type of citation command. I was
(vaguely) thinking of the third case as a "variant" of an in-text
citation type, rather than a separate type.

Actually, the Pandoc example you give seems to support this way of
thinking about it:  

> Doe, by contrast, found negative results [-@doe17].

That is a fourth case, right? "[-@doe17]" is not equivalent to "-@doe17"?

In other words, what we have here are two orthogonal distinctions:
parenthetical vs. in-text, and normal vs. author-suppressed. So, at
least on my funny way of counting ;), that's two citation "types", with
two "variants" within each of those types.

> one of the CSL implementers (Frank Bennett) figured out how to make
> the above example an author-in-text variant, so that you don't need
> suppress-author, and the entire sentence is the citation.
>
> He did this by adding an optional "infix" variable to the citation.
>
> So in that example, you would have:
>
> - command: "author-in-text"
> - citekey: "doe17"
> - infix: "by contrast, found negative results"
>
> This is arguably an edge case, but it does relate to the question of
> whether we need two (standard and author-in-text) or three commands
> (adding the suppress-author).
>
> One could make the reasonable argument (I think, though not everyone
> would agree) that the workaround for the above example is to use
> author-in-text command but restructure the sentence:
>
> @doe17, by contrast, found negative results.
>
> From that perspective, I guess we indeed need only two commands:
> standard (parenthetical) and author-in-text.

This way of writing the sentence seems less obvious to me than the
pandoc syntax. It also has the potential disadvantage that the choice
between rendering

"Doe (2017), by contrast, found negative results"

and

"Doe, by contrast, found negative results (2017)"

now has to be made at the level of the stylesheet instead of at the
level of the sentence where that citation appears. My instinct is that
this choice is informed by individual writing style and better made at
the level of the sentence. But you probably have a better sense than I
do of whether this is something that should at least sometimes be
controlled by the stylesheet. (Are there e.g. journals that always want
in-text citations to look like the latter case? I have no idea.)

In any case, if I'm right that this choice is usually better made at the
sentence level, then I think the syntax needs to support all four cases.
.The pandoc syntax does this, and I think the suppress-author variation
is probably needed often enough that we should have something similar.

-- 
Best,
Richard

Re: $LR in Table Formula

[Eric S Fraga]

Ignore my previous email/post.  I was obviously under the influence.  I
see the LR references in the code.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-492-gc990d4

Re: $LR in Table Formula

[Eric S Fraga]

On Saturday, 18 Apr 2020 at 01:31, Marco Wahl wrote:
> Hi!
>
> By accident at browsing the code I stumbled over "$LR" in column
> formulas.  TBH I don't understand "$LR" and I haven't found a bit about
> it in the documentation.
>
> What is the meaning of $LR?

Where in the code did you find this?  I cannot see it anywhere in latest
org, assuming you are talking about the code for org mode.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-492-gc990d4

Re: Bug: org-table-insert-column edits formulas wrongly [9.3 (release_9.3 @ /usr/local/Cellar/emacs-plus/HEAD-9d38564/share/emacs/28.0.50/lisp/org/)]

[Eric S Fraga]

On Saturday, 18 Apr 2020 at 00:51, Marco Wahl wrote:
> Okay, pushed.

Thank you!  Seems to work very well.

Now, I might be pushing my luck so apologies but: it would be nice if
the kill row/column behaviour were also consistent.  Right now, if you
kill a row, it leaves point where it was; if you kill a column, it moves
point to the previous column.  That is, for instance, if point is in row
2 column 2, deleting a row will leave point in row 2, column 2. Deleting
a column moves point to row 2 column 1.  The row killing behaviour seems
more usable so I wonder whether we could have the column behaviour
changed as well?

Thanks again,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-492-gc990d4

Re: adding paragraph folding to visibility cycling?

[Bruce D'Arcus]

Hi Nicolas,

On Sat, Apr 18, 2020 at 4:03 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > One feature I have always found helpful when working on long documents
> > is paragraph folding; where paragraphs are folded to display just the
> > first line.
>
> [...]
>
> > I can get paragraph folding and unfolding in org using packages like
> > origami (say with origami-toggle-all-nodes), but I was wondering if
> > there's a way to easily add it to org visibility cycling?
>
> How would that work? I.e.,
> - what key,
> - how does it integrate with folding cycling, if it does at all?

My question was based on the idea to do the latter.

Right now, I just keybindings for  origami-toggle-all-nodes origami-toggle-node.

But I was thinking to have this folding as a step between disclosing
all headings, and disclosing everything.

Does that make sense?

Bruce

Re: wip-cite status question and feedback

[Bruce D'Arcus]

Just one question, Richard ...

On Sat, Apr 18, 2020 at 5:50 AM Richard Lawrence
 wrote:

[...]

> I think it is worth pointing out to Bib(La)TeX users that it is useful
> to avoid a proliferation of citation commands in Org syntax. The syntax
> discussed so far achieves this by "factoring out" formatting information
> that BibLaTeX puts into the command into other parts of the syntax and
> into the choice of citation stylesheet. For example, instead of having
> \footnotecite and \parencite as separate commands, you can just have a
> single cite command, and the choice of stylesheet determines whether
> citations get formatted as footnotes or as in-text parenthetical
> citations or as something else.

Before the question, I did just want to add that this is an excellent point.

[...]

> My experience is that it's typically just two (e.g. parenthetical and
> author-in-text), and my memory of the earlier conversation was that most
> people agreed.

Just to align what you're saying and what I'm saying:

I see three commands in the pandoc syntax: standard/parenthetical,
author-in-text, and suppress-author; that look like so:

[@doe17]
@doe17
-@doe17

Implicit in what you wrote is the last one is not needed.

The question, then: Is that what you're saying; we don't need suppress-author?

I think I actually agree, though will add a topic that came up in the
CSL implementation discussion for the author-in-text styles in the
past few days.

Here's a common way a citation might be integrated in a narrative text:

Doe, by contrast, found negative results (2017).

So we have the author name in-text, than some text, then the year-only citation.

The traditional way to do that in pandoc is to use the suppress-author
command at the end.

Doe, by contrast, found negative results [-@doe17].

So the piece of information I refer to above is that one of the CSL
implementers (Frank Bennett) figured out  how to make the above
example an author-in-text variant, so that you don't need
suppress-author, and the entire sentence is the citation.

He did this by adding an optional "infix" variable to the citation.

So in that example, you would have:

- command: "author-in-text"
- citekey: "doe17"
- infix: "by contrast, found negative results"

This is arguably an edge case, but it does relate to the question of
whether we need two (standard and author-in-text) or three commands
(adding the suppress-author).

One could make the reasonable argument (I think, though not everyone
would agree) that the workaround for the above example is to use
author-in-text command but restructure the sentence:

@doe17, by contrast, found negative results.

>From that perspective, I guess we indeed need only two commands:
standard (parenthetical) and author-in-text.

Bruce

Bug: org-publish-sitemap messes absolute sitemap paths [9.3.6 (9.3.6-25-g685b2c-elpa @ c:/Users/juanj/OneDrive/Library/Emacs/elpa-26/org-20200316/)]

[Juan José García Ripoll]

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.


The line

  (sitemap-filename (concat root (or sitemap-filename "sitemap.org")))

in ox-publish.el prevents the user from using an absolute path for the
location of the sitemap. This is also not very good practice, because
concatenation does not guarantee good pathnames. Instead it should read

  (sitemap-filename (expand-file-name (or sitemap-filename

 "sitemap.org")
  root))

Emacs  : GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Package: Org mode version 9.3.6 (9.3.6-25-g685b2c-elpa @ 
c:/Users/juanj/OneDrive/Library/Emacs/elpa-26/org-20200316/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-protocol-default-template-key "l"
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-refile-targets '((org-agenda-files :maxlevel . 1)
  ("archive-2020.org" :maxlevel . 1))
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function
 org-icalendar-combined-agenda-file "~/Nextcloud/Documents/Notes/calendar.ics"
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-agenda-files '("~/Nextcloud/Documents/Notes/calendar.org"
"~/Nextcloud/Documents/Notes/areas.org"
"~/Nextcloud/Documents/Notes/projects.org"
"~/Nextcloud/Documents/Notes/meetings.org"
"~/Nextcloud/Documents/Notes/someday.org")
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-mode-hook '(#[0 "\301\211.\207"
   [imenu-create-index-function org-imenu-get-tree] 2]
 visual-line-mode juanjo:code-defaults
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-finalize-agenda-hook '(org-agenda-to-appt)
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-startup-indented t
 org-agenda-default-appointment-duration 60
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-babel-load-languages '((emacs-lisp . t) (python . t))
 org-ascii-format-drawer-function #[771 ".\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-babel-python-command 
"C:\\Users\\juanj/OneDrive/Library/Windows/scripts/conda_python.cmd"
 org-catch-invisible-edits 'show-and-error
 org-occur-hook '(org-first-headline-recenter)
 org-cycle-separator-lines 0
 org-protocol-protocol-alist '(("ebib-biblio-interface" :protocol
"ebib-biblio-interface" :function
ebib-biblio-interface-handler)
   ("share" :protocol "share" :function
jjgr-org-protocol-share)
   )
 org-structure-template-alist '(("n" . "notes") ("a" . "export ascii")
("c" . "center") ("C" . "comment")
("e" . "example") ("E" . "export")
("h" . "export html") ("l" . "export latex")
("q" . "quote") ("s" . "src") ("v" . "verse"))
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-todo-keywords '((sequence "TODO" "NEXT" "WAIT" "EVENT" "PROJ" "|" "DONE"
  "CANCEL" "DELEGATED")
 )
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-id-method 'org
 org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function

Re: wip-cite status question and feedback

[Richard Lawrence]

Joost Kremers  writes:

> Good points. I guess what this boils down to is whether Org wants 
> to be like LaTeX, where simple things are doable and complicated 
> things possible, or Pandoc, where simple things are simple indeed 
> and complicated things essentially impossible.
>
> To clarify: in LaTeX (biblatex) you can mix footnote and in-text 
> citations in a single document, Pandoc doesn't allow that. 
> Pandoc's functionality is sufficient for a great majority of 
> cases, but if you want or need to go beyond it, things get very 
> difficult.

Right. The Pandoc syntax trades some of the flexibility of (Bib)LaTeX
for the ability to render the citations it *does* support in a whole
bunch of non-LaTeX formats.

I personally think this is a good tradeoff, and one I would like to see
Org adopt. In both Org and Pandoc, you can use embedded LaTeX if you
need it. If you need the full power of BibLaTeX citations, then you are
confined to LaTeX export anyway, so you might as well just use BibLaTeX
commands in your document. But if you fall into the great majority of
use cases, you can use specialized citation syntax, and thereby get
reasonable behavior in other export formats too.

> My suggestion would still be not to hard-code a limit on possible 
> citation commands. Org itself should probably just provide the 
> basics, but users and add-on packages should be allowed to define 
> more specific commands with readable names and there should be a 
> well-defined interface for doing so (just like users and packages 
> can add new link types, for example).

I agree with this. I see no problem with having an analogue of
org-add-link-type for citations, and I think it's reasonable to have the
syntax allow for such extensions, so that e.g.

[cite/my-custom-cite-type: ...]

can still be recognized by the parser as a citation, which extensions
can then give a semantics to. But I think there needs to be a clear
syntactic delimitation between citations that are expected to work "out
of the box" (which to me primarily means: exported correctly in the
built-in backends) vs. those that need some additional extension to
export correctly or support additional behavior (which doesn't need to
be available on all backends, and could e.g. support BibLaTeX-only
users).  Otherwise the problem of getting citations working is too big a
project.

Best,
Richard

Re: wip-cite status question and feedback

[Richard Lawrence]

Hi all,

Nice to see this issue being discussed again!

I don't have a lot to add and at the moment I don't have a lot of time
to contribute, but I wanted to make one point about this issue:

Joost Kremers  writes:

> On Mon, Apr 13 2020, Nicolas Goaziou wrote:
>> denis.maier.li...@mailbox.org writes:
>>> What about allowing something more verbose? Perhaps
>>> "cite-intext:" or "cite:intext:"?
> [...]
>>> The simple syntax is great for most cases, but if you want to
>>> support some of those not so common biblatex commands, this might be
>>> better.
>>
>> Alphanumeric suffix provides 62 combinations, which should hopefully
>> be enough for any citation back-end out there (I'm looking at you
>> biblatex). It's not terribly readable, tho, as you point out.
>
> 62 combinations might sound like a lot, but if you want your cite
> commands to be mnemonic, you'll run out of options much more quickly.

This came up in the discussion in 2015, too. So maybe this can help
avoid repeating a long discussion about this:

I think it is worth pointing out to Bib(La)TeX users that it is useful
to avoid a proliferation of citation commands in Org syntax. The syntax
discussed so far achieves this by "factoring out" formatting information
that BibLaTeX puts into the command into other parts of the syntax and
into the choice of citation stylesheet. For example, instead of having
\footnotecite and \parencite as separate commands, you can just have a
single cite command, and the choice of stylesheet determines whether
citations get formatted as footnotes or as in-text parenthetical
citations or as something else.

This obviously has the drawback that if you only have single citation
command, you only get to make the choice about formatting once for the
whole document (via the stylesheet). So, I think the relevant question
is: how many different basic citation types are needed *within a single
document*, keeping in mind that these basic types will be formatted in
different ways, depending on the choice of stylesheet?

My experience is that it's typically just two (e.g. parenthetical and
author-in-text), and my memory of the earlier conversation was that most
people agreed. This is also borne out in the Pandoc syntax. As long as
we have two basic types of citations, the finer points of formatting
them can be achieved via other syntax, including the choice of
stylesheet.

-- 
Best,
Richard

Re: adding paragraph folding to visibility cycling?

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> One feature I have always found helpful when working on long documents
> is paragraph folding; where paragraphs are folded to display just the
> first line.

[...]

> I can get paragraph folding and unfolding in org using packages like
> origami (say with origami-toggle-all-nodes), but I was wondering if
> there's a way to easily add it to org visibility cycling?

How would that work? I.e., 
- what key,
- how does it integrate with folding cycling, if it does at all?

Regards,

-- 
Nicolas Goaziou

Re: Inconsistent use of \ref and \eqref in ox-latex and ox-html

[Nicolas Goaziou]

Hello,

Brian Powell  writes:

> The issue is that when exporting equation numbers with ox-html, it uses 
> MathJax's \eqref that wraps the equation in parentheses, for example:
>
> "Refer to (3) for more."
>
> However, when exporting the same document with ox-latex, it uses Latex's \ref 
> that does not wrap the equation in parentheses. Would it be possible to add 
> an option or variable to ox-html for the user to select whether to use \ref 
> or \eqref on export? 
>
> For those of us that publish to HTML and PDF, it is very difficult because 
> you end up with either double or no parentheses.
>
> My proposed fix would be a change to ox-html from:
>
>(format "\\eqref{%s}"
>(org-export-get-reference destination info))
>
> to
>
>(format (if org-html-export-mathjax-ref "\\ref{%s}" 
> "\\eqref{%s}")
>(org-export-get-reference destination info))
>
> The variable org-html-export-mathjax-ref is non-nil to use \ref vs.
> nil to be the default \eqref.

The variable could be more general, e.g.,
org-html-export-equation-reference-format, and default to "\\ref{%s}".
Note the export back-ends do not use variables directly. It would be

  (format (plist-get info :html-equation-reference-format)
  (org-export-get-reference destination info))

where the correspondence between :html-equation-reference-format is set
in back-end definition.

Also, it needs to be referenced in "HTML specific properties" section of
the manual.

Would you want to propose a patch ?

Regards,

-- 
Nicolas Goaziou

Fwd: Re: how to renumber footnotes?

[Joost Kremers]

Accidentally sent this message off-list. Trying again:

On Fri, Apr 17 2020, Sharon Kimble wrote:
org-footnote can't tell that footnote 1 ([fn:1]) at the 
beginning is in
the right place when confronted with footnote 1 ([fn:1]) 
half-way

through!


No, obviously, so you'll have to renumber the footnotes in the 
second file

before you merge the two files.


Which is why I'm looking for some other solution, and I believe
that it might be able to be achieved programmatically. 
Unfortunately my
lisp skills are almost nil, hence my request for someone to 
help.


I use the following function for renumbering stuff such as 
footnotes:


#+begin_src emacs-lisp
(defun jk-renumber-counters (start regexp)
"Renumber counters.
Renumbering starts at START.  REGEXP describes the counters to be
renumbered.  The actual number must be enclosed in a group."
(save-excursion
  (goto-char (point-min))
  ;; because we incf the counter before using it, we need to 
  adjust:

  (let ((counter (1- start))
(counters (make-hash-table :test 'equal))
fn)
(while (re-search-forward regexp nil t)
  (setq fn (match-string 1))
  (replace-match (or (gethash fn counters)
 (puthash fn (format "%s" (cl-incf
 counter)) counters))
 nil nil nil 1)
#+end_src

In your case, you should be able to call this function with:

  M-: (jk-renumber-footnotes 355 "\\[fn:\\([0-9]+\\)\\]") RET

Change «355» to the number you want to start the footnotes in the 
second file

with.

If you already merged the two files and don't want to separate 
them again, you
could take out the line `(goto-char (point-min))`, put point at 
the position
where you want to start renumbering footnotes and then call the 
function. But
I'd play it safe and renumber the footnotes before merging the 
files.


HTH


--
Joost Kremers
Life has its moments