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

João Pedro writes: > I'd like to ask if I could contribute to this. I have followed the > discussion to a point, but would be more than happy to try and > contribute to this so it gets merged for the next Org major version, as > I've been waiting for this for quite a while now. It solves the majo

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

João Pedro writes: > I'd like to ask if I could contribute to this. I have followed the > discussion to a point, but would be more than happy to try and > contribute to this so it gets merged for the next Org major version, as > I've been waiting for this for quite a while now... It has been ove

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

Hello! João Pedro writes: > So, if I understand correctly, =header-reform= is where we're at right > now and after we're done with this overhauling of the parsing of > (mutually exclusive) header params, we'll get back to the actual syncing > logic, which should be mostly done. Exactly -- ref

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

João Pedro writes: >>Something that handles tangle-params and result-params, > > 1. So the idea is to continue parsing multi-option header arguments into >their separate components, but have a common place to, after parsing >it into their components, handle them all in a single place?

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

Mehmet Tekman writes: > Okay, I've cleaned up my branches and rebased where I could, and now I > think my code is at a place where you can jump in. > > This will be a long email summarizing what's been done so far, where the > pitfalls were, where we are now, and what needs to be done: > ... Tha

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

Em domingo, 05/05/2024 às 18:47 (+02), Mehmet Tekman escreveu: > Hello João and org! Hi Mehmet! > This will be a long email summarizing what's been done so far, where the > pitfalls were, where we are now, and what needs to be done: Thank you for the summary. Albeit long, it was quite importa

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

Hello João and org! Mehmet Tekman on 29/04/2024 wrote: >> Can you wait until Sunday for me to resolve this, and then we can >> discuss? Okay, I've cleaned up my branches and rebased where I could, and now I think my code is at a place where you can jump in. This will be a long email summarizi

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

Em segunda, 29/04/2024 às 09:43 (+02), Mehmet Tekman escreveu: > The development is happening chaotically on my own repo > (gitlab.com/mtekman/org-mode) across several incomplete branches. > > I've actually been working on it on and off for the last two weeks, but > I've been facing some rebasin

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

Hello! João Pedro writes: > I'd like to ask if I could contribute to this. I have followed the > discussion to a point, but would be more than happy to try and > contribute to this so it gets merged for the next Org major version, That's the plan, and I'll happily take any help I can get. >

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

Hey Mehmet and Org! I'd like to ask if I could contribute to this. I have followed the discussion to a point, but would be more than happy to try and contribute to this so it gets merged for the next Org major version, as I've been waiting for this for quite a while now. It solves the major gripe

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

