org-agenda-move-date-from-past-immediately-to-today could work for non-days
org-agenda-move-date-from-past-immediately-to-today moves a ts immediately to today in agenda, but only if you do org-agenda-do-date-later by one day. if you instead do it by 7 days or so, it will check and not do the feature. i keep getting surprised by this, so i thought perhaps newcomers would be too. do you think it makes sense to drop that check and make the variable work consistently for all time periods? imo that would be the least surprising and most useful behavior. the drawbck of not dong so is that you take past scheduled, for example, and move them by weeks into the future, only to find out later that you moved them into the past. but perhaps others have different sensibilities and there is some reason for the check. -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [wip-cite-new] Adjust punctuation around citations
Hello,
"Bruce D'Arcus" writes:
> On Sun, Jun 20, 2021 at 3:41 AM Nicolas Goaziou
> wrote:
>> As another, imperfect, workaround, I submit the following idea for
>> consideration:
>>
>> "A quotation ending without punctuation" [cite: @hoel-71-whole].
>> "A quotation ending with a period"[cite: @hoel-71-whole].
>>
>> IOW, the presence or absence of a space before the citation determines,
>> according to a note rule, if the punctuation should go inside or outside
>> the quotation. When processing non-note citations, we just need to
>> ensure there is at least a space after the previous element, which is
>> less "dangerous" than removing punctuation.
>>
>> I find it a bit too subtle, and so error-prone, but so is punctuation
>> anyway.
>>
>> WDYT?
>
> Just to confirm, Nicolas, your proposal would basically say the second
> example would override the default punctuation-moving behavior for the
> locale?
No, this behaviour is still customizable. For example,
`org-cite-note-rules' would contain the following entry:
("fr" adaptive same before)
where `adaptive' means the proposal above.
OTOH, "en-us" would still be
("en-us" inside outside after)
where the space does not matter since the punctuation always goes
inside.
> And for an in-text/author-date style, what would the output be with
> that example?
>
> I, someone who may have an "en-US" bias you could say, would expect:
>
> "A quotation ending with a period" (Hoel, 1971).
>
> As in, the in-quote period would be dropped regardless, and therefore
> a space would also need to be added.
In any non-note situation, we just make sure the citation is preceded by
a space, so the example would be equivalent to
"A quotation ending without punctuation" [cite: @hoel-71-whole].
"A quotation ending with a period" [cite: @hoel-71-whole].
without moving punctuation.
Does that make sense?
Regards,
--
Nicolas Goaziou
Re: [wip-cite-new] Adjust punctuation around citations
On Sun, Jun 20, 2021 at 3:41 AM Nicolas Goaziou wrote: ... > > The example you are highlighlighting here was why I was earlier > > suggesting for a rule that would allow something like this input: > > > > "A quotation ending with a period." [cite: @hoel-71-whole]. > > > > ... where the second would be dropped, hence getting the expected output. > > This is interesting, but we might get false positives, as in the > following (far-fetched) example > > … the so-called "foobar". [cite/text: See @hoel-71-whole p. 42]. > > which bites us because we need to process even non-note citations to > remove the spurious punctuation while ignoring the necessity of a given > punctuation character. Yeah, I wasn't sure of the details. > As another, imperfect, workaround, I submit the following idea for > consideration: > > "A quotation ending without punctuation" [cite: @hoel-71-whole]. > "A quotation ending with a period"[cite: @hoel-71-whole]. > > IOW, the presence or absence of a space before the citation determines, > according to a note rule, if the punctuation should go inside or outside > the quotation. When processing non-note citations, we just need to > ensure there is at least a space after the previous element, which is > less "dangerous" than removing punctuation. > > I find it a bit too subtle, and so error-prone, but so is punctuation > anyway. > > WDYT? Just to confirm, Nicolas, your proposal would basically say the second example would override the default punctuation-moving behavior for the locale? And for an in-text/author-date style, what would the output be with that example? I, someone who may have an "en-US" bias you could say, would expect: "A quotation ending with a period" (Hoel, 1971). As in, the in-quote period would be dropped regardless, and therefore a space would also need to be added. Is that right Denis? It wouldn't make sense to do any of these; right? "A quotation ending with a period." (Hoel, 1971). "A quotation ending with a period." (Hoel, 1971) "A quotation ending with a period"(Hoel, 1971). etc. Bruce
Re: [PATCH] Fix regression in org-get-time-of-day introduced in aba1f2066
Hello, Ihor Radchenko writes: > The new version of org-get-time-of-day errors on empty string argument. > The attached patch is fixing this. Thanks. I applied a slightly different fix. Regards, -- Nicolas Goaziou
Re: Failure to resolve internal links on ox-html export?
On Fri, Jun 18, 2021 at 6:22 PM Tim Cross wrote: > > Tim Visher writes: > > > Hi Juan Manuel, > > > > On Fri, Jun 11, 2021 at 2:31 PM Juan Manuel Macías < > maciasch...@posteo.net> wrote: > > > > Try setting this variable to non-nil: > > > > (setq org-export-with-broken-links t) > > > > Thanks for the tip here! This is definitely close to what I want. I > think I'm going to need to code up something additional though in that none > of the > > default options (mark or ignore) are really the behavior that I want. > > > > - mark: I don't like the way the text comes out here. I don't want to > have BROKEN LINK in the exported text at all. > > - ignore: I don't like how the text of the link simply disappears in > this case. > > > > What I really want is something that keeps the link text but drops the > link, essentially converting it into plain text (or stylized text if the > link text is in > > markup). > > > > I'll have to play around with how to do that. > > Although I've never used them, I think export filters sound like they > might be what you want. Have a look at the Advanced Export configuration > section of the manual and how to define export filters. You should be > able to define an org-export-filter-link-function that will tranform > links into just the title text from the original link. > Thanks, Tim! I'll check them out. I hadn't heard of them before.
Re: Remove all Org metadata with header argument `:comments org'
Juan Manuel Macías writes: > I am writing an *.el file from an *.org file (and then I run > org-babel-tangle). With the header argument `:comments org' not only the > text in my org file is converted to comments (my desired goal) but also > the drawers, keywords and other Org metadata. Since I don't see that all > that stuff is necessary in a source file, wouldn't it be better to get > rid of it during the tangle process, leaving only pure content as > comment strings? Maybe converting the Org file content to plain text > with ox-ascii, or something like that? > > What do you think? You can customise org-babel-process-comment-text to something like (lambda (string) (org-export-string-as string 'ascii t)). Untested though. Best, Ihor
Re: prettify-symbols-mode in org agenda?
William Xu writes:
> Thanks. At least not something weird in my emacs config. :)
>
> I think your patch is ready to be merged into orgMode. Hopefully it can be
> merged soon.
I believe that I managed to fix the problem you observe, though I do not
understand how. Can you test the attached updated patch?
Best,
Ihor
>From 6ce497a4af2da6a7c144c5f470679d154af2db0f Mon Sep 17 00:00:00 2001
Message-Id: <6ce497a4af2da6a7c144c5f470679d154af2db0f.1624188342.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Tue, 4 May 2021 20:33:10 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda
* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width. The old code used manual
parsing of text properties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'. The visibility settings of current buffer
are taken into account.
(org--string-from-props): Removed. It was only used by old
`org-string-width' code.
(org-buffer-substring-fontified): New function. Like
`buffer-substring', but make sure that the substring is fontified.
(org-looking-at-fontified): New function. Like `looking-at', but make
sure that the match is fontified.
* lisp/org.el (org-get-heading): Make sure that heading is fontified.
(org--get-local-tags, org-get-tags, org-scan-tags): Add optional
argument `fontified'. When non-nil, the returned tags are fontified.
* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled,
org-agenda-fix-displayed-tags, org-search-view, org-agenda-get-todos,
org-agenda-get-timestamps, org-agenda-get-sexps,
org-agenda-get-deadlines, org-agenda-get-progress,
org-agenda-get-blocks, org-tags-view, org-agenda-list, org-todo-list,
org-agenda-highlight-todo): Make sure that fontification is the same
with original Org buffers. All the buffer-substring and match-data
queries are changed to ensure that region of interest is fontified.
Also, preserve composition properties, used i.e. by
`prettify-symbols-mode'. The composition is usually set to be removed
on text change, so we do the changes inside
`with-silent-modifications'.
(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.
Preserve fontification and composition of headlines and tags in
agenda. If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.
In addition, tags alignment is now done pixel-wise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers. The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
---
lisp/org-agenda.el | 145 +++--
lisp/org-macs.el | 134 +
lisp/org.el| 36 +++
3 files changed, 181 insertions(+), 134 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index cbae3c022..071ee24f4 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3984,7 +3984,7 @@ (defun org-agenda-finalize ()
(put-text-property (point-at-bol) (point-at-eol)
'tags
(org-with-point-at mrk
- (org-get-tags
+ (org-get-tags nil nil t
(setq org-agenda-represented-tags nil
org-agenda-represented-categories nil)
(when org-agenda-top-headline-filter
@@ -,9 +,12 @@ (defun org-agenda-list ( arg start-day span with-hour)
(put-text-property s (1- (point)) 'org-today t))
(setq rtnall
(org-agenda-add-time-grid-maybe rtnall ndays todayp))
- (when rtnall (insert ;; all entries
- (org-agenda-finalize-entries rtnall 'agenda)
- "\n"))
+ (with-silent-modifications
+;; Composition property in entries may be self-destructed
+;; on change. Suppress the self-destruction.
+ (when rtnall (insert ;; all entries
+ (org-agenda-finalize-entries rtnall 'agenda)
+ "\n")))
(put-text-property s (1- (point)) 'day d)
(put-text-property s (1- (point)) 'org-day-cnt day-cnt)))
(when (and org-agenda-clockreport-mode clocktable-start)
@@ -4778,10 +4781,11 @@ (defun org-search-view ( todo-only string edit-at)
(and (eq org-agenda-show-inherited-tags t)
(or (eq org-agenda-use-tag-inheritance t)
(memq 'todo org-agenda-use-tag-inheritance
- tags (org-get-tags nil (not inherited-tags))
+ tags (org-get-tags
+nil (not inherited-tags) t)
txt (org-agenda-format-item
""
- (buffer-substring-no-properties
+ (org-buffer-substring-fontified
beg1 (point-at-eol))
level category tags t))
(org-add-props txt props
@@ -4815,8 +4819,11 @@ (defun
Re: org-collector.el does not deal with inherited properties well
Found the answer here: https://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg00292.html Sorry for writing before looking through the archives carefully. Best wishes for everyone. Vikas On Sun, 20 Jun 2021 at 16:26, Vikas Rawal wrote: > Hello, > > org-collector.el seems to fill "0" for properties that are inherited just > as it does for properties that are not defined for a particular headline > (for which also, 0 is poor choice; nil would have been better). This should > not be the correct behaviour. Or is it intentional, and I am missing > something? > > Thanks and best wishes, > > Vikas > > Org-mode version: 9.4.5 (9.4.5-29-gc43041-elpaplus) > >
org-collector.el does not deal with inherited properties well
Hello, org-collector.el seems to fill "0" for properties that are inherited just as it does for properties that are not defined for a particular headline (for which also, 0 is poor choice; nil would have been better). This should not be the correct behaviour. Or is it intentional, and I am missing something? Thanks and best wishes, Vikas Org-mode version: 9.4.5 (9.4.5-29-gc43041-elpaplus)
[PATCH] Fix regression in org-get-time-of-day introduced in aba1f2066
The new version of org-get-time-of-day errors on empty string argument. The attached patch is fixing this. Best, Ihor >From b615265881bdbb65f9a99d9f076424cb2233b250 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sun, 20 Jun 2021 17:15:34 +0800 Subject: [PATCH] Fix regression in org-get-time-of-day introduced in aba1f2066 * lisp/org-agenda.el (org-get-time-of-day): Do not check 'face property when S argument is an empty string. The old version of the code would throw error on (get-text-property 1 'face s). --- lisp/org-agenda.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index a6bc8bcf0..f9077f0c8 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -6995,7 +6995,8 @@ (defun org-get-time-of-day (s string) (group-n 3 (or "am" "pm"))) word-end))) (save-match-data - (when (and (not (eq 'org-link (get-text-property 1 'face s))) + (when (and (not (string-empty-p s)) + (not (eq 'org-link (get-text-property 1 'face s))) (string-match time-regexp s)) (let ((hours (let* ((ampm (and (match-end 3) (downcase (match-string 3 s -- 2.31.1
Re: [wip-cite-new] Adjust punctuation around citations
Hello, "Bruce D'Arcus" writes: > On Mon, Jun 14, 2021 at 7:45 AM Denis Maier wrote: >> * Note style input (=semantically strict input) >> >> "A quotation ending with a period." [cite: @hoel-71-whole] >> >> "A quotation ending without punctuation". [cite: @hoel-71-whole] >> >> As the input preserves the location of punctuation in the original >> material, I'd say it should be much easier to deal with this. We >> don't have to add information which isn't in the input, but rather >> we'll just have to move any punctuation to after the citation >> object. Maybe I'm missing something, but to me this looks like >> a much simpler operation than going in the opposite direction. This cannot be. We don't know anything about the cite after the quotation. A bare cite could be starting out a new sentence: "A quotation ending with a period." [cite: @hoel-71-whole] pretends… OTOH, we know perfectly when a citation is meant to become a footnote (at least in basic and csl processors). And we know — almost, as you demonstrated — where to put that footnote. Moreover, I think the syntax you propose has another drawback: it doesn't correspond to any desired output (note or something else). As this looks artificial, I fear it might hinder readability of the Org document. ... period." [cite:@doe21] [cite/text:@doe21] pretends… >> Maybe we should stop talking about author date vs note style input, but >> rather about strict vs. non-strict input. > > It's definitely not author-date vs note. I see it as in-text citations > vs note citations. As in, the former applies to other styles beyond > author-date. I think the current patch is purely about note citations. I mentioned "author-date" in a docstring just because I didn't know how to express it otherwise. So, in a way, I agree it can be considered as in-text citations vs note citations, indeed. > The example you are highlighlighting here was why I was earlier > suggesting for a rule that would allow something like this input: > > "A quotation ending with a period." [cite: @hoel-71-whole]. > > ... where the second would be dropped, hence getting the expected output. This is interesting, but we might get false positives, as in the following (far-fetched) example … the so-called "foobar". [cite/text: See @hoel-71-whole p. 42]. which bites us because we need to process even non-note citations to remove the spurious punctuation while ignoring the necessity of a given punctuation character. As another, imperfect, workaround, I submit the following idea for consideration: "A quotation ending without punctuation" [cite: @hoel-71-whole]. "A quotation ending with a period"[cite: @hoel-71-whole]. IOW, the presence or absence of a space before the citation determines, according to a note rule, if the punctuation should go inside or outside the quotation. When processing non-note citations, we just need to ensure there is at least a space after the previous element, which is less "dangerous" than removing punctuation. I find it a bit too subtle, and so error-prone, but so is punctuation anyway. WDYT? Regards, -- Nicolas Goaziou
