Re: Question on contributing to Org-mode
Ag Ibragimov writes: > M-x emacs-version and org-version report: > > GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.5.0, NS appkit-1894.50 > Version 10.15.5 (Build 19F101)) of 2020-06-07 > Org mode version 9.3.7 (9.3.7-2-g706970-elpaplus @ > ~/.emacs.d/elpa/28.0/develop/org-plus-contrib-20200608/) > > Now I'm confused, what's in master of bzg/org-mode? It contains what will be the next feature release (9.4, at the moment). Notice that your reported version above contains a git revision: 706970. If you look that up in the repo, you'll find that it's a few commits back from the current tip of the maint branch. The maint branch is the source for the ELPA builds and is where bug fix releases are cut from. > And if someone wants to send patches, which branch it should be based > of? Bug fixes that apply to maint should ideally be based off of maint, and master is usually appropriate for everything else.
Re: [PATCH] allow for multiline headers
Hi Nicolas, On 13/06/2020 17:18, Nicolas Goaziou wrote: Hello, Mario Frasca writes: I can leave existing loops in peace, or edit them keeping them cl-loop-free. as for myself, I find it practical and readable. Then you'll enjoy reading, e.g., `org-contacts-try-completion-prefix'. FWIW, I don't. oops. I do see your point here. no, at this level, it's not pleasant any more. I don't know Org Plot enough, but these expectations should be located in "org-plot.el". I expect `org-table-to-lisp' to be as faithful as possible. In particular, this function is used in `org-table-align'; as such, it should not do anything fancy. I have removed the changes, and added some tests that freeze the current behaviour. that was already in the last patch I sent. Unit tests are not worth a formal definition. However, "test-ox.el" contains unit tests. I'm not sure what you mean by the first sentence, but I found the header tests in the test-ox.el file, and added one where multiple lines header is accepted. is it related enough as to be included in my proposal? to me, unit tests are readable function definitions, often the best form of technical documentation. I have had colleagues writing tests that weren't "unitary" at all, mixing all sort of elements together. when written as an after-thought, it's a serious risk. So, if your question is: "should Org support multiple lines headers?", I'd say that it already does, but it should definitely be made more consistent across the various libraries (e.g., Org Plot). I can move the org-table-collapse-header function from org-table.el to org-plot.el, but to me it makes little sense, relegating a generic function to a sub-module: others will look for the functionality in org-table, not see it, and duplicate the function somewhere else. for example, do I understand it correctly, that the concept defined in the export functionality, but not in org-table itself? anyhow, what do we do next? MF >From b407252fc82d29646d267974c626dbc30145f07f Mon Sep 17 00:00:00 2001 From: mfrasca Date: Fri, 12 Jun 2020 11:42:34 -0500 Subject: [PATCH] lisp/org-table.el: Allow collapsing header into single line * lisp/org-table.el (org-table-collapse-header): new function that collapses multiple header lines into one list. * lisp/org-plot.el (org-plot/gnuplot): use org-table-collapse-header and trust there will be no more leading `hline' symbols in lisp table. * testing/lisp/test-org-table.el (test-org-table/to-lisp): adding tests to already existing to-lisp function. (test-org-table/collapse-header): adding tests to new collapse-header function. * testing/lisp/test-ox.el (test-org-export/has-header-p): testing exporting table with multi-line header. --- lisp/org-plot.el | 6 ++-- lisp/org-table.el | 27 testing/lisp/test-org-table.el | 58 ++ testing/lisp/test-ox.el| 10 ++ 4 files changed, 97 insertions(+), 4 deletions(-) diff --git a/lisp/org-plot.el b/lisp/org-plot.el index a23195d2a..662d38e54 100644 --- a/lisp/org-plot.el +++ b/lisp/org-plot.el @@ -289,11 +289,9 @@ line directly before or after the table." (setf params (plist-put params (car pair) (cdr pair) ;; collect table and table information (let* ((data-file (make-temp-file "org-plot")) - (table (org-table-to-lisp)) - (num-cols (length (if (eq (nth 0 table) 'hline) (nth 1 table) - (nth 0 table) + (table (org-table-collapse-header (org-table-to-lisp))) + (num-cols (length (nth 0 table (run-with-idle-timer 0.1 nil #'delete-file data-file) - (while (eq 'hline (car table)) (setf table (cdr table))) (when (eq (cadr table) 'hline) (setf params (plist-put params :labels (nth 0 table))) ; headers to labels diff --git a/lisp/org-table.el b/lisp/org-table.el index 6462b99c4..c40ad5bea 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -5458,6 +5458,33 @@ The table is taken from the parameter TXT, or from the buffer at point." (forward-line)) (nreverse table) +(defun org-table-collapse-header (table glue max-header-lines) + "Collapse the lines before 'hline into a single header. + +The given TABLE is a list of lists as returned by `org-table-to-lisp'. +The leading lines before the first `hline' symbol are considered +forming the table header. This function collapses all leading header +lines into a single header line, followed by the `hline' symbol, and +the rest of the TABLE. Header cells are GLUEd together with a space, +or the given character." + (setq glue (or glue " ")) + (setq max-header-lines (or max-header-lines 4)) + (while (equal 'hline (car table)) +(setq table (cdr table))) + (let* ((trailer table) + (header-lines (cl-loop for line in table +until (equal line 'hline) +collect line +do (setq trailer (cdr trailer) +(if (and trailer (<= (length header-lines) max-header-lines)) +
Re: [PATCH] allow for multiline headers
Hello, Mario Frasca writes: > is there an agreement on cl-lib usage within the project? Using cl-lib is OK, even though I wish we could use "seq.el" instead. > I was hinted at cl-loop in this mailing list, and I liked it, in > particular the `collect' clause, the destructuring feature, and less > parentheses. That's exactly my point. It does way too much, and it is very far from Lisp. Since it does so much stuff, it is tempting to use it all over the place, for every single iteration. And then, your code doesn't look like Lisp anymore. See how they defaced that poor "org-contacts.el" =/ > I can leave existing loops in peace, or edit them keeping them > cl-loop-free. as for myself, I find it practical and readable. Then you'll enjoy reading, e.g., `org-contacts-try-completion-prefix'. FWIW, I don't. > this is not a correct description of the current status, at least not > within org-plot. > > (let ((table (org-table-to-lisp)) … > > in org-plot we expect either the first or the second element of > `table' to be a list; > > any leading `hline' is removed; I don't know Org Plot enough, but these expectations should be located in "org-plot.el". I expect `org-table-to-lisp' to be as faithful as possible. In particular, this function is used in `org-table-align'; as such, it should not do anything fancy. > a table looking like hline-header-hline-data is treated as having > a header, while your description says it's all data, no header, > because of the leading hline. The manual states: Rows before the first horizontal rule are header lines. But you are right, this is ambiguous. Moreover, I mis-remembered how I defined header lines in the export framework. Per "ox.el", the header is the first row group. A row group is a group of one or more data rows located between row separators or table boundaries. This is more accurate than the above. > but in my opinion if there's any problem or misunderstanding here, > it's because there's no unit tests that describe the correct > behaviour. can we work at that? Unit tests are not worth a formal definition. However, "test-ox.el" contains unit tests. > anyhow, what do you think of the multiple-lines-header option? Multiple lines header are already a thing, at least in the export framework. Try to export, e.g., | a | | b | |---| | c | in HTML. They are also assumed to be valid in the manual, per above. So, if your question is: "should Org support multiple lines headers?", I'd say that it already does, but it should definitely be made more consistent across the various libraries (e.g., Org Plot). Regards, -- Nicolas Goaziou
Question on contributing to Org-mode
I have never ever before tried contributing patches to Org-mode, mainly because it is such a big project that I am rarely sure if whatever I'm trying to do is right. Finally, I've found something that perhaps I could improve. Namely, I wanted to extend Clojure code blocks to be executed with clj command line tool and babashka. I have cloned the project from https://code.orgmode.org/bzg/org-mode, found ob-clojure.el and realized that org-babel-execute:clojure function is not the same as the one is being used in my Emacs. M-x emacs-version and org-version report: GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.5.0, NS appkit-1894.50 Version 10.15.5 (Build 19F101)) of 2020-06-07 Org mode version 9.3.7 (9.3.7-2-g706970-elpaplus @ ~/.emacs.d/elpa/28.0/develop/org-plus-contrib-20200608/) Now I'm confused, what's in master of bzg/org-mode? And if someone wants to send patches, which branch it should be based of?
Re: [PATCH] allow for multiline headers
what about these two groups of tests, and the header collapse function?
>From ceb21024159a75dbdb9fef32eebe1fc8c7076d2f Mon Sep 17 00:00:00 2001
From: mfrasca
Date: Fri, 12 Jun 2020 11:42:34 -0500
Subject: [PATCH] lisp/org-table.el: Allow collapsing header into single line
* lisp/org-table.el (org-table-collapse-header): new function that
collapses multiple header lines into one list.
* lisp/org-plot.el (org-plot/gnuplot): use org-table-collapse-header
and trust there will be no more leading `hline' symbols in lisp table.
* testing/lisp/test-org-table.el (test-org-table/to-lisp):
adding tests to already existing to-lisp function.
(test-org-table/collapse-header): adding tests to new
collapse-header function.
---
lisp/org-plot.el | 6 ++--
lisp/org-table.el | 27
testing/lisp/test-org-table.el | 58 ++
3 files changed, 87 insertions(+), 4 deletions(-)
diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index a23195d2a..662d38e54 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -289,11 +289,9 @@ line directly before or after the table."
(setf params (plist-put params (car pair) (cdr pair)
;; collect table and table information
(let* ((data-file (make-temp-file "org-plot"))
- (table (org-table-to-lisp))
- (num-cols (length (if (eq (nth 0 table) 'hline) (nth 1 table)
- (nth 0 table)
+ (table (org-table-collapse-header (org-table-to-lisp)))
+ (num-cols (length (nth 0 table
(run-with-idle-timer 0.1 nil #'delete-file data-file)
- (while (eq 'hline (car table)) (setf table (cdr table)))
(when (eq (cadr table) 'hline)
(setf params
(plist-put params :labels (nth 0 table))) ; headers to labels
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 6462b99c4..c40ad5bea 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -5458,6 +5458,33 @@ The table is taken from the parameter TXT, or from the buffer at point."
(forward-line))
(nreverse table)
+(defun org-table-collapse-header (table glue max-header-lines)
+ "Collapse the lines before 'hline into a single header.
+
+The given TABLE is a list of lists as returned by `org-table-to-lisp'.
+The leading lines before the first `hline' symbol are considered
+forming the table header. This function collapses all leading header
+lines into a single header line, followed by the `hline' symbol, and
+the rest of the TABLE. Header cells are GLUEd together with a space,
+or the given character."
+ (setq glue (or glue " "))
+ (setq max-header-lines (or max-header-lines 4))
+ (while (equal 'hline (car table))
+(setq table (cdr table)))
+ (let* ((trailer table)
+ (header-lines (cl-loop for line in table
+until (equal line 'hline)
+collect line
+do (setq trailer (cdr trailer)
+(if (and trailer (<= (length header-lines) max-header-lines))
+ (cons (apply #'cl-mapcar
+ #'(lambda ( x)
+ (org-trim
+ (mapconcat #'identity x glue)))
+ header-lines)
+ trailer)
+ table)))
+
(defun orgtbl-send-table ( maybe)
"Send a transformed version of table at point to the receiver position.
With argument MAYBE, fail quietly if no transformation is defined
diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el
index 64a1b4b16..5d54f4999 100644
--- a/testing/lisp/test-org-table.el
+++ b/testing/lisp/test-org-table.el
@@ -1304,6 +1304,64 @@ See also `test-org-table/copy-field'."
(should (string= got
expect)
+;;; the initial to lisp converter
+
+(ert-deftest test-org-table/to-lisp ()
+ "Test `orgtbl-to-lisp' specifications."
+ ;; 2x2 no header
+ (should
+ (equal '(("a" "b") ("c" "d"))
+ (org-table-to-lisp "|a|b|\n|c|d|")))
+ ;; 2x2 with 1-line header
+ (should
+ (equal '(("a" "b") hline ("c" "d"))
+ (org-table-to-lisp "|a|b|\n|-\n|c|d|")))
+ ;; 2x4 with 2-line header
+ (should
+ (equal '(("a" "b") ("A" "B") hline ("c" "d") ("aa" "bb"))
+ (org-table-to-lisp "|a|b|\n|A|B|\n|-\n|c|d|\n|aa|bb|")))
+ ;; leading hlines do not get stripped
+ (should
+ (equal '(hline ("a" "b") hline ("c" "d"))
+ (org-table-to-lisp "|-\n|a|b|\n|-\n|c|d|")))
+ (should
+ (equal '(hline ("a" "b") ("c" "d"))
+ (org-table-to-lisp "|-\n|a|b|\n|c|d|")))
+ (should
+ (equal '(hline hline hline hline ("a" "b") ("c" "d"))
+ (org-table-to-lisp "|-\n|-\n|-\n|-\n|a|b|\n|c|d|"
+
+(ert-deftest test-org-table/collapse-header ()
+ "Test `orgtbl-to-lisp' specifications."
+ ;; 2x2 no header - no collapsing
+ (should
+ (equal '(("a" "b") ("c" "d"))
+ (org-table-collapse-header (org-table-to-lisp "|a|b|\n|c|d|"
+ ;; 2x2 with 1-line header - no collapsing
+ (should
+ (equal '(("a" "b") hline ("c" "d"))
+ (org-table-collapse-header (org-table-to-lisp "|a|b|\n|-\n|c|d|"
+ ;; 2x4 with 2-line header - collapsed
+ (should
+ (equal '(("a A" "b B") hline ("c" "d") ("aa" "bb"))
+
Re: [PATCH] allow for multiline headers
hi Nicolas, is there an agreement on cl-lib usage within the project? I was hinted at cl-loop in this mailing list, and I liked it, in particular the `collect' clause, the destructuring feature, and less parentheses. I had no exposure to cl-loop before the hint received here. I can leave existing loops in peace, or edit them keeping them cl-loop-free. as for myself, I find it practical and readable. let's say I'll try to limit usage. On 12/06/2020 17:44, Nicolas Goaziou wrote: Also, the first hline is used to determine where to end the header. A table starting with a hline has no header. Therefore, I suggest to avoid removing hlines at the beginning of a table, we would lose information. this is not a correct description of the current status, at least not within org-plot. (let ((table (org-table-to-lisp)) … in org-plot we expect either the first or the second element of `table' to be a list; any leading `hline' is removed; if the second element of `table' is a hline, the first element of `table' is considered to be the header (in this case -and only in this case- any subsequent `hline' is then removed from `table'); the presence of hline elements in `table' will crash the routine. -- a table looking like hline-header-hline-data is treated as having a header, while your description says it's all data, no header, because of the leading hline. but in my opinion if there's any problem or misunderstanding here, it's because there's no unit tests that describe the correct behaviour. can we work at that? in fact, there's not even a org-table-headers function, that would return the table headers. anyhow, what do you think of the multiple-lines-header option? MF
Re: Bug: fontification error with #end_src in 9.3.7 [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)]
Kyle Meyer writes: > I'll try to take a closer look tomorrow. This should be fixed by ba6ca79af.
Re: Inconsistent behaviour: toggle inline images does not work with relative paths [9.3.7 (9.3.7-2-g706970-elpa @ /Users/matthijs/.emacs.d/elpa/org-20200608/)]
Hello, Very strange. I cannot now reproduce it either. Might be because I updated some packages in the meantime or something. Guess next time I come across it I’ll need to dive into the org-toggle-inline-images function myself to see what’s going on. Sorry for keeping you busy. Regards, Matthijs de Jonge > Op 13 jun. 2020, om 18:06 heeft Nicolas Goaziou het > volgende geschreven: > > Hello, > > Matthijs de Jonge writes: > >> Today I ran into some behavior that seemed strange to me: >> >> I have inline images: >> >> [[file:relative/path/from/org-file.png]] >> >> With org-startup-with-inline-images these work as expected. >> >> What does not work as expected is org-toggle-inline-images : this does >> not disable inline image preview (though it does *enable* it). > > I cannot reproduce it. Calling `org-toggle-inline-images' twice bring me > back to link text. Could you try again with a minimal setup? > > Regards, > -- > Nicolas Goaziou
Re: tags-todo org-agenda-custom-command weirdness
Stig Brautaset writes: > Hi, > > I'm seeing some weirdness with tags-todo vs tags custom agenda commands. I forgot to mention my Emacs / Org versions: - GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.4.0, NS appkit-1894.40 Version 10.15.4 (Build 19E287)) of 2020-04-18 - Org mode version 9.3.7 (9.3.7-2-g706970-elpaplus @ /Users/stig/.emacs.d/elpa/org-plus-contrib-20200608/) Stig
Re: Statistic cookies for headings and list items
Hello, Bastien writes: > Here are a few solutions I can imagine: > > 1. when an entry contains both a list (as its direct contents) and >subheadings, only consider subheadings in the stats calculation. > > 2. when an entry contains both a list (as its direct contents) and >subheadings, only consider the list in the calculation. > > 3. if one of the two options above, allow the user to use a custom >property to change the default (e.g. CUSTOM_STATS: list/headings) >and consider the list of the subheadings. > > 4. add a new syntax rule to consider that stats at the beginning of >a headline are always for subheadings, while stats at the end of >a headline are always for the first list in direct contents. > > I'd be in favor of (1) (without (3)) to keep things simple, but > maybe that's a good opportunity to consider (4). I think (3) is > only relevant if we go for (2), which I don't really like. > > What do you think? Isn't COOKIE_DATA property there to disambiguate this situation? Regards, -- Nicolas Goaziou
Re: Inconsistent behaviour: toggle inline images does not work with relative paths [9.3.7 (9.3.7-2-g706970-elpa @ /Users/matthijs/.emacs.d/elpa/org-20200608/)]
Hello, Matthijs de Jonge writes: > Today I ran into some behavior that seemed strange to me: > > I have inline images: > > [[file:relative/path/from/org-file.png]] > > With org-startup-with-inline-images these work as expected. > > What does not work as expected is org-toggle-inline-images : this does > not disable inline image preview (though it does *enable* it). I cannot reproduce it. Calling `org-toggle-inline-images' twice bring me back to link text. Could you try again with a minimal setup? Regards, -- Nicolas Goaziou
Re: [PATCH] org-element.el: Fix properties being upcased by parser
Hello, Leo Vivier writes: > From e96e96931109026f406b3cabb0186319e902aca7 Mon Sep 17 00:00:00 2001 > From: Leo Vivier > Date: Fri, 12 Jun 2020 06:45:32 +0200 > Subject: [PATCH] org-element.el: Update comment > > * org-element.el (org-element-keyword-parser): Mention that `keyword' > is normalized by being upcased Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [RFC] Rewrite org-(forward|backward)-paragraph
Since there was no negative feedback, I pushed to master. Thanks.
Re: multiple EXPORT_LATEX_HEADER lines
Hello, On 2020-06-12 16:01, Eric S Fraga writes: > The snippet from the OP will collate all three LaTeX header lines into a > single line on export, which is expected in terms of org's > behaviour. This appears to cause problems with LaTeX, which is maybe > expected or not; I don't know what LaTeX expects when working in @ > letter mode as I've seldom (if ever?) had to redefine @ variables. This is the crux of the issue: there does not seem to be any way to generate a multi-line header. And this causes problems with LaTeX. There are two workarounds for this that I know of: put the latex in some other file and \input it, or use a dedicated file and use multiple #+LATEX_HEADER. I ended up doing it that way. Thanks, Alan signature.asc Description: PGP signature
Re: Bug: Export to html not working [9.3.7 (9.3.7-2-g706970-elpaplus @ /Users/gmauer/.emacs.d/elpa/develop/org-plus-contrib-20200608/)]
Hello, George Mauer writes: > I wrote the following literate-programming style org file > https://github.com/togakangaroo/daily-programmer/blob/master/get-directories/README.org > > When I run org-export-dispatch on this and export it to an html file it > creates a single file which - aside from the footer - contains only a > single letter `n` as contents I cannot reproduce it. You may want to test with a minimal set-up, and possibly bisect your configuration. Regards, -- Nicolas Goaziou
Re: [BUG] [C-u C-u C-c C-o] open link with external program invalid to open file
Hello, stardiviner writes: > When I press =[C-u C-u C-c C-o]= to open an image file link with system > external > program. It can't open the image file. Is it really an Org bug? I.e., is your mailcap file properly set up? If you think this is really an Org bug, could you provide an ECM, including your .mailcap? Regards, -- Nicolas Goaziou
tags-todo org-agenda-custom-command weirdness
Hi,
I'm seeing some weirdness with tags-todo vs tags custom agenda commands.
Below is the smallest case I've managed to narrow it down to. I would
*expect* that all the a1-4 commands return the same results, and that
the b1-4 return the same results. That is not what I'm seeing, however.
(setq-default org-agenda-custom-commands
'(("a1" "A1" tags-todo "-PROJ/TODO")
("a2" "A2" tags "-PROJ/TODO")
("a3" "A3" ((tags-todo "-PROJ/TODO")))
("a4" "A4" ((tags "-PROJ/TODO")))
("b1" "B1" tags-todo "-PROJ/DONE")
("b2" "B2" tags "-PROJ/DONE")
("b3" "B3" ((tags-todo "-PROJ/DONE")))
("b4" "B4" ((tags "-PROJ/DONE")
The effect of a1 & a2 appears identical to eachother, and a3 & a4 too,
but a1-2 and a3-4 differ (in that the former seems to include scheduled
items, but the latter does not.)
What I'm seeing for b1-4 is even weirder. Here I observe b1, b2 and b4
have identical behaviour[*], but b3 is the odd one out: while the other
three return a list of DONE non-project tasks, b3 doesn't find anything.
[*] I suspect the reason b2 and b4 are identical is that I have no
scheduled DONE tasks.
I also see this with =m= vs =M= in the org-agenda menu. I see it even
when starting emacs with -q, so it appears to not be some spectactular
breakage on my part. Is anyone else seing this?
Stig
Re: Bug: Option to disable evaluation of code blocks during export [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)]
Hello, I understand the frustration of not being able to bend emacs to ones immediately. But many times my initial workflow turned out not to be the best one. I just wanted to share my workflow hoping that it might be a solution to the original post problem. >> Consider the scenario where a number of people are working on a common >> overall "book" which is constructed from many org-files. The >> "hardcoded" setting of :eval no-export header in individual blocks >> would mean that I cannot interactively enable or disable the >> evaluation of the blocks. At some point, I experienced the same problem and as the document get larger and larger it tends to complicate the management of code block evaluation. I have found two solutions to this problem using existing org-mode features. * First use global property header :eval yes, but evaluate only the sub-tree of interest when the need comes. For a book it might be a part, a chapter (even a paragraph by artificially creating a sub-tree at the desired point). In that way you have only one trigger to push to disable evaluation for the entire document. To makes things quicker one can define a way to change :eval from yes to no very quickly. (I use point registers for this purpose (info "(emacs) Registers"), but you could imagine a function with key-bindings) * Second The second solution could be to use checkpoints with cache for instance. Let say that, one wants to work on Part 1 only and wants to evaluate code just for this part then. The following work flow might be suitable. * Part 1 :PROPERTIES: :header-args: :eval yes :cache yes :END: #+BEGIN_SRC matlab A = [16 3 2 13; 5 10 11 8; 9 6 7 12; 4 15 14 1] #+END_SRC ** strip the header row #+BEGIN_SRC matlab A = [1 ; 2], B = A.', C = transpose(A) #+END_SRC * Part 2 :PROPERTIES: :header-args: :eval no :cache yes :END: #+BEGIN_SRC matlab ones(3,3) #+END_SRC HTH, Jeremie
Re: Get Grades Done: the joys of Org's simple power
Hi Leo, > Well the changelog in org-web hasn't been updated in quite a while: > https://github.com/DanielDe/org-web/blob/master/changelog.org > wheras organice seem to actively developed > https://github.com/200ok-ch/organice/blob/master/changelog.org . > > The have a section in their readme that shows how they differ: > https://github.com/200ok-ch/organice#org-web Awesome, thanks for the additional pointers! Devin: Organice supports online editing of files hosted on Dropbox, Google Drive or WebDAV - maybe this would fit your use case? --Diego --Diego
Re: Bug: Option to disable evaluation of code blocks during export [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)]
Hello, John Ciolfi writes: > Perhaps, in the interactive C-c C-e mode there could be: > > [C-e] Eval code blocks: always | never | use-eval-header-setting > > where 'use-eval-header-settings' is the default and uses whatever was > set by the current org file and emacs session. Always and never would > override that. As I said, this would add an indirection level to an already complicated topic. Moreover, toggles in the export interface are never duplicates from in-buffer settings, so far. This would set a precedent, and might be a sign that this isn't right. > Consider the scenario where a number of people are working on a common > overall "book" which is constructed from many org-files. The > "hardcoded" setting of :eval no-export header in individual blocks > would mean that I cannot interactively enable or disable the > evaluation of the blocks. Why would you add :eval no-export to every block in the first place? In this situation, there should be a global setting, which could be overridden locally with appropriate header arguments. Having a global way, even dynamic, to override every setting in the buffer doesn't seem very useful. It is imprecise; some blocks could still be used to set up export process. I assume there's a good reason if a source code block specifies :eval yes. > Part of my confusion was that it took a little bit to figure this out > (I ended up debugging the lisp code to get what I wanted). I think > this could be improved in the doc, though I do admit, I'm not entirely > clear on all the ways to control evaluation of code blocks during > export. If I were, I'd propose something for the org manual. I think the starting point is in (info "(org) Exporting Code Blocks"). Improvements to the manual are welcome, of course. Regards, -- Nicolas Goaziou
Re: Get Grades Done: the joys of Org's simple power
Diego Zamboni writes: > Hi Leo, > > Thanks - I had seen that one too, and couldn't figure out which one > was a fork of the other one. Both have recent activity - do you know > what are the main differences between them? > Well the changelog in org-web hasn't been updated in quite a while: https://github.com/DanielDe/org-web/blob/master/changelog.org wheras organice seem to actively developed https://github.com/200ok-ch/organice/blob/master/changelog.org . The have a section in their readme that shows how they differ: https://github.com/200ok-ch/organice#org-web
Re: [PATCH] Fix org-capture-place-entry narrow bounds
Hello, Kevin Liu writes: > From 8e7b28054492424170f14f11297b416ef7575540 Mon Sep 17 00:00:00 2001 > From: nivekuil > Date: Fri, 29 May 2020 16:48:31 -0700 > Subject: [PATCH] capture: Fix org-capture-place-entry narrow bounds > > * lisp/org-capture.el > (org-capture-place-entry): > Prevent breaking the following headline inside the capture buffer. > This should match the behavior from 9.3. > (org-capture-finalize): > Reverts cb2774d1a, which solves a similar problem but only in the > finalize stage, so the subtree structure would still be broken in the > middle of editing the capture. Applied. Thank you. Regards, -- Nicolas Goaziou
[BUG] [C-u C-u C-c C-o] open link with external program invalid to open file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 When I press =[C-u C-u C-c C-o]= to open an image file link with system external program. It can't open the image file. I tested on minimal Emacs config, confirmed this problem. Org Mode version: latest "master" branch Org mode version 9.3.4 (release_9.3.4-644-g14d358.dirty @ /home/stardiviner/Code/Emacs/org-mode/lisp/) Emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.17.3) of 2020-06-12 - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7khQcUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsNM3ggAjWkVKAhnsmue0BZq9gxq390UHSan QsiOQN/BzYkUAHHtuY0Jwh5e8u6QO0TXa44v/K/8O4hNMXe7HV59SD2VIs1TvzCA QFCqtGXeJZyeNizh9SS6A4R35KM8e6pg5LjruPEyekkUplaFf5qUJX0sn5x9SY9Z tTZO3Bzd4nW2k8joX1DSqFURK+7WNO7en1XRFjF2FjkBp/J4e5aZwHHhLkGxGR4Q Jn8Xvyf8c3nhrhE+HypwreRexBgiHKhoTK6DIJ9ztXD97/3s2RQ/qbXxVIeqm58U Vivn5XqQDFxgBeOeOhgKVRSmC1/x83CwkxBDSGXHT4U0BKSPt07MPm1L7w== =w8gz -END PGP SIGNATURE-
Re: Bug: fontification error with #end_src in 9.3.7 [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)]
John Ciolfi writes:
> Given the following org file, on the #+end_src line, I get "Org mode
> fontification error in # at 9". If I place a newline
> before the #+end_src line, the error goes away. This is a recent
> regression. This worked fine in 9.2.6 and prior.
>
> #+begin_src C++
> #include
> int main() {
> std::cout << "hello";
> return 0;
> }
>
> // The results:
> #+end_src
>
> #+RESULTS:
Thanks for the report.
This bisects to 04d2828ad (org: Fix verbatim block fontification to end
blocks on headlines, 2019-12-11). Reverting different parts of that
patch, it seems this is the problematic hunk:
diff --git a/lisp/org.el b/lisp/org.el
index 68ca5839a..14840d8ca 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5320,10 +5320,14 @@ (defun org-fontify-meta-lines-and-blocks-1 (limit)
(add-text-properties
beg (if whole-blockline bol-after-beginline end-of-beginline)
'(face org-block-begin-line))
- (add-text-properties
-beg-of-endline
-(min (point-max) (if whole-blockline (min (point-max) (1+
end-of-endline)) end-of-endline))
-'(face org-block-end-line))
+ (unless (string-prefix-p "*" (match-string 1))
+ (add-text-properties
+ beg-of-endline
+ (if whole-blockline
+ (let ((beg-of-next-line (1+ end-of-endline)))
+(min (point-max) beg-of-next-line))
+(min (point-max) end-of-endline))
+ '(face org-block-end-line)))
t))
((member dc1 '("+title:" "+author:" "+email:" "+date:"))
(org-remove-flyspell-overlays-in
I'll try to take a closer look tomorrow.
