Limiting a repeating timestamp ?

2023-04-07 Thread David Masterson
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



Re: [BUG] ox-md image captions

2023-04-07 Thread Max Nikulin

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

A workaround for Org is export snippet or block for the paragraph with 
caption


#+md: Figure 1. Caption



Re: [BUG] No font lock in src blocks for shells in org-babel-shell-names (was Re: Font lock for org-babel shell scripts?)

2023-04-07 Thread Derek Chen-Becker
In the code I posted, I had to explicitly (require 'sh-script) to ensure
that the sh-ancestor-alist is loaded before the code. I'm not enough of an
elisp guru to know if there's a way to defer that.

Cheers,

Derek

On Fri, Apr 7, 2023 at 9:30 AM Matt  wrote:

>
>   On Tue, 04 Apr 2023 08:30:34 -0400  Ihor Radchenko  wrote ---
>
>  > See the attached tentative patch.
>
> After applying the patch, I get the following error when trying to load
> Emacs:
>
> Warning (comp): /home/ahab/Projects/org-mode/lisp/org.el: Error: Symbol's
> value as variable is void sh-ancestor-alist
>
> I wasn't able to resolve it.  I suspect the issue is on my end, such as a
> mixed install or the need to  re-byte-compile  `sh-script.el'.
>
> To run Org from source I do one of the following:
>
> ;; When using my init
> (use-package org :straight (:local-repo "/home/ahab/Projects/org-mode"))
>
> ;; When running emacs -q
> (add-to-list 'load-path "/home/ahab/Projects/org-mode/lisp")
> (require 'org-loaddefs)
>
> If I need to recompile Emacs byte code, I'm not sure how I'd do that since
> I'm running Guix and those files live in the write protected /gnu/store.
>


-- 
+---+
| 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  |
+---+


Re: [BUG] No font lock in src blocks for shells in org-babel-shell-names (was Re: Font lock for org-babel shell scripts?)

2023-04-07 Thread Matt


  On Tue, 04 Apr 2023 08:30:34 -0400  Ihor Radchenko  wrote --- 

 > See the attached tentative patch.

After applying the patch, I get the following error when trying to load Emacs:

Warning (comp): /home/ahab/Projects/org-mode/lisp/org.el: Error: Symbol's value 
as variable is void sh-ancestor-alist

I wasn't able to resolve it.  I suspect the issue is on my end, such as a mixed 
install or the need to  re-byte-compile  `sh-script.el'.  

To run Org from source I do one of the following:

;; When using my init
(use-package org :straight (:local-repo "/home/ahab/Projects/org-mode"))

;; When running emacs -q
(add-to-list 'load-path "/home/ahab/Projects/org-mode/lisp")
(require 'org-loaddefs)

If I need to recompile Emacs byte code, I'm not sure how I'd do that since I'm 
running Guix and those files live in the write protected /gnu/store.



Re: [BUG] ox-md image captions

2023-04-07 Thread Vladimir Alexiev
Hi Max!
It's not about the tooltip in HTML:
figure captions are very important in scholarly publishing.


Re: [BUG] ox-md image captions

2023-04-07 Thread Max Nikulin

On 05/04/2023 02:41, Ihor Radchenko wrote:

IMHO, it would make more sense if Pandoc had a toggle to treat captions
differently. As an alternative.


printf '![Alt](file.jpg "title")\n' |
pandoc -f org -t markdown_strict

disables generation of .

I think, it is unlikely that users with mobile devices (touchscreen 
only) have chance to notice title attribute. The only site where I check 
image titles is https://xkcd.com/1179/ . Alt text describes image for 
those who do not see image while caption should be apparent for those 
who see it.


I believe that it is Org bug that it places caption as title, but there 
is no better alternatives besides HTML. Duplicating caption as alt text, 
as pandoc does, is a bug as well.




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

2023-04-07 Thread Ihor Radchenko
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 



Re: [PATCH] Fix bug in orgtbl-self-insert-command when used with evil-escape

2023-04-07 Thread Ihor Radchenko
Aaron Zeng  writes:

> There appears to be a bug in orgtbl-self-insert-command, which uses 
> last-input-event instead of last-command-event.  self-insert-command itself 
> uses the latter variable.
> ...
> With the patch, the above steps correctly insert f and then a newline.

Thanks!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=54a743cd7
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=19b0d0e5a

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



Re: [PATCH] Handle block-type when checking `org-src-fontify-natively'

2023-04-07 Thread Ihor Radchenko
Nathaniel Nicandro  writes:

> I think I found a bug where the condition for `org-src-fontify-natively`
> in `org-src-fontify-meta-lines-and-blocks-1` wasn't handling the block
> type.  `org-src-fontify-natively` says it should fontify src blocks
> only, but the condition didn't have that constraint.  Attached is a
> patch that adds in the constraint.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=616e80a9f

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