BUG: org-agenda-entry-text-cleanup-hook not working
Hi, org-agenda-entry-text-cleanup-hook is not called when agenda is produced. Org mode version 9.3.6 (release_9.3.6-471-g9e385d Prove: (defun ct-clean-agenda-entry () (message "XXX1")) (add-hook 'org-agenda-entry-text-cleanup-hook 'ct-clean-agenda-entry) But there is no output while agenda is displayed with a lot of entries. I don't know why because in org-agenda-get-some-entry-text there is an unconditional (run-hooks 'org-agenda-entry-text-cleanup-hook)
Re: Bug: Moving org-inline-tasks produces error message [9.3.6 (9.3.6-elpa @ /home/c.hemminghaus/.emacs.d/elpa/org-9.3.6/)]
Hi, Wouldn't it be the much better approach to change inline tasks so that the END line is one level below the "begin" line? I did not think it through. But IMO it would make IT more compatible with normal org behavior, and also more visually appealing. With the END notation it would still be unambiguous. I'm aware that this change would have an impact on existing documents. But worth a simple migration command the improvement would be worth the little pain. Regards, m Am Do., 13. Mai 2021 um 15:08 Uhr schrieb Bastien : > Hi Christian, > > Bastien writes: > > > Christian Hemminghaus writes: > > > >> I ran into an error message while composing structured text with > >> org-mode using org-inline-tasks. The error appears when moving around > >> inline tasks in my document. > > > > yes, I confirm this bug. > > Carsten proposed a patch that I adapted a little bit and pushed to the > maint branch. We now throw an error saying that dragging inline tasks > is not supported. > > Thanks, > > -- > Bastien > > > -- > Confidentiality Notice:This email and any attachments it may contain are > intended for the individual or entity above and may be confidential and > protected by legal privilege. SmartPM Technologies, Inc. makes no > warranties, express or implied, concerning the accuracy of the information > contained herein, which is subject to change without notice. Unintended > recipients should be aware that use of this e-mail or any of its > attachments in any way is forbidden. >
Re: Moving some lisp/ob-*.el files to org-contrib - your advice?
hi, Bastien, > 2e0375d2 — Bastien Guerry2 days ago > lisp/ob-julia.el: Add a Homepage header that Homepage seems to point at https://git.savannah.gnu.org/cgit/emacs/org-mode.git which appears to be a (the?) full-on org-mode git repo, and which doesn't appear to have ob-julia.el. for whatever reason, i point at https://github.com/gjkerns/ob-julia in case that's of use. cheers, Greg ps -- snooping around, trying to figure out if i understood things, org-link-edit.el seems to lack a Homepage.
Re: prettify-symbols-mode in org agenda?
Ihor Radchenko writes:
>> I think I'm still seeing the issue. For example, if i change (M-x
>> org-agenda-todo) a TODO item into next state ONGOING, which i have made
>> prettified:
>>
>> (push '("ONGOING" . "" ) prettify-symbols-alist)
>>
>> So far so good. But as soon as I call org-agenda-redo-all, after the
>> agenda is refreshed, it changes back to text 'ONGOING'.
>
> I was able to reproduce using prettify-symbols-mode (though not using
> pretty-symbols-mode). Should be fixed now in the attached patch.
The issue seems still present.
pretty-symbols-mode is deprecated, and replaced by
prettify-symbols-mode? From its homepage:
https://github.com/drothlis/pretty-symbols
--
William
Re: [PATCH] org-refile.el: Fix the case of emtpy buffer name
In my opinion, patch is the minimal change that fixes particular
workflow and can be committed in the current form. Commit message may be
improved a bit.
I have a question (mainly to maintainer) if another approach could lead
to undesired effects, see below.
I have noticed a couple of old issues that can be improved later since
they may require more changes than allowed for "TINYCHANGE".
On 14/05/2021 01:20, satotake wrote:
[PATCH] org-refile.el: Fix the case of emtpy buffer name
Buffer not associated with a file may be more precise since "*scratch*"
has name.
* lisp/org-refile.el (org-refile-get-targets): Ensure
arg of `file-name-non' and `file-truename' is non-nil.
truncated function name
Comments below a loosely related to the suggested patch.
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -310,11 +310,13 @@ converted to a headline before refiling."
(setq f (buffer-file-name (buffer-base-buffer f
(setq f (and f (expand-file-name f)))
(when (eq org-refile-use-outline-path 'file)
-(push (list (file-name-nondirectory f) f nil nil) tgs))
+(push (list (and f (file-name-nondirectory f)) f nil nil) tgs))
(when (eq org-refile-use-outline-path 'buffer-name)
(push (list (buffer-name (buffer-base-buffer)) f nil nil) tgs))
(when (eq org-refile-use-outline-path 'full-file-path)
-(push (list (file-truename (buffer-file-name
(buffer-base-buffer))) f nil nil) tgs))
Notice `file-truename'
+(push (list (and (buffer-file-name (buffer-base-buffer))
+ (file-truename (buffer-file-name
(buffer-base-buffer
+ f nil nil) tgs))
(org-with-wide-buffer
(goto-char (point-min))
(setq org-outline-path-cache nil)
@@ -337,9 +339,10 @@ converted to a headline before refiling."
#'identity
(append
(pcase org-refile-use-outline-path
- (`file (list (file-name-nondirectory
-(buffer-file-name
- (buffer-base-buffer)
+ (`file (list
+ (and (buffer-file-name
(buffer-base-buffer))
I hope, additional operation in the inner loop has minimal performance
penalty. Additional variable may be introduced and initialized before
the loop over headings. It may help to avoid discrepancy similar to
`file-truename'.
+(file-name-nondirectory
+ (buffer-file-name
(buffer-base-buffer))
(`full-file-path
(list (buffer-file-name
(buffer-base-buffer
Earlier patch, that added `file-truename' above, missed this point. At
first I was surprised why this clause does not require modification.
To maintainers:
What are negative consequences of completely skipping of buffers that
have no associated files? I mean not to add them to the list for
iteration. I can anticipate some tests should be fixed but I do not
think it is a problem. Anyway `org-goto' and `org-refile' do not work in
such buffers (from my point of view, reaction to such issue should be
saving content of buffer to some file since critical size of notes is
achieved):
On 14/05/2021 01:20, satotake wrote:
In addition to your point, I found that we cannot refile internally even with
my patch. In other words, if we can cache and reuse it, error ("Please
indicate a target file in the refile path") is raised
when we select it as refile target.
Probably, we need to some additional fixations.
It may be good to filter `files' which does not have `buffer-file-name'.
Have you tried org-capture?
Yes. Mostly I use org-capture, especially, for creating TODO tasks.
I sometimes start with fundamental-mode new buffer.
After writing some texts, I switch to org-mode and try to call refile.
I do not know why I do it by myself clearly but I tend to do it when I
do not have any clear goal for the file.
Thank you for details. I think, it is a kind of valid workflow.
Personally I would consider it unreliable however. I suppose,
`org-default-notes-file' (default capture target) better suited for
temporary notes since it minimizes risk of lost text in the case of
failure. It requires to change habits a bit to call org-capture with
simple template in advance.
Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use
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 do not insist that interactive preview or smarter approach to guess > separator have to be implemented. Feel free to disregard my > comments. I am just not sure whether you are aware of limitations for > noticeable part of users. 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 would also like to hear from the maintainers on what the think about the issue and are they willing for an workaround? -- Utkarsh Singh http://utkarshsingh.xyz
Disabling paredit in export buffers?
I'm enabling paredit globally for all prog-modes, and it breaks HTML export. I'm trying to find a way to disable paredit in all Org export temporary buffers. Any suggestions? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [wip-cite-new] Adjust punctuation around citations
Hi, (strict inside before) corresponds to French typography. Regarding French typography. With this example: --- #+language: fr #+cite_export: test "This is a complete sentence."[cite:@key] "This is an incomplete sentence" [cite:@key]. "This is an incomplete sentence". [cite:@key] This is a complete sentence. [cite:@key] This is an incomplete sentence [cite:@key]. I'm getting: "This is a complete sentence[1]." "This is an incomplete sentence[2]" . "This is an incomplete sentence"[3]. This is a complete sentence[4]. This is an incomplete sentence[5]. 1, 3, 4, 5 look ok. 2 is a bit odd. - there's the spurios space before the period. - I think in that case the footnote mark should be just before the period, i.e. after the quotation mark. Basically like example 3. I think the textbook rule regarding French typography is: Place the footnote mark just before the final punctuation. Punctuation is placed inside quotation marks if we have a full quotation, otherwise outside. (OTOH, that seems to be a textbook rule. As I've said, I haven't seen that in real books.) I don't know if that is feasible with the current parameters. Denis
Re: [wip-cite-new] Adjust punctuation around citations
On Fri, May 14, 2021 at 4:44 AM Denis Maier wrote: > These things are not only language dependent, but depend also on the > chosen citation style. E.g. with in-text styles you'll have (outside > outside before) in German, and American typography, in French likely as > well. > So, perhaps another setting: > #+type-of-citation-style: in-text > #+type-of-citation-style: note Shouldn't in general this be up to the export processor? I wouldn't expect to have to set this if I'm using citeproc-org or biblatex. Bruce
Re: [wip-cite-new] Adjust punctuation around citations
On Fri, May 14, 2021 at 6:26 AM Nicolas Goaziou wrote: > > Hello, > > "Bruce D'Arcus" writes: > > > But I get this error when I run the export to test. > > > > org-export-as: Wrong number of arguments: # > org-macro-initialize-templates>, 1 > > This looks like an unrelated error. Just confirming this was in fact the case, and I now have it working. It seems to work as expected from my perspective. Bruce
Re: The fate of ditaa.jar (9.4.5.)
> Sent: Friday, May 14, 2021 at 11:23 PM > From: "Arthur Miller" > To: "Christopher Dimech" > Cc: "Dr. Arne Babenhauserheide" , "Jarmo Hurri" > , emacs-orgmode@gnu.org > Subject: Re: The fate of ditaa.jar (9.4.5.) > > Christopher Dimech writes: > > >> Sent: Friday, May 14, 2021 at 5:30 PM > >> From: "Dr. Arne Babenhauserheide" > >> To: "Arthur Miller" > >> Cc: "Jarmo Hurri" , emacs-orgmode@gnu.org > >> Subject: Re: The fate of ditaa.jar (9.4.5.) > >> > >> > >> Arthur Miller writes: > >> > >> > Exactly, so it is enough to just download a single file and point your > >> > org to it with one `setq' in your init file. So it does not need a > >> > pacakge managmenet on os level. > >> > >> Package management is how users should install software. Otherwise you > >> quickly reach the point where they blindly curl and run untrusted > >> shell-scripts from shady websites. > > > > I agree with the assessment regarding shady websites. > > > >> > However, Org could also simply say: use another distro that has ditaa in > >> > it's repository, such as Arch Linuz (in AUR). > >> > >> That would be openly hostile. > > No is not. There are so many distributions that are half-done, > unmaintained, etc. By the way, if your distro does not have a package > for ditaa, then you might maybe consider doing a community service and > provide a package script for your distro? I guess your distro have some > way for users to contribute a package? > > > If there exists the serious problem of not finding ditaa, then ditaa should > > be provided. > > For the rest there exist no problem and users can easily install from their > > Package Manager. > > > > You can't brush off a boyfriend and expect him to do you a favor using Free > > Software > > by telling him to use another distro. ;) > > > > :-) It is just the usual one: "you deserve a better one " That would be true if you got a crappy one. :)
Re: The fate of ditaa.jar (9.4.5.)
Christopher Dimech writes: >> Sent: Friday, May 14, 2021 at 5:30 PM >> From: "Dr. Arne Babenhauserheide" >> To: "Arthur Miller" >> Cc: "Jarmo Hurri" , emacs-orgmode@gnu.org >> Subject: Re: The fate of ditaa.jar (9.4.5.) >> >> >> Arthur Miller writes: >> >> > Exactly, so it is enough to just download a single file and point your >> > org to it with one `setq' in your init file. So it does not need a >> > pacakge managmenet on os level. >> >> Package management is how users should install software. Otherwise you >> quickly reach the point where they blindly curl and run untrusted >> shell-scripts from shady websites. > > I agree with the assessment regarding shady websites. > >> > However, Org could also simply say: use another distro that has ditaa in >> > it's repository, such as Arch Linuz (in AUR). >> >> That would be openly hostile. No is not. There are so many distributions that are half-done, unmaintained, etc. By the way, if your distro does not have a package for ditaa, then you might maybe consider doing a community service and provide a package script for your distro? I guess your distro have some way for users to contribute a package? > If there exists the serious problem of not finding ditaa, then ditaa should > be provided. > For the rest there exist no problem and users can easily install from their > Package Manager. > > You can't brush off a boyfriend and expect him to do you a favor using Free > Software > by telling him to use another distro. ;) > :-) It is just the usual one: "you deserve a better one "
Re: [wip-cite-new] Adjust punctuation around citations
Hello, "Bruce D'Arcus" writes: > But I get this error when I run the export to test. > > org-export-as: Wrong number of arguments: # org-macro-initialize-templates>, 1 This looks like an unrelated error. > > Not sure what I'm doing wrong; I: > > 1. pulled the branch > 2. ran make You probably need to reload Org (M-x org-reload) at this point. > 3. evaled your "test" code > 4. ran the export Regards, -- Nicolas Goaziou
Re: [wip-cite-new] Adjust punctuation around citations
Am 13.05.2021 um 23:33 schrieb Nicolas Goaziou: Hello, [...] RULE is a triplet of symbols (PUNCT POSITION RELATIVE): PUNCT is the desired location of the punctuation with regards to the quotation, if any. It may be `inside', `outside', or`strict', the latter meaning the punctuation should not be moved. POSITION is the desired location of the citation with regards to the quotation, if any. It may be `inside' or `outside'. RELATIVE is the relative position of the citation with regards to the closest punctuation. It may be `after' or `before'. For example, (inside outside after) corresponds to American typography; (strict outside after) corresponds to German typography; (strict inside before) corresponds to French typography. These things are not only language dependent, but depend also on the chosen citation style. E.g. with in-text styles you'll have (outside outside before) in German, and American typography, in French likely as well. So, perhaps another setting: #+type-of-citation-style: in-text #+type-of-citation-style: note And ideally this RULE should be configurable directly as well: #+punct-moving-rule: strict inside before INFO is the export state, as a property list. Optional argument PUNCT is a list of punctuation marks to be considered. When nil, it includes the following: \".\" \",\" \";\" \":\" \"!\" and \"?\". Here as well, it should be possible to configure these on a user level. Something like: #+moved-punctuation: ,.?! WDYT? Denis
Re: [wip-cite-new] Adjust punctuation around citations
Am 14.05.2021 um 01:21 schrieb Bruce D'Arcus: On Thu, May 13, 2021 at 5:33 PM Nicolas Goaziou wrote: WDYT? Looks really good; thanks for this! But I get this error when I run the export to test. org-export-as: Wrong number of arguments: #, 1 Not sure what I'm doing wrong; I: 1. pulled the branch 2. ran make 3. evaled your "test" code 4. ran the export Exactly, what I was doing. It works without problems here. Denis
