Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

[Gavin Downard]

Ihor Radchenko  writes:
> Do we have any tests covering this part of the code?

Not that I know of. I can add a test case for this specific instance,
but I'm not sure if I should add more comprehensive tests in this patch.
What do you think?

> In Emacs 26, we will need (require 'subr-x), but otherwise it is not a
> problem to use `if-let'.

Oh, I didn't realize that. Sorry about that.

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Eric Abrahamsen]

Ihor Radchenko  writes:

> Eric Abrahamsen  writes:
>
>> We should definitely be using the paradigm above (using the
>> gnus-summary-buffer as the current buffer). The article number fetching
>> only works by accident in the article buffer, and other stuff (like
>> finding the original nnselect group name) won't work at all.
>
> I am convinced then.
> Ideally, it would be nice to have tests, though I have no clue how to
> approach writing them.
>
>> Later in the function we've got this:
>>
>> (save-window-excursion
>>   (save-excursion
>> (gnus-article-show-summary)
>> (gnus-summary-article-header)))
>>
>> If we're currently in article-mode. The call to
>> `gnus-article-show-summary' would protect against the case where the
>> summary buffer has been killed in the meantime, but I agree that's kind
>> of a pathological case.
>
> I'd say that the patch will be an improvement anyway.
>
>> Probably it would be enough to wrap the whole containing `let*' in a
>> (with-current-buffer gnus-summary-buffer ...). If we're already in the
>> summary buffer, no harm done.
>
> I am not sure if it is safe.
> There is
> (save-window-excursion (gnus-summary-select-article))
> which calls (set-buffer gnus-summary-buffer)
>
> `with-current-buffer' will certainly alter how things work (although,
> switching buffer when capturing link is already fishy).

Ugh, this whole thing is a mess. I think the first question is: should
this function "fix" the state of Gnus before it makes a link? Should it
attempt to re-open the Summary buffer if it's been closed? Should it
switch current articles if the open article buffer is not the one that
point is on in the Summary buffer?

If we make a decision about that, then it should be easier to decide how
to handle the code changes themselves.

Eric

Re: [Bug] org-insert-link removes on one link from 2 added by org-store-link

[Samuel Wales]

"in my case"

On 7/23/23, Max Nikulin  wrote:
> On 13/07/2023 10:34, Samuel Wales wrote:
>> link has already been stored is a bug in my case in that i can't just
>> go to a header, grab it [whether rabbed bfere or not] and then paste
>> it.  i surprise easily when the wrong link gets pasted.
>
> The message is not a bug, it tells me that I am trying to store a wrong
> link. The issue is that current implementation does not prevent
> appearance of multiple identical links after several cycles
> store-link/insert-link to the same heading.
>
> Whether stored links should be reordered depends on specific action, so
> a defcustom user option is not a rescue:
>
> 1. Collect links in certain order for `org-insert-org-links'. Duplicated
> link is a real error.
>
> 2. Copy link going to immediately insert it. Making the link the default
> one sounds reasonable. Perhaps the user still should be notified.
>
> So I disagree that "already stored" is a bug, but there is room for
> improvements.
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Bug: org-anniversary dates not exported to iCalendar [9.4.6 (9.4.6-3-g37f69b-elpaplus @ /home/marcus/.emacs.d/elpa/org-plus-contrib-20210531/)]

[Marcus Zibrowius]

> This is because Emacs diary only looks 
> `icalendar-export-sexp-enumeration-days' days ahead from now when 
> exporting non-standard diary sexps. By default, it is 2 weeks. 
> So, you would see the anniversary in icalendar if it were 2 weeks from 
> now.
> 
> You can increase `icalendar-export-sexp-enumeration-days' to get the 
> anniversary occurrences exported up to that number of days ahead.

The variable `icalendar-export-sexp-enumeration-days` is indeed set to 14.   
However, even entries of the form 

* Test 1
%%(org-anniversary 2023 07 22) Test1
* Test 2
%%(org-anniversary 2023 07 24) Test2

do not get exported today (2023 07 23).  

> Also, `org-anniversary' does not support %d. AFAIK, it is only working 
> for built-in sexp types, which are handled specially.

%d works perfectly in the agenda view.

Marcus 

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Jens Schmidt]

On 2023-07-23  12:26, Max Nikulin wrote:


Is nnselect a real NNTP group or is it some instance existing solely
in user's configuration?


Like nnvirtual and nnir, nnselect exists only in user's configuration,
yes.  All these three backends are "wrapper backends" that keep track of
the original messages which they wrap by pairs

  (ORIGINAL-GROUP, MESSAGE-ID)


Does gnus have global Message-ID index?


Gnus can have a global Message-ID cache, but it's not on by default (at
least not in Emacs 28, haven't checked others).  And anyway, it's a
potentially incomplete *cache*, and not an *index*.

(info "(url) news/nntp/snews") or  or 
https://www.gnu.org/software/emacs/manual/html_node/url/news_002fnntp_002fsnews.html


