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.
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:
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
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
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
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
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
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
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.
--
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
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
>>> "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
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
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
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
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
"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
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
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
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
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
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~.
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
"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".
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
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.
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
Bastien writes:
> Debugger entered--Lisp error: (void-variable org--up-heading-cache)
> org-up-heading-safe()
> Ihor, do you see what's happening here?
This is very odd. `org--up-heading-cache' is supposed to be buffer-local
variable available in all buffers with default value of nil. Yet,
Hi,
Ihor Radchenko writes:
> While testing another patch for agenda fontification, I noticed that
> agenda can spend up to half!! time doing org-up-heading-safe. Mostly
> inside queries for inherited tags and properties.
I encounter a bug with this cache, it seems the buffer-local variable
Hi Nicolas,
Nicolas Goaziou writes:
>> Is this okay to install this in the maint branch?
>
> I didn't test it, but it seems to fix the issues reported. So I guess
> this is fine.
Done, thanks!
--
Bastien
43 matches
Mail list logo
