Re: [BUG] (org-babel-result-to-file) adds the relative path even if attachment link is generated [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Johan Tolö

Johan Tolö  writes:
[snipped]

* Test
:PROPERTIES:
:DIR:  build
:END:

#+begin_src R :results output file graphics :file build/test.png
  plot(1)
#+end_src

#+RESULTS:
[[attachment:build/test.png]]

The expected result is:

#+RESULTS:
[[attachment:test.png]]

My ob-core.el has in the org-babel-result-to-file function (on 
line 2712):


(file-relative-name result-file-name)

I changed it to:

(file-relative-name result-file-name attach-dir)

and got the expected result.

[snipped]

Adding a elisp example that produces the same unwanted behaviour:

* Test
:PROPERTIES:
:DIR:  build
:END:

#+begin_src emacs-lisp :results value file
 "build/test.png"
#+end_src

#+RESULTS:
[[attachment:build/test.png]]



--
Johan Tolö



Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

2022-12-05 Thread David Masterson
 writes:

> On Mon, Dec 05, 2022 at 07:54:25PM -0800, David Masterson wrote:
>
>> Question: which end of load-path is "front" if you look at load-path via
>> describe-variable?  It's been far too long since my days of Elisp
>> hacking.
>
> This goes "left to right" when looking at it on a conventional
> display. The first hit "wins".

So I did have it backwards.  Hmm.

> [...]
> meaning that Emacs first looks in my personal directories, then
> in the system local ones (I have a "locally" installed Emacs
> from the distribution's POV).
>
> The distribution's directories would go even later, were there
> any.

But this is a matter of when things are added to load-path.  If
something from the distribution is loaded before you setup your
load-path (before ,emacs), it gets very difficult to override it locally
(somewhat by design).  The load can also happen by dependency loads
before you get to setting up your local (Org) package.

I'll have to test when the distribution org is getting loaded.

Thanks

-- 
David Masterson



Re: Multiple versions of Org in load-path problem

2022-12-05 Thread David Masterson
 writes:

> On Mon, Dec 05, 2022 at 06:50:33PM -0800, David Masterson wrote:
>> I'm using Debian v11.5 on my Chromebook.  I have used 'apt install' to
>> load the pre-built version of Emacs 27.1.  I've just found out that it
>> installs a pre-built version of Org-9.3 in /usr/share/emacs/27.1/lisp.
>> That directory is early in the load-path, so it appears to be loaded out
>> of startup.el(?).  Everything seems to be working fine in my setup of
>> Emacs and Org.
>
> Hm. I run a self-compiled Emacs, so I can't check at the moment;
> take this with a grain of salt.
>
> That said for a distro putting the distro-provided places earlier
> in the load-path than the local- or user-provided ones seems wrong;
> admins/users have no chance to override them, no?

Hmm.  You could be correct.  Which means it's the order of loading in my
.emacs file.  I'll have to test this to see when Org is first loaded.

-- 
David Masterson



Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Greg Minshall
Chuck,

sorry, i didn't see the change you had added.

> So, isn't that what is wanted?

that's a policy question that i can't answer.  :)

cheers, Greg



Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

2022-12-05 Thread tomas
On Mon, Dec 05, 2022 at 07:54:25PM -0800, David Masterson wrote:

[...]

> Question: which end of load-path is "front" if you look at load-path via
> describe-variable?  It's been far too long since my days of Elisp
> hacking.

This goes "left to right" when looking at it on a conventional
display. The first hit "wins". My load path looks like this
(well, a part of it, I don't want to bore everyone ;-)

   ( "~/.emacs.d/lisp"
 "/home/tomas/.emacs.d/elpa/geiser-0.10/"
 "/home/tomas/.emacs.d/elpa/geiser-0.10"
 "/home/tomas/.emacs.d/elpa/markdown-mode-2.1" 
 ...
 "/usr/local/share/emacs/29.0.50/lisp/emacs-lisp"
 "/usr/local/share/emacs/29.0.50/lisp/cedet"
 ... )

meaning that Emacs first looks in my personal directories, then
in the system local ones (I have a "locally" installed Emacs
from the distribution's POV).

The distribution's directories would go even later, were there
any.

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: Multiple versions of Org in load-path problem

2022-12-05 Thread tomas
On Mon, Dec 05, 2022 at 06:50:33PM -0800, David Masterson wrote:
> I'm using Debian v11.5 on my Chromebook.  I have used 'apt install' to
> load the pre-built version of Emacs 27.1.  I've just found out that it
> installs a pre-built version of Org-9.3 in /usr/share/emacs/27.1/lisp.
> That directory is early in the load-path, so it appears to be loaded out
> of startup.el(?).  Everything seems to be working fine in my setup of
> Emacs and Org.

Hm. I run a self-compiled Emacs, so I can't check at the moment;
take this with a grain of salt.

That said for a distro putting the distro-provided places earlier
in the load-path than the local- or user-provided ones seems wrong;
admins/users have no chance to override them, no?

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Berry, Charles
Hi Greg,


> On Dec 5, 2022, at 4:41 PM, Greg Minshall  wrote:
> 
> hi, Charles,
> 
>> This makes a list like '("a" "b" "c") into a data.frame with one column.
> 
> 1. which version of Org are you running?
> : Org mode version 9.6 (9.6-g60de19 @ 
> /home/minshall/.emacs.d/straight/build/org/):
> 

Org mode version 9.6 (release_9.6-14-g53814a (dated 2022-12-02)

> 2. is my below example yours?


Not with the change I indicated (which includes your changes of sequencep to 
listp)

I have


#+begin_src R :var list='("a" "b" "c")
 list
#+end_src

#+RESULTS:
| a |
| b |
| c |



> 
> i think i used to see the behavior you describe in 9.5.
> 

So, isn't that what is wanted?


HTH,

Chuck


> cheers, Greg
> 
> 
> 
> #+begin_src R :var list='("a" "b" "c")
>  list
> #+end_src
> 
> #+RESULTS:
> | a | b | c |





Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

2022-12-05 Thread David Masterson
Kyle Meyer  writes:

> Bastien writes:
>
>> Kyle Meyer  writes:
> [...]
>
>>> Every spot that calls org-assert-version is preceded by a line that
>>> requires org-macs, so isn't this error likely due to a mixed
>>> installation/load-path issue where the wrong/older org-macs is taking
>>> precedence?
>>
>> Yes: I thought `org-assert-version' job was to help catching mixed
>> installations, so my reasoning was that, even when an old org-macs
>> version has been loaded, autoloading `org-assert-version' would help
>> report about mixed installation.
>
> I see.  So your goal isn't to resolve any errors due to mixed
> installation but instead to get the more informative error message from
> org-assert-version?
>
> I don't think autoloading will help because it will look in the
> org-macs file at the front of the load-path, and, in the bad case, that
> does not have the org-assert-version definition.

Question: which end of load-path is "front" if you look at load-path via
describe-variable?  It's been far too long since my days of Elisp
hacking.

Another typical use case is Org bundled with Emacs and you want to
install a later version of Org via package-install.

>> That said, do you have any idea how to fix the bug people encounter
>> when installing Org from ELPA and being bitten by "invalid-function
>> org-assert-version"?
>
> Sorry, I don't.  Given a mixed installation where the org-macs at the
> front of load-path does _not_ have org-assert-version, I don't see a way
> to catch that.  Not helpful at the moment, but I suppose the situation
> improves with time as Org versions that do not have org-assert-version
> become less abundant.

Is Org the only thing that will call 'org-assert-version'? Then assume
that a pre-built version of Emacs/Org is self-consistent.  Then
(perhaps?) patch an early spot in Org-9.6 to do:

  (if (and (featurep 'org) (< org-version 9.6))
  (unload-feature 'org))

-- 
David Masterson



Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

2022-12-05 Thread David Masterson
Kyle Meyer  writes:

> Bastien writes:
>
>> Some users reported an (invalid-function org-assert-version) error
>> when installing Org from ELPA:
>>
>> https://lists.sr.ht/~bzg/emacsfr/%3Cd091463e1615422eb00070727d6a094ec0ae3c73.camel%40adocentyn.io%3E
>> https://www.reddit.com/r/emacs/comments/z7qulo/comment/iyd9vam/?context=3
>>
>> This patch autoloads `org-assert-version'.
>
> I don't understand the rationale behind this.  Every spot that calls
> org-assert-version is preceded by a line that requires org-macs, so
> isn't this error likely due to a mixed installation/load-path issue
> where the wrong/older org-macs is taking precedence?

Bingo!  This sounds like my problem -- installing/loading org-9.6 when
org-9.3 was already loaded by the startup process (Debian pre-built
Emacs 27.1) results in errors related to 'org=assert-version'.

>> It also removes the ;; generated-autoload-file: "org-loaddefs.el"
>> footer in all files and let Make create org-autoloads.el instead.
>
> I'm worried with how this will play with the Org bundled with Emacs.

It doesn't play in my case.

-- 
David Masterson



Multiple versions of Org in load-path problem

2022-12-05 Thread David Masterson
I'm using Debian v11.5 on my Chromebook.  I have used 'apt install' to
load the pre-built version of Emacs 27.1.  I've just found out that it
installs a pre-built version of Org-9.3 in /usr/share/emacs/27.1/lisp.
That directory is early in the load-path, so it appears to be loaded out
of startup.el(?).  Everything seems to be working fine in my setup of
Emacs and Org.

I'd like to upgrade to org-9.6 from ELPA via the package-install in
Emacs which installs it into ~/.emacs.d/elpa.  I have a lot of
use-package calls in my ,emacs to load everything, but it runs into
problems with the mixed Org environment -- 9.3 is loaded at startup and
9.6 is "sort of" loaded by use-package.  The errors I get are from some
calls to use-package to load packages and are 'org-assert-version'
errors (a few of the packages [AFAIK] have no relationship to Org [like
hypernole]).

Is there a proper way to do this?  Do I really have to delete the
built-in 9.3 version (by hand or package-delete?) or will that mess up
something else?  I saw mention of 'unload-feature' which is new to me --
would that be safe to use?

-- 
David Masterson



Flyspell causes severe slowdown when manipulating footnotes

2022-12-05 Thread arozbiz
I just upgraded to Org 9.6 and I've noticed that having flyspell-mode
turned on causes very large slowdowns when adding or deleting footnotes in
an org file with lots of footnotes (e.g., more than 200, which is common
for the academic articles that I use org for). Any ideas for what might be
causing this?

Alan


Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Greg Minshall
hi, Charles,

> This makes a list like '("a" "b" "c") into a data.frame with one column.

1. which version of Org are you running?
: Org mode version 9.6 (9.6-g60de19 @ 
/home/minshall/.emacs.d/straight/build/org/):

2. is my below example yours?

i think i used to see the behavior you describe in 9.5.

cheers, Greg



#+begin_src R :var list='("a" "b" "c")
  list
#+end_src

#+RESULTS:
| a | b | c |



Re: [BUG] Org-mode 9.6 parallel build issue [9.6 (N/A @ /usr/share/emacs/site-lisp/org-mode/)]

2022-12-05 Thread Maciej Barć

Hi Ihor!


Cannot reproduce.


I think this is more likely to happen to users who actually compile on 
boxes with very high CPU/thread count.

A common user with ~8 threads probably will not hit this issue
(I also could not reproduce this on my 4c/8t daily-driver).
Regardless if a common users is likely to hit those errors, they could 
indicate that there are some bugs in the Makefiles.



Could you please provide a more clear recipe to reproduce, if possible?


There are logs in the bug report on the Gentoo Bugzilla,
from the bug I had already mentioned:
https://884243.bugs.gentoo.org/attachment.cgi?id=839581
and from the one occurring with the documentation generation process:
https://884403.bugs.gentoo.org/attachment.cgi?id=840181


what exactly emake does differently


Not much, it is just a wrapper for make that adds the MAKEOPTS variable 
from the Portage configuration.

You can see the exact make command in the logs, that is:
- for bug 884243: make -j62 ORGVERSION=9.6 
datadir=/usr/share/emacs/etc/org-mode

- and for 884403: make -j63 pdf card

Thanks for taking a look at it!

On 12/5/22 14:34, Ihor Radchenko wrote:

Maciej Barć  writes:


Hello!

The 9.6 release fails to build with multiple jobs (-j62).
This issue was found automatically by the Gentoo Tinderbox CI.
Link to the Gentoo bug report: https://bugs.gentoo.org/884243


Thanks for reporting!

I tried

cd /tmp
git clone --depth=1 git://git.savannah.gnu.org/emacs/org-mode.git
cd org-mode
make -j64

Cannot reproduce.

The error discussed might happen when make clean is not properly
executed.

Could you please provide a more clear recipe to reproduce, if possible?
I do not remember what exactly emake does differently compared to the above.



--
Have a great day!

~ Maciej XGQT Barć


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Berry, Charles



> On Dec 4, 2022, at 6:43 PM, Greg Minshall  wrote:
> 
> i see this same behavior.  to me, (org-babel-R-assign-elisp) seems to be
> the problem, but it hasn't changed any time recently.  (nor, if my =git
> blame= is done correctly, has anything else in ob-R.el.)
> 
> i don't understand how (org-babel-R-assign-elisp) thinks.  it seems to
> assign =max= and =min= assuming that =value= is a list of (at least one)
> list(s).
> 
> this *might* be a fix.  but, i don't have a lot of confidence it will
> not have bad side effects for other cases.  (though i tested it with a
> simple list, and a simple table with more than one row, and a list of
> two lists, the first of length 3, the second of length 2.):
> 
> modified   lisp/ob-R.el
> @@ -241,7 +241,7 @@ This function is called by `org-babel-execute-src-block'."
> (defun org-babel-R-assign-elisp (name value colnames-p rownames-p)
>   "Construct R code assigning the elisp VALUE to a variable named NAME."
>   (if (listp value)
> -  (let* ((lengths (mapcar 'length (cl-remove-if-not 'sequencep value)))
> +  (let* ((lengths (mapcar 'length (cl-remove-if-not 'listp value)))
>(max (if lengths (apply 'max lengths) 0))
>(min (if lengths (apply 'min lengths) 0)))
> ;; Ensure VALUE has an orgtbl structure (depth of at least 2).

- (unless (listp (car value)) (setq value (list value)))
+ (unless (listp (car value)) (setq value (mapcar 'list value)))


> 

This makes a list like '("a" "b" "c") into a data.frame with one column.

HTH,
Chuck






Re: How to disable completely org-persist

2022-12-05 Thread Colin Baxter
> Angelo Graziosi  writes:

> Colin Baxter wrote:
>> I too would like a means to disable org-persist.

> On emacs-devel there was this suggestion:

> https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00125.html

It appears to work, after removing a couple of surplus brackets from the
end of the last line.

Best wishes,



Re: Displaying macros differently

2022-12-05 Thread Vikas Rawal
This is perfect, thank you!

On Mon, 5 Dec 2022 at 09:13, William Denton  wrote:

> On 4 December 2022, Vikas Rawal wrote:
>
> > I frequently use orgmode macros -- like {{{M(Year 1998--99)}}} -- in
> tables
> > designed for latex export. I find that the macro syntax occupies many
> > character spaces. At the very least, 9 spaces are taken up even if my
> macro
> > shortcut is just one character long. This is very difficult with wide
> > tables as often the tables go off the screen just because of this.
> >
> > I was wondering if there is a simple way of making org display the macros
> > differently. That is, use some kind of overlay, and display the above
> macro
> > may be like M:Year 1998--99. Or some special character could be used to
> > denote that there is a macro underlying what is visible here.
>
> Is this close enough?
>
> (setq org-hide-macro-markers t)
>
> That hides the {{{macro}}} curly brackets (if there's no leading space).
>
> I also have this to toggle macro visibility in the document so I can see
> them
> when I want to:
>
> #+begin_src emacs-lisp
> (defun wtd/toggle-org-macro-markers ()
>"Toggle visibility of {{{macro}}} markers"
>(interactive)
>(setq org-hide-macro-markers (not org-hide-macro-markers))
>(font-lock-mode)
>(font-lock-mode))
> #+end_src
>
> I think there's been some discussion about evaluating the macros and
> showing the
> result, but I don't think that's possible.
>
> Bill
>
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada
>


Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Esteban Ordóñez
El 2022-12-05 10:25, Christian Moe escribió:
> Esteban Ordóñez writes:
> 
 Hope it clarifies things.
>>
>> It does.  Thank you very much, Christian.
> 
> Just to note: The helpful clarification was Ihor's.

It was helpful.  I am sorry. I quoted tho wrong person.

> I added a note about strings like this being tricky to localize and
> keeping that in mind when doing them in English.

Yours was a more complete explanation, which was very useful.  That is
what I meant.



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Esteban Ordóñez
El 2022-12-05 08:44, Ihor Radchenko escribió:
> So, do not worry about taking too much time for anything. The most
> important thing is contributing. We do not expect speed.

Thank you very much for your patience and mentorship.  And everyone
elese's.



Re: How to disable completely org-persist

2022-12-05 Thread Angelo Graziosi
Colin Baxter wrote:
>  I too would like a means to disable org-persist. 

On emacs-devel there was this suggestion:

https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00125.html



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Christian Moe


Esteban Ordóñez writes:

>>> Hope it clarifies things.
>
> It does.  Thank you very much, Christian.

Just to note: The helpful clarification was Ihor's.

I added a note about strings like this being tricky to localize and
keeping that in mind when doing them in English.

Yours,
Christian



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Esteban Ordóñez
El 2022-12-05 08:50, Christian Moe escribió:
> Ihor Radchenko writes:
> 
>> Esteban Ordóñez  writes:
>>
>>> El 2022-12-04 06:17, Ihor Radchenko escribió:
>>>
 #+BEGIN: clocktable :scope file :maxlevel 2
 #+CAPTION: Clock summary at [2022-12-04 Sun 14:16]
 |   Headline   |   Time|
 |--+---|
 | *Total time* | *0h 0min* |
 #+END:
>>>
>>> It is still not clear what "Clock summary at" refers to.  Perhaps
>>> someone fairly proficient in the English language could use it in a
>>> sentence.  That sentence needs to specifically convey the sense of what
>>> "Clock summary at" means in org-mode.  Then I could translate it to
>>> Spanish correctly.  Nevertheless, the translation is probably fair
>>> enough.
>>
>> In other words, the caption is trying to say that the table below lists
>> summary of clocked time as of [...] date; how much time is spent doing
>> various tasks before [...] date.
>>
>> Hope it clarifies things.

It does.  Thank you very much, Christian.

So "Clock summary at" is more like "Clock summary up to"?

That would translate to "Resumen de tiempos hasta" in Spanish.  But is
seems like a long text, even if it is gramatically correct.



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Christian Moe


Ihor Radchenko writes:

> Esteban Ordóñez  writes:
>
>> El 2022-12-04 06:17, Ihor Radchenko escribió:
>>
>>> #+BEGIN: clocktable :scope file :maxlevel 2
>>> #+CAPTION: Clock summary at [2022-12-04 Sun 14:16]
>>> |   Headline   |   Time|
>>> |--+---|
>>> | *Total time* | *0h 0min* |
>>> #+END:
>>
>> It is still not clear what "Clock summary at" refers to.  Perhaps
>> someone fairly proficient in the English language could use it in a
>> sentence.  That sentence needs to specifically convey the sense of what
>> "Clock summary at" means in org-mode.  Then I could translate it to
>> Spanish correctly.  Nevertheless, the translation is probably fair
>> enough.
>
> In other words, the caption is trying to say that the table below lists
> summary of clocked time as of [...] date; how much time is spent doing
> various tasks before [...] date.
>
> Hope it clarifies things.

And the timestamp includes hours/minutes, therefore the preposition "at"
is used ("at sixteen minutes past two") rather than "on" ("on the fourth
of December").

I mention this because it's the kind of formulation that can trip people
up during localization, especially if they don't know how "[date]" is
going to be formatted. Going forward, it's worth thinking about making
strings easy to localize. There was just a presentation about this at
Emacsconf the other day (https://emacsconf.org/2022/talks/localizing/).

In the case of "Clock summary at [date time]", the string "Clock
summary, [date time]" would be just as clear and leave less scope for
error, and one could even drop the comma. This might in any case be the
best solution for translations if people are confused what to do with
"at" in their language. (In some, it would simply be the right
translation -- e.g. for Norwegian, for which I'll send a patch shortly).

Yours,
Christian



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Ihor Radchenko
Esteban Ordóñez  writes:

> I am sorry to take so much time to contribute.  I guess that I feel very
> unsure.  Next time, I will do it in a more timely manner, considering
> that the "time question" has been overcome!  ;-)

Emm. I am not sure what you are referring to.
Some bugs remain open for years before they are closed. And our expected
timing for responses is ~1 month.

So, do not worry about taking too much time for anything. The most
important thing is contributing. We do not expect speed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Esteban Ordóñez
I am sorry to take so much time to contribute.  I guess that I feel very
unsure.  Next time, I will do it in a more timely manner, considering
that the "time question" has been overcome!  ;-)



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Esteban Ordóñez
El 2022-12-05 08:15, Ihor Radchenko escribió:
"the table below lists summary of clocked time as of [...] date; how
much time is spent doing
various tasks before [...] date."
> Hope it clarifies things.

It does!

'(("en" "File" "L"  "Timestamp"  "Headline" "Time"  "ALL"   "Total
time"   "File time" "Clock summary at")
("es" "Archivo"  "N"  "Fecha y hora" "Tarea" "Tiempo" "TODO" "Tiempo
total" "Tiempo de archivo" "Resumen de tiempos en")

or, if you want an abbreviated synthax (but not gramatically correct):
'(("en" "File" "L"  "Timestamp"  "Headline" "Time"  "ALL"   "Total
time"   "File time" "Clock summary at")
("es" "Archivo"  "N"  "Hora" "Tarea" "Tiempo" "TODO" "Tiempo total"
"Tiempo archivo" "Resumen tiempos en")



Re: [BUG] Org-mode 9.6 parallel build issue [9.6 (N/A @ /usr/share/emacs/site-lisp/org-mode/)]

2022-12-05 Thread Ihor Radchenko
Maciej Barć  writes:

> Hello!
>
> The 9.6 release fails to build with multiple jobs (-j62).
> This issue was found automatically by the Gentoo Tinderbox CI.
> Link to the Gentoo bug report: https://bugs.gentoo.org/884243

Thanks for reporting!

I tried

cd /tmp
git clone --depth=1 git://git.savannah.gnu.org/emacs/org-mode.git
cd org-mode
make -j64

Cannot reproduce.

The error discussed might happen when make clean is not properly
executed.

Could you please provide a more clear recipe to reproduce, if possible?
I do not remember what exactly emake does differently compared to the above.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



[BUG] Org-mode 9.6 parallel build issue [9.6 (N/A @ /usr/share/emacs/site-lisp/org-mode/)]

2022-12-05 Thread Maciej Barć

Hello!

The 9.6 release fails to build with multiple jobs (-j62).
This issue was found automatically by the Gentoo Tinderbox CI.
Link to the Gentoo bug report: https://bugs.gentoo.org/884243

--
Have a great day!

~ Maciej XGQT Barć


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Ihor Radchenko
Esteban Ordóñez  writes:

> El 2022-12-04 06:17, Ihor Radchenko escribió:
>
>> #+BEGIN: clocktable :scope file :maxlevel 2
>> #+CAPTION: Clock summary at [2022-12-04 Sun 14:16]
>> |   Headline   |   Time|
>> |--+---|
>> | *Total time* | *0h 0min* |
>> #+END:
>
> It is still not clear what "Clock summary at" refers to.  Perhaps
> someone fairly proficient in the English language could use it in a
> sentence.  That sentence needs to specifically convey the sense of what
> "Clock summary at" means in org-mode.  Then I could translate it to
> Spanish correctly.  Nevertheless, the translation is probably fair
> enough.

In other words, the caption is trying to say that the table below lists
summary of clocked time as of [...] date; how much time is spent doing
various tasks before [...] date.

Hope it clarifies things.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

2022-12-05 Thread Esteban Ordóñez
El 2022-12-04 06:17, Ihor Radchenko escribió:

> #+BEGIN: clocktable :scope file :maxlevel 2
> #+CAPTION: Clock summary at [2022-12-04 Sun 14:16]
> |   Headline   |   Time|
> |--+---|
> | *Total time* | *0h 0min* |
> #+END:

It is still not clear what "Clock summary at" refers to.  Perhaps
someone fairly proficient in the English language could use it in a
sentence.  That sentence needs to specifically convey the sense of what
"Clock summary at" means in org-mode.  Then I could translate it to
Spanish correctly.  Nevertheless, the translation is probably fair
enough.



Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Jérémie Juste
Hello Johan,

Many thanks for reporting the issue.
I'll investigate further and submit a patch next weekend at the latest.

Best regards,
Jeremie

On Mon, Dec 5, 2022 at 11:42 AM Johan Tolö  wrote:

> Greg Minshall  writes:
>
> > i see this same behavior.  to me, (org-babel-R-assign-elisp)
> > seems to be
> > the problem, but it hasn't changed any time recently.  (nor, if
> > my =git
> > blame= is done correctly, has anything else in ob-R.el.)
> [snipped]
>
> Yeah, the problem is not a change to ob-R.el but the recent change
> to ob-core.el (see the message of the commit I referenced). But
> the change to ob-core.el is final if I understand it correctly
> which means that ob-R.el has to be updated. Sorry if I was unclear
> in my description.
>
> Named plain lists were previously turned into data.frames with
> each first level item in one row. Second level items were in the
> second column I believe. After the change to ob-core.el they are
> still data.frames but first level items form columns instead of
> rows. Second (or deeper) level items are dropped as they should be
> after the change to ob-core.el (according to the commit message).
>
> --
> Johan Tolö
>
>

-- 
Jérémie Juste


Re: Fix the confusing "result silenced" message

2022-12-05 Thread Ihor Radchenko
Rudolf Adamkovič  writes:

> Rudolf Adamkovič  writes:
>
>> Agreed.  Please, see the updated patch.
>
> Oops, I dropped an important word in the commit message.
>
> Please see the third version of patch below.

Thanks!
Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=78d283e27

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [PATCH] Explain how to end a buffer narrowing.

2022-12-05 Thread Ihor Radchenko
yuvallangerontheroad  writes:

> Please review.

Thanks!
Applied onto main with a small amendment to the commit message.
I added ":" after the changelog description term.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c4de06ce1

You are now also listed as Org contributor.
https://git.sr.ht/~bzg/worg/commit/2ea3051b

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Johan Tolö

Greg Minshall  writes:

i see this same behavior.  to me, (org-babel-R-assign-elisp) 
seems to be
the problem, but it hasn't changed any time recently.  (nor, if 
my =git

blame= is done correctly, has anything else in ob-R.el.)

[snipped]

Yeah, the problem is not a change to ob-R.el but the recent change 
to ob-core.el (see the message of the commit I referenced). But 
the change to ob-core.el is final if I understand it correctly 
which means that ob-R.el has to be updated. Sorry if I was unclear 
in my description.


Named plain lists were previously turned into data.frames with 
each first level item in one row. Second level items were in the 
second column I believe. After the change to ob-core.el they are 
still data.frames but first level items form columns instead of 
rows. Second (or deeper) level items are dropped as they should be 
after the change to ob-core.el (according to the commit message).


--
Johan Tolö