In any case, Gnus is *not only* an NNTP newsreader, since it has a
plethora of other backends (aka. "select methods"), ranging from nnimap
to nneething, which turns a directory into a, well, group?  See
.  Funnily enough, I personally stopped using
Gnus as NNTP newsreader long ago ...

I am curious whether namely "gnus" links have to be used or it is 
possible to rely on more generic "news:"/"nntp:; links, or even 
 (perhaps with some 
`browse-url' configuration)? It should improve portability.


For nntp groups you already have the option to store links as web links
to groups.google.com, by means of `org-gnus-prefer-web-links'.  Here
again I'm not really an NNTP expert so I cannot tell whether this is
portable/optimal/whatever.

This could be extended to provide more options for backends that support 
more specific link types, but I think the default should stay the gnus:"

links, since only that covers all the available Gnus backends.

Re: [Bug] org-insert-link removes on one link from 2 added by org-store-link

[Max Nikulin]

On 13/07/2023 10:34, Samuel Wales wrote:

link has already been stored is a bug in my case in that i can't just
go to a header, grab it [whether rabbed bfere or not] and then paste
it.  i surprise easily when the wrong link gets pasted.


The message is not a bug, it tells me that I am trying to store a wrong 
link. The issue is that current implementation does not prevent 
appearance of multiple identical links after several cycles 
store-link/insert-link to the same heading.


Whether stored links should be reordered depends on specific action, so 
a defcustom user option is not a rescue:


1. Collect links in certain order for `org-insert-org-links'. Duplicated 
link is a real error.


2. Copy link going to immediately insert it. Making the link the default 
one sounds reasonable. Perhaps the user still should be notified.


So I disagree that "already stored" is a bug, but there is room for 
improvements.

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Max Nikulin]

On 22/07/2023 16:06, Jens Schmidt wrote:

- Create an nnselect group and open an article from that.  In the
   article buffer, do M-x org-store-link RET, then paste the link with
   C-c C-l in some Org mode buffer.  The resulting link looks like

gnus:#e18xcfu-0004ht...@fencepost.gnu.org

   That is, it lacks the group name before the hash sign.  Correct would
   have been:

gnus:nnml+archive:test01#e18xcfu-0004ht...@fencepost.gnu.org


I am not a gnus user, so my comments may be irrelevant due to my 
ignorance. In that case I am sorry.


Is nnselect a real NNTP group or is it some instance existing solely in 
user's configuration? Does gnus have global Message-ID index?


Generally news group is not necessary to specify a message on a NNTP 
server, it may be retrieved by Message-ID only. The name of the news 
group is mandatory if *article number* is used.


(info "(url) news/nntp/snews") or  or
https://www.gnu.org/software/emacs/manual/html_node/url/news_002fnntp_002fsnews.html

I am curious whether namely "gnus" links have to be used or it is 
possible to rely on more generic "news:"/"nntp:; links, or even 
 (perhaps with some 
`browse-url' configuration)? It should improve portability.

Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

[Ihor Radchenko]

Gavin Downard  writes:

>> Notice
>> "Double definition `%s=' in TBLFM line, please fix by hand"
>>
>> below. A bit more code is required to keep this sanity check for named 
>> columns.
>>
>
> Oh, good catch. Specifically, I think this should be caught inside of
> `org-table-recalculate', where it catches conflicting direct column
> references (eg "$1") and end-relative column references ("$<").

Do we have any tests covering this part of the code?

>> `if-let' is not available in Emacs-26
>>
>
> Are you sure? It looks like `if-let' was introduced in Emacs 25.

In Emacs 26, we will need (require 'subr-x), but otherwise it is not a
problem to use `if-let'.

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

Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

[Ihor Radchenko]

Eric Abrahamsen  writes:

> We should definitely be using the paradigm above (using the
> gnus-summary-buffer as the current buffer). The article number fetching
> only works by accident in the article buffer, and other stuff (like
> finding the original nnselect group name) won't work at all.

I am convinced then.
Ideally, it would be nice to have tests, though I have no clue how to
approach writing them.

> Later in the function we've got this:
>
> (save-window-excursion
>   (save-excursion
> (gnus-article-show-summary)
> (gnus-summary-article-header)))
>
> If we're currently in article-mode. The call to
> `gnus-article-show-summary' would protect against the case where the
> summary buffer has been killed in the meantime, but I agree that's kind
> of a pathological case.

I'd say that the patch will be an improvement anyway.

> Probably it would be enough to wrap the whole containing `let*' in a
> (with-current-buffer gnus-summary-buffer ...). If we're already in the
> summary buffer, no harm done.

I am not sure if it is safe.
There is
(save-window-excursion (gnus-summary-select-article))
which calls (set-buffer gnus-summary-buffer)

`with-current-buffer' will certainly alter how things work (although,
switching buffer when capturing link is already fishy).

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