Re: newline or no newline at end of capture: expected behavior

[Samuel Wales]

hi bastien,

another example is, whenever i capture a headline like "* test\n" and
finalize, it creates a blank line after the headline.

is it expected that users should remove the final newline in the
capture buffer, in a finalize hook, to prevent this?

it would heolp me figure out whether it is pebcak, expected, or a bug
if i know what is the expected result, and whether users are expected
to capture only capture buffers that do not have final newlines.  [bug
on empty buffer still exists.]

On 9/23/20, Samuel Wales  wrote:
> i have the same question for headline-only capture
> buffers.  i.e. what is the expected result with and without trailing
> newline.
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: org-table-sum

[Jeremie Juste]

Hello,

Thanks for the input.

>From what I understand, it seems that org-table-sum is not behaving as
expected. I don't know if it would be interesting to split the function
into 2. One for summing of time values and one for summing integers?

For the sum of integers (possibly real numbers) it might be interesting
to make a function use TBLFM directly? 

Best regards,
Jeremie






On Friday, 25 Sep 2020 at 10:59, Robert Pluim wrote:
>> On Thu, 24 Sep 2020 16:48:14 -0400, Kyle Meyer  said:
>
> >> I did not find a way to reproduce this with other numbers, but the
> >> order seems to matter.
>
> Kyle> See .
>
> Exactly. Which is why you should use 'calc' with floating point
> numbers, it handles them correctly. i.e.
>
> | 171.00 |
> |   4.07 |
> |   4.44 |
> |   2.61 |
> |  12.21 |
> |   6.69 |
> |  19.72 |
> |  23.09 |
> |   6.23 |
> |  15.28 |
> | 250.00 |
> | 250.00 |
> | 250.00 |
> |  78.85 |
> ||
> ||
> #+TBLFM:@>$1=vsum(@1$1..@-1$1)
>
> Put point in that empty cell and do 'C-u C-c C-c'
>
> Robert
>

-- 
Best regards
Jeremie Juste

Re: org-tables with monetary amounts

[Neil Jerram]

On Fri, 25 Sep 2020 at 12:36, Daniele Nicolodi  wrote:

> On 25/09/2020 11:25, Neil Jerram wrote:
> > Aside: Perhaps I'm misunderstanding them, but none of the open source
> > tools, including (h)ledger, seem to be of much help here.
> > - They focus on data entry and reconciliation, which I don't need as I'm
> > happy to download and use OFX files from my bank.
>
> I don't think the focus of ledger (or hledger, or beancount) is on data
> entry. Actually beancount even has an ingest framework to deal with
> importing data from bank statements and other sources.
>

Fair enough.  But I think what I really meant is that I would prefer tools
that can work directly on the data sources that I already have - i.e. OFX
files from my bank - without needing to convert those first into their own
file format.  To put it another way, if the file format per se is not an
important feature, what are the ways that the plain text accounting tools
add the most value?  The value I'm interested in is in (a) categorizing and
(b) reporting; but I haven't yet seen any of these tools having the kind of
intelligence, out of the box, that I'm looking for in those areas.


> > - They don't offer anything intelligent and automated for automatically
> > categorizing transactions.
>
> For beancount there is smart_importer
> https://github.com/beancount/smart_importer and it is not difficult to
> hack your own. I indeed use my own tool based on a simple machine
> learning algorithm implemented by scikit-learn (Python).
>

Thanks, but if I'm using a tool, I'd rather it had the intelligence
built-in (with appropriate configurability).  If I have to code...  well, I
have already done it myself.


>
> > - They don't have a sophisticated representation of a budget, and
> > reporting against that.
>
> I am not sure what you mean by "sophisticated representation of a
> budged". Once you categorize expenses in a (hierarchical) set of
> expenses accounts it is trivial to use something like beancount to check
> the balances against a budget.
>

