Re: [BUG] org-agenda-later sometimes creates a void display [9.7.11 (release_9.7.11 @ /usr/local/share/emacs/31.0.50/lisp/org/)]

2025-01-05 Thread Ihor Radchenko
Michael Heerdegen  writes:

>> May you please post detailed steps to recreate the issue starting from
>> emacs -Q? See https://orgmode.org/manual/Feedback.html#Feedback
>
> I really just hit C-c a a M-> f as I said.  C-c a is `org-agenda',
> the following "a" means "current week or day" as usual.

That's what I tried myself.
I do not see any problem.
Please, do try to follow
https://orgmode.org/manual/Feedback.html#Feedback and provide detailed
steps showing how to reproduce the problem you are seeing without your
personal config.

> I have a guess what the problem is. ...

First, we need to establish whether the problem is with Org mode itself
or it is a combination of your config and Org mode.

For now, I simply do not know what is that problem you are
experiencing. Because I cannot see it locally on my side.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [BUG] org-agenda-later sometimes creates a void display [9.7.11 (release_9.7.11 @ /usr/local/share/emacs/31.0.50/lisp/org/)]

2025-01-05 Thread Michael Heerdegen
Ihor Radchenko  writes:

> I am unable to reproduce.
> May you please post detailed steps to recreate the issue starting from
> emacs -Q? See https://orgmode.org/manual/Feedback.html#Feedback

I really just hit C-c a a M-> f as I said.  C-c a is `org-agenda',
the following "a" means "current week or day" as usual.

I have a guess what the problem is.  When you look at the implementation
of `org-agenda-later': at the end we are setting window-start to the
former value of (window-start), which we remembered.

In my case the current day (aka "today") contains much more entries than
any other day.  When I hit f with point at point-max of the current wekk
agenda, the next, shorter week agenda view will be displayed with
window-start forced to position larger than the new `point-max'.

Are you maybe able to provoke a similar situation?


Thx,

Michael.



Re: [BUG] org-agenda-later sometimes creates a void display [9.7.11 (release_9.7.11 @ /usr/local/share/emacs/31.0.50/lisp/org/)]

2025-01-05 Thread Michael Heerdegen
Ihor Radchenko  writes:

> That's what I tried myself.
> I do not see any problem.
> Please, do try to follow
> https://orgmode.org/manual/Feedback.html#Feedback and provide detailed
> steps showing how to reproduce the problem you are seeing without your
> personal config.

This will be a lot of work.  I really hope we can avoid it.

> > I have a guess what the problem is. ...
>
> First, we need to establish whether the problem is with Org mode
> itself or it is a combination of your config and Org mode.
>
> For now, I simply do not know what is that problem you are
> experiencing. Because I cannot see it locally on my side.

What I am seeing is what one sees for any window showing a sufficiently
large buffer after evaluating something like

  (setf (window-start) (+ 10 (point-max)))

and I have clearly shown that exactly that is what the code potentially
does.  I really don't want to spend half an hour to create a recipe
until you at least think about what I said.  I'm a big fan of recipes,
really, but in this case I would have to prepare a complete fake org
file with dozens of fake entries corresponding to suitable finely
composed dates ... this will take unnecessarily long, can't you please
just think about what I said?  Five minutes?  Please.

Does restoring the result of (window-start) from the old agenda view, as
a plain number(!), always give good results in your case?  What happens
for you in the scenario I described, when (window-start) of the previous
view is larger than (point-max) of the new view?  Emacs can't do
anything but to show nothing when the end of the buffer lies "before"
window-start.  No?


Michael.



org agenda bulk todo with note

2025-01-05 Thread pinmacs

Given:

1. A tendency of massively marking all items as schedule [1]
2. Some of that items should be done on daily basis (I generate them 
with a daily template and the power of org-capture)
3. Life happens and some of them are accumulated, for my last case, that 
was 29 entries pending to be processed


Action:

I procedure with a batch action for that 29 entries (imagine here a 
batch script), and now that it is done, then I need to clear it up from 
my org-agenda


org-agenda-bulk-action  [2] does not serve me because it marks the TODO 
thing without a note, and it's not possible to add a note with the 
prefix. Going to offtopic, I also discovered that does not respect the 
enforce-todo-dependencies [3], ignores if that entries have child todo 
items.


I tried to create a org-agenda-bulk-custom-functions but I failed 
because I wanted a chosen state and a shared note for all the bulk items 
and the way that functions work cannot be done.


