Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

[Derek Chen-Becker]

Thanks for the help on this! I've reworked the changes into two patches
(one for the README and one for tangle) and I think I've covered your
concerns. I also added a unit test for the org-base-buffer-file-name
function to cover the miss on provided buffers. Please let me know if you
have any questions.

Thanks,

Derek


On Mon, Jan 13, 2025 at 10:21 AM Ihor Radchenko  wrote:

> Derek Chen-Becker  writes:
>
> >> Also, what about other places in the code that use `buffer-file-name'?
> >> We may want to use the new function there as well.
> >
> > Definitely. There are hundreds of places in the code where the same
> pattern
> > applies. Per our previous discussion in the thread, though, I thought it
> > would be better to start small and incrementally work through them. If
> you
> > want me to include more changes,I'm going to need to help sorting all of
> > these out:
> >
> > ❯ rg -q --stats buffer-file-name
> > 185 matches
> > 182 matched lines
>
> It is ok to only limit the current patch to fixing the bug in question.
> We can continue with more changes later, after merging the more limited
> patch.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+


0002-ob-tangle-Ensure-proper-tangling-within-a-capture-bu.patch
Description: Binary data


0001-testing-README-Add-details-on-use-of-TEST_NO_AUTOCLE.patch
Description: Binary data

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/)]

[Michael Heerdegen]

Ihor Radchenko  writes:

> > One step back: What problem does this hack solve? [...]
>
> https://orgmode.org/list/87lfh2hk4k@gmail.com/

I asked rhetorically ;-)  But thanks, this is what I expected.

> > How about something like this?
> >
> >  - If point is at bob, we ensure that point is restored at bob - and
> >likewise for eob.
> >
> >  - When bob was visible in the prior view, we use window-start = 1
> >for the new view, too
> >
> >  - But when bob was not visible in the last view, we try to restore the
> >visible line number containing the window point, so that hitting f
> >will show the cursor at the same vertical position as in the last
> >view.  Or maybe better: restore the vertical position of the
> >beginning of the weekday point was in.
>
> I hope that my idea in the patch is good enough and that we do not need
> to go into redisplay complications.

These points would not mess with redisplay, just set window-start to
something different than now.


> -(set-window-start nil wstart)))
> +(set-window-start nil wstart 'noforce)))

Nice trick (or workaround), thanks.

Yes, this solves my problem indeed, and behaves quite ok.  Time will
show whether I like the behavior, but it's a definite improvement, so I
suggest we go with it for now.


Thanks for your help,

Michael.

Re: [ERROR] org-todo [C-c C-t] change task todo state raised error

[Ihor Radchenko]

stardiviner  writes:

> When I change a task from "TODO" to "DONE", or "DONE" to "TODO", or
> other todo keywords with [C-c C-t]. Org mode will raise bellowing error
> "*randomly*". (I can't reproduce it in stable.)
>
> #+begin_example
> Debugger entered--Lisp error: (args-out-of-range # 0
> 3092985)

Hard to suggest much without a reproducer.
The backtrace does not ring any bells.

Some shots in the dark:
- something about narrowing
- something about long lines in buffer
- if nothing works, can try to bisect Org (slowly and painfully)

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

Re: [PATCH] Fix ox-icalendar export of diary timestamps

[Ihor Radchenko]

Jack Kamm  writes:

> Unfortunately I found a case in the wild where this change caused a
> temporary problem in org-caldav:
> https://github.com/dengste/org-caldav/issues/315
> ...
> I attach a patch to do this, by adding an option `active-exclude-diary'
> for `org-icalendar-with-timestamps' and `org-export-with-timestamps'.

Sounds reasonable.

> +To export active timestamps only without diary timestamps, users can
> +set ~org-export-with-timestamps~ and ~org-icalendar-with-timestamps~
> +to ~active-exclude-diary~.

Maybe you can emphasize more that "without diary timestamp" is the old
behavior. We often use "old behavior" when guiding users how to revert
newly added features that do not want.

Otherwise, LGTM.

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

Re: [BUG] Cannot tangle src block in capture buffer [9.7.6]

[Ihor Radchenko]

Derek Chen-Becker  writes:

