Re: [RFC] [feat] org-colview/org-columns: 'column view' moving rows up/down

[Sławomir Grochowski]

Thank you Ihor for the code review.
Now please help me find everything that can be improved in this patch.


> The patch looks good in general, but you need to add proper commit
> message. See https://orgmode.org/worg/
> 
> org-contribute.html#commit-messages
> 


Fixed.

Also, you need to add etc/ORG-NEWS entry about the new functionality and
> also modify the manual.
>

I added description to the manual and missing description of two
other commands: org-columns-move-left, org-columns-move-right that were
missing.


> Finally, I see no records about you copyright assignment status.
> Please take a look at
> https://orgmode.org/worg/org-contribute.html#copyright
>

 Yes, it's my first time. I sent an email to ass...@gnu.org, yesterday.

Does this test have anything to do with the new feature?
>

 Yes, you are right. This test has nothing in common with the feature. I
have removed it.

On Fri, Apr 7, 2023 at 1:01 PM Ihor Radchenko  wrote:

> Sławomir Grochowski  writes:
>
> > Recently I often use 'column view' feature.
> > To my suprise in 'column view' user can't move rows up & down.
> > So I wrote a little code snippet to be able to do it, and I'm sharing it
> with you.
> >
> > Questions:
> > 1. Why user can't move rows up & down in 'column view'?
> > 2. Is this was intentional design decision?
>
> I do not see any particular reason.
> The current design dates back to 15 years ago - the initial commit in
> our current git repo.
>
> > I think 'column view' is missing one the core feel & functionality of
> org-mode - moving rows (headings) up & down.
> > In my experiance with 'column view' & tables I shuffle a lot of columns
> & rows order.
>
> Sounds reasonable.
>
> > From 1f0f2052b8dddf4982ab35267ed1564f2250784b Mon Sep 17 00:00:00 2001
> > From: Sławomir Grochowski 
> > Date: Mon, 3 Apr 2023 19:23:09 +0200
> > Subject: [PATCH] org-columns: add feat to move row up/down
>
> The patch looks good in general, but you need to add proper commit
> message. See https://orgmode.org/worg/org-contribute.html#commit-messages
>
> Also, you need to add etc/ORG-NEWS entry about the new functionality and
> also modify the manual.
>
> Finally, I see no records about you copyright assignment status.
> Please take a look at
> https://orgmode.org/worg/org-contribute.html#copyright
>
> > +(defun org-columns--move-row ( up)
> > +"Move table row. Calls `org-move-subtree-down' or
> `org-move-subtree-up'."
>
> *Move column view table row.
>
> We generally prefer single sentence as the first line of the docstring.
> Also, please describe UP argument in the docstring.
>
> > +;; Each column is an overlay on top of a character.  So there has
> > +;; to be at least as many characters available on the line as
> > +;; columns to display.
> > +;; 'org-columns--display-here'
> > +(ert-deftest test-org-colview/bug-add-whitespace ()
> > +  "Insert space characters if number of characters on the line
> > +  is lower then number of columns."
> > +  :expected-result :failed
>
> Does this test have anything to do with the new feature?
>
> > +(ert-deftest test-org-colview/columns-move-row-down ()
> > +  "Test `org-columns-move-row-down' specifications."
> > +  (should
> > +   (equal "* H
> > +** B
> > +** A
> > +"
> > +  (org-test-with-temp-text "* H
> > +** A
> > +** B
> > +"
> > +(let ((org-columns-default-format "%ITEM")) (org-columns)
> > + (next-line 1)
> > + (org-columns-move-row-down)
> > + (buffer-substring-no-properties (point-min)
> (point-max)))
>
> One special case we may want to consider is when columns are from
> different heading levels, like
>
> * H
> ** A
> *** A1
> ** B
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
From c5cc24607306399d1b1ca583e63a2fe7b71dbf89 Mon Sep 17 00:00:00 2001
From: Sławomir Grochowski 
Date: Mon, 3 Apr 2023 19:23:09 +0200
Subject: [PATCH] lisp/org-colview.el: add new commands to move column view
 table row

* doc/org-manual.org (org-columns-move-row-up,
org-columns-move-row-down) and also (org-columns-move-left,
org-columns-move-right): Document two new and two old commands.
* etc/ORG-NEWS new commands to move rows up & down: Document the new feature.
* lisp/org-colview.el (org-columns--move-row, org-columns-move-row-up,
org-columns-move-row-down): New functions.
* testing/lisp/test-org-colview.el (test-org-colview/columns-move-row-down,
test-org-colview/columns-move-row-up,
test-org-colview/columns--move-row-stay-at-the-same-column,
test-org-colview/columns-move-row-down-with-subheading): New tests.
---
 doc/org-manual.org   | 24 
 etc/ORG-NEWS |  5 +++
 

export only certain columns of an org-table to csv

[Uwe Brauer]

Hi 

I have the following simple table


#+Name: table
| / | /  | <> | <> |
|   | Name   | Sheet1 | Sheet2 |
|---+++|
|   | Smith  | Ex1| Ex2|
|   | Miller | Ex3| Ex4|


I hoped that the first two columns would not be exported to csv
(orgtbl-to-csv), indeed they are not when exporting to latex or html but
for csv, all columns have been exported.

What do I miss?

Thanks and regards

Uwe Brauer 

-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

[Max Nikulin]

On 29/03/2023 23:52, Ihor Radchenko wrote:

I was able to reproduce on Debian using virtual machine.
Also, several people were able to reproduce in Matrix when I asked them.
And we got one report from Fedora user. + Several from Ubuntu users.
Recently, there was also
https://old.reddit.com/r/orgmode/comments/123qnqq/workaround_for_orgassertversion_problem_not/


I would consider adding to ELPA README and Org manual something like:

If compiling of ELPA packages causes a lot of warnings related to 
`org-assert-version' then delete just installed Org package, start new 
Emacs session ensuring that Org is not loaded (-q?) and try to install 
from such clean state.


I never expected that result of compiling may depend on whether the 
directory with built-in Org contains besides .elc files gzipped sources 
.el.gz (as after make install) or original .el files.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882#134 (sorry, I sent 
this message without Cc to emacs-orgmode.)

Re: [PATCH v2] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el))

[Max Nikulin]

+;; Package-Requires: ((emacs "26.1") (compat "29.1.4.1"))


Is there a way to express (or (compat "29.1.4.1") (emacs "28.1")) to 
avoid installing compat in the case of sufficiently new emacs? E.g. 
dpkg/apt allows such alternatives.


Early I asked concerning compat-29.1.3. I would prefer to install 
elpa-compat system package to avoid network activity in response to 
make. Required version matters for those who builds packages for 
backport repositories for various linux distributions. It allows to 
decide if it is necessary to provide newer elpa-compat or it is enough 
to package elpa-org.


On 08/04/2023 18:41, Ihor Radchenko wrote:


I see. Unfortunately, using third-party non-standard packages like
makem.sh or eldev will be more troublesome. We will need to sync Org
repo with them or demand users to install them separately.


I was looking for sources of inspiration. I do not suggest to take these 
tools. Perhaps somebody may suggest a better example of build scripts 
for Emacs packages.



I do not like the idea of network queries on every make.

Any better suggestions?


Do not run install dependencies for regular targets like test or
compile. At least do not do it unless it is explicitly requested by
command line argument or a variable in local.mk


compat.el is required for "compile" target. Compilation will simply fail
with older Emacs. And "test" triggers "compile".


There are different types of build systems. Some of them allows to 
specify which dependencies should be pulled, some do not. My expectation 
is that make does not attempt to manage dependencies. For me it is OK to 
type an additional command to install them and to fail otherwise.


In my opinion


+   @$(FIND) $(pkgdir) \(  -name \*.elc \) -exec $(RM) {} +


command tells that package management capabilities in Emacs are rather 
rudimentary (in comparison to e.g. python toolchain). That is why I am 
in favor to more manual dependency management. Notice that I am not 
against an option to do it from make.


Untested:

$(FIND) $(pkgdir) -name \*.elc -delete

"@" for silencing is intentionally dropped, parenthesis are unnecessary 
for single condition.



Actually, we need pkgdir := $(shell pwd)/pkg-deps.
CURDIR is wrong because default.mk will trigger evaluation in every make
sub-process as well.


default.mk is included from top level Makefile only.


Not sure here. I just noticed that GITVERSION got re-calculated many
times when looking at debug output of make. (It was slowing things down
significantly). GITVERSION is in targets.mk though.


GITVERSION is defined as ?=, so it is a variable with deferred 
evaluation. Immediately evaluated variable may defined using :=



pkgdir = $(top_builddir)/pkg-deps


How to define top_builddir? If also via `pwd`, I see not much difference.


I consider it as self-documenting code. Intermediate variable makes it 
apparent for readers that the directory is relative to the top of the 
package file tree.


Since out of source tree builds are not supported, I would consider 
adding emacs version to path. The idea is to allow keeping installed 
packages when switching between several emacs versions.


A note concerning variable name. For me it is associated for the 
directory where current package should be installed. I do not remember 
origin, but I noticed that such meaning is used in arch 
https://wiki.archlinux.org/title/creating_packages#Defining_PKGBUILD_variables 
Perhaps the same name is in gentoo in other sense that makes it suitable 
for storage of dependencies.

Re: Limiting a repeating timestamp ?

[Ihor Radchenko]

Mark Barton  writes:

> Not exactly the answer to the question, but I sometimes use the 
> org-clone-subtree-with-time-shift function to copy a scheduled meeting. That 
> will give me copies with the timestamps shifted by the amount requested 
> (weekly, monthly, etc.). The advantage I found with this, is that I can then 
> edit any of the copies to adjust for holidays.

Note that you can exclude holidays automatically using `org-class' in
diary sexp-style timestamps.

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

Re: Limiting a repeating timestamp ?

[Mark Barton]

> On Apr 7, 2023, at 9:53 PM, David Masterson  wrote:
> 
> Is there a way of creating a Task which is a once a week meeting that
> will take place in (say) June, July, and August and then stop repeating?
> 
> -- 
> David Masterson
> 

Not exactly the answer to the question, but I sometimes use the 
org-clone-subtree-with-time-shift function to copy a scheduled meeting. That 
will give me copies with the timestamps shifted by the amount requested 
(weekly, monthly, etc.). The advantage I found with this, is that I can then 
edit any of the copies to adjust for holidays.

Mark Barton

Re: [O] Injecting properties with noweb

[Ken Mankoff]

Hi Ihor,

I had posted this in another thread, but repeat it here for anyone interested. 
I think it is a similar end result to what you posted, but skips the =identity= 
 step. The examples below show (1) setting a bash environment variable in 
screen, or (2) printing from a Python prompt after sshing to a remote computer. 
It is language agnostic. Because it uses PROPERTIES and not :var, it also lets 
me work in Org Column View mode.


* Header
:PROPERTIES:
:foo: 42
:END:

#+NAME: ex1-screen-bash
#+BEGIN_SRC screen

export foo="<>"
#+END_SRC

#+NAME: ex2-ssh-python
#+BEGIN_SRC bash

ssh somewhere
python
print("<>")
#+END_SRC

#+CALL: ex2-ssh-python()

#+RESULTS:
: foo


The relevant section from my library-of-babel is:

* Properties into header args
:PROPERTIES:
:hellomessage: hello
:END:

https://emacs.stackexchange.com/questions/41922/

#+NAME: get_property
#+BEGIN_SRC emacs-lisp :var prop_name="" :results silent

(org-with-point-at org-babel-current-src-block-location
  (org-entry-get nil prop_name t))
#+END_SRC

** Example Usage

*** Header arg

#+HEADER: :var prop_message=(org-entry-get nil "hellomessage" t)
#+BEGIN_SRC emacs-lisp
  (message prop_message)
#+END_SRC

#+RESULTS:
: hello

*** Noweb

#+BEGIN_SRC emacs-lisp :noweb yes
  (message "<>")
#+END_SRC


#+RESULTS:
: hello

#+BEGIN_SRC bash :noweb yes :results verbatim
echo "<>"
#+END_SRC

#+RESULTS:
: hello

If hope this helps someone if they need it.

  -k.




On 2023-04-08 at 05:22 -07, Ihor Radchenko  wrote...
> Ken Mankoff  writes:
>
>> Is it possible to set variables using Org Babel inside screen, which
>> does not support ":var" header args? I'd actually lke a double-nested
>> screen over ssh, and the ability to re-use Babel code blocks under
>> different headings, using header args or PROPERTIES to change
>> variables. That is, something like:
>
> Yes.
>
>> ...
>> #+NAME: get-prop
>> #+BEGIN_SRC emacs-lisp :var prop="FOO" :noweb yes
>> (org-macro--get-property prop "")
>> #+END_SRC
>>
>> #+NAME: inject_vars
>> #+BEGIN_SRC shell :noweb yes
>> # echo <> # testing
>> echo export FOO=<>
>> echo export BAR=<>
>> echo export BAZ=<>
>> #+END_SRC
>
> This did not work as you expected because noweb evaluates code block
> with point at that code block.
>
> To get the property value at the code block where you expand noweb
> reference, you need to compute the value in the arguments to the
> reference. Something like
>
> #+name: identity
> #+begin_src elisp :var x=""
>
> x
> #+end_src
>
> ...
> echo export FOO=< ...

Re: [BUG] Documentation for #+INCLUDE: does not specify order when exporting [9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)]

[Ihor Radchenko]

Tim Landscheidt  writes:

> But why did I spend a few hours debugging this before final-
> ly understanding Org's mode of operation?  The first sen-
> tence of the documentation in "13.4 Include Files" reads:
>
> | During export, you can include the content of another file.
> | […]
>
> I'm not a native speaker, but the word "during" drew the
> mental image for me that, when exporting, Org starts at the
> top of the document, reads through to the end, and if en-
> counters a "#+INCLUDE:" statement /during/ that, it includes
> the referenced file at that point.
>
> Now the Org manual is already beset with examples that look
> as if someone complained about something not being document-
> ed somewhere, and then someone adding one sentence just that
> somewhere, so I don't want to add to that with "just a quick
> fix".
>
> But I do think it would be helpful if the "order" while ex-
> porting would be documented in a meaningful way.

Sure. We can add a section summarizing the export process at the end of
"13 Exporting". Patches welcome!

The export sequence is implemented in `org-export-as'.

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

Confirmed.

[BUG] Documentation for #+INCLUDE: does not specify order when exporting [9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)]

[Tim Landscheidt]

With the Org file:

| #+BEGIN_SRC python :results silent :exports results
|   test = '1'
|   with open('test-a.log', 'w') as f:
|   f.write(f'Test {test}a\n')
|   with open('test-b.log', 'w') as f:
|   f.write(f'Test {test}b\n')
| #+END_SRC

| Test, part A:

| #+INCLUDE: "test-a.log" verbatim

| Test, part B:

| #+INCLUDE: "test-b.log" verbatim

and test-a.log and test-b.log not existing, on the first
(unsuccessful) export, the error:

| org-export-expand-include-keyword: Cannot include file /tmp/test-a.log

is displayed.  However, if these files already exist, they
are included as is, and /after/ that inclusion, the Python
source block is executed.

This means that if one changes "test = '1'" to "test = '2'"
in the Python source block, one has to export the Org file
twice to see the changed result in the export.

Technically, this is probably the "correct" behaviour as
otherwise the order of execution would be very hard to de-
termine.

But why did I spend a few hours debugging this before final-
ly understanding Org's mode of operation?  The first sen-
tence of the documentation in "13.4 Include Files" reads:

| During export, you can include the content of another file.
| […]

I'm not a native speaker, but the word "during" drew the
mental image for me that, when exporting, Org starts at the
top of the document, reads through to the end, and if en-
counters a "#+INCLUDE:" statement /during/ that, it includes
the referenced file at that point.

Now the Org manual is already beset with examples that look
as if someone complained about something not being document-
ed somewhere, and then someone adding one sentence just that
somewhere, so I don't want to add to that with "just a quick
fix".

But I do think it would be helpful if the "order" while ex-
porting would be documented in a meaningful way.

Re: [O] Injecting properties with noweb

[Ihor Radchenko]

Ken Mankoff  writes:

> Is it possible to set variables using Org Babel inside screen, which does not 
> support ":var" header args? I'd actually lke a double-nested screen over ssh, 
> and the ability to re-use Babel code blocks under different headings, using 
> header args or PROPERTIES to change variables. That is, something like:

Yes.

> ...
> #+NAME: get-prop
> #+BEGIN_SRC emacs-lisp :var prop="FOO" :noweb yes
> (org-macro--get-property prop "")
> #+END_SRC
>
> #+NAME: inject_vars
> #+BEGIN_SRC shell :noweb yes
> # echo <> # testing
> echo export FOO=<>
> echo export BAR=<>
> echo export BAZ=<>
> #+END_SRC

This did not work as you expected because noweb evaluates code block
with point at that code block.

To get the property value at the code block where you expand noweb
reference, you need to compute the value in the arguments to the
reference. Something like

#+name: identity
#+begin_src elisp :var x=""
x
#+end_src

...
echo export FOO=.
Support Org development at ,
or support my work at 

Re: [PATCH v2] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el))

[Ihor Radchenko]

Max Nikulin  writes:

>> I know no other Emacs packages that manage dependencies using make.
>
> org-ql uses a helper shell script. org-roam and projectile use eldev 
> that is procedural, not declarative build system. I have not figured out 
> which way magit handles dependencies. I have no more ideas what projects 
> may involve unit tests and dependencies.

I see. Unfortunately, using third-party non-standard packages like
makem.sh or eldev will be more troublesome. We will need to sync Org
repo with them or demand users to install them separately.

Also, eldev is not on ELPA, and we cannot use it at all.

As for makem.sh, AFAIK, it will be even worse wrt network access - it
tries refreshing and downloading some packages by default, unless we
explicitly disable that feature. And under the hood, makem.sh anyway
does the same emacs --eval thing I used in the patch.

>>> I do not like the idea of network queries on every make.
>> Any better suggestions?
>
> Do not run install dependencies for regular targets like test or 
> compile. At least do not do it unless it is explicitly requested by 
> command line argument or a variable in local.mk

compat.el is required for "compile" target. Compilation will simply fail
with older Emacs. And "test" triggers "compile".

>> Actually, we need pkgdir := $(shell pwd)/pkg-deps.
>> CURDIR is wrong because default.mk will trigger evaluation in every make
>> sub-process as well.
>
> default.mk is included from top level Makefile only.

Not sure here. I just noticed that GITVERSION got re-calculated many
times when looking at debug output of make. (It was slowing things down
significantly). GITVERSION is in targets.mk though.

> By the way, it is 
> better to explicitly express that path is relative to top project 
> directory by defining e.g. top_builddir (or abs_top_builddir) at first and
>
> pkgdir = $(top_builddir)/pkg-deps

How to define top_builddir? If also via `pwd`, I see not much difference.

> Today I noticed the following trick in (likely stale) 
> https://github.com/org-roam/org-roam/blob/main/default.mk
>
> TOP := $(dir $(lastword $(MAKEFILE_LIST)))
>
> I have not realized if it is safe enough.

Reading through 6.14 Other Special Variables section of make manual, it
does not look safe - MAKEFILE_LIST may be altered by presence of includes.

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

Re: [PATCH v2] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el))

[Max Nikulin]

On 03/04/2023 00:00, Ihor Radchenko wrote:

Max Nikulin writes:


Ihor, do added makefile rules follow best practices used by other Emacs
packages in respect to dependencies?

I know no other Emacs packages that manage dependencies using make.


org-ql uses a helper shell script. org-roam and projectile use eldev 
that is procedural, not declarative build system. I have not figured out 
which way magit handles dependencies. I have no more ideas what projects 
may involve unit tests and dependencies.


Actually Org uses make just as interface, not as a declarative build 
system that is able to minimize work by updating only necessary targets. 
Build rules are effectively procedural: complete rebuild on every 
invocation.



I do not like the idea of network queries on every make.

Any better suggestions?


Do not run install dependencies for regular targets like test or 
compile. At least do not do it unless it is explicitly requested by 
command line argument or a variable in local.mk



+pkgdir = $(shell pwd)/pkg-deps


Make has CURDIR variable, but I am unsure if it is safe to use it in 
this context.


Actually, we need pkgdir := $(shell pwd)/pkg-deps.
CURDIR is wrong because default.mk will trigger evaluation in every make
sub-process as well.


default.mk is included from top level Makefile only. By the way, it is 
better to explicitly express that path is relative to top project 
directory by defining e.g. top_builddir (or abs_top_builddir) at first and


pkgdir = $(top_builddir)/pkg-deps

Today I noticed the following trick in (likely stale) 
https://github.com/org-roam/org-roam/blob/main/default.mk


TOP := $(dir $(lastword $(MAKEFILE_LIST)))

I have not realized if it is safe enough.

Re: [PATCH] Add missing "stuck" agenda view to Special Agenda Views section of manual

[Ihor Radchenko]

Ruslan Bekenev  writes:

> I’ve been trying to make my custom agenda view and I really wanted to see the 
> list of stuck projects in there. 
> Looking at “Special Agenda Views” section of the manual I was sure there is 
> no ~stuck~ special view because it isn’t mentioned there.
> Turned out there is such a view, it just mentioned in “Block agenda” section 
> of the manual.
>
> I think "Special Agenda Views” section must also mention ~stuck~ as an 
> option. 

The purpose of the paragraph you are referring to is not listing all the
special agenda views, but describing `org-agenda-skip-function'. `stuck'
type agenda ignores user-defined `org-agenda-skip-function'.

Canceled.

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

Re: [BUG] ox-md image captions

[Ihor Radchenko]

Max Nikulin  writes:

> On 07/04/2023 22:29, Vladimir Alexiev wrote:
>> It's not about the tooltip in HTML:
>> figure captions are very important in scholarly publishing.
>
> I see and I do not like that Org exports caption as title (tooltip). On 
> the other hand neither original markdown nor GitHub flavored markdown 
> have notion of figure caption. Pandoc extension has the issue with 
> duplicated text in caption and alt. I have seen mention of  
> block in commonmark, but I have never tried it.
>
> MarkDown is rather basic format and the closest approach it a paragraph 
> below an image despite they are not grouped into figure.
>
>  ![](fig.jpg)
>
>  Figure 1. Caption

In theory, we can directly use  HTML tags + direct HTML in
the MD export. That will be actually the closest way. But direct HTML is
not well-received when using the MD in practice. For example, sourcehut,
GitHub, and Reddit do not allow arbitrary html fragments when rendering
MD (AFAIK).

> A workaround for Org is export snippet or block for the paragraph with 
> caption
>
> #+md: Figure 1. Caption

A better workaround is a custom filter, or we may provide a
customization, if someone offers a patch.

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

Re: [BUG] ox-md image captions

[Ihor Radchenko]

Vladimir Alexiev  writes:

> It's not about the tooltip in HTML:
> figure captions are very important in scholarly publishing.

I agree, but are you actually publishing scholar articles to MD? Caption
are correctly handled in Latex and ODT publishing - the most common
formats for scholary articles.

The problem with MD is that it does not have notion of captions and
hence we have to make up some kind of ad-hoc convention, which may or
may not work with specific article format you need to produce.

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

Re: Limiting a repeating timestamp ?

[Ihor Radchenko]

David Masterson  writes:

> Is there a way of creating a Task which is a once a week meeting that
> will take place in (say) June, July, and August and then stop repeating?

No, other than using diary sexp.
It is a frequently requested feature though.

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

[PATCH] Add missing "stuck" agenda view to Special Agenda Views section of manual

[Ruslan Bekenev]

Hi guys, 

I’ve been trying to make my custom agenda view and I really wanted to see the 
list of stuck projects in there. 
Looking at “Special Agenda Views” section of the manual I was sure there is no 
~stuck~ special view because it isn’t mentioned there.
Turned out there is such a view, it just mentioned in “Block agenda” section of 
the manual.

I think "Special Agenda Views” section must also mention ~stuck~ as an option. 

The patch below just adds it. 

Let me know if it makes any sense. 

Thanks,
Ruslan

From 7ffa93aa66eab099d7c41d0d1c99aa97818fd39e Mon Sep 17 00:00:00 2001
From: Ruslan Bekenev 
Date: Sat, 8 Apr 2023 17:38:40 +1000
Subject: [PATCH] doc/org-manual.org; Add missing ~stuck~ agenda view

---
 doc/org-manual.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4644e5adc..4881b9a76 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21441,7 +21441,7 @@ Org provides a special hook to further limit items in 
agenda views:
 ~agenda~, ~agenda*~[fn:: The ~agenda*~ view is the same as ~agenda~
 except that it only considers /appointments/, i.e., scheduled and
 deadline items that have a time specification =[h]h:mm= in their
-time-stamps.], ~todo~, ~alltodo~, ~tags~, ~tags-todo~, ~tags-tree~.
+time-stamps.], ~todo~, ~alltodo~, ~tags~, ~tags-todo~, ~tags-tree~, ~stuck~.
 Specify a custom function that tests inclusion of every matched item
 in the view.  This function can also skip as much as is needed.
 
-- 
2.37.1 (Apple Git-137.1)