I'm still thinking this through.  The simplest kind of budget would be a
number for each category, for the whole year.  But then you don't have a
very detailed evaluation if, say, you're looking at your actual expenditure
and it's only February.  Some bits of budget might only be expected on a
few specific dates; others are regular every month; others could be monthly
but varying in amount; others are allowances that could happen any time.
It seems to me that when you can predict particular expenses, it's better
if you can express those precisely and that an "expenditure against budget"
report can take those into account as well as the allowance pots.


>
> > Do you know of a good forum (other than this!) for discussing such
> points?
>
> The ledger-cli and the beancount mailing lists may be the right places
> to discuss the use of these tools.
>

Thank you.  I wish there was also a unified plaintextaccounting.org mailing
list, as I don't think my questions are for a specific tool.


>
> > I've attached mine, in case you read Scheme and there's more detail in
> > there that is of interest.
>
> My use case is very different, thus something external to org-mode is
> not really useful.
>
> Maybe an example would clarify what my use case is. I am working on a
> research proposal where I need to provide details about funding
> allocation in a few different categories over a certain amount of years.
> In my document this is an org-table. Right now I have two choices to
> edit the table:
>
> - have monetary amounts in the cells (example "123.00 EUR") and do the
> match externally,
>
> - do the math in the org-table, specify the right formatting for all
> computed cells, and still have to post-process it to add the currency
> symbols to the input cells.
>
> Either solution is sub-optimal. It would be nice if org-tables could
> support monetary fields as they support time fields.
>

Yes indeed.  The answer about Calc units sounded as though it could address
this - is there still a gap in applying it to your case?

Alternatively I believe an org-table formula can invoke arbitrary Lisp, so
in principle you could code a function to parse all the inputs (including
units), do the math needed, and then format the output with the desired
unit.

Best wishes,
Neil



>
> Cheers,
> Dan
>

Re: [PATCH] Fix `org-lint-link-to-local-file'

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> Subject: [PATCH] Fix `org-lint-link-to-local-file'.

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou

[PATCH] Fix `org-lint-link-to-local-file'

[Ihor Radchenko]

I have been trying to run org-lint on my files recently. Ended up fixing 
org-lint itself...

See the attached.

Best,
Ihor

>From feacb6fd2898b5788e6d70b3139cf83359b96ca6 Mon Sep 17 00:00:00 2001
From: Ihor Radchenko 
Date: Sat, 26 Sep 2020 14:24:44 +0800
Subject: [PATCH] Fix `org-lint-link-to-local-file'.

* lisp/org-lint.el (org-lint-link-to-local-file): 1. Fix call to
`org-attach-expand' being called with point not at the attachment:
link.  2. Fix typo in call to `format'.  File argument had to be
outside the if.
---
 lisp/org-lint.el | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/org-lint.el b/lisp/org-lint.el
index 79ad640e4..e4e0ef751 100644
--- a/lisp/org-lint.el
+++ b/lisp/org-lint.el
@@ -574,15 +574,16 @@ Use :header-args: instead"
 	   (let* ((path (org-element-property :path l))
 		  (file (if (string= type "file")
 			path
-			  (org-attach-expand path
+  (org-with-point-at (org-element-property :begin l)
+			(org-attach-expand path)
 	 (and (not (file-remote-p file))
 		  (not (file-exists-p file))
 		  (list (org-element-property :begin l)
 			(format (if (org-element-lineage l '(link))
 "Link to non-existent image file %S \
 in description"
-  "Link to non-existent local file %S"
-  file))
+  "Link to non-existent local file %S")
+file)
 	  (_ nil))
 
 (defun org-lint-non-existent-setupfile-parameter (ast)
-- 
2.26.2

Re: [PATCH] Adaptive Org faces in headings?

[Bastien]

Bastien  writes:

> Ihor Radchenko  writes:
>
>> The attached patch seems to fix the issue.
>
> Applied as 979e82fc3, thanks a lot!

Also, marking the initial bug report as closed, thanks again.

-- 
 Bastien