Hi Marcin,
Marcin Borkowski writes:
> Ping?
Just a side remark -- we recently added this to Worg:
If you have nothing special to add to your first message and just
want to "bump" the thread, please wait at least one month before
doing so.
https://orgmode.org/worg/org-mailing-list.html
Hi Utkarsh,
Utkarsh Singh writes:
> For now can you review the patches I proposed earlier in this
> thread?
Not until both you and Maxim are confident this is useful, complete
and predictable.
Also, if you resend the patch for review, please use a proper commit
message: https://orgmode.org/wor
Kyle Meyer writes:
> 823f9744e looks like a regression because it removes the distinction
> between `tags' and `tags-todo'.
I reverted this commit.
> James Cash sent a followup patch to this in a detached thread:
>
> https://orgmode.org/list/87tuvyaopv@gmail.com
>
> As I mentioned in that
Bastien writes:
> Bastien writes:
>
>> Confirming this as an issue, if someone wants to fix it.
>
> This should be fixed now with 823f9744e in maint, tags-todo should now
> include DONE headings.
823f9744e looks like a regression because it removes the distinction
between `tags' and `tags-todo'.
Dear Stanislav,
I'd like to revive this thread: did you have time to ask the person
on reddit to share the solution as a patch? Or could you make this
patch yourself, by any chance?
Thanks a lot,
--
Bastien
Bastien writes:
> Confirming this as an issue, if someone wants to fix it.
This should be fixed now with 823f9744e in maint, tags-todo should now
include DONE headings.
--
Bastien
On Sun, May 16, 2021 at 6:03 PM Denis Maier
wrote:
>
> Am 16.05.2021 um 23:38 schrieb Bruce D'Arcus:
> > Can you clarify the rule/situation that would use that approach?
> >
>
> Chicago Manual of Style 15.26:
> "When the source of a block quotation is given in parentheses at the end
> of th
Hi Warren,
Warren Lynn writes:
> But then if you run "org-agenda-undo" immediately in the agenda
> buffer, the task did not revert back to the original, instead, only
> the "LOGBOOK" part is gone
This should be fixed now, thanks.
--
Bastien
Am 16.05.2021 um 23:38 schrieb Bruce D'Arcus:
On Sun, May 16, 2021 at 5:29 PM Denis Maier
wrote:
...
There's only one further complication: if the quotation is a set off
block quote, the citation comes after the punctuation mark:
This is a complete sentence. (author year)
I've not seen that
On Sun, May 16, 2021 at 5:29 PM Denis Maier
wrote:
...
> There's only one further complication: if the quotation is a set off
> block quote, the citation comes after the punctuation mark:
> This is a complete sentence. (author year)
I've not seen that with the cases I'm familiar with (US and UK
Am 15.05.2021 um 13:56 schrieb Nicolas Goaziou:
Hello,
[...]
At the moment, the `org-cite-adjust-punctuation' function is designed
with author-year to note conversion in mind, not the other way. I don't
have enough examples of the opposite transformation to even be sure the
current interface
Hello,
Joost Kremers writes:
> On Sun, May 16 2021, Nicolas Goaziou wrote:
>
>> So... let's get liberal and say a key must match:
>>
>> (rx "@" (one-or-more (any word "-.:?!`'/*@+|()<>&_^$#%&~")))
>>
>> Nothing bad could happen, right?
>
> On a scale of 1 to 10, 1 being getting an error messag
Hi Sébastien,
Sébastien Miquel writes:
> I think something went wrong though. I've attached as a new patch a
> part of the previous one that wasn't applied. Without it, some
> write-back buffers are never killed.
Sorry I overlooked this, and thanks a lot for the patch, applied now.
--
Bastie
Nick Savage writes:
> Thanks for the bug report, I can confirm this is happening.
I read too hastily, I've now applied your patch against maint.
Thanks!
--
Bastien
Maxim Nikulin writes:
> On 03/05/2021 04:08, Christian Moe wrote:
[snip]
>> Something that would help, without adding new syntax, is
>> making macro expansion smart enough to *ignore* separators when the
>> macro definition contains only *one* argument anyway, as in the cases
>> above.
>
> I thi
On Sun, May 16 2021, Nicolas Goaziou wrote:
> However, allowing anything means some keys will not be compatible with
> some bibliography formats. For example, I doubt BibTeX would appreciate
> a percent character in a key.
Careful, trying to find out the details of BibTeX's file format is a ques
>>> "UB" == Uwe Brauer writes:
> Hi
> I am currently running 9.4.5, well actually a version compiled from git
> master, that I upgraded a couple of weeks ago.
> Commit is e641d3736036732e7642807146a97b0876cb8b83
My bad, I deleted an important information in the table, everything
works as expe
Hi
I am currently running 9.4.5, well actually a version compiled from git
master, that I upgraded a couple of weeks ago.
Commit is e641d3736036732e7642807146a97b0876cb8b83
However in the version I used two month ago the following worked nicely
#+TBLNAME: raw-data
| Stud | Mark |
|-
Hi Bastien,
Bastien writes:
Sorry it took so long to apply this patch, this is now done in maint.
No problem, thank you for getting back on this.
I think something went wrong though. I've attached as a new patch a
part of the previous one that wasn't applied. Without it, some
write-back buffer
On 16/05/2021 19:17, Bastien wrote:
Juan Manuel Macías writes:
(On the other hand, maybe better than an alternate separator, some kind of
warning for unescaped commas might be more useful, as Maxim commented
here: https://orgmode.org/list/s7g...@ciao.gmane.io/)
Yes, probably -- feel free to
On 14/05/2021 21:54, Utkarsh Singh wrote:
On 2021-05-13, 00:08 +0700, Maxim Nikulin wrote:
Comma is decimal separator for es_ES, de_DE, ru_RU, etc. The point is
that order in which separator candidates are tried should depend on
active locale.
I am willing to work on this problem but before t
Hello,
Juan Manuel Macías writes:
> I am writing a custom parse tree filter that does the following (LaTeX
> backend): if a heading has the ':font:' property, the content of that
> heading is enclosed in a LaTeX group. If the property is ':fontfeature:',
> then the content is enclosed in a diffe
Hi all,
I am writing a custom parse tree filter that does the following (LaTeX
backend): if a heading has the ':font:' property, the content of that
heading is enclosed in a LaTeX group. If the property is ':fontfeature:',
then the content is enclosed in a different group. The filter works fine
wh
"Bruce D'Arcus" writes:
> I'm not super sure of the details around, for example, bibtex, but
> this post seems to be helpful to check against for the details?
>
> https://tex.stackexchange.com/questions/388500/what-is-valid-as-a-biblatex-entry-key/388652#388652
Oh my! You're reviving a 6 years o
On Sun, May 16, 2021 at 8:55 AM Nicolas Goaziou wrote:
> Oh my! You're reviving a 6 years old thread[¹]!
6 years in the TeX world is the blink of an eye!
> ... we can put the burden of the user's shoulders.
>
> So... let's get liberal and say a key must match:
>
> (rx "@" (one-or-more (any wo
Hi Nick,
Nick Savage writes:
> Thanks for the bug report, I can confirm this is happening.
I'm now adding the X-Woof-Bug: confirmed header to track this.
Thanks,
--
Bastien
Hi Aimé,
> hope to have done this right as a first time.
Thanks for the effort - but the patch is not in a readable format for
me. I suggest you clone org-mode.git* and run C-x v = in the modified
file to get a proper patch in the buffer, save this buffer as a patch
and attach it (vs. include it
Hi Jarmo,
Jarmo Hurri writes:
> I pulled the latest master and noticed that contrib has been moved into
> a separate repository. I also cloned this contrib repository, but can
> not find the file
>
> scripts/ditaa.jar
It still lives here: https://orgmode.org/worg/code/scripts/ (I forgot
to push
Hi Juan,
Juan Manuel Macías writes:
> (On the other hand, maybe better than an alternate separator, some kind of
> warning for unescaped commas might be more useful, as Maxim commented
> here: https://orgmode.org/list/s7g...@ciao.gmane.io/)
Yes, probably -- feel free to propose a patch for this
Hi Sébastien,
Sébastien Miquel writes:
> I've fixed an issue in my previous patch with the write-back buffer
> not getting killed.
Sorry it took so long to apply this patch, this is now done in maint.
> There's also a remaining issue with the ~undo-boundary~ call in
> ~org-edit-src-exit~. Call
On Sun, May 16, 2021 at 7:29 AM Nicolas Goaziou wrote:
>
> "Bruce D'Arcus" writes:
>
> > I was just interacting with one of the org-roam-bibtex developers about
> > org-cite.
> >
> > He noted that citekeys can only start with an underscore or alpha character.
> >
> > Is that a necessary restricti
"Bruce D'Arcus" writes:
> I was just interacting with one of the org-roam-bibtex developers about
> org-cite.
>
> He noted that citekeys can only start with an underscore or alpha character.
>
> Is that a necessary restriction?
>
> He, it turns out, mostly has keys of the form '2020-DOE-ABC".
It
I was just interacting with one of the org-roam-bibtex developers about
org-cite.
He noted that citekeys can only start with an underscore or alpha character.
Is that a necessary restriction?
He, it turns out, mostly has keys of the form '2020-DOE-ABC".
Bruce
Ihor Radchenko writes:
> Sorry, I cannot reproduce on my side using Emacs master, Emacs 27, and
> Emacs 25. I used the following recipe:
>
> 1. cd /path/to/org
> 2. make clean
> 3. make
> 4. emacs -Q -L ./lisp/ -l org -l /tmp/1.el ~/Org/inbox.org
> 5. M-x org-agenda < t
> 6. M-x org-todo on the f
Hello,
"Bruce D'Arcus" writes:
> On Sat, May 15, 2021 at 5:29 PM Nicolas Goaziou
> wrote:
>> I pushed in "wip-cite-new" an attempt to parse styles as a pair (name .
>> variant). I also updated oc-natbib.el and oc-basic.el accordingly.
>
> Looks good to me, and seems a good balance.
Thanks.
>
Hi Ihor,
Ihor Radchenko writes:
> Can it be some strange interaction between .el, .elc, or even .eln
> files compiled for different Org versions?
Mhh... probably -- I'll monitor this closely.
--
Bastien
Ihor Radchenko writes:
> Nicolas Goaziou writes:
>> It should be a paragraph. I'll fix it soon.
>>
>> Note the problem can be reproduced with only
>>
>> * test
>> :end:
>
> Thanks!
Fixed. Thank you.
> Also, I have few more questions (or maybe bug reports) about
> syntax/parsing:
>
> 1. Doe
Nicolas Goaziou writes:
> It should be a paragraph. I'll fix it soon.
>
> Note the problem can be reproduced with only
>
> * test
> :end:
Thanks!
Also, I have few more questions (or maybe bug reports) about
syntax/parsing:
1. Does org-element--current element suppose to return (paragraph ..
>>> "BC" == Berry, Charles writes:
Chuck
> Uwe,
> You used `:exports code :eval never-export' (from an earlier posting).
> I think you want `:exports both :eval never-export' to keep babel from
> removing the results.
Thanks very much, that was the essential bit of code. Solved!
smime.p7s
Hello,
Ihor Radchenko writes:
> I am wondering about the element structure of the following Org buffer:
>
> * test
> :drawer:
> Paragraph
> * test
> :end:
>
> Should the ":end:" line belong to drawer or should it be a separate
> paragraph? Running org-element-at-point at the beginning of ":end:"
40 matches
Mail list logo
