Re: Interest in an Org video meetup?

[Matt]

  On Wed, 26 Apr 2023 17:13:47 -0400  Corwin Brust  wrote --- 
 > On Wed, Apr 26, 2023 at 9:31 AM Matt m...@excalamus.com> wrote:
 > >
 > > FSF associate members have access to a FSF hosted Jitsi instance.  I'm an 
 > > FSF associate member and could host it using that if I'm able to make the 
 > > time.
 > >
 > 
 > We can make EmacsConf instance of BigBlueButton (BBB) available, as
 > well.  FWIW I had more success with BBB than Jitsi for larger
 > meetings.

That's generally been my experience, too.  Glad to hear that's an available 
option.  Hopefully we can bring this to fruition.

Re: [BUG] Linking SCHEDULED and DEADLINE repeating timestamps to avoid desynchronization

[J. G.]

 Thanks for confirming the issue.
For the record, after doing some more research it looks like at least one other 
person came across this issue, and the workaround was using org-edna in place 
of the repeaters, which will push the timestamps together to the same date 
offset prior to the scheduled-deadline date range, and then increment them 
forward to the correct dates:
Use Edna Instead of the Repeater Pattern · Konubinix' Site


| 
| 
|  | 
Use Edna Instead of the Repeater Pattern · Konubinix' Site


 |

 |

 |





On Thursday, April 27, 2023 at 04:28:11 AM PDT, Ihor Radchenko 
 wrote:  
 
 "J. G."  writes:

> * TODO My late recurring todoSCHEDULED: <2023-04-12 Wed ++1w> DEADLINE: 
> <2023-04-13 Thu ++1w>
> Right now it is Wednesday (2023-04-26 to be precise), and as shown above, my 
> task had a scheduled timestamp on a Wednesday from a previous week. The 
> repeater is ++1w, so marking the task as done bumps it to repeat on Wednesday 
> of next week (2023-05-03 to be precise). That functions as expected.
> But the deadline timestamp is on a Thursday of a previous week with a
> repeater of ++1w, so marking the task as done bumps it to Thursday of
> this week (2023-04-27 to be precise). So marking it as done it has the
> logical but unexpected result of having the scheduled timestamp for a
> date (2023-05-03) after the deadline timestamp (2023-04-27).

Confirmed.
I think it makes sense to have a special case for scheduled and
deadlines, making sure that they shift by the same number of days in
future, when their repeaters are the same.

However, I do not think that it should be done for all other timestamps
under heading.

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

  

