Ihor Radchenko writes:
> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=24feef95e
Thanks!
--
Bastien Guerry
Ihor Radchenko writes:
> It just _seems_ trivial. This innocently-looking patch will break tests.
>
> Duplicate of https://list.orgmode.org/orgmode/875y2oxfd8@red-bean.com/T/#u
> Canceled.
Doh! And I already reverted this myself! I'm getting old.
Thanks.
--
Bastien Guerry
Ihor Radchenko writes:
> Fixed, on main.
> I removed the folding part, but forgot to add invisible property
> handling.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c8bd2092b
Great, thanks!
--
Bastien Guerry
Ihor Radchenko writes:
> I think that it is premature.
> This is a warning recently introduced on Emacs master, and it is still
> being debated upon. See
> https://yhetil.org/emacs-devel/50e29988-d354-4d10-990f-31828dbe6...@gmail.com/t/#u
Okay, fair enough.
--
Bastien Guerry
Hi,
The current version of Citation handling section of the manual is rather
technical. I tried to rewrite it aiming for ordinary users not familiar
with Org mode internals.
Please, let me know if it reads better.
>From 89e5bd96a1219e85f8e6be7a6eabb840257b021a Mon Sep 17 00:00:00 2001
Message-ID
On 06/05/2024 04:35, Bruno Cardoso wrote:
Fixed.
I have tried the patch. It mostly works, so I do not insist on further
polishing. However it should be resent with proper description.
I had dropped the search code because I wasn't considering the search
option properly. If I understand corr
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> Woof! does not seem to update the new emails any more.
>> https://tracker.orgmode.org/?sorting-by=date page only contains emails
>> back from March. No new bugs/requests/news are visible.
>
> I restarted Woof, let's see if the dog is barking a
András Simonyi writes:
> Thanks Ihor, I have pushed it to main.
Thanks!
Applied. <- a control message for Woof!
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=288e0a11c
^ reference to make life easier when digging mailing list archives for
future maintainers.
--
Ihor Radchenko
Ihor Radchenko writes:
> A few bug reports and patches arrived but nothing is reflected on the
> Woof! list.
Yes, confirmed, I will have a closer look at this today or tomorrow.
--
Bastien Guerry
On 25/03/2024 00:16, Ihor Radchenko wrote:
I just released Org mode 9.6.23 that fixes several critical
vulnerabilities.
Since a variant of exploit has been published, it is time to add a test
that might prevent code change re-introducing the most severe vulnerability.
From af8cddb44f5ee01fb1c
Charles Millar writes:
> Please note that in the second src_latex the zero is stripped from the
> results. The final zero is required for my purposes, i.e. dollars and
> cents. This occurs in both results and on export to pdflatex,
>
> Does org's evaluation cause this or does latex? I have atte
Mehmet Tekman writes:
> Okay, I've cleaned up my branches and rebased where I could, and now I
> think my code is at a place where you can jump in.
>
> This will be a long email summarizing what's been done so far, where the
> pitfalls were, where we are now, and what needs to be done:
> ...
Tha
João Pedro writes:
>>Something that handles tangle-params and result-params,
>
> 1. So the idea is to continue parsing multi-option header arguments into
>their separate components, but have a common place to, after parsing
>it into their components, handle them all in a single place?
Max Nikulin writes:
> On 25/03/2024 00:16, Ihor Radchenko wrote:
>>
>> I just released Org mode 9.6.23 that fixes several critical
>> vulnerabilities.
>
> Since a variant of exploit has been published, it is time to add a test
> that might prevent code change re-introducing the most severe vuln
Hello!
João Pedro writes:
> So, if I understand correctly, =header-reform= is where we're at right
> now and after we're done with this overhauling of the parsing of
> (mutually exclusive) header params, we'll get back to the actual syncing
> logic, which should be mostly done.
Exactly -- ref
On 06/05/2024 19:44, Ihor Radchenko wrote:
Charles Millar writes:
#+NAME: TABLE2
|22578.60|
src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
This is expected. When you assign :var, Org mode reads the ta
Max Nikulin writes:
> On 06/05/2024 19:44, Ihor Radchenko wrote:
>> Charles Millar writes:
>>> #+NAME: TABLE2
>>> |22578.60|
>>>
>>> src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
>>> :exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}}}
>>
>> This is expec
On Saturday, May 4th, 2024 at 15:19, Ihor Radchenko wrote:
> > I tried to ask for bibtex.el to handle the accurate parsing in
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712, but it looks like
> > it is not of interest upstream. So, we may have to implement a Bibtex
> > entry parser accor
On 5/6/24 12:42 PM, Ihor Radchenko wrote:
Max Nikulin writes:
On 06/05/2024 19:44, Ihor Radchenko wrote:
Charles Millar writes:
#+NAME: TABLE2
|22578.60|
src_latex[:var printthis=TABLE2[-1,-1] :eval yes :results replace
:exports results]{\num{printthis}} {{{results(@@latex:\num{22578.6}@@)}
David Masterson writes:
> Ihor Radchenko writes:
>
>> David Masterson writes:
>>
>>> So I have this form:
>>>
>>> :exclude "\(init\|calendar-beorg\).org"
>>>
>>> but that doesn't seem to work as I get an ignorable error in processing
>>> calendar-beorg.org (a known Beorg issue).
>>>
>>> Is my
On 4/30/2024 2:10 PM, Drew Adams wrote:
I've also fixed a bug in EWW and bug-reference-mode
where it would return nil for (thing-at-point 'url)
if point was at the *end* of a URL.
By "at the end" I assume you really mean just
_after_ a URL, i.e., no longer on/at the URL.
FWIW, that's actually
Thanks for your reply, Jim.
> On 4/30/2024 2:10 PM, Drew Adams wrote:
> >> I've also fixed a bug in EWW and bug-reference-mode
> >> where it would return nil for (thing-at-point 'url)
> >> if point was at the *end* of a URL.
> >
> > By "at the end" I assume you really mean just
> > _after_ a URL,
> 1. #+attr_org is prioritised
> 2. Docstrings are updated
>
> Handled, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fede1c990
Just a note that we already prioritize #+attr_org when
aligning/centering images. So this change makes sense.
Karthik
23 matches
Mail list logo