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
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 wil
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.
>
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
> ^
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 t
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
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
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
frequency of my emails today)
Best,
Mehmet
From 020992b46b5a7c2ae18c677afb5c29c00de58059 Mon Sep 17 00:00:00 2001
From: Mehmet Tekman
Date: Tue, 1 Aug 2023 05:14:46 +0200
Subject: [PATCH 1/3] * testing/lisp/test-ob.el: New tests for merge-params
(test-ob/get-src-block-property):
(test-ob/merge
e how accurate or value this is.
I've been reordering and splitting commits for a while now, but I think
it's really not easy to seperate the new tangle-sync component from my
merge-params rewrite.
I've attached my patches, including fixes from the last review you gave
- I hope y
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 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
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
lated ones are failing so I'll need
to dig more into what's going on there. Attached is the 3rd patch
Best
From 3f39671f3ec55e6db076f2b1b5ccad12380eb32a Mon Sep 17 00:00:00 2001
From: Mehmet Tekman
Date: Thu, 3 Aug 2023 08:22:03 +0200
Subject: [PATCH 3/3] * lisp/ob-core.el (org-babel-me
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
Yep, signed and received May 10 2023, before I did my initial
patch submission
RT: 1938590
Best
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
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
>
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
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,
ambiguities
when resolving `:tangle' headers. This turned out to be a
general problem for any header that had multiple parameters, so
the merge-params function was re-written. This introduced some
ambiguities in itself, so we decided to write a better testing
framework for it.
> M
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
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
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
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
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
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
>> 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.
>>
>
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 i
(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
;, and
I think in a previous rendition of ob-tangle-sync.el, I called
`org-babel-detangle' interactively. But I see now that I no
longer directly call it anywhere in my edited code, so I can
easily change it back.
Attached is a patch
Best
On Wed, 3 May 2023 at 04:35, Ruijie Yu wrote:
&
e-sync.el
diff --git a/lisp/ob-tangle-sync.el b/lisp/ob-tangle-sync.el
new file mode 100644
index 0..35513fff2
--- /dev/null
+++ b/lisp/ob-tangle-sync.el
@@ -0,0 +1,130 @@
+;;; ob-tangle-sync.el --- Synchronize Source Code and Org Files -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2009-2
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.
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
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
> 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
ing: t; -*-
+
+;; Copyright (C) 2009-2023 Free Software Foundation, Inc.
+
+;; Author: Mehmet Tekman
+;; Keywords: literate programming, reproducible research
+;; URL: https://orgmode.org
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;;
37 matches
Mail list logo
