Question about relative paths generated by Org

2024-08-09 Thread Wiktor Kwapisiewicz

Hello,

I'm using Org-mode's clock feature and it's really great!

One thing bothers me: the links generated by the ":link t" option on the 
clocktable [0] are absolute [1] and it causes problems when using the 
same file on two different machines:


#+BEGIN: clocktable :scope file :maxlevel 3 :link t
#+CAPTION: Clock summary at [2024-08-08 Thu 11:02]
| Headline | Time   |  |
|--++--|
| *Total time* | *4:32* |  |
|--++--|
| 
[[file:/home/runner/work/org-test/org-test/README.org::Project][Project]] 
 | 4:32   |  |
| \_  [[file:/home/runner/work/org-test/org-test/README.org::Task 
1][Task 1]]   || 3:30 |
| \_  [[file:/home/runner/work/org-test/org-test/README.org::Task 
3][Task 3]]   || 1:02 |

#+END:

I've tried adjusting that with `(setq org-link-file-path-type 
'relative)` but it doesn't seem to have any effect on the automatically 
generated clocktable (I ran emacs -nw README.org so the PWD should be 
correct).


Is there anything I could try to make the links relative so that they 
look like this: [[file:README.org::Task 3][Task 3]] ?


I've made a repository for reproducing this case: 
https://github.com/wiktor-k/org-test and I'm using emacs 29.4 and org 
9.6.15.


Thank you for your time and help!

Kind regards,
Wiktor

[0]: https://github.com/wiktor-k/org-test/blob/main/README.org?plain=1#L39

[1]: https://github.com/wiktor-k/org-test/blob/main/README.org?plain=1#L46



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-09 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> I think, text/org may be added as well (without removing of
>>> text/x-org).
>>
>> Shall we consider this this after we find a way for these low-preference
>> mappings to be useful?
>
> If you mean "negotiate... to override "applicaion/vnd.lotus-organizer"
> with "text/org"", I have no objections.
>
>>> Perhaps a worg page may be created to clarify current state of media
>>> type for org files. The question is what is the appropriate directory.
>>
>> I agree that it would be good to track this information in one place so
>> we don't repeat ourselves ;)
>
> We can put such a page alongside /org-syntax.org, maybe even linked from
> there. Feel free to create such a page.

Would the following patch be appropriate?

Thanks!

Joseph

>From c898ba723faeb67929f52728c67e2b8858f99738 Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Fri, 9 Aug 2024 05:55:52 -0700
Subject: [PATCH] org-media-type.org: New file; Describe state of NodeJS MIME
 database

---
 org-media-type.org | 37 +
 1 file changed, 37 insertions(+)
 create mode 100644 org-media-type.org

diff --git a/org-media-type.org b/org-media-type.org
new file mode 100644
index ..f5d69b7c
--- /dev/null
+++ b/org-media-type.org
@@ -0,0 +1,37 @@
+#+title: Org Media Type
+#+author: Joseph Turner
+#+options: toc:t ':t author:nil
+#+language: en
+#+category: worg
+#+bind: sentence-end-double-space t
+#+html_link_up:index.html
+#+html_link_home:  https://orgmode.org/worg/
+
+#+begin_comment
+This file is released by its authors and contributors under the GNU
+Free Documentation license v1.3 or later, code examples are released
+under the GNU General Public License v3 or later.
+#+end_comment
+
+* Introduction
+
+This page tracks information about the ~.org~ extension media type.
+
+Based on [[https://yhetil.org/orgmode/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com/][this thread on the Org mode mailing list]], the consensus is
+that the ~.org~ file extension should map to the ~text/org~ MIME type.
+
+Until the [[file:org-syntax.org][Org syntax spec]] is complete and a proposal submitted to and
+approved by IANA, we can ask downstream MIME libraries to override
+~applicaion/vnd.lotus-organizer~ with ~text/org~.
+
+* Downstream MIME Libraries
+
+** jshttp/mime-db - NodeJS
+
+[[https://github.com/jshttp/mime-db][jshttp/mime-db]] is the de facto standard MIME database for NodeJS.
+[[https://github.com/jshttp/mime-db/commit/5797174e5434a8d2978d9fdc13ec6a47ba20a02f][This commit]] adds a mapping from ~.org~ to ~text/x-org~, but the two
+popular NodeJS utilities for getting a MIME type from a file
+extension, [[https://github.com/jshttp/mime-types][jshttp/mime-types]] and [[https://github.com/broofa/mime][broofa/mime]], return
+~applicaion/vnd.lotus-organizer~.  Both libraries return only the
+highest preference media type, and IANA-sourced media types are
+preferred over other types.
-- 
2.41.0



org-mode-flyspell-verify: Why skip checking the LOGBOOK?

2024-08-09 Thread Morgan Willcock
With org-log-into-drawer set to t any notes that are taken with
org-add-note go into a LOGBOOK drawer, but this also removes the
spell-checking provided by Flyspell.

It seems intentional to prevent checking the LOGBOOK (or equivalent)
when the value of org-log-into-drawer is non-nil:

  ;; Ignore checks in LOGBOOK (or equivalent) drawer.
  ((let ((log (org-log-into-drawer)))
 (and log
  (let ((drawer (org-element-lineage element 'drawer)))
(and drawer
 (org-string-equal-ignore-case
  log (org-element-property :drawer-name drawer))
   nil)

...but why should the location of the note matter to the spell-checker?

Is there any way to re-enable spell-checking of the notes without adding
advice to org-mode-flyspell-verify to hijack the result?

Thanks,
Morgan

-- 
Morgan Willcock



Re: [FEATURE] On line-numbers inside Org Babel Source Blocks.

2024-08-09 Thread Divya
On 7 August 2024 13:59:16 GMT, di...@subvertising.org wrote:
>Hello, Org Mode!
>
>I've been using Org Mode for literate programming purposes, and would like to 
>have line-numbers within `src` blocks. I am able to export the Org buffer and 
>get the line-numbers, but I am unable to do the same with regards to just in 
>Org buffers. I am aware of `org-edit-special`, but I would rather appreciate 
>if I can just look at a piece of code and know how long it is. I believe a 
>header argument can be useful in toggling this.
>
>Since the source blocks can already implement syntax highlighting, font and 
>other means of interacting with displaying Babel source blocks, theoretically 
>this shouldn't be that difficult to implement? I'd be glad to help 
>implementing this feature, if I can be slightly guided on where to refer to 
>look for in the codebase.
>
>Regards,
>
>Divya Ranjan
>

Any suggestions, Ihor?