>> Also, what about other places in the code that use `buffer-file-name'?
>> We may want to use the new function there as well.
>
> Definitely. There are hundreds of places in the code where the same pattern
> applies. Per our previous discussion in the thread, though, I thought it
> would be better to start small and incrementally work through them. If you
> want me to include more changes,I'm going to need to help sorting all of
> these out:
>
> ❯ rg -q --stats buffer-file-name
> 185 matches
> 182 matched lines

It is ok to only limit the current patch to fixing the bug in question.
We can continue with more changes later, after merging the more limited patch.

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

Re: [PATCH] LSP support in org-src buffers

[Karthik Chikmagalur]

>> We are not in hurry. Any progress will be appreciated as long as there
>> is some.
>
> Unfortunately, this important patch is stuck.
> It would be nice is somebody revived the work on it.
> Anyone interested will do, not just people involved in this thread :)

After trying it for a while, my opinion is that this way of getting LSP
support is a hack and somewhat fragile.  This is why I haven't worked on
it since.  On the Eglot repo, they're considering adapting LSP's jupyter
notebook support to source blocks in Org:

https://github.com/joaotavora/eglot/issues/523#issuecomment-2542536622

There are some limitations:

- This requires some work on the Eglot side, specifically a new minor
  mode that sets some Eglot state variables.

- I don't think many language servers include notebook support.

But the support might be better than the background-tangling approach
used by proposal in this thread.

Karthik

Re: [BUG] Edge case for preview image alignment

[Karthik Chikmagalur]

>> Currently the value of `org-image-align' or of the `:align' attr_*
>> keyword is respected when previewing images in the following two
>> situations:
>>
>> [...]
>>
>
> These two situations are the same - standalone image in a paragraph.
> The second example is _two_ paragraphs. (affiliated keywords force-start
> a new paragraph)

Thanks for the clarification.

> Sure. Because it works for both inline and standalone images, unlike
> org-image-align:
>
> org-image-align is a customizable variable defined in ol.el.
> ...
> Documentation
> How to align images previewed using org-link-preview-region.
> 
> Only stand-alone image links are affected by this setting.  These
> are links without surrounding text.

I'm aware that only standalone image links are supported -- my question
was if we should change this behavior.