Re: [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

[Ihor Radchenko]

Ihor Radchenko  writes:

> I would like to assess the efficiency of one of search optimizations used
> in org-element.el [1]

Thanks everyone for responding!

It looks like the optimization is useful at least to some people (20%
cached searches is a good thing to have).

A number of people also reported significant fraction of cache queries
associated with editing (non-hashable). They cannot, unfortunately, be
handled by this particular optimization and I have to leave them as is.

I am thus leaving the code in place, removing the statistics gathering
parts.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2bc510217

Done.

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

Re: Interest in an Org video meetup?

[George Mauer]

 ✋ Interested as well

On Thu, Apr 27, 2023, 07:43 Dave Marquardt  wrote:

> Russell Adams  writes:
>
> > Would there be any interest in a monthly 1-2 hour long ad-hoc screen
> > sharing and video discussion for Org-mode?
>
> I'm interested.
>
> -Dave
>
>
>

Re: [ANN] lisp/ob-tangle-sync.el

[Mehmet Tekman]

Ihor Radchenko  writes:

> Do I understand correctly that your package is adding the following new
> features:
>
> 1. Automatically manages balanced
>`org-babel-tangle'/`org-babel-detangle' in Org sources and target
>buffers.
> 2. Attempts to make more fine-grained tangling/detanging functionality
>by controlling tangling behaviour on per-src-block basis (via
>:tangle-sync skip/pull/export/both)
>

That is correct

> If so, I think that (2) probably belongs to the main babel code
> (`org-babel-tangle' and `org-babel-detangle'). Since you are
> contributing to Org directly, you are free to modify these functions as
> you need.
>
> Note that your current approach with `org-babel-tangle-sync-synchronize'
> will give unexpected results when one edits multiple src blocks or the
> corresponding tangled source in multiple places - the :tangle-sync value
> is only checked at point and `org-babel-tangle'/`org-babel-detange' is
> then called for the whole buffer, not just for the current code block.

That's... a really good point. I didn't consider that I'm calling a
tangle or detangle function on an entire file based on the
=:tangle-sync action= of a single block... which might have different
actions in another block for the same file!

I've attached a toy.org file which should explain what the desired
action would be in such a situation, and I fully agree that I will
likely need to modify the current tangle and detangle code so that the
sync direction is on a per-block basis, and not per-file.

I will work on this a bit more and submit a full patch with this in
mind.

Best,
Mehmet
#+TITLE: Sync Many Blocks
#+PROPERTY: header-args  :tangle /tmp/default_tangle.txt :comments yes

* Default Tangle

 The =:tangle= target here is given by the ~PROPERTY~ header.  It is
 made up of three parts which synchronize with the tangled destination
 file in 3 different ways as given below: 

** File Contents
 
*** Free Head

#+begin_src conf
  This is some text that can be synced both ways
#+end_src

*** Pull Middle

#+begin_src conf  :tangle-sync import
  The middle text only retrieves from the default tangle file
#+end_src

*** Push tail

#+begin_src conf  :tangle-sync export
  This last piece of text only exports from the source org mode file.
#+end_src

* Desired Function

When =org-babel-tangle= is called, only the [[Free Head]] and [[Push tail]]
sections are tangled. The middle section in the tangled file is
_skipped_.

When =org-babel-detangle= is called, only the [[Pull Middle]] section is
updated here. The other two sections are _skipped_.

* Why skipped?

The functions suffixes explicitly state a direction (=tangle= /
=detangle=), and it's probably important that we retain this
directionality.

If we want to synchronize all blocks (i.e. import the middle section
from the tangled file during =org-babel-tangle=, and export the head
and tail sections during =org-babel-detangle=), then perhaps we set a
specific custom variable =(setq org-babel-tangle-alwayssync t)=?

Or, we create a specific function =org-babel-sync= (for lack of better
name) which tangles/detangles in whatever desired direction the source
block specifies.

Re: Interest in an Org video meetup?

[Dave Marquardt]

Russell Adams  writes:

> Would there be any interest in a monthly 1-2 hour long ad-hoc screen
> sharing and video discussion for Org-mode?

I'm interested.

-Dave

Re: [ANN] lisp/ob-tangle-sync.el

[Ihor Radchenko]

Mehmet Tekman  writes:

> I would like to contribute some a new library into org-mode, which
> performs automatic synchronization between tangled files and their
> org-mode source blocks via a global minor mode
> `org-babel-tangle-sync-mode' which uses the after-save-hook.

Thanks for your interest in contributing to Org mode!

> By activating =org-babel-tangle-sync-mode=, I can edit either of those
> buffers and every time that I save it would automatically update the
> other.  If I add the header argument =:tangle-sync = then I
> can specify an action of:
> - skip :: do nothing, just save the buffer, even if the sync mode is active
> - pull :: only pull changes from =~/.bashrc= into the Emacs_conf org-mode file
> - export :: only export changes from Emacs_conf to =~/.bashrc=, even if called
> from =~/.bashrc=
> - both :: (default) synchronize freely between tangled file and source block
>   (the is also the nil value)

Do I understand correctly that your package is adding the following new
features:

1. Automatically manages balanced
   `org-babel-tangle'/`org-babel-detangle' in Org sources and target
   buffers.
2. Attempts to make more fine-grained tangling/detanging functionality
   by controlling tangling behaviour on per-src-block basis (via
   :tangle-sync skip/pull/export/both)

If so, I think that (2) probably belongs to the main babel code
(`org-babel-tangle' and `org-babel-detangle'). Since you are
contributing to Org directly, you are free to modify these functions as
you need.

Note that your current approach with `org-babel-tangle-sync-synchronize'
will give unexpected results when one edits multiple src blocks or the
corresponding tangled source in multiple places - the :tangle-sync value
is only checked at point and `org-babel-tangle'/`org-babel-detange' is
then called for the whole buffer, not just for the current code block.

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

[BUG] Linking SCHEDULED and DEADLINE repeating timestamps to avoid desynchronization

[Ihor Radchenko]

"J. G."  writes:

> * TODO My late recurring todoSCHEDULED: <2023-04-12 Wed ++1w> DEADLINE: 
> <2023-04-13 Thu ++1w>
> Right now it is Wednesday (2023-04-26 to be precise), and as shown above, my 
> task had a scheduled timestamp on a Wednesday from a previous week. The 
> repeater is ++1w, so marking the task as done bumps it to repeat on Wednesday 
> of next week (2023-05-03 to be precise). That functions as expected.
> But the deadline timestamp is on a Thursday of a previous week with a
> repeater of ++1w, so marking the task as done bumps it to Thursday of
> this week (2023-04-27 to be precise). So marking it as done it has the
> logical but unexpected result of having the scheduled timestamp for a
> date (2023-05-03) after the deadline timestamp (2023-04-27).

Confirmed.
I think it makes sense to have a special case for scheduled and
deadlines, making sure that they shift by the same number of days in
future, when their repeaters are the same.

However, I do not think that it should be done for all other timestamps
under heading.

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

Re: [ANN] lisp/ob-tangle-sync.el

[Mehmet Tekman]

Ruijie Yu   writes:

> Great idea!  Some inline comments below.
>
> You only need to say #'expand-file-name instead of the quoted lambda.
> Also, you need to set the variable, otherwise the variable
> `org-babel-tangle-sync-files' is undefined.
>
> What I have in mind is this:
>:set (lambda (var val) (set var (mapcar #'expand-file-name val)))
>
> Here you don't have to use `progn' because it is implied from 
> `save-excursion'.
>

Thanks! I've made your changes, and I've also incorporated John
Wiegley's comments about using "import" instead of "pull" as a
tangle-sync action word (small diff attached).

I've also written up my changes in the ~etc/ORG-NEWS~ and
targeted my custom variable for the 9.7 release (diff attached).

> Is there possibility to have a local minor mode (without introducing too
> much code changes)?

I initially tried it this way, but the problem is that an org
source block buffer might be in sync-mode, but it's
corresponding tangle file might not be, making any changes
asymmetric.

Another issue is in order to see the changes in the tangled file,
the tangle buffer needs to be reverted (with user prompt) which
then switches off the sync-mode for that buffer on reload.

One way around this (and it's something I implemented 3 years ago in
my messy org-tanglesync[0] MELPA code) is to set an explicit list of
"sync files", and then for Emacs to parse every =:tangle= header in a
given file when loaded (via =org-src-mode-hook=) to create an alist of
config files and their associated tangled files[1], such as
=((file1.conf . (tanglefile1.txt tanglefile2.txt etc)))=. Then, for
example, when ~tanglefile1.txt~ is loaded, Emacs knows that it should
load the sync-mode too.

This approach works reasonably well when the "sync files" list is
mandatory, but it's also prone to errors if a sync file is edited and
the alist of config files isn't updated, and the user would also lose
the flexibility of having ~ob-tangle-sync~ function everywhere.

I think a global minor mode is really elegant in this regard and I
wish I knew about it 3 years ago!

Best,
Mehmet


0: https://gitlab.com/mtekman/org-tanglesync.el
1: 
https://gitlab.com/mtekman/org-tanglesync.el/-/blob/master/org-tanglesync.el#L400-L410
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 03894f128..29f60c755 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -207,12 +207,35 @@ selection.
 TODO state, priority, tags, statistics cookies, and COMMENT keywords
 are allowed in the tree structure.
 
-*** Asynchronous code evaluatation in ~ob-shell~
+*** Asynchronous code evaluation in ~ob-shell~
 
 Running shell blocks with the ~:session~ header freezes Emacs until
 execution completes.  The new ~:async~ header allows users to continue
 editing with Emacs while a ~:session~ block executes.
 
+*** Automatic sync of source blocks and tangled blocks in ~ob-tangle-sync~
+
+Invoking minor mode =org-babel-tangle-sync-mode= synchronizes contents
+between a currently visited tangled file its org-mode source block
+(and vice versa) via the =after-save-hook=.
+
+Desired tangling actions can be assymetric depending on whether the
+org-mode source block header argument =:tangle-sync = has an
+action of:
+
+- =skip= :: do nothing, just save the buffer, even if the sync mode is
+active
+
+- =import= :: only pull changes from the tangled block into the
+  org-mode source block (even when visited from either)
+
+- =export= :: only pull changes from the org-mode source block into
+  the tangled block (even when visited from either)
+
+- =both= (or nil) :: freely sync changes of current buffer to
+ associated source or target
+
+
 ** Miscellaneous
 *** Blank lines after removed objects are not retained during export
 
diff --git a/lisp/ob-tangle-sync.el b/lisp/ob-tangle-sync.el
index 61c23f647..cfa6abdd2 100644
--- a/lisp/ob-tangle-sync.el
+++ b/lisp/ob-tangle-sync.el
@@ -44,7 +44,6 @@
 (define-minor-mode org-babel-tangle-sync-mode
   "Global minor mode that synchronizes tangled files after every save."
   :global t
-  :interactive t
   :lighter " o-ts"
   (if org-babel-tangle-sync-mode
   (add-hook 'after-save-hook 'org-babel-tangle-sync-synchronize nil t)
@@ -57,8 +56,8 @@ here are subject to the org-babel-tangle-sync treatment.  If nil,
 then all org files with tangle headers are considered."
   :group 'org-babel-tangle-sync
   :type 'list
-  :package-version '(Org . "9.6.5")
-  :set (lambda (_var val) (mapcar #'(lambda (x) (expand-file-name x)) val)))
+  :package-version '(Org . "9.7")
+  :set (lambda (var val) (set var (mapcar #'expand-file-name val
 
 
 (defun org-babel-tangle-sync--babel-tangle-jump (link block-name)
@@ -95,15 +94,15 @@ If the cursor is either within the source file or in destination
 tangled file, perform a desired tangling action.  The tangling
 action by default is to detangle the tangled files' changes back
 to its source block, or to tangle the source block to its tangled
-file.