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
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 notio
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
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-ances
Hi Max!
It's not about the tooltip in HTML:
figure captions are very important in scholarly publishing.
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
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 vie
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, ont
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 constrain