On Thursday, 1 Jul 2021 at 23:16, Nicolas Goaziou wrote:
> Applied. Thanks to both of you.
Thank you!
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-570-g7666d6
: Latest paper written in org: https://arxiv.org/abs/2106.05096
On Thursday, 1 Jul 2021 at 18:28, Uwe Brauer wrote:
> I currently have to collaborate with an excel file that contains quite a
> bit of complex formula.
Do you need bi-directional collaboration? If you do, I doubt there's a
solution out there. Collaboration with people using MS based tools is
>>> "ESF" == Eric S Fraga writes:
> On Thursday, 1 Jul 2021 at 18:28, Uwe Brauer wrote:
>> I currently have to collaborate with an excel file that contains quite a
>> bit of complex formula.
> Do you need bi-directional collaboration? If you do, I doubt there's a
> solution out there. Collab
Hi
I'd like to add a range values of two columns something like this
#+begin_src elisp
#+Name: check
| User1 | User2 | Result |
|---+---+|
| 1 | 3 | [4]|
| 4 | 8 | [4]|
| 9 | 3 | [4]|
|---+---+|
| 7 | 9 | [4]|
#+
On Friday, 2 Jul 2021 at 10:42, Uwe Brauer wrote:
> I'd like to add a range values of two columns something like this
I am not sure what you are trying to achieve. Would you please explain
in more detail? It kind of looks like you are trying to add columns 1
and 2 to get column 3? If so, you
>>> "ESF" == Eric S Fraga writes:
> On Friday, 2 Jul 2021 at 10:42, Uwe Brauer wrote:
>> I'd like to add a range values of two columns something like this
> I am not sure what you are trying to achieve. Would you please explain
> in more detail? It kind of looks like you are trying to add co
On Friday, 2 Jul 2021 at 11:23, Uwe Brauer wrote:
> No I only want to add the parts of column $1 and $2 that are between the
> two hlines
Okay; problem 1 is that org formulas are not really vector based: a
range on the left hand side says that each element in the range will be
assigned the outcom
>>> "ESF" == Eric S Fraga writes:
> On Friday, 2 Jul 2021 at 11:23, Uwe Brauer wrote:
>> No I only want to add the parts of column $1 and $2 that are between the
>> two hlines
> Okay; problem 1 is that org formulas are not really vector based: a
> range on the left hand side says that each elem
On Friday, 2 Jul 2021 at 12:04, Uwe Brauer wrote:
> I will have a look thanks (I already thought about commenting out
> unwanted rows, but that looked ugly).
The nice thing about the advanced features is they give you full control
and none of the extra notation is exported.
--
: Eric S Fraga vi
On 02/07/2021 01:38, Eli Zaretskii wrote:
From: Maxim Nikulin Date: Fri, 2 Jul 2021 00:01:59 +0700
--- a/lisp/net/mailcap.el
+++ b/lisp/net/mailcap.el
-(start-process-shell-command command nil command)))
...
+(make-process
+ :name "mailcap-view-file" :connection-type 'pipe :noquery
> From: Maxim Nikulin
> Date: Fri, 2 Jul 2021 19:21:55 +0700
> Cc: Lars Ingebrigtsen
>
> > And with other handlers, this could be an
> > incompatible behavior change if the handler behaves differently when
> > its standard handles are connected to a pipe rather than a terminal
> > device.
>
> E
>>> "ESF" == Eric S Fraga writes:
> On Friday, 2 Jul 2021 at 12:04, Uwe Brauer wrote:
>> I will have a look thanks (I already thought about commenting out
>> unwanted rows, but that looked ugly).
> The nice thing about the advanced features is they give you full control
> and none of the extra
William Xu writes:
> I need to make below additional change, otherwise it works perfectly.
Incorporated in the attached final version of the patch.
> Looking at the changes, I see you changed below `concat' call to
> `format'. Is this in the end some bug in the `concat' implementation?
It is
Timothy writes:
> Hi Ihor,
>
> This thread is looking promising! Just wondering if you might have time
> to respond to William's latest reply?
Sure. Just descended from work staff down to the Emacs area in my TODO
list ;)
Timothy writes:
> Marking as a patch for Woof.
Was is not marked? My patch message should have X-Woof-Patch header.
On Friday, 2 Jul 2021 at 16:07, Uwe Brauer wrote:
> The problem is the target @<<$3..@>>$3
>
> There seems no option to specify such a range.
Sorry, I didn't explain myself properly. You can specify which rows
should be calculated automatically so that you can then use a simple
column formula wi
Anders, I just want to say that I tested this out and it works great. It's
quite shocking, actually, to have such an easy path from org to odt with
live citations. I'd love to see this stuff in MELPA or otherwise made more
generally accessible, as i think it fills a substantial need.
On Tue, Jun
Hello,
I just added an interface to unify functions responsible for inserting
citations in a buffer. The default binding is .
I also plugged a rather crude function with that interface. In order to
use it, you can evaluate:
(setq org-cite-insert-processor 'basic)
Internally, this will bind t
On 02/07/2021 19:37, Eli Zaretskii wrote:
From: Maxim Nikulin
Date: Fri, 2 Jul 2021 19:21:55 +0700
Cc: Lars Ingebrigtsen
And with other handlers, this could be an
incompatible behavior change if the handler behaves differently when
its standard handles are connected to a pipe rather than a term
> From: Maxim Nikulin
> Date: Fri, 2 Jul 2021 23:24:23 +0700
>
> On 02/07/2021 19:37, Eli Zaretskii wrote:
> >> From: Maxim Nikulin
> >> Date: Fri, 2 Jul 2021 19:21:55 +0700
> >> Cc: Lars Ingebrigtsen
> >>
> >>> And with other handlers, this could be an
> >>> incompatible behavior change if the h
Hi,
(cc:ing Jens L. in case this is relevant for his dev work on org-re-reveal).
I'm experimenting with the new citation syntax in slideshows generated with
org-re-reveal. Mostly it works fine, but cite-links don't function
properly in the slideshow because in reveal, internal links only work wh
>>> "ESF" == Eric S Fraga writes:
> On Friday, 2 Jul 2021 at 16:07, Uwe Brauer wrote:
>> The problem is the target @<<$3..@>>$3
>>
>> There seems no option to specify such a range.
> Sorry, I didn't explain myself properly. You can specify which rows
> should be calculated automatically so th
Looking good Nicolas.
Just one small thing.
If I run on a citation, I get a list of styles, including "nil".
If I select that, "nil" is added to the citation, so that the result
is "[cite/nil:@key]".
On Fri, Jul 2, 2021 at 12:11 PM Nicolas Goaziou wrote:
>
> Hello,
>
> I just added an interfa
Also:
1. I don't see a way to add a key to an existing citation. Editing an
existing key uses completing-read, rather than
completing-read-multiple (as for a new citation), and places point
after the existing key means the style editing UI will pop up.
2. If I use CRM to add multiple keys, for rea
I’ve been experimenting with using a single org file to generate an article
when exported to LaTeX (or HTML) and a Beamer presentation when exported to
Beamer, without requiring any edits to the org file itself.
For this to be really useful, the exporter has to be able to do different
things d
Hello,
"Bruce D'Arcus" writes:
> Looking good Nicolas.
>
> Just one small thing.
>
> If I run on a citation, I get a list of styles, including "nil".
>
> If I select that, "nil" is added to the citation, so that the result
> is "[cite/nil:@key]".
That's expected. "nil" is the name of the proces
"Bruce D'Arcus" writes:
> 1. I don't see a way to add a key to an existing citation. Editing an
> existing key uses completing-read, rather than
> completing-read-multiple (as for a new citation), and places point
> after the existing key means the style editing UI will pop up.
Indeed, there's n
On Fri, Jul 2, 2021, 4:14 PM Nicolas Goaziou wrote:
> "Bruce D'Arcus" writes:
>
> > 1. I don't see a way to add a key to an existing citation. Editing an
> > existing key uses completing-read, rather than
> > completing-read-multiple (as for a new citation), and places point
> > after the existi
I would not use a prefix arg here. you should just check what is at the
point, and if it is a citation then append it after the citation at point,
and if not insert a new one (maybe after moving the point to an appropriate
place if needed).
John
---
Professor Jo
Hello,
John Kitchin writes:
> I would not use a prefix arg here. you should just check what is at the
> point, and if it is a citation then append it after the citation at point,
> and if not insert a new one (maybe after moving the point to an appropriate
> place if needed).
Well, currently, i
"Bruce D'Arcus" writes:
> BTW, you may already be thinking this, but you may as well add completion
> from the files registered with OC at this point. :-)
>
> Only having the completion table populated with in-document keys won't be
> very useful, particularly in a new document.
The completion t
On Fri, Jul 2, 2021, 5:48 PM Nicolas Goaziou wrote:
> "Bruce D'Arcus" writes:
>
> > BTW, you may already be thinking this, but you may as well add completion
> > from the files registered with OC at this point. :-)
> >
> > Only having the completion table populated with in-document keys won't be
> Anders, I just want to say that I tested this out and it works great. It's
> quite shocking, actually, to have such an easy path from org to odt with live
> citations. I'd love to see this stuff in MELPA or otherwise made more
> generally accessible, as i think it fills a substantial need.
H
"Bruce D'Arcus" writes:
> On Fri, Jul 2, 2021, 5:48 PM Nicolas Goaziou wrote:
> Rather than just completing the key, how about something like:
>
> ("title author date" . "key")
>
> E.g. look up against the data, and return the key.
Well, I guess it's possible to do. Patches welcome!
>
> It's h
On Fri, Jul 2, 2021 at 6:33 PM Nicolas Goaziou wrote:
> The completion table, if required, and the completion mechanism belong
> to the insert function. So, you can plug anything you want.
You're right.
It is likely less work, with better results, for me to adapt what you
do with the basic inse
On Fri, Jul 2, 2021 at 5:21 PM Nicolas Goaziou wrote:
>
> Hello,
>
> John Kitchin writes:
>
> > I would not use a prefix arg here. you should just check what is at the
> > point, and if it is a citation then append it after the citation at point,
> > and if not insert a new one (maybe after movin
Hi Jeremie,
>> The requirement for a second file parameter was added in Org 9.3 to
>> support the use case in this thread:
>>
>> https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/
>>
>> But this syntax is annoyingly verbose for ob-R users, and also broke
>> lots of ob-R exa
Jack Kamm writes:
> I think it would still make sense though, and would be beneficial beyond
> ob-R. According to [1], the "graphics" and "link" arguments don't do
> anything unless used with "file", so it would make sense for them to
> automatically add the "file" argument.
Mmmm, I think it w
38 matches
Mail list logo
