Re: How to have a repeating item within some hours?
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#i-didnt-receive-an-answer If every post with no reply within 4 days is bumped, we will end up with more bumps than original posts :) Thanks for your patience, -- Bastien
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
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/worg/org-contribute.html#commit-messages Thanks, -- Bastien
Re: tags-todo agenda shoud not ignore DONE items
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 thread (<87361d7p3q@kyleam.com>) and > suggested in this thread (<87d061auiw@kyleam.com>), I think tags and > tags-todo should stay aligned with agenda's m/M, with tags-todo > excluding DONE items just as M does. Sorry I missed these replies, I see now. If you think there are places in the documentation that needs some fixing or clarification please go ahead as you see fit. Thanks, -- Bastien
Re: tags-todo agenda shoud not ignore DONE items
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'. Consider the following file
--8<---cut here---start->8---
* h1 :atag:
* TODO h2 :atag:
* DONE h3 :atag:
* h4
* TODO h5
* DONE h6
--8<---cut here---end--->8---
and the following configuration
(setq org-agenda-custom-commands
'(("1" tags "atag")
("2" tags-todo "atag")))
Before the above commit, 1 should show
scratch:h1
:atag:
scratch:TODO h2
:atag:
scratch:DONE h3
:atag:
and 2
scratch:TODO h2
:atag:
That matches my expectations, though the request in this thread is that
2 includes "DONE h3" as well.
With 823f9744e, both 1 and 2 show
scratch:h1
:atag:
scratch:TODO h2
:atag:
scratch:DONE h3
:atag:
Note the inclusion of a non-TODO entry for 2 (tags-todo).
---
James Cash sent a followup patch to this in a detached thread:
https://orgmode.org/list/87tuvyaopv@gmail.com
As I mentioned in that thread (<87361d7p3q@kyleam.com>) and
suggested in this thread (<87d061auiw@kyleam.com>), I think tags and
tags-todo should stay aligned with agenda's m/M, with tags-todo
excluding DONE items just as M does.
Re: Bug: Appointments duration and effort sums in agenda column view [9.3.7 (release_9.3.7-700-ga1e5be @ ~/.emacs.d/straight/build/org/)]
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
Re: tags-todo agenda shoud not ignore DONE items
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
Re: [wip-cite-new] Adjust punctuation around citations
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 the quotation, the opening parenthesis appears after the final > punctuation mark of the quoted material. No period either precedes or > follows the closing parenthesis." Maybe me and a lot of scholars aren't very good at following these rules :-) Or maybe the stuff I read and write doesn't follow Chicago, etc for whatever reason. > Seems to be the same in MLA and APA by the way: > https://writingcenter.uagc.edu/block-quotations Very helpful! So what are you thinking; this punctuation-manipulation should not apply to blockquotes at all? Bruce
Re: Bug: org-agenda-undo does not work with repeated tasks [9.4]
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
Re: [wip-cite-new] Adjust punctuation around citations
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 with the cases I'm familiar with (US and UK English). The citation would just be inside the final period of the blockquote, so depending on style class: - ... ending of blockquote (Doe, 2019). - ... ending of blockquote [doe19]. - ... ending of blockquote.[1] So there would be need for any special handling. I mean blockquotes don't normally include quotation marks around them. 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 the quotation, the opening parenthesis appears after the final punctuation mark of the quoted material. No period either precedes or follows the closing parenthesis." And the example: If you happen to be fishing, and you get a strike, and whatever it is starts off with the preliminaries of a vigorous fight; and by and by, looking down over the side through the glassy water, you see a rosy golden gleam, the mere specter of a fish, shining below in the clear depths; and when you look again a sort of glory of golden light flashes and dazzles as it circles nearer beneath and around and under the boat; . . . and you land a slim and graceful and impossibly beautiful three-foot goldfish, whose fierce and vivid yellow is touched around the edges with a violent red—when all these things happen to you, fortunate but bewildered fisherman, then you may know you have been fishing in the Galapagos Islands and have taken a Golden Grouper. (Pinchot 1930, 123) Seems to be the same in MLA and APA by the way: https://writingcenter.uagc.edu/block-quotations Denis
Re: [wip-cite-new] Adjust punctuation around citations
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 English). The citation would just be inside the final period of the blockquote, so depending on style class: - ... ending of blockquote (Doe, 2019). - ... ending of blockquote [doe19]. - ... ending of blockquote.[1] So there would be need for any special handling. I mean blockquotes don't normally include quotation marks around them. Can you clarify the rule/situation that would use that approach? Bruce
Re: [wip-cite-new] Adjust punctuation around citations
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 would be appropriate. I even believe this is not often
possible, as it would imply rewording, i.e., add information that is not
present in the original document.
This doesn't seem to be a limitation, though. This feature is useful for
users having to switch between author-year and note styles. The rule of
thumb is to always write author-year in source.
Well, I have to admit I was a bit confused when I first read this since
the examples we're currently working with wouldn't be correct examples
for author-date citations in German and English:
--8<---cut here---start->8---
#+language: de
#+cite_export: test
1. "This is a complete sentence." [cite:@key]
2. "This is an incomplete sentence" [cite:@key].
3. This is a complete sentence. [cite:@key]
4. This is an incomplete sentence [cite:@key].
--8<---cut here---end--->8---
In German and English author-date styles example 1. and 2. will both be
rendered as:
"This is a complete sentence" (author year).
"This is an incomplete sentence" (author year).
So, in both cases the punctuation comes after the citation.
After looking up a few guidelines from French speaking universities in
Canada, it looks like in French you'll actually render these citations as:
"This is a complete sentence." (author year)
"This is an incomplete sentence" (author year).
(Don't know if that is consistent across la francophonie.)
I.e., with a complete sentence you'll have the final punctuation inside
the quotation marks with the citation following the citation. So, as you
say the location of the punctuation is semantically meaningful in French
even with author-date styles, but that isn't the case in German and
English. In German and British English, the location of the punctuation
is only semantically meaningful with note citation styles.
Now, interestingly, the way you'll place the punctuation marks in German
and British English seems to conform to French author-date punctuation
placement.
This means that in German and British English a conversion from
"This is a complete sentence." [cite:@key]
to
"This is a complete sentence" (citation).
is actually not adding, but removing information.
OTOH, if you write targeting German/English author-date styles, it's not
possible to switch correctly to a note style in German and British
English. (You'll have to indicate the location of the punctuation in the
original material, which means it has to be moved when targeting an
author-year style.)
So, I still think (outside outside before) should work in general for
English and German. If I understand correctly you've already added it as
(pcase style ("author-year" ...
Correct?
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)
Can surrounding context be considered in that transformation?
Denis
In any case, this explains why the docstring has a bias. I updated it to
insist on the fact that these are rules for author-year to note
conversion.
Also, this function is not meant to be accessible to the end user. It is
called from the processor, which knows the type (or style) of the
citation. It may also choose not to use this function. So, I agree with
Bruce D'Arcus: selecting an appropriate rule and punctuation ought to
happen at that level.
More importantly, I don't think fine-grain configuration is required.
For specific needs, this "smart" feature should be disabled, and
elements (punctuation, citation) positioned manually. But, again, if
configuration is needed, the processor should provide it, e.g., through
variables, not Org Cite. For example, a defcustom could offer to 1) not
use this feature 2) rely on "language" keyword 3) apply a user-defined
rule and punctuation set.
What would be nice, however, would be an association between language
and default rules and punctuation characters.
WDYT?
Meanwhile, I modified `org-cite-adjust-punctuation' function a bit. Here
is its new docstring.
--8<---cut here---start->8---
Adjust punctuation around CITATION object.
When CITATION follows a quotation, or when there is punctuation next to it,
the function tries to normalize the location of punctuation and citation
according to some RULE.
RULE is a triplet of symbols (PUNCTUATION CITE ORDER):
PUNCTUATION is the desired location of the punctuation with regards to the
quotation, if any. It may be `inside', `outside', or`static'. When set to
`static', the punctuation is not moved.
CITE is the desired location of the citation with
Re: [org-cite] citekey restrictions?
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 message and having to go
> online
> to find out what it means, and 10 being the total and utter destruction of our
> solar system, I doubt it'll exceed 1.
What a relief! Thanks.
I changed the syntax for key to the regexp above. I even added curly
brackets. Now, the following is a valid key:
@{}
I then cleaned-up a bit the branch, and rebased on top of master.
Regards,
--
Nicolas Goaziou
Re: [Patch] Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
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. -- Bastien
Re: [bug] C-u org-update-statitics-cookies errors out with "Non-existent agenda file" if current file isn't saved
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
Re: [PATCH] Possibility of using alternative separators in macros
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 think, this is an idea of the best approach. Unsure concerning
> precise form. Maybe e.g. "$_" could expand into all arguments greater
> than maximum referenced number. No promise of forward compatibility of
> the following hack since it relies on undocumented implementation
> details.
>
> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
> #'identity _ ",")))
>
> {{{allargshack(one, two, three)}}}
>
> I do not know if Eric can swap order of arguments of his credits
> macro. Extracting namely last argument requires a bit more lisp code.
Yes, I didn't think that far. This would provide a comprehensive
backwards-compatible solution to the comma-escaping problem, though
perhaps not the most newbie-friendly one. It would also make macros more
flexible and powerful in the bargain (I'm sure people will think of
other uses for this than commas).
Yours,
Christian
Re: [org-cite] citekey restrictions?
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 quest that
I think no-one has ever returned from. :D I have a comment in =parsebib.el=
saying that BibTeX allows $ ^ and & in entry keys, despite the fact that those
characters are special in TeX...
The regexp =parsebib.el= uses for entry keys is this:
"[^\"@\\#%',={} \t\n\f]+"
Mind you, I have no idea if BibTeX really rejects all these characters (well,
I'm pretty sure about the white space... :D ), but even if they are acceptable,
they probably don't occur much in the wild. At least I'm not aware of any user
complaints since the time I added support for $^&, which was four years ago,
> 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 message and having to go online
to find out what it means, and 10 being the total and utter destruction of our
solar system, I doubt it'll exceed 1.
--
Joost Kremers
Life has its moments
[SOLVED] (was: BUG? Frequency table does not work any more.)
>>> "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 expected. smime.p7s Description: S/MIME cryptographic signature
BUG? Frequency table does not work any more.
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 | |--+---| | | 0 | | | 0 | | | 0 | | | 0 | | | 0 | | | 0 | | | 1 | | | 1.25 | | | 1.25 | | | 2 | | | 2 | | | 2.5 | | | 2.5 | | | 3 | | | 3 | | | 3.25 | | | 4 | | | 4 | | | 4.25 | | | 4.5 | | | 4.5 | | | 4.5 | | | 5.5 | | | 5.5 | | | 5.75 | | | 6 | | | 6.5 | | | 7 | | | 7.5 | | | 9 | |--+---| | Mean | 3.342 | #+TBLFM: $1=@#-1::@32$2=vmean(@I$2..@II$2) That still works However #+BEGIN_SRC emacs-lisp (defun in-interval (bounds el) (and (>= el (car bounds)) (<= el (cadr bounds #+END_SRC #+RESULTS: : in-interval | lower bound | upper bound | frequency | |-+-+---| | 1 | 5 |16 | | 5 | | 0 | #+TBLFM: $3='(length (org-lookup-all '($1 $2) '(remote(raw-data,@2$2..@>$2)) nil 'in-interval));N That does not work any more. When I put my cursor on TBLFM and run C-c C-c then a cryptic message Cells in the region copied, use M-x org-table-paste-rectangle to paste them in a table. [2 times] But I don't want to copy the cells in the region, I want to execute the function. That is a important matter since I rely on the functionality quite a bit. What shall can I do Regards Uwe Brauer
Re: [Patch] Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
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 buffers are never killed. Regards, -- Sébastien Miquel >From f293a9d5808c413ce785646ebf5f480df3a00a2f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sun, 16 May 2021 19:13:53 +0200 Subject: [PATCH] org-src.el (org-edit-src-exit): Fix write-back-buf not getting killed * lisp/org.el (org-edit-src-exit): Fix write-back-buf not getting killed --- lisp/org-src.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index df3c76e13..5604e6568 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -1255,8 +1255,8 @@ Throw an error if there is no such buffer." (narrow-to-region beg end) (replace-buffer-contents write-back-buf) (goto-char (point-max - (when (and expecting-bol (not (bolp))) (insert "\n"))) - (when write-back-buf (kill-buffer write-back-buf + (when (and expecting-bol (not (bolp))) (insert "\n") +(when write-back-buf (kill-buffer write-back-buf)) ;; If we are to return to source buffer, put point at an ;; appropriate location. In particular, if block is hidden, move ;; to the beginning of the block opening line. -- 2.31.1
Re: [PATCH] Possibility of using alternative separators in macros
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 propose a patch for this. Thanks! Such warnings should be property of particular macros. Sometimes ignoring of arguments may be handy. So no patch is required. The trick could be documented somewhere, but I am unsure concerning proper place. Actually, I do not think, fatal error is user-friendly behavior. I am not aware if export already have convenient facilities to report warnings. Currently I do not feel I am ready to implement such feature if it does not exist yet. However the point of that message was that extra commas may be made "transparent" for macros by introducing additional substitution, e.g. "$_" that expands into "rest" arguments. I consider "$@" or "$*" as worse variant since it rather mean "all arguments", so it is less flexible. For "eval" lisp macros, it is just replacing "_" by "$_" in argument list. Simple text macros require a bit more work but it is still comparable with documenting the feature. We need a decision if "rest arguments" feature should be introduced. Once added, it will be harder to discard it due to compatibility issues.
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
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 this can you identify any other locale with similar problem or a resource from where I can information's about locale. I do not think list of locales should be hard coded. I am not familiar with elisp enough to tell you if locale properties such as decimal separator are exposed through some function. I expect, it is quite probable. As a last measure, some number, e.g. 0.5 or 1.5 could be formatted using a locale-aware function and result string could be checked if it contains ",".
Re: [Question] Custom parse tree filter
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 different group. The filter works fine > when all the headings are at the same level. But with different levels, > it does not returns the expected result. It's evident that I'm doing > something catastrophically wrong :-). I wonder if anyone could put me on > the track of the origin of my error... > > Below, the offender function and a sample. Thanks in advance! I think you are operating at the wrong level. Higher level headlines contain lower level ones. I suggest to operate on sections instead. Also, using `org-element-interpret-data' is meh because you're operating at the parse tree level. You can insert export-snippet objects directly. Here's a proposal. This could be refactored, but you get the idea. --8<---cut here---start->8--- (defun my-custom-filters/fontspec-headline (tree backend info) (when (org-export-derived-backend-p backend 'latex) (org-element-map tree 'section (lambda (section) (let ((font (org-export-get-node-property :FONT section t)) (fontfeature (org-export-get-node-property :FONTFEATURE section t)) (create-export-snippet ;; Create "latex" export-snippet with value V. (lambda (v) (org-element-create 'export-snippet (list :back-end "latex" :value v) (cond (font (apply #'org-element-set-contents section (append (list (funcall create-export-snippet "%font start\n")) (org-element-contents section) (list (funcall create-export-snippet "%font end\n") (fontfeature (apply #'org-element-set-contents section (append (list (funcall create-export-snippet "%fontfeature start\n")) (org-element-contents section) (list (funcall create-export-snippet "%fontfeature end\n" info) tree)) --8<---cut here---end--->8--- Also, when "org-cite-wip" is merged, you will be able to replace, e.g., (funcall create-export-snippet "%fontfeature start\n") with (org-export-raw-string "%fontfeature start\n") Regards, -- Nicolas Goaziou
[Question] Custom parse tree filter
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
when all the headings are at the same level. But with different levels,
it does not returns the expected result. It's evident that I'm doing
something catastrophically wrong :-). I wonder if anyone could put me on
the track of the origin of my error...
Below, the offender function and a sample. Thanks in advance!
Best regards,
Juan Manuel
#+BIND: org-export-filter-parse-tree-functions
(my-custom-filters/fontspec-headline)
#+begin_src emacs-lisp :exports results :results none
(defun my-custom-filters/fontspec-headline (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
(org-element-map tree 'headline
(lambda (hl)
(cond ((org-element-property :FONT hl)
(let* ((font (org-element-property :FONT hl))
(contents (org-element-interpret-data
(org-element-contents hl)))
(contents-new (concat
"@@latex:{\\fontspec{@@"
(replace-regexp-in-string
"\s*\\(\\[.+\\]\\)\s*" "" font)
"@@latex:}%@@\n"
(if (string-match "\\(\\[.+\\]\\)" font)
(concat "@@latex:" (match-string 1
font) "%@@\n\n")
"\n")
contents
"\n@@latex:}@@")))
(org-element-set-contents hl (with-temp-buffer
(insert contents-new)
(org-element-parse-buffer)
((org-element-property :FONTFEATURE hl)
(let* ((fontfeature (org-element-property :FONTFEATURE hl))
(contents (org-element-interpret-data
(org-element-contents hl)))
(contents-new (concat
"@@latex:{\\addfontfeature{@@"
fontfeature
"@@latex:}%@@\n"
contents
"\n@@latex:}@@")))
(org-element-set-contents hl (with-temp-buffer
(insert contents-new)
(org-element-parse-buffer)))
info)
tree))
#+end_src
* Minion Pro
:PROPERTIES:
:font: Minion Pro [Style=Historic,Color=teal]
:END:
Lorem ipsum dolor.
** Lowercase Numbers
:PROPERTIES:
:fontfeature: Numbers=Lowercase
:END:
Lorem ipsum dolor 1234567890.
*** Letter Space
:PROPERTIES:
:fontfeature: LetterSpace=14.6
:END:
Lorem ipsum dolor 1234567890.
Re: [org-cite] citekey restrictions?
"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 old thread[¹]! Basically, current syntax is inherited from a previous citation specification allowing shortcuts: @key instead of [cite:@key]. Since these shortcuts do not exist anymore, we don't need to be so careful about characters allowed in a key. The only one being dangerous is the semicolon, since it is used to separate keys in a citation reference. Closing square bracket could also be problematic if it is not paired properly. So, to be on a safe side, anything beside space, semicolon and square brackets are fine. 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. OTOH, 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 word "-.:?!`'/*@+|()<>&_^$#%&~"))) Nothing bad could happen, right? [¹] https://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00131.html -- Nicolas Goaziou
Re: [org-cite] citekey restrictions?
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 word "-.:?!`'/*@+|()<>&_^$#%&~"))) > > Nothing bad could happen, right? Probably not. As you say, you can put the burden on the user, and can always tighten it later if something comes up. Bruce
Re: [bug] C-u org-update-statitics-cookies errors out with "Non-existent agenda file" if current file isn't saved
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
Re: [PATCH] Link handling for qutebrowser org-mac-link.el
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) to your email. If you want your patch to be perfect, you can check this page too: https://orgmode.org/worg/org-contribute.html#commit-messages Thanks in advance, -- Bastien
Re: The fate of ditaa.jar (9.4.5.)
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 the files on Worg at first, but this is fixed.) I also mentioned this more clearly in etc/ORG-NEWS, I agree we should provide users with the relevant information here. Thanks, -- Bastien
Re: [PATCH] Possibility of using alternative separators in macros
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. Thanks! -- Bastien
Re: [Patch] Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
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~. Calling ~undo~ after ~indent-region~ or > ~comment-region~ will send the cursor to the beginning of the src > block I believe we can live with it. Thanks! -- Bastien
Re: [org-cite] citekey restrictions?
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 restriction? > > > > He, it turns out, mostly has keys of the form '2020-DOE-ABC". > > It is not a necessary restriction. > > What do you suggest as the first character? Underscore, and > alphanumeric? I think so; yes. > So keys would need to: > > - start with _ or alnum > - end with _ or alnum > - optionally contain any alnum or symbol among #$%&+./:<>?_~- 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 Bruce
Re: [org-cite] citekey restrictions?
"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 is not a necessary restriction. What do you suggest as the first character? Underscore, and alphanumeric? So keys would need to: - start with _ or alnum - end with _ or alnum - optionally contain any alnum or symbol among #$%&+./:<>?_~- Regards,
[org-cite] citekey restrictions?
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
Re: prettify-symbols-mode in org agenda?
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 first item selecting "NEXT" state > 7. M-x org-agenda-redo-all > > The 1.el and inbox.org are attached. > > Can you try to reproduce using the same steps as I did? I can't reproduce it using your steps and config. I compared the org config differences. I'm using a different org keyword ONGOING, instead of NEXT. In fact, if I replace NEXT with ONGOING in 1.el, then I can reproduce the issue. This is very strange.. After step 7, I can see it still shows ONGOING text in the agenda buffer, but in the buffer inbox.org, it is been correctly prettified. -- William 1.el Description: application/emacs-lisp
Re: [wip-cite-new] New natbib processor
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. > You mention it was "an attempt"; WDYT of the result? I like simplicity; plain styles are simple. I cannot tell if it is really useful yet. This change is supposed to ease switching from one processor to another, but no other processor is relying on variants so far. Someone™ needs to write "oc-citeproc.el" or "oc-biblatex.el" to see them in action. So, I'll defer to your judgement. Regards, -- Nicolas Goaziou
Re: [PATCH] Use cache in org-up-heading-safe
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
Re: Question about Org syntax
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. Does org-element--current element suppose to return (paragraph ...) >on empty buffer? It is undefined. `org-element-current-element' is an internal function being called at the beginning of "something". However, `org-element-at-point' is expected to return nil in an empty buffer. > 2. Some of the element parsers honour LIMIT argument partially. Part of >the parsing is typically done using looking-at (ignoring the LIMIT) >and part is honouring it. This can backfire when LIMIT is before >first characteristic line of the element. For example take headline >parser: > >* Example headline > >:contents-begin of the parsed headline will be _after_ :end > >Or even >* example headline > >:contents-begin is equal to :begin, sometimes leading to infinite >loops in org-element--parse-to called by org-element-cache (hence, >known bug with Emacs hangs when org-element-use-cache is non-nil) > >Some of the parsers potentially causing similar issues are: > >In particular, org-element-footnote-definition-parser, >org-element-headline-parser, org-element-inlinetask-parser, >org-element-plain-list-parser, org-element-property-drawer-parser, >org-element-babel-call-parser, org-element-clock-parser, >org-element-comment-parser, org-element-diary-sexp-parser, >org-element-fixed-width-parser, org-element-horizontal-rule-parser, >org-element-keyword-parser, org-element-node-property-parser, >org-element-paragraph-parser, ... LIMIT is not a random position in the buffer. It is supposed to be the end of the parent element, or (point-max). It is a bug (in the parser or in the cache) if it ends up being anywhere else. > 3. Some of the element parsers ignore LIMIT altogether: > org-element-item-parser, org-element-section-parser... `org-element-section-parser' actually recomputes LIMIT since it calls `outline-next-heading'. This is sub-optimal and could probably be removed. `org-element-item-parser' is called in `item' mode, i.e., right after `org-element-plain-list-parser', which already takes care of LIMIT. No need to handle it twice. > Is there any reason behind this? I though that parsing narrowed > buffer is supposed to honour narrowing. Also, ignoring LIMIT might > cause issue when trying to parse only visible elements. No, parsing ignores any narrowing, hence the copious use of `org-with-wide-buffer' or `org-with-point-at'. Narrowing is here to help the user focus on a part of the document, not to cheat on the surrounding syntax. As an example Here is an example: what do you think about it? Narrowing the buffer to ": what do you think about it?" for reasons should not trick the parser into thinking you're in a fixed width area. Regards, -- Nicolas Goaziou
Re: Question about Org syntax
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 ...) on empty buffer? 2. Some of the element parsers honour LIMIT argument partially. Part of the parsing is typically done using looking-at (ignoring the LIMIT) and part is honouring it. This can backfire when LIMIT is before first characteristic line of the element. For example take headline parser: * Example headline :contents-begin of the parsed headline will be _after_ :end Or even * example headline :contents-begin is equal to :begin, sometimes leading to infinite loops in org-element--parse-to called by org-element-cache (hence, known bug with Emacs hangs when org-element-use-cache is non-nil) Some of the parsers potentially causing similar issues are: In particular, org-element-footnote-definition-parser, org-element-headline-parser, org-element-inlinetask-parser, org-element-plain-list-parser, org-element-property-drawer-parser, org-element-babel-call-parser, org-element-clock-parser, org-element-comment-parser, org-element-diary-sexp-parser, org-element-fixed-width-parser, org-element-horizontal-rule-parser, org-element-keyword-parser, org-element-node-property-parser, org-element-paragraph-parser, ... 3. Some of the element parsers ignore LIMIT altogether: org-element-item-parser, org-element-section-parser... Is there any reason behind this? I though that parsing narrowed buffer is supposed to honour narrowing. Also, ignoring LIMIT might cause issue when trying to parse only visible elements. Best, Ihor
Re: when executing a src block with latex construct, display problem because of +
>>> "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 Description: S/MIME cryptographic signature
Re: Question about Org syntax
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:" line > yields (drawer ...). It should be a paragraph. I'll fix it soon. Note the problem can be reproduced with only * test :end: Regards, -- Nicolas Goaziou
Re: [PATCH] Use cache in org-up-heading-safe
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, the backtrace suggests that variable does not exist. Can you see the variable description when running describe-variable? Will the error disappear if you eval-last-sexp on the defvar-local? Can it be some strange interaction between .el, .elc, or even .eln files compiled for different Org versions? Best, Ihor
Re: [PATCH] Use cache in org-up-heading-safe
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
`org--up-heading-cache' is not initialized in every buffer from which
org-agenda-list might need it.
I'm attaching the bugtrace.
Ihor, do you see what's happening here?
--
Bastien
Debugger entered--Lisp error: (void-variable org--up-heading-cache)
org-up-heading-safe()
org-block-todo-from-children-or-siblings-or-parent((:type todo-state-change
:position 20793 :from todo :to done))
org-entry-blocked-p()
org-agenda--mark-blocked-entry()))
org-agenda-finalize-entries((... ... ... ... ... ... ... ... ... ... ... ...
... ... ...) tags)
org-tags-view((4) #("+Code+TODO={NEXT\\|STRT}" 11 23 (regexp t)))
#f(compiled-function () #)()
funcall(#f(compiled-function () #))
(let ((org-agenda-category-filter-preset '("-ETL"))) (funcall
'#f(compiled-function () #)))
eval((let ((org-agenda-category-filter-preset '("-ETL"))) (funcall
'#f(compiled-function () #
org-agenda(nil "cc")
(lambda nil (interactive) (org-agenda nil "cc"))()
funcall-interactively((lambda nil (interactive) (org-agenda nil "cc")))
command-execute((lambda nil (interactive) (org-agenda nil "cc")))
Re: [Patch] to correctly sort the items with emphasis marks in a list
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