Hey, Ihor Radchenko writes: > Sorry for the late reply. Just got around to process your email. All good, I know how it is, especially the grind towards the end of the year. >> + (setq action "export" >> +file (read-char raw-tangle > ^

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

Sorry for the late reply. Just got around to process your email. Mehmet Tekman writes: > I made some small edits a few months ago, to reform the header arguments > so that tangle actions would be encoded in the `:tangle-params' header > and would largely leave the `:tangle' header alone… but whe

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

Ihor Radchenko writes: > Mehmet Tekman writes: > >> Okay, I will definitely need to refactor my patches then, but I'm >> quite happy with the state of my current patch branch, so it will >> be an additional patch instead of a brand new set of patches >> I think. > > It has been a while since the

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

Mehmet Tekman writes: > Okay, I will definitely need to refactor my patches then, but I'm > quite happy with the state of my current patch branch, so it will > be an additional patch instead of a brand new set of patches > I think. It has been a while since the most recent message in this thread

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

Mehmet Tekman writes: > Ihor Radchenko writes: > >> No. :result-params is not an actual header argument. It is >> implementation detail - parsing :results header arg internally produces >> (:results . "all the values concatenated") and _also_ (:result-params >> "val 1" "val 2" ...). > > Hmm... w

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

Ihor Radchenko writes: > No. :result-params is not an actual header argument. It is > implementation detail - parsing :results header arg internally produces > (:results . "all the values concatenated") and _also_ (:result-params > "val 1" "val 2" ...). Hmm... what is the benefit if they encode

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

Mehmet Tekman writes: > Hello, I'm a bit overworked at the moment, sorry for the delay in > response. No worries. We are not in hurry. Take your time as needed and comfortable. >> We may have to use the approach employed for :results header argument >> where in addition to (:results . "string v

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

Hello, I'm a bit overworked at the moment, sorry for the delay in response. > We may have to use the approach employed for :results header argument > where in addition to (:results . "string value"), we have > (:result-params "sub-value" "sub-value" ...). Isn't this similar to my `:tangle-sync' p

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

Mehmet Tekman writes: > Anyway, I finally did it - I got it to work. Every single patch now > pasts tests. Consider the following edge case: #+PROPERTY: header-args :tangle "file name with spaces and no word.txt" #+begin_src emacs-lisp :tangle sync #+end_src With your patch, I got :tangle "fi

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

Hello > #+begin_src lang :tangle yes foo no bar baz "foo bar" > should yield > '("yes" "foo" "no" "bar" "baz" #("foo bar" 0 7 (org-babel-quote t))) > We will allow using quotes to include whitespace. > In such scenarios, we still capture this unknown value. > This is useful for some third-party b

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

Mehmet Tekman writes: > * Under vanilla `org-babel-merge-params', any number of :tangle header > values are permitted and concatenated together. > > e.g 4: > __ > ´ > (should ;; 4. > override-document-and-parent-header-with-local-tfile-and-action > (equal '(:tangle "rand

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

Ignore the patches in that last email, (but please do address some of the concerns I had about the number of `:any` outputs). Anyway, I finally did it - I got it to work. Every single patch now pasts tests. Please review these patches and *not the patches in the last email*. (Apologies for the fr

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

Ihor Radchenko writes: > > Side note: I had one newly added test failing on the latest main. You > may need to rebase your branch and check if tests are still passing. > The rebase was fine, but I'm having a problem aligning my patch branch to work without any tangle involvement. The first hurd

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

Mehmet Tekman writes: > Pre-weekend update: I have a `merge-params' solution, and it's passing tests. Side note: I had one newly added test failing on the latest main. You may need to rebase your branch and check if tests are still passing. > I will need to refactor/cherry pick my branch someho

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

Pre-weekend update: I have a `merge-params' solution, and it's passing tests. I will need to refactor/cherry pick my branch somehow to make the patch less "tangle sync"-centric, but I'm sure I can make it work. On Thu, 3 Aug 2023 at 10:46, Mehmet Tekman wrote: > > > You dropped mailing list from

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

> You dropped mailing list from the CC. Was it intentional? Whoops, no. Still figuring out an email solution in emacs. > If I understand your concern correctly, you may simply let-bind > `org-babel-common-header-args- > w-values' in the tests to make sure that > your new parameter merging code is

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

Mehmet Tekman writes: >> setq unexplained-params (delete-dups unexplained-params)) > > The help mentions that it stores the result in the list, and it looks > like it works > > #+BEGIN_SRC elisp > (let ((x '(1 2 1 2 3))) (delete-dups x) x) > #+END_SRC This is just implementation detail. As a gen

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

Thanks for the review! > setq unexplained-params (delete-dups unexplained-params)) The help mentions that it stores the result in the list, and it looks like it works #+BEGIN_SRC elisp (let ((x '(1 2 1 2 3))) (delete-dups x) x) #+END_SRC > > What we can do it make `org-babel-read' assign a text

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

Mehmet Tekman writes: >It's a big patch mostly, because there were no intermediate commits >in which the org framework wouldn't be broken. Hope that's okay! Sure it is. > ** Problems > > It seems to work well for most tests, except for the "file with > spaces.txt" which I'm not sure how

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

Okay, and now I've patched the related string splitting functions so that ("let's get \"ready to rumble\" now") is split into: ("let's" "get" "ready to rumble" "now") All my tests are passing but a few unrelated ones are failing so I'll need to dig more into what's going on there.

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

Hello again, I've attached two patches: 1. Tests for the existing merge parameters function, based on your last edits to my previous patch. 2. A rewrite of the entire merge parameters function, with the new tangle sync actions. It's a big patch mostly, because there were no intermediat

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

Bastien Guerry writes: >> Bastien, may you please confirm? > > Yes, I do confirm. Thanks Mehmet for contributing! Thanks! Updated our records. https://git.sr.ht/~bzg/worg/commit/70026249 -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at .

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

Ihor Radchenko writes: > Mehmet Tekman writes: > >> Yep, signed and received May 10 2023, before I did my initial >> patch submission >> >> RT: 1938590 > > Bastien, may you please confirm? Yes, I do confirm. Thanks Mehmet for contributing! -- Bastien Guerry

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

Mehmet Tekman writes: > Yep, signed and received May 10 2023, before I did my initial > patch submission > > RT: 1938590 Bastien, may you please confirm? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at

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

Yep, signed and received May 10 2023, before I did my initial patch submission RT: 1938590 Best

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

Mehmet Tekman writes: > But I think you're right, and tomorrow evening I will just bite the bullet and > submit a merged-params patch. That is: > * An updated merged params function > * New testing suite for the merge params Thanks! May I know if you have FSF copyright assignment? (see https://o

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

Ihor Radchenko writes: > Is there any specific reason why you want to merge these tests now and > not later, when you submit the full patch? Convenience on my part, and closure of the many many patch branches that I have open. But I think you're right, and tomorrow evening I will just bite the

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

Mehmet Tekman writes: > I've adapted this to write a git patch which currently passes with > upstream/main, and contains a few `should-not` statements which are > planned to be `should` statements after the merge function has been > patched for the `:tangle' multi-parameter property. I do not li

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

Hello Ihor Radchenko writes: > > > Mehmet Tekman writes: > > Question: What is the order of submission of patches? > > > >Do I submit a testing patch first which works strictly with > >vanilla Org first, and then a new merge-params function, and > >then yet another testing patch that

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

Mehmet Tekman writes: >> Another meetup is on July 26. https://emacs-berlin.org/ >> Or we can arrange a jitsi call. > > Sure, I can be there tomorrow! Ok. There are several talks planned at the beginning, and we may discuss your patch after those. >> The tests are indeed not passing on vanilla

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

Ihor Radchenko writes: > Another meetup is on July 26. https://emacs-berlin.org/ > Or we can arrange a jitsi call. Sure, I can be there tomorrow! > To name them, you can use separate ert-deftest statements. Oh sure, but I don't want to clutter the library. > Also, see the attached modified ve

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

Mehmet Tekman writes: >> P.S. There going to be Emacs meetup this Saturday, July 22 >> (https://emacs-apac.gitlab.io/announcements/july-2023/). I plan to be >> there and, if you need it, we can try to resolve difficulties in more >> interactive way. > > I am currently travelling this weekend, oth

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

Hello > Ihor Radchenko writes: > > P.S. There going to be Emacs meetup this Saturday, July 22 > (https://emacs-apac.gitlab.io/announcements/july-2023/). I plan to be > there and, if you need it, we can try to resolve difficulties in more > interactive way. I am currently travelling this weekend,

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

Mehmet Tekman writes: >> ... I will rewrite to to conform to the >> `org-test-with-temp-text' examples. > > So I've just rewritten the `merge-params' testing function I > wrote before, this time using the `org-test-with-temp-text' > method/macro. Side note: You are re-implementing the already av

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

Hello again! > Ihor Radchenko writes: > > Two months have passed since the last message in this thread. > Mehmet, have you had a chance to work on this? May you need any help? General recap of where we are so far with this patch: The tangle-sync mode I wished to implement had some ambiguities

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

Apologies, this patch has been burning in the back of mind for a while now, but I keep getting distracted with other random side projects. I appreciate the wake up call, and I will refocus my efforts next week in my free time. Best, Mehmet

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

Mehmet Tekman writes: > ... I will rewrite to to conform to the > `org-test-with-temp-text' examples. Two months have passed since the last message in this thread. Mehmet, have you had a chance to work on this? May you need any help? -- Ihor Radchenko // yantar92, Org mode contributor, Learn m

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

Ah, running `org-lint' and correcting the header line as well as adding languages to the other blocks fixed the mistakes - thanks for this, I thought I was losing my mind. Ihor Radchenko writes: > The expected result is (:tangle . "yes") for the first block and > (:tangle . "file with spaces.t

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

Mehmet Tekman writes: >> See the above 3 examples: (1) "foo.txt" shadowed by "no"; (2) "no" >> shadowed by "foo.txt"; (3) "no" shadowed by "foo.txt" then shadowed by >> "yes". >> >> You can also consider "foo.txt" shadowed by "bar.txt" and other >> variations. > > I've created a small patch that

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

Hello again, Ihor Radchenko writes: >>> I recommend trying various edge cases with your patch. >>> In particular: >>> >>> 1. Testing exclusive group inheritance when we inherit a header arg >>>value that matches :any: >>> >>>#+PROPERTIES: header-args :tangle "foo.txt" >>>#+begin_src

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

Mehmet Tekman writes: >> I feel confused when reading the modified code. >> > > Okay, I guess comments are not my strong suit. I will try to remove any > unnecessary comments and use better variable names. No, comments were useful. They revealed that our understanding of the expected behaviour m

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

Hello, thanks for the last review and sorry for the lapse in communication. May is proving to be a very strange month. Ihor Radchenko writes: > Mehmet Tekman writes: >> >> I've modified the `merge' function within `org-babel-merge-params' so >> that the main logic now accumulates a list of po

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

Mehmet Tekman writes: >> It will be great if you could do it. >> I have other things to work on. > > Of course! I'm just a little unfamiliar on how one coordinates active > collaboration via mailing list :-) Usually, we leave working on the patches to one person - whoever is the most interested

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

Ihor Radchenko writes: > It will be great if you could do it. > I have other things to work on. Of course! I'm just a little unfamiliar on how one coordinates active collaboration via mailing list :-) Anyways - I did it, and it took less time than I thought > We should modify it. For example l

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

mtekma...@gmail.com writes: >>In other words, we will need a special match for :any - "anything not >>equal to other values in all the groups combined". > > Agreed, and I can try putting together something working in a day or > two. Or, if this is something you can easily implement yoursel

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

Ihor Radchenko writes: > 1. We will assume that :any can only occur one time in the exclusive >groups. (Otherwise, there is no single definite way to parse header >arguments) Makes sense (or we could revamp all header parsing into some kind of finite state machine… (I joke… for now…)) >

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

Mehmet Tekman writes: > I'm having some problems getting: > > `:tangle > [import/export/both/skip]' > > to work nicely with the existing framework. The main issue lies in the > `:any` keyword in `org-babel-common-header-args-w-values' for the tangle > entry making it difficult to determine where

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

Ihor Radchenko writes: > Yes. See `org-babel-common-header-args-w-values'. In particular, take a > look at (results ...). Thanks, it took me some time to get my head around how to use this. > I now ported a bit of documentation from my refactor branch. > See https://git.savannah.gnu.org/cgit/e

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

Mehmet Tekman writes: >> 3. Please do not use private functions from third-party libraries. I am >>talking about `cl--set-buffer-substring' in particular. >> > > So initially I used `(setf (buffer-substring X Y) new-content)` but I > recieved a warning from Emacs that it was an obsolete gener

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

Mehmet Tekman writes: > On closer inspection it might actually be unpractical to have the sync > action within the `:tangle' syntax, the main reason being that people > might define the tangle target in the document header for ease of use. This is not a problem. Try #+PROPERTY: header-args :re

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

>> Ihor Radchenko writes: >> >> May it be better to make :tangle header argument compound? >> Like ":tangle "file" export". Similar to :results header argument. See >> "16.6 Results of Evaluation" section of Org manual. >> > > Mehmet Tekman writes: > > That's a great idea I had not considered,

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

Ihor Radchenko writes: > Mehmet Tekman writes: >> >> One issue that I cannot seem to solve by myself is getting the >> `org-babel-tangle-sync-mode' to persist on the `after-save-hook' >> after it's been activated. My understanding of this hook is >> that it is global and persists across buffe

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

Mehmet Tekman writes: > I've modified the ob-tangle.el file for the main tangling and > detangling functions. Most importantly, both functions can now > exchange information from the source Org mode file to the target > remote tangle file in either direction, depending on whether the > source Or

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

Mehmet Tekman writes: > (Sorry for the previous top posting.) > > One issue that I cannot seem to solve by myself is getting the > `org-babel-tangle-sync-mode' to persist on the `after-save-hook' > after it's been activated. My understanding of this hook is > that it is global and persists acros

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

(Sorry for the previous top posting.) One issue that I cannot seem to solve by myself is getting the `org-babel-tangle-sync-mode' to persist on the `after-save-hook' after it's been activated. My understanding of this hook is that it is global and persists across buffers, but I'm seeing some inco

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

> I noticed that you modified argument order of a public function > `org-babel-detangle' -- is it possible that you retain the order of > arguments? Good catch - I think I changed the order so that it would match the interactivity of its sister function `org-babel-tangle', and I think in a previou

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

Mehmet Tekman writes: > Hello again, sorry for the delay - I had some holiday time off > that couldn't wait ;-) > > I've modified the ob-tangle.el file for the main tangling and > detangling functions. Most importantly, both functions can now > exchange information from the source Org mode fil

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

Hello again, sorry for the delay - I had some holiday time off that couldn't wait ;-) I've modified the ob-tangle.el file for the main tangling and detangling functions. Most importantly, both functions can now exchange information from the source Org mode file to the target remote tangle file in

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

Ruijie Yu writes: > Thanks. Can you make a full patch from the current main branch to your > changes, with a commit message and so on? This would help reviewers to > look at the full picture of what are modified. Take a look at the > manpage git-format-patch(1) if you aren't sure how to do it.

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

Mehmet Tekman writes: > 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

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

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 functi

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

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

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

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 (va

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

Mehmet Tekman writes: > Dear fellow org-users, > > 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-ho

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

> For the sake of consistency, perhaps import and export, rather than pull and > export? And, great idea! Absolutely - unless the "pull" / "push" crowd wants to chime in! I'm also not 100% sold on the "both" action keyword. There, writing "sync" would make more sense, but I'm hesitant to write a

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

> "MT" == Mehmet Tekman writes: MT> - skip :: do nothing, just save the buffer, even if the sync mode is MT> active MT> - pull :: only pull changes from =~/.bashrc= into the Emacs_conf org-mode file MT> - export :: only export changes from Emacs_conf to =~/.bashrc=, even if called