>> Should we support image alignment in case 3?
>>
>> The only situation in which I can see this being undesirable is when you
>> have hard-wrapped/filled lines and the image link coincidentally ends up
>> on its own line.  In this case it doesn't make sense for the image
>> preview to respect `org-image-align'.  There might be other syntactical
>> reasons why supporting case 3 doesn't make sense, so I am asking here.
>
> Maybe. Or not.
>
> Alignment is intersecting its syntax with export.
> But export will only align truly standalone images.
> There will be no notion of "image in a line of its own in the middle of
> paragraph"

This is another factor I hadn't considered.

> Also, what would you do if there are multiple images like that or when
> the purpose of :align attribute is to align the whole paragraph?
>
> Consider something like
>
> # Align the whole paragraph
> #+attr_html: :align center
> Paragraph with inlined
> [[file:image.png]]
> image and
> [[file:image2.png]]
> another one.

In this case no alignment rule would be applied to the image.

I didn't realize that

Some text in a paragraph,
#+attr_org: :align center
[[file:/path/to/file]]
followed by more text

is considered two paragraphs, and that the affiliated keyword applies to
the second paragraph and not just the link at the start of the second
paragraph.  So my proposal isn't consistent.

Please close this bug/issue.

Karthik

The ob-R :results graphics file :dir "images" :file "plot.png" specified directory not working

[stardiviner]

This seems not working, I have following example:

In Org mode file "~/Org/Programming/R/test.org"

#+begin_src R :results graphics file :dir "images" :file "hist_rnorm.png"
x <- rnorm(100)
print(mean(x))
hist(x)
#+end_src

#+RESULTS[(2025-01-14 11:19:59) 2387108d2b01bf63b1eac4044a7430ea7ba87466]:
[[file:images/hist_rnorm.png]]

The generated plot image "images/hist_rnorm.png" is NOT in
"~/Org/Programming/R/images/hist_rnorm.png". It's in "~/Org/hist_rnorm.png".

My environment:
- Emacs version: GNU Emacs 31.0.50 (commit nil)
- Org mode version: 9.8-pre (using branch "main" latest commit "c2d57df0e")

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


On Tue, Aug 6, 2024 at 4:42 PM Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
> > I'd like to hear from ob-R/ob-julia users whether the current behavior
> > is something they rely on. If not, I'd prefer to follow the conventions
> > we introduce in the manual and suppress the ESS's directory prompt.
>
> The responses expressed no objections to the change.
> So, ob-R and ob-julia now obey the working directory conventions common
> for the rest of babel backends - use default-directory or :dir; no
> queries.
>
> Closed.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=62b88d613e
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Re: The ob-R :results graphics file :dir "images" :file "plot.png" specified directory not working

[stardiviner]

I tested using org-mode's `make repro` clean Emacs & org-mode environment
instance. It works fine. I double checked my Emacs init file about R
settings. Have not found suspicious config.
Here is my reproduce test.


[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


On Tue, Jan 14, 2025 at 1:10 PM stardiviner  wrote:

> This seems not working, I have following example:
>
> In Org mode file "~/Org/Programming/R/test.org"
>
> #+begin_src R :results graphics file :dir "images" :file "hist_rnorm.png"
> x <- rnorm(100)
> print(mean(x))
> hist(x)
> #+end_src
>
> #+RESULTS[(2025-01-14 11:19:59) 2387108d2b01bf63b1eac4044a7430ea7ba87466]:
> [[file:images/hist_rnorm.png]]
>
> The generated plot image "images/hist_rnorm.png" is NOT in
> "~/Org/Programming/R/images/hist_rnorm.png". It's in
> "~/Org/hist_rnorm.png".
>
> My environment:
> - Emacs version: GNU Emacs 31.0.50 (commit nil)
> - Org mode version: 9.8-pre (using branch "main" latest commit "c2d57df0e")
>
> [stardiviner] GPG key ID: 47C32433
> IRC(freeenode): stardiviner Twitter:  @numbchild
> Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
> Blog: http://stardiviner.github.io/
>
>
> On Tue, Aug 6, 2024 at 4:42 PM Ihor Radchenko  wrote:
>
>> Ihor Radchenko  writes:
>>
>> > I'd like to hear from ob-R/ob-julia users whether the current behavior
>> > is something they rely on. If not, I'd prefer to follow the conventions
>> > we introduce in the manual and suppress the ESS's directory prompt.
>>
>> The responses expressed no objections to the change.
>> So, ob-R and ob-julia now obey the working directory conventions common
>> for the rest of babel backends - use default-directory or :dir; no
>> queries.
>>
>> Closed.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=62b88d613e
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>>
>>


test-ob-R.org
Description: Binary data

Re: [PATCH] LSP support in org-src buffers

[Ihor Radchenko]

Ihor Radchenko  writes:

> We are not in hurry. Any progress will be appreciated as long as there
> is some.

Unfortunately, this important patch is stuck.
It would be nice is somebody revived the work on it.
Anyone interested will do, not just people involved in this thread :)

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

Re: [BUG] Edge case for preview image alignment

[Ihor Radchenko]

Karthik Chikmagalur  writes:

> Please close this bug/issue.

Canceled.

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

Re: [PATCH] LSP support in org-src buffers

[Ihor Radchenko]

Karthik Chikmagalur  writes:

> After trying it for a while, my opinion is that this way of getting LSP
> support is a hack and somewhat fragile.  This is why I haven't worked on
> it since.

I was more referring to the idea with tangling
https://gist.github.com/bigodel/15599f3c1da23d1008b7d7d4ff8bff77 shared
by Joao.

> ... On the Eglot repo, they're considering adapting LSP's jupyter
> notebook support to source blocks in Org:
>
> https://github.com/joaotavora/eglot/issues/523#issuecomment-2542536622
>
> There are some limitations:
>
> - This requires some work on the Eglot side, specifically a new minor
>   mode that sets some Eglot state variables.
>
> - I don't think many language servers include notebook support.

> But the support might be better than the background-tangling approach
> used by proposal in this thread.

I agree that it would be best to make use of the native langserver
capabilities, if they are available. However, tangling approach is much
more universal. It will cover more than just LSP servers - other
traditional dev tools as well.

So, there is a lot of value in having that independent of dedicated
eglot/lsp support.

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

Re: [BUG] Image width specifications like :width 300px not working

[Ihor Radchenko]

Karthik Chikmagalur  writes:

>> Probably, we can extend the regexp to treat things like px/pt as pixel
>> width as well.
>>
>> I suggest doing it in a separate patch rather than making many changes
>> together with introducing a new feature as you suggested. Having too
>> many things in a single commit can lead to confusion. 
>
> Okay.  I'll send a patch to accommodate px and pt specifications after
> merging the org-link-preview patch.  The relevant function was moved
> into a different file so it's easier to do it in this order.

Fixed, on main.
See https://list.orgmode.org/orgmode/87wmg4148s@gmail.com/

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