Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Adam Faryna]

Thanks. I understand now.

I think to generate a patch in this case it's too much hustle, for a minor
benefit.

--
Adam

On Wed, 9 Sep 2020 at 09:13, Bastien  wrote:

> Hi Adam,
>
> Adam Faryna  writes:
>
> > Ok, maybe I misunderstood the purpose of this function. I wanted to
> > use it to check if the timestamp is active or inactive and I tried to
> > get it by using (org-at-timestamp-p 'inactive) while pointing at the
> > timestamp. But actually when I call it on any timestamp like
> > [2020-09-04 Fri], <2020-09-04 Fri> I always get nil. So either it's a
> > bug, or I miss something.
>
> (org-at-timestamp-p) returns t on an active timestamp.
>
> (org-at-timestamp-p 'inactive) returns t on any timestamp, including
> inactive ones.
>
> If you think the docstring could be enhanced, can you share a patch?
>
> See https://orgmode.org/worg/org-contribute.html on how to contribute.
>
> Thanks,
>
> --
>  Bastien
>

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Bastien]

Hi Adam,

Adam Faryna  writes:

> Ok, maybe I misunderstood the purpose of this function. I wanted to
> use it to check if the timestamp is active or inactive and I tried to
> get it by using (org-at-timestamp-p 'inactive) while pointing at the
> timestamp. But actually when I call it on any timestamp like
> [2020-09-04 Fri], <2020-09-04 Fri> I always get nil. So either it's a
> bug, or I miss something.

(org-at-timestamp-p) returns t on an active timestamp.

(org-at-timestamp-p 'inactive) returns t on any timestamp, including
inactive ones.

If you think the docstring could be enhanced, can you share a patch?

See https://orgmode.org/worg/org-contribute.html on how to contribute.

Thanks,

-- 
 Bastien

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Adam Faryna]

Ok, maybe I misunderstood the purpose of this function. I wanted to use it
to check if the timestamp is active or inactive and I tried to get it by
using (org-at-timestamp-p 'inactive) while pointing at the timestamp. But
actually when I call it on any timestamp like [2020-09-04 Fri], <2020-09-04
Fri> I always get nil. So either it's a bug, or I miss something.

Thanks,

Adam

On Tue, 8 Sep 2020 at 15:26, Bastien  wrote:

> Hi Adam,
>
> thanks, but I still need to understand the exact change you suggest
> and what general fix/improvement it will provide.  Probably a patch
> will be easier to understand for this.
>
> Thanks,
>
> --
>  Bastien
>

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Bastien]

Hi Adam,

thanks, but I still need to understand the exact change you suggest
and what general fix/improvement it will provide.  Probably a patch 
will be easier to understand for this.

Thanks,

-- 
 Bastien

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Adam Faryna]

I think the problem is general. If you work with any timestamp that is
agenda like, you can't check using this function if it's active or
inactive. The one solution would be to remove parameter "agenda" and
consider every timestamp as a agenda like (the "timestamp" in "
org-at-timestamp-p" suggest that there is time information in it anyway) by
default, or keep it as it is but extend parameter list with support of
named parameters where agenda-like can be activated with :agenda t,
inactive timestamp with :inactive t, with default values nil.

Thanks,
Adam

On Sat, 5 Sep 2020 at 13:59, Bastien  wrote:

> Hi Adam,
>
> you forgot to copy the emacs-orgmode list - can you repost your email
> there?
>
> Thanks,
>
> --
>  Bastien
>

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Bastien]

Hi Adam,

Adam Faryna  writes:

> The problem is I needed to check if the timestamp is agenda like and
> inactive or ignore the context at the same time. But
> org-at-timestamp-p takes only one parameter, and I needed to give it
> multiple parameters, which is not possible in the current version.

Can you show the first of org-at-timestamp-p you would need for your
purpose? 

Does it solve a general problem?

> Can you amend the implementation of org-at-timestamp-p to make it
> accept a list of parameters or named parameters instead of just one
> parameter?

We cannot amend the implementation of org-at-timestamp-p just for
flexibility's sake, because there would be no good reason not to 
change other functions as well.

If you have a generic change to propose to org-at-timestamp-p please
go ahead.

Thanks,

-- 
 Bastien