But the bulk items are in a variable (nice), 
org-agenda-bulk-marked-entries, and you can traverse it with a generic 
function, so I did it. It took me, unexpectetly, 1h30m to get it working 
(and I could not find other stuff around), so I am sharing what I have 
done so other people can benefit, and by the way, I would like to know 
what do you think of that approach and if you have ideas to improve it.


See it attached in file org-agenda-bulk-todo-with-note.el

With that script I added a note of resolution of that items saying that 
it was resolved through my task with CUSTOM_ID/ID X (like when you close 
multiple issues in a ticketing software) [4]


A healthy 2025 for you guys,
pinmacs


[1] offtopic, but I am sharing it anyway

#+begin_src emacs-lisp
(defun my/org-heading-insert-scheduled ()
  (if (or
   (and (string-match-p my/diary-file (buffer-name))
    (= (org-current-level) 4))
   (and (string-match-p my/board-file (buffer-name))
    (= (org-current-level) 4))
   (and (string-match-p "projects.org" (buffer-name))
    ;; projects are 4-level (tasks start at 6-level, we don't 
care on its children)

    (> (org-current-level) 5))
   (and (string-match-p "projects-candidates.org" (buffer-name))
    ;; projects are 4-level (tasks start at 3-level, we don't 
care on its children)

    (> (org-current-level) 3))
   )
  (save-excursion
    ;; src 
https://emacs.stackexchange.com/questions/72147/org-mode-adding-creation-date-property-upon-heading-creation

    ;;(org-back-to-heading)
    (org-schedule nil (format-time-string "[%Y-%m-%d %a]" nil)

(add-hook 'org-insert-heading-hook 'my/org-heading-insert-scheduled 'append)
#+end_src

[2] https://orgmode.org/manual/Agenda-Commands.html

[3] (setq org-enforce-todo-dependencies t) 
https://orgmode.org/manual/TODO-dependencies.html


[4] all that state changes are stored, in my case, in (setq 
org-log-state-notes-into-drawer "TRACE");; this should be run with M-x
;; all selected bulk entries should have same todo keywords
(defun my/bulk-todo-with-note ()
  "For each marked entry in the Org agenda, set the TODO state with a shared note,
and insert the same user-provided note for all items."
  (interactive)
  (unless org-agenda-bulk-marked-entries
(user-error "No entries are marked in the agenda"))
(let* ((buffer-todo-keywords (with-current-buffer (marker-buffer (car org-agenda-bulk-marked-entries)) org-todo-keywords-1))
   (chosen-state
;; not good when specific on a buffer
(org-icompleting-read "Choose new TODO state: " buffer-todo-keywords nil t))
   (shared-note (read-string "Enter note for all marked items: ")))
(dolist (marker org-agenda-bulk-marked-entries)
  (with-current-buffer (marker-buffer marker)
(goto-char marker)
(org-todo chosen-state)
(org-add-log-setup 'state chosen-state nil nil)
;; Insert the shared note and finalize it.
(org-add-log-note)
(insert shared-note)
(org-store-log-note)


Re: [BUG] org-agenda-later sometimes creates a void display [9.7.11 (release_9.7.11 @ /usr/local/share/emacs/31.0.50/lisp/org/)]

2025-01-05 Thread Ihor Radchenko
Michael Heerdegen  writes:

> especially after displaying the agenda when it didn't exist before, when
> I display it (`org-agenda'), switch to it and then move point to the end
> of the agenda buffer, and hit f (`org-agenda-later'), I see an purely
> void window.  I don't think I messed with agenda displaying, so others
> may be able to reproduce this issue.

I am unable to reproduce.
May you please post detailed steps to recreate the issue starting from
emacs -Q? See https://orgmode.org/manual/Feedback.html#Feedback

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

2025-01-05 Thread Lennart Jablonka

[replying to two messages]

Quoth onf:

On Sat Jan 4, 2025 at 7:37 AM CET, G. Branden Robinson wrote:

At 2025-01-04T01:23:02+0100, onf wrote:

[…]

> My impression of Plan 9's troff is that it's a poorly maintained
> descendant of DWB troff that's used only to format manpages.


It’s not only used to format man pages: It’s also used to format 
volume 2 of the manual; i.e., the papers in /sys/doc are formatted 
by troff.  The papers at the state of the fourth edition’s 
abandonment (2015) is at https://9p.io/sys/doc/index.html ; see, 
for example, the https://9p.io/sys/doc/troff.pdf linked thence.


Beside /sys/doc and /sys/man, the International Workshop on
Plan 9¹ accepts papers written in -ms.  And I know of at least one 
person who wrote some sort of thesis for a degree using troff on 
9front.  (Said thesis was on Plan 9.)


Troff on 9front is not used very much to format man pages not 
written for Plan 9.  It sometimes is, but not very often.  There 
was no need to import -mdoc yet, for example.



I wouldn't say _poorly_ maintained; its commit rate seems to match or
even exceed its defect rate.  This could illustrate (1) low adoption or
(2) adequacy for the (limited?) purposes to which people apply it. [...]


Which commit rate are you referring to? I thought the official sources
are at https://plan9.io/sources/plan9/sys/src/cmd/troff/ ... or maybe
you meant the 9front version?


Yes, the sources there are the last sources of Plan 9 as 
distributed by Bell Labs.  It was abandoned in 2015 and is now 
dead.  Beside that, there is the commit rate of plan9port and that 
of 9front.


I don’t care for plan9port.  I do care about 9front.

Per my understanding, troff on Plan 9 (and thus 9front and 
plan9port) is just bwk’s continuation of troff.  The Unix system 
would have been replaced by Plan 9 with bwk continuing developing 
troff like nothing happened, only now on Plan 9 instead of on v10.


Yes, there are few changes to troff on 9front.  I remember fixing 
a little defect.  If anything, it might get replaced by Neatroff 
at some point.


Quoth G. Branden Robinson:

I'd like to see an attempt at reconstructing DWB 3.4 from the existing
DWB 3.3 code base (made portable) and an old snapshot of Plan 9, maybe
circa 2000.  It'd be good to have a plausible exhibit of the end of the
line for AT&T Unix troff--what the body looked like at the murder scene.


You can find old versions of Plan 9 at the website of the 
“Plan 9 Foundation”: https://p9f.org/dl/index.html .  The troff 
sources are in /sys/src/cmd/troff.  I doubt they changed very much 
in the last 30 years.



> Poor, in general.  Where Courier bold-italic existed, it was
> sometimes called "CX".

I meant support for CB and CI, not CBI.


Also poor, outside of the horizon I previously articulated.  :(

System V Unix supported these names _only_ on the "aps" device
(Autologic APS-5).  Plan 9 doesn't.  DWB 3.3 doesn't.

The "aps" device on Solaris 10 troff supports CB but not CI.


Plan 9 does have those names.  It has all of C, CO, and CW for 
Courier and CI, CB, and CX for Courier-{Oblique,Bold,BoldOblique}.


¹ The website is at https://iwp9.org/ , the last proceedings at 
https://10e.iwp9.org/10iwp9proceedings.pdf .  The papers with the 
usual, traditional, ugly -ms extra half-inch at the right were set 
with troff.




Re: [PATCH] ob-tangle: Tangle BibTeX files with the standard .bib file extension

2025-01-05 Thread Rudolf Adamkovič
Ihor Radchenko  writes:

>> +(ert-deftest ob-tangle/bibtex ()
>> +  "Tangle BibTeX into a `.bib' file."
>
> I think that the test is not necessary here.
> We already test `org-babel-tangle-lang-exts' in
> `ob-tangle/collect-blocks', I think.
> Or do I miss something?

I wanted to make sure this behavior, specifically for BibTeX, will never
get "lost in translation", say when refactoring.  I noticed that other
files add to the `org-babel-tangle-lang-exts' list, so I figured that
this code may moved in the future, etc.  And we all know how that goes.
More generally, for the end-user, the correct BibTeX file extension is a
crucial requirement, not a cosmetic one, so I wrote a test to make sure
we will never-ever break it.

Rudy
-- 
"If you're thinking without writing, you only think you're thinking."
--- Leslie Lamport

Rudolf Adamkovič  [he/him]
http://adamkovic.org



Re: [PATCH] ob-tangle: Tangle BibTeX files with the standard .bib file extension

2025-01-05 Thread Ihor Radchenko
Rudolf Adamkovič  writes:

> I wanted to make sure this behavior, specifically for BibTeX, will never
> get "lost in translation", say when refactoring. ...

Ok.
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=405787dfbc

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



[PATCH] ob-tangle: Tangle BibTeX files with the standard .bib file extension

2025-01-05 Thread Rudolf Adamkovič
---
 etc/ORG-NEWS   |  7 +++
 lisp/ob-tangle.el  |  3 ++-
 testing/lisp/test-ob-tangle.el | 24 
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8f266c560..097550805 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -484,6 +484,13 @@ ignored by ~org-babel-tangle-collect-blocks~. Now, if it 
inherits a
 filename), a source block without =language= will get tangled to that
 file.
 
+*** BibTeX is tangled with the standard =.bib= file extension
+
+Previously, =bibtex= source blocks located in a file named =NAME.org=
+were tangled into a file named =NAME.bibtex=.  Now, they are tangled
+into a file named =FILE.bib=, using the standard extension =.bib=,
+matching the rest of the ecosystem, including BibTeX and LaTeX.
+
 * Version 9.7
 
 ** Important announcements and breaking changes
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 1f5de9250..38cad78ab 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -58,7 +58,8 @@
 
 (defcustom org-babel-tangle-lang-exts
   '(("emacs-lisp" . "el")
-("elisp" . "el"))
+("elisp" . "el")
+("bibtex" . "bib"))
   "Alist mapping languages to their file extensions.
 The key is the language name, the value is the string that should
 be inserted as the extension commonly used to identify files
diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index 6e95c4c91..4a197f76b 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -715,6 +715,30 @@ another block
(funcall count-blocks-in-target-files
 (org-babel-tangle-collect-blocks)
 
+(ert-deftest ob-tangle/bibtex ()
+  "Tangle BibTeX into a `.bib' file."
+  (let ((file (make-temp-file "org-tangle-" nil ".org"))
+(bib "@Misc{example,
+  author = {Richard Stallman and {contributors}},
+  title = {{GNU} {Emacs}},
+  publisher = {Free Software Foundation},
+  url = {https://www.emacs.org/},
+}"))
+(unwind-protect
+(with-current-buffer (find-file-noselect file)
+  (insert (format "#+begin_src bibtex :tangle yes
+%s
+#+end_src"
+  bib))
+  (org-babel-tangle)
+  (let ((bib-file (file-name-with-extension file "bib")))
+(should (file-exists-p bib-file))
+(should (string= (string-trim (org-file-contents bib-file))
+ bib
+  (delete-file file
+
+(delete-file file)
+
 (provide 'test-ob-tangle)
 
 ;;; test-ob-tangle.el ends here
-- 
2.47.1




Re: [BUG] Html making 'ltximg' directory in source folder, rather than out folder [9.7.11 (release_9.7.11 @ /home/pranshu/Documents/appsource/emacs/lisp/org/)]

2025-01-05 Thread Ihor Radchenko
Ihor Radchenko  writes:

>> When doing:
>> (org-export-to-file 'html "~/new/path/thing.html")
>> and the file option has the path "~/other/path/file.org", the 'ltximg'
>> directory is made in "~/other/path/", which is not intutive, or useful
>> behaviour.
>>
>>
>> (the option 'tex' is set to 'dvisvgm')
>
> Confirmed.
> Something like the attached patch should fix this.

Fixed, on main. Using a modified version of the patch with NEWS entry
and appropriate commit message.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d4a13e6a06

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [PATCH] ob-tangle: Tangle BibTeX files with the standard .bib file extension

2025-01-05 Thread Ihor Radchenko
Rudolf Adamkovič  writes:

> +*** BibTeX is tangled with the standard =.bib= file extension
> +
> +Previously, =bibtex= source blocks located in a file named =NAME.org=
> +were tangled into a file named =NAME.bibtex=.  Now, they are tangled
> +into a file named =FILE.bib=, using the standard extension =.bib=,
> +matching the rest of the ecosystem, including BibTeX and LaTeX.

Thanks!

> +(ert-deftest ob-tangle/bibtex ()
> +  "Tangle BibTeX into a `.bib' file."

I think that the test is not necessary here.
We already test `org-babel-tangle-lang-exts' in
`ob-tangle/collect-blocks', I think.
Or do I miss something?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 



Re: [BUG] Html making 'ltximg' directory in source folder, rather than out folder [9.7.11 (release_9.7.11 @ /home/pranshu/Documents/appsource/emacs/lisp/org/)]

2025-01-05 Thread General discussions about Org-mode.
Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>>> When doing:
>>> (org-export-to-file 'html "~/new/path/thing.html")
>>> and the file option has the path "~/other/path/file.org", the
>>> 'ltximg'
>>> directory is made in "~/other/path/", which is not intutive, or
>>> useful
>>> behaviour.
>>>
>>>
>>> (the option 'tex' is set to 'dvisvgm')
>>
>> Confirmed.
>> Something like the attached patch should fix this.
>
> Fixed, on main. Using a modified version of the patch with NEWS entry
> and appropriate commit message.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d4a13e6a06

Thanks a lot

-- 
Pranshu Sharma