Re: [PATCH] ob-tangle.el: Speed up tangling
Hi Tom, Thank you for the comments. Tom Gillespie writes: > All of the issues that I'm aware of are related to what > happens if tangling fails part way through the process. That's not something I had considered. I wrote a new version of the patch (attached) which addresses the insecure behaviour and the possibility of failure. Please tell me what you think. I've also + silenced the ~write-region~ messages, since I'm now writing to temporary files. + added the list of tangled files to the message to the user at the end of the tangling process. + replaced the use of ~when-let~. Regards, -- Sébastien Miquel >From 82e4c1beade71194c90d377cdff7ef23532f4aa2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sat, 17 Apr 2021 21:48:30 +0200 Subject: [PATCH] ob-tangle.el: Improve tangling ,* lisp/ob-tangle.el (org-babel-tangle-collect-blocks): Group collected blocks by tangled file name. (org-babel-tangle): Avoid quadratic behavior in number of blocks. Preserve original file in case of failure. Display the list of tangled files at the end. --- lisp/ob-tangle.el | 167 -- 1 file changed, 87 insertions(+), 80 deletions(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 4c0c3132d..efafef5b8 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -225,87 +225,83 @@ matching a regular expression." (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info 'light (user-error "Point is not in a source code block" path-collector) - (mapc ;; map over all languages - (lambda (by-lang) - (let* ((lang (car by-lang)) - (specs (cdr by-lang)) - (ext (or (cdr (assoc lang org-babel-tangle-lang-exts)) lang)) - (lang-f (org-src-get-lang-mode lang)) - she-banged) - (mapc - (lambda (spec) - (let ((get-spec (lambda (name) (cdr (assoc name (nth 4 spec)) - (let* ((tangle (funcall get-spec :tangle)) - (she-bang (let ((sheb (funcall get-spec :shebang))) - (when (> (length sheb) 0) sheb))) - (tangle-mode (funcall get-spec :tangle-mode)) - (base-name (cond - ((string= "yes" tangle) - (file-name-sans-extension - (nth 1 spec))) - ((string= "no" tangle) nil) - ((> (length tangle) 0) tangle))) - (file-name (when base-name - ;; decide if we want to add ext to base-name - (if (and ext (string= "yes" tangle)) - (concat base-name "." ext) base-name - (when file-name - ;; Possibly create the parent directories for file. - (let ((m (funcall get-spec :mkdirp)) - (fnd (file-name-directory file-name))) - (and m fnd (not (string= m "no")) - (make-directory fnd 'parents))) - ;; delete any old versions of file - (and (file-exists-p file-name) - (not (member file-name (mapcar #'car path-collector))) - (delete-file file-name)) - ;; drop source-block to file - (with-temp-buffer - (when (fboundp lang-f) (ignore-errors (funcall lang-f))) - (when (and she-bang (not (member file-name she-banged))) + (mapc ;; map over file-names + (lambda (by-fn) + (let ((file-name (car by-fn))) + (when file-name + (let ((lspecs (cdr by-fn)) + (fnd (file-name-directory file-name)) + modes make-dir she-banged lang) + ;; drop source-blocks to file + ;; We avoid append-to-file as it does not work with tramp. + (with-temp-buffer + (mapc + (lambda (lspec) + (let* ((block-lang (car lspec)) + (spec (cdr lspec)) + (get-spec (lambda (name) (cdr (assq name (nth 4 spec) + (she-bang (let ((sheb (funcall get-spec :shebang))) + (when (> (length sheb) 0) sheb))) + (tangle-mode (funcall get-spec :tangle-mode))) + (unless (string-equal block-lang lang) + (setq lang block-lang) + (let ((lang-f (org-src-get-lang-mode lang))) + (when (fboundp lang-f) (ignore-errors (funcall lang-f) + ;; if file contains she-bangs, then make it executable + (when she-bang + (unless tangle-mode (setq tangle-mode #o755))) + (when tangle-mode + (add-to-list modes tangle-mode)) + ;; Possibly create the parent directories for file. + (let ((m (funcall get-spec :mkdirp))) + (and m fnd (not (string= m "no")) + (setq make-dir t))) + ;; Handle :padlines unless first line in file + (unless (or (string= "no" (funcall get-spec :padline)) +(= (point) (point-min))) + (insert "\n")) + (when (and she-bang (not she-banged)) (insert (concat she-bang "\n")) - (setq she-banged (cons file-name she-banged))) - (org-babel-spec-to-string spec) - ;; We avoid append-to-file as it does not work with tramp. - (let ((content (buffer-string))) - (with-temp-buffer - (when (file-exists-p file-name) - (insert-file-conte
Re: [PATCH] manual: Fix publish stylesheet
Hello, Erik Hetzner writes: > Subject: [PATCH] manual: Fix publish options > > * doc/org-manual.org (Publishing sample configuration): > * doc/org-guide.org (Publishing): > Fix stylesheet setting in publish: :style is not a valid option; use > :html-head instead. :table-of-contents is not a valid option; use > :with-toc instead. :publishing-function is required. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [PATCH] org-table-import: Make it more smarter for interactive use
Hello, Utkarsh Singh writes: > My previous patch proposed to add support for importing file with > arbitrary name and building upon that this patch tries to make use of it > by making org-table-import smarter by simply adding more separators > (delimiters). Good idea, thank you. Some comments follow. > +(defun org-table-guess-separator (beg0 end0) > + "Guess separator for `org-table-convert-region' for region BEG0 to END0. > + > +List of preferred separator: > +comma, TAB, ';', ':' or SPACE I suggest to use full names everywhere: comma, TAB, semicolon, colon, or SPACE. > +If region contains a line which doesn't contain the required > +separator then discard the separator and search again using next > +separator." > + (let ((beg (save-excursion > +(goto-char (min beg0 end0)) > +(beginning-of-line 1) > +(point))) (beginning-of-line 1) + (point) -> (line-beginning-position) since you don't intent to move point. > + (end (save-excursion > +(goto-char (max beg0 end0)) > +(end-of-line 1) > +(if (bolp) (backward-char 1) (end-of-line 1)) I'm not sure about what you mean above. First, the second call to end-of-line is useless, since you're already at the end of the line. Second, what is wrong if point is at an empty line? Why do you want to move it back? > +(point You may want to use `line-end-position'. > +(save-excursion > + (goto-char beg) > + (cond > + ((not (re-search-forward "^[^\n,]+$" end t)) '(4)) > + ((not (re-search-forward "^[^\n\t]+$" end t)) '(16)) > + ((not (re-search-forward "^[^\n;]+$" end t)) ";") > + ((not (re-search-forward "^[^\n:]+$" end t)) ":") > + ((not (re-search-forward "^\\([^'\"][^\n\s][^'\"]\\)+$" end t)) " ") > + (t nil) I think you need to wrap `save-excursion' around each `re-search-forward' call. Otherwise each test starts at the first line containing the separator previously tested. > + > ;;;###autoload > (defun org-table-convert-region (beg0 end0 &optional separator) >"Convert region to a table. > @@ -862,10 +891,7 @@ org-table-convert-region > integer When a number, use that many spaces, or a TAB, as field separator > regexp When a regular expression, use it to match the separator > nil When nil, the command tries to be smart and figure out the > - separator in the following way: > - - when each line contains a TAB, assume TAB-separated material > - - when each line contains a comma, assume CSV material > - - else, assume one or more SPACE characters as separator." > + separator using `org-table-guess-seperator'." I wonder if creating a new function is warranted here. You could add the news checks after those already present in the code, couldn't you? Regards, -- Nicolas Goaziou
Re: [PATCH] org.el (org-show-context-detail): add option 'ancestors-with-entry
Hello, Cheong Yiu Fung writes: > Hi, I'm proposing a new option in `org-show-context-detail', which shows > current headline, its ancestors, *and the entry itself*. This is useful > when export matched subtrees and their contents quickly with least > manual intervention. > > Consider when working on different aspects of a project and taking notes > as we go: > > * Project > A project tree > ** Task1 > ** Task2 > *** ASK Something to align > Something for discussion > ** Task3 > ** Task4 > *** ASK Something else to align > Something else. > > At some point, we may wish to export only certain contents. For example, > to export headings with TODO keyword of "ASK", along with the task > context (ancestors TASK heading name), and their own content for > discussion with colleagues. Ideally, this can be done by > org-sparse-tree, followed by org-export with visible-only + subtree-only > option. > > Expected output: > * Project > ** Task2 > *** ASK Something to align > Something for discussion > ** Task4 > *** ASK Something else to align > Something else. > > Current options, though, either require manual expansion to show both > ancestors AND entry, which becomes tedious soon; > > * Project > ** Task2 > *** ASK Something to align > ** Task4 > *** ASK Something else to align > > or it shows extra contents (`local' will include the *next* heading, in > this example, the non-related Task3) > > * Project > *** ASK Something to align > Something for discussion > ** Task3 > *** ASK Something else to align > Something else. > > `ancestor-with-entries' is a long name that pose some difficulties to > updating documentations, so I wish to have some feedbacks before moving > on. Is there better way to achieve this effect? Am I overlooking > something? Don't you need to simply move point within the entry and use `ancestors' view? Regards, -- Nicolas Goaziou
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hello, Juan Manuel Macías writes: > I wonder if this other approach can be viable or if it is something > crazy: if the spaces in org-sort-remove-invisible are a > problem only for the first emphasis of each item, how about this > fix to org-sort-list? (not modifying org-sort-remove-invisible): I think `org-sort-remove-invisible' is wrong, so it is the one that needs to be fixed. Could you try the following instead? --8<---cut here---start->8--- (defun org-sort-remove-invisible (s) "Remove invisible part of links and emphasis markers from string S." (let ((remove-markers (lambda (m) (concat (match-string 1 m) (match-string 4 m) (match-string 5 m) (remove-text-properties 0 (length s) org-rm-props s) (replace-regexp-in-string org-verbatim-re remove-markers (replace-regexp-in-string org-emph-re remove-markers (org-link-display-format s) t tt) t t))) --8<---cut here---end--->8--- Regards, -- Nicolas Goaziou
Re: [PATCH] Startup option to separate macros arguments with an alternative string
Hello,
Juan Manuel Macías writes:
> I would like to propose this (possible) patch.
>
> With `#+STARTUP: macro-arg-sep-other' the macros arguments can be
> separated by a string other than comma, whose value is defined in
> `org-macro-arg-sep-other' (by default it is "'@").
Even though Org syntax partly is, I don't think parameterizable syntax
is a way to go. I'd rather have less variables controlling it. (I'm
looking at you `org-list-allow-alphabetical', and
`org-plain-list-ordered-item-terminator'.)
That being said, we can discuss syntax that is not depending upon some
variable. For example macro names are written with a limited set of
characters (alphanumeric, dash, underscore). We might allow the optional
argument separator to be located right before the opening parenthesis,
e.g.,
{{{macroname@(latin@Lorem ipsum dolor sit amet, ...)}}}
{{{macroname|(latin|Lorem ipsum dolor sit amet, ...)}}}
But see below.
> Rationale for this patch: There are many contexts where the comma character
> can be
> inappropriate as an argument separator, since it has to be escaped
> many times.
That's true. But I wonder if you're hitting a limit of replacement
macros use case. IMO, macros are good for short text. For bigger ones,
you may want to use some Babel code, in the language of your choice.
WDYT?
Regards,
--
Nicolas Goaziou
Re: Using backticks for the inline code delimeter?
Hello, Maxim Nikulin writes: > On 05/04/2021 06:06, Nicolas Goaziou wrote: >> Joost Kremers writes: >> >>> I tend to agree that allowing local modifications of Org's syntax is pretty >>> much >>> pointless, but then why is `org-emphasis-alist` a user option? >> In practice, the faces, i.e., the values, are meant to be >> customizable, >> not the keys. > > It would be great to have more clear statement in the doc string. Even > in the manual it could be stressed stronger. Patch welcome! > Unsure if the current phrase really forbids extension, I would rather > tend to interpret it as invitation to customize the list: "To narrow > down the list of available markup syntax, you can customize > ~org-emphasis-alist~." It depends. IMO, narrowing down the list means removing some markup from fontification, i.e., setting a nil face. However, it shouldn't prevent Org from interpreting such syntax. You can use zero-width space for that. > Maybe the code interpreting this variable could spit a warning on > attempt to add new emphasizing characters. As a first step, the type of the defcustom shouldn't be '(repeat ...), but a fixed list. Regards, -- Nicolas Goaziou
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Hello, Ramesh Nedunchezian writes: > Thanks for the feedback. I would be most happy if you could borrow > ideas from my patch. (The changes are really small.) Sorry, my plate is full already. Maybe someone else will want to give it a try. > Additional notes: > > 1. I didn't have information on how the trust levels map to the error >levels. I also had some difficulty getting the error, info, warning >highlighter to work. > > 2. My patch assumes that the org buffer is associated with a file. >This may not be true. This is a big drawback. Is it possible to circumvent this limitation? Regards, -- Nicolas Goaziou
Re: Concerns about community contributor support
Hello all, I've avoided saying anything in this discussion but not from lack of empathy with the initial post. Many valid points have been made in the thread and I understand the frustrations. My own view is that org is now at a different stage than it was some years ago. It is a feature-full package which generally works well for a very *large* set of use cases. As a result, it is being used by many people and so is no longer a niche product. And, hence: On Saturday, 17 Apr 2021 at 23:29, Thomas S. Dye wrote: > But, my sense is that patches to Org mode proper will continue to be > adopted slowly and deliberately. and this is as it should be. I *rely* on org for my work these days. I would not want the type of chaotic development we had in the early days, development that would affect the stability of the package. New features need to be considered very carefully. But, also, as has also been said: the "maintainers" are volunteers and do have other things to do. Stating that there is an expectation for them to answer within a particular time frame is not fair. If there is a feature *you* need that is not there, the beauty of Emacs is that you can have that feature, if you have implemented it, regardless of whether it is accepted in the main org package. A large part of my org environment is code that I have written myself to meet my needs; my org specific config file is 3000 lines. Some bits along the way have migrated into org or have informed org features but I can work the way I want to or need to regardless of whether the features are in the main code or in my own config. The excellent work that was done in creating version 9 (or maybe 8?) in providing a wide range of hooks and filters means that practially everything is customisable without requiring changes to org itself. And this leads back to the first point: I want org to exhibit a certain level of stability now as otherwise much of my workflow would break. I suspect many others have this same requirement. And the maintainers are very good at avoiding breakage when new features are accepted but this takes time to evaluate the impact of those new features. thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
Bug: TexInfo export fails when there is a headline with value "top" [9.4.5 (release_9.4.5-287-gb33fac @ /home/rameshnedunchezian/src/org-mode/lisp/)]
When I export the following snippet, I get an error. See attachments
for details.
* Commands in library ~helm-sys~
** top
:PROPERTIES:
:DESCRIPTION: Brief summary of what Org does.
:END:
- ~helm-top~ ::
#+findex: helm-top
#+kindex: C-x c t
Preconfigured ~helm~ for top command.
test.texi:4: warning: @settitle missing argument
test.texi:11: warning: @title missing argument
test.texi:42: @node `top' previously defined
test.texi:18: here is the previous definition as @node
test.texi:39: warning: @menu entry node name `top' different from node name
`Top'
test.texi:30: warning: @detailmenu entry node name `top' different from node
name `Top'
\input texinfo@c -*- texinfo -*-
@c %**start of header
@setfilename test.info
@settitle
@documentencoding UTF-8
@documentlanguage en
@c %**end of header
@finalout
@titlepage
@title
@author Ramesh Nedunchezian
@end titlepage
@contents
@ifnottex
@node Top
@top
@end ifnottex
@menu
* Commands in library @code{helm-sys}::
@detailmenu
--- The Detailed Node Listing ---
Commands in library @code{helm-sys}
* top:: Brief summary of what Org does.
@end detailmenu
@end menu
@node Commands in library @code{helm-sys}
@chapter Commands in library @code{helm-sys}
@menu
* top:: Brief summary of what Org does.
@end menu
@node top
@section top
@table @asis
@item @code{helm-top}
@findex helm-top
@kindex C-x c t
Preconfigured @code{helm} for top command.
@end table
@bye
test.org
Description: Lotus Organizer
[PATCH] org-protocol: Fix missing '+' in js snippet
* org-protocol (org-protocol-capture): Add missing plus-sign to javascript snippet to allow readers of the doc string to use example snippet with minimal edits. TINYCHANGE --- lisp/org-protocol.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el index 731f51e19..7e9f3b26a 100644 --- a/lisp/org-protocol.el +++ b/lisp/org-protocol.el @@ -464,7 +464,7 @@ This function detects an URL, title and optional text, separated by `/'. The location for a browser's bookmark looks like this: javascript:location.href = \\='org-protocol://capture?url=\\='+ \\ -encodeURIComponent(location.href) + \\='&title=\\=' \\ +encodeURIComponent(location.href) + \\='&title=\\=' + \\ encodeURIComponent(document.title) + \\='&body=\\=' + \\ encodeURIComponent(window.getSelection()) -- 2.29.3
Re: [Patch] to correctly sort the items with emphasis marks in a list
On 19/04/2021 15:33, Nicolas Goaziou wrote: Could you try the following instead? --8<---cut here---start->8--- (defun org-sort-remove-invisible (s) "Remove invisible part of links and emphasis markers from string S." (let ((remove-markers (lambda (m) Just a curiosity, what is style guide recommendation: let - lambda or cl-labels? (concat (match-string 1 m) (match-string 4 m) (match-string 5 m) (remove-text-properties 0 (length s) org-rm-props s) (replace-regexp-in-string org-verbatim-re remove-markers (replace-regexp-in-string org-emph-re remove-markers (org-link-display-format s) t tt) Single "t" is at the end, isn't it? t t))) I think, the patch is an improvement. There is still a minor shortcoming that ordering of emphasized and non-emphasized words is undefined - /a/ - *a* - a Let's leave it aside since it requires multilevel comparison similar to collation in locales and more strict definition which part of string is compared at each level: - /a/ :: A - /a/ :: Z - a :: A - a :: Z In my opinion, a more severe limitation comes from sequential regexp-based approach. Consider stripping markers from 1. "a =b *c* d= e" 2. "*b* /i/" First case could be solved by splitting the input string by verbatim regexp at first and by applying emphasis substitution only to non-verbatim parts. However I am rather shy to experiment with regexps definition to avoid including chars before and after emphasis markers. It would be great to get role of particular characters from more reliable parser (or at least from text properties affected by fontification). I have some tests for `org-sort-remove-invisible', see the attachment. Actually I do not like such style of tests, I strongly prefer to see all failures at once, but I have not found if such technique is used anywhere in org tests. >From 6719386aa5a95394a4cb98ce28b889f545620bd9 Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Mon, 19 Apr 2021 19:06:36 +0700 Subject: [PATCH] More tests for `org-sort-list' * lisp/org.el (org-verbatim-re): Add to the docstring a statement concerning subgroups meaning. * testing/lisp/test-org-list.el (test-org-list/sort): Add cases with text emphasis. Stress in comments that it is significant whether locale-specific collation rules ignores spaces. * testing/lisp/test-org.el (test-org/org-sort-remove-invisible): Add tests for `org-sort-list' helper. Add a test with expected failures to make apparent limitation of simple regexp-based approach in `org-sort-remove-invisible' function. --- lisp/org.el | 3 ++- testing/lisp/test-org-list.el | 34 +- testing/lisp/test-org.el | 27 +++ 3 files changed, 62 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index c2738100f..3d4f5553a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3685,7 +3685,8 @@ After a match, the match groups contain these elements: 5 The character after the match, empty at the end of a line") (defvar org-verbatim-re nil - "Regular expression for matching verbatim text.") + "Regular expression for matching verbatim text. +Groups 1-5 have the same meaning as in `org-emph-re' pattern.") (defvar org-emphasis-regexp-components) ; defined just below (defvar org-emphasis-alist) ; defined just below diff --git a/testing/lisp/test-org-list.el b/testing/lisp/test-org-list.el index 3689a172f..cc7914c8d 100644 --- a/testing/lisp/test-org-list.el +++ b/testing/lisp/test-org-list.el @@ -1225,7 +1225,39 @@ b. Item 2" (equal "- b\n- a\n- C\n" (org-test-with-temp-text "- b\n- C\n- a\n" (org-sort-list t ?A) - (buffer-string)) + (buffer-string + ;; Emphasis in the beginning. + (should + (equal "- a\n- /z/\n" + (org-test-with-temp-text "- /z/\n- a\n" +(org-sort-list t ?a) +(buffer-string + (should + (equal "- *a*\n- z\n" + (org-test-with-temp-text "- z\n- *a*\n" +(org-sort-list t ?a) +(buffer-string + ;; Emphasis of second word. + ;; Locales with significant spaces (C, es_ES, pl_PL) + ;; are more sensitive to problems with sort. + (should + (equal "- a b\n- a /z/\n" + (org-test-with-temp-text "- a /z/\n- a b\n" +(org-sort-list t ?a) +(buffer-string + (should + (equal "- a *b*\n- a z\n" + (org-test-with-temp-text "- a z\n- a *b*\n" +(org-sort-list t ?a) +(buffer-string + ;; Space role in sorting. + ;; Test would fail for locales with ignored space, e.g. en_US, it works + ;; in C and currently rare locales having significant space (es_ES, pl_PL) + (should + (equal "- Time stamp\n- Timer\n" + (org-te
Re: Bug: TexInfo export fails when there is a headline with value "top" [9.4.5 (release_9.4.5-287-gb33fac @ /home/rameshnedunchezian/src/org-mode/lisp/)]
Hello, Ramesh Nedunchezian writes: > When I export the following snippet, I get an error. See attachments > for details. > > * Commands in library ~helm-sys~ > > ** top >:PROPERTIES: >:DESCRIPTION: Brief summary of what Org does. >:END: I think this is a (documentation?) bug in Texinfo. "Top" is a reserved node name in Texinfo, and Org Texinfo export has a mechanism to prevent collision with it. So far so good. Here, you use "top" node name, which is _not_ supposed to be reserved, since case in node names is significant. See (info "(texinfo)Node Line Requirements"). Apparently, any case combination from "Top" is forbidden. But this is not documented in the Texinfo manual. I worked around it, but I suggest to report it upstream, too. Fixed. Thanks. Regards, -- Nicolas Goaziou
Re: sort “on-the-fly” in org-agenda-view
Heh, I just found myself wanting to do this. I often use C-c ^ to sort subtrees by creation date, and I wanted to do that with my global TODO list just now, but couldn't figure out how. So, imo there is at least a small need for this feature. signature.asc Description: PGP signature
Re: [PATCH] org-table-import: Make it more smarter for interactive use
On 2021-04-19, 10:19 +0200, Nicolas Goaziou wrote: >> My previous patch proposed to add support for importing file with >> arbitrary name and building upon that this patch tries to make use of it >> by making org-table-import smarter by simply adding more separators >> (delimiters). > > Good idea, thank you. Some comments follow. > >> +(defun org-table-guess-separator (beg0 end0) >> + "Guess separator for `org-table-convert-region' for region BEG0 to END0. >> + >> +List of preferred separator: >> +comma, TAB, ';', ':' or SPACE > > I suggest to use full names everywhere: comma, TAB, semicolon, colon, or > SPACE. > >> +If region contains a line which doesn't contain the required >> +separator then discard the separator and search again using next >> +separator." >> + (let ((beg (save-excursion >> + (goto-char (min beg0 end0)) >> + (beginning-of-line 1) >> + (point))) > > (beginning-of-line 1) + (point) -> (line-beginning-position) > > since you don't intent to move point. > >> +(end (save-excursion >> + (goto-char (max beg0 end0)) >> + (end-of-line 1) >> + (if (bolp) (backward-char 1) (end-of-line 1)) > > I'm not sure about what you mean above. First, the second call to > end-of-line is useless, since you're already at the end of the line. > Second, what is wrong if point is at an empty line? Why do you want to > move it back? > >> + (point > > You may want to use `line-end-position'. > >> +(save-excursion >> + (goto-char beg) >> + (cond >> + ((not (re-search-forward "^[^\n,]+$" end t)) '(4)) >> + ((not (re-search-forward "^[^\n\t]+$" end t)) '(16)) >> + ((not (re-search-forward "^[^\n;]+$" end t)) ";") >> + ((not (re-search-forward "^[^\n:]+$" end t)) ":") >> + ((not (re-search-forward "^\\([^'\"][^\n\s][^'\"]\\)+$" end t)) " ") >> + (t nil) > > I think you need to wrap `save-excursion' around each > `re-search-forward' call. Otherwise each test starts at the first line > containing the separator previously tested. >> + >> ;;;###autoload >> (defun org-table-convert-region (beg0 end0 &optional separator) >>"Convert region to a table. >> @@ -862,10 +891,7 @@ org-table-convert-region >> integer When a number, use that many spaces, or a TAB, as field separator >> regexp When a regular expression, use it to match the separator >> nil When nil, the command tries to be smart and figure out the >> - separator in the following way: >> - - when each line contains a TAB, assume TAB-separated material >> - - when each line contains a comma, assume CSV material >> - - else, assume one or more SPACE characters as separator." >> + separator using `org-table-guess-seperator'." Thanks for reviewing the patch! > I wonder if creating a new function is warranted here. You could add the > news checks after those already present in the code, couldn't you? At first I was also reluctant in creating a new function but decided to do so because: + org-table-convert-region is currently doing two thing 'guessing the separator' and 'converting the region'. I thought it was a good idea to separate out function into it's atomic operations. + Current guessing technique is quite basic as it assumes that data (file that has to be imported) has no error/inconsistency in it. I would like to show you the doc string of Python's CSV library implementation to guess separator (region inside """): """ Looks for text enclosed between two identical quotes (the probable quotechar) which are preceded and followed by the same character (the probable delimiter). For example: ,'some text', The quote with the most wins, same with the delimiter. If there is no quotechar the delimiter can't be determined this way. """ And if this functions fails then we have: """ The delimiter /should/ occur the same number of times on each row. However, due to malformed data, it may not. We don't want an all or nothing approach, so we allow for small variations in this number. 1) build a table of the frequency of each character on every line. 2) build a table of frequencies of this frequency (meta-frequency?), e.g. 'x occurred 5 times in 10 rows, 6 times in 1000 rows, 7 times in 2 rows' 3) use the mode of the meta-frequency to determine the /expected/ frequency for that character 4) find out how often the character actually meets that goal 5) the character that best meets its goal is the delimiter For performance reasons, the data is evaluated in chunks, so it can try and evaluate the smallest portion of the data possible, evaluating additional chunks as necessary. """ I tried to do similar in Elisp but currently facing some issues due to my inexperience in functional programming. Also moving the 'guessing' part out the function may lead to development of even better algorithm than Python counterpart. Modified version of concerned function: (defun org-table-guess-s
Re: [PATCH] org.el (org-show-context-detail): add option 'ancestors-with-entry
Hi Nicolas, > Don't you need to simply move point within the entry and use `ancestors' > view? Yes, but that would work only for one entry. My main use case is to first filter tree by `org-sparse-tree', then export all filtered contents with `visible-only' option. If I am to use `ancestors' view and move point within each entry one by one to expand, it would be very repetitive. I think this is helpful for generating HTML page or PDF from matching query quickly. Yiufung On Mon, Apr 19, 2021, at 4:21 PM, Nicolas Goaziou wrote: > Hello, > > Cheong Yiu Fung writes: > > > Hi, I'm proposing a new option in `org-show-context-detail', which shows > > current headline, its ancestors, *and the entry itself*. This is useful > > when export matched subtrees and their contents quickly with least > > manual intervention. > > > > Consider when working on different aspects of a project and taking notes > > as we go: > > > > * Project > > A project tree > > ** Task1 > > ** Task2 > > *** ASK Something to align > > Something for discussion > > ** Task3 > > ** Task4 > > *** ASK Something else to align > > Something else. > > > > At some point, we may wish to export only certain contents. For example, > > to export headings with TODO keyword of "ASK", along with the task > > context (ancestors TASK heading name), and their own content for > > discussion with colleagues. Ideally, this can be done by > > org-sparse-tree, followed by org-export with visible-only + subtree-only > > option. > > > > Expected output: > > * Project > > ** Task2 > > *** ASK Something to align > > Something for discussion > > ** Task4 > > *** ASK Something else to align > > Something else. > > > > Current options, though, either require manual expansion to show both > > ancestors AND entry, which becomes tedious soon; > > > > * Project > > ** Task2 > > *** ASK Something to align > > ** Task4 > > *** ASK Something else to align > > > > or it shows extra contents (`local' will include the *next* heading, in > > this example, the non-related Task3) > > > > * Project > > *** ASK Something to align > > Something for discussion > > ** Task3 > > *** ASK Something else to align > > Something else. > > > > `ancestor-with-entries' is a long name that pose some difficulties to > > updating documentations, so I wish to have some feedbacks before moving > > on. Is there better way to achieve this effect? Am I overlooking > > something? > > Don't you need to simply move point within the entry and use `ancestors' > view? > > Regards, > -- > Nicolas Goaziou >
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hello,
Maxim Nikulin writes:
> Just a curiosity, what is style guide recommendation: let - lambda or
> cl-labels?
I stay away from CL as much as possible, otherwise newcomers will have
to learn two languages to start contributing, Elisp and CL (cl-loop,
ewww). CL is still necessary however, as we cannot use `seq' yet.
Also, there is `letrec' instead of `cl-labels'.
> In my opinion, a more severe limitation comes from sequential
> regexp-based approach. Consider stripping markers from
> 1. "a =b *c* d= e"
> 2. "*b* /i/"
Fair enough. Here comes another, more involved, attempt.
--8<---cut here---start->8---
(defun org-sort-remove-invisible (s)
"Remove emphasis markers and any invisible property from string S.
Assume S may contain only objects."
;; org-element-interpret-data clears any text property, including
;; invisible part.
(org-element-interpret-data
(let ((tree (org-element-parse-secondary-string
s (org-element-restriction 'paragraph
(org-element-map tree '(bold code italic strike-through underline verbatim)
(lambda (o)
(pcase (org-element-type o)
;; Terminal object. Replace it with its value.
((or `code `verbatim)
(let ((new (org-element-property :value o)))
(org-element-insert-before new o)
(org-element-put-property
new :post-blank (org-element-property :post-blank o
;; Non-terminal objects. Splice contents.
(_
(let ((contents (org-element-contents o))
(c nil))
(while contents
(setq c (pop contents))
(org-element-insert-before c o))
(org-element-put-property
c :post-blank (org-element-property :post-blank o)
(org-element-extract-element o)))
;; Return modified tree.
tree)))
--8<---cut here---end--->8---
It is not perfect, but it does a better job.
WDYT?
> + ;; Space role in sorting.
> + ;; Test would fail for locales with ignored space, e.g. en_US, it works
> + ;; in C and currently rare locales having significant space (es_ES,
> pl_PL)
> + (should
> + (equal "- Time stamp\n- Timer\n"
> + (org-test-with-temp-text "- Timer\n- Time stamp\n"
> +(org-sort-list t ?a)
> +(buffer-string))
Since this test is bound to fail for some developers, I assume it
shouldn't be included.
> + (dolist (case '(("Lost =in *verbatim* text= fragment" .
> + "Lost in *verbatim* text fragment")
> + ("Adjucent emphasis: *Overlapped* /regexps/" .
> + "Adjucent emphasis: Ovelapped regexps")))
typo
Regards,
--
Nicolas Goaziou
Re: [Patch] to correctly sort the items with emphasis marks in a list
hi, Nicolas, i'm curious, not knowing history and/or procedures. > ... CL is still necessary however, as we cannot use `seq' yet. why is 'seq not "yet" available? what will make it available? cheers, Greg
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hi Greg, seq cannot be used because it is not available in older versions of emacs that org still supports. When support for those older versions is dropped then seq could be used. Best, Tom
Bug: redundant and undocumented #label is required to link to a table [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]
Using Org mode version 9.4.4 I build this document:
<>
#+NAME: t1
#+begin_src R :exports both
library(tidyverse)
x <- tribble(~a, ~b, 1, 3)
x
#+end_src
#+CAPTION: Org Table
#+RESULTS: t1
| 1 | 3 |
I want to refer to Table [[t1]].
<>
What I expect: the latex export will include the table and link to it.
What happens instead: the code and table appear, numbered and captioned.
However, the link is broken ("I want to refer to Table ??"). Looking in
the latex, this line reads
> I want to refer to Table \ref{org993764c}.
but that label org993764c appears nowhere else in the file.
Org-lint doesn't complain about the file at all. I posted this
earlier to this list and learned about a workaround
" It works if you put a #+label on the table ... which confuses me,
because I looked through the manual for #+label and there's no mention
of it at all, but a bunch of my Org files use it (for LaTeX export). "
(William Denton writing in
https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00170.html)
As another workaround, the snippet as written (with no #+label) works
if you export to html instead of latex.
- JP
---
Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
of 2020-07-07
Package: Org mode version 9.4.4 (9.4.4-dist @
/home/powellj/elisp/org-9.4.4/lisp/)
current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-adapt-indentation nil
org-latex-classes '(("achemso" "\\documentclass{achemso}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
("article" "\\documentclass[11pt]{article}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
("report" "\\documentclass[11pt]{report}"
("\\part{%s}" . "\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("book" "\\documentclass[11pt]{book}"
("\\part{%s}" . "\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-reverse-note-order t
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-agenda-start-on-weekday nil
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME
CONTENTS)"]
org-log-done 'time
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-startup-folded 'content
org-agenda-loop-over-headlines-in-active-region nil
org-link-search-must-match-exact-headline nil
org-file-apps '(("\\.pdf" . "evince %s") (auto-mode . emacs)
(directory . emacs)
("\\.mm\\'" . default) ("\\.x?html?\\'" . default)
("\\.pdf\\'" . default))
org-agenda-skip-scheduled-if-done t
org-agenda-custom-commands '(("d" todo #("DELEGATED" 0 9 (face
org-warning)) nil)
("c" todo
#("DONE|DEFERRED|CANCELLED" 0 23 (face
org-warning))
nil)
("w" todo #("WAITING" 0 7 (face
org-warning)) nil)
("W" agenda "" ((org-agenda-ndays 21)))
("A" agenda ""
((org-agenda-skip-function
(lambda nil
(org-agenda-skip-entry-if (quote
notregexp)
"\\=.*\\[#A\\]")
)
)
(org-agenda-ndays 1)
(org-agenda-overriding-header
"Today's Priority #A tasks: ")
)
)
("u" alltodo ""
((org
Re: [Patch] to correctly sort the items with emphasis marks in a list
On 19/04/2021 23:08, Nicolas Goaziou wrote: + ;; Space role in sorting. + ;; Test would fail for locales with ignored space, e.g. en_US, it works + ;; in C and currently rare locales having significant space (es_ES, pl_PL) + (should + (equal "- Time stamp\n- Timer\n" + (org-test-with-temp-text "- Timer\n- Time stamp\n" +(org-sort-list t ?a) +(buffer-string)) Since this test is bound to fail for some developers, I assume it shouldn't be included. Locale "C" is forced for this group of tests. I have added the test to catch an attempt to change locale since it would affect other cases. I hope, the comment might be useful for those who play with sorting having a regular locale instead of fallback "C".
Re: Bug: redundant and undocumented #label is required to link to a table [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]
Hello,
James Powell writes:
> Using Org mode version 9.4.4 I build this document:
>
> <>
>
> #+NAME: t1
> #+begin_src R :exports both
>
> library(tidyverse) x <- tribble(~a, ~b, 1, 3) x #+end_src
>
> #+CAPTION: Org Table
> #+RESULTS: t1
>
> | 1 | 3 |
>
> I want to refer to Table [[t1]].
> <>
>
> What I expect: the latex export will include the table and link to it.
>
> What happens instead: the code and table appear, numbered and captioned.
> However, the link is broken ("I want to refer to Table ??"). Looking in
> the latex, this line reads
>
> > I want to refer to Table \ref{org993764c}.
>
> but that label org993764c appears nowhere else in the file.
>
> Org-lint doesn't complain about the file at all. I posted this
> earlier to this list and learned about a workaround
>
> " It works if you put a #+label on the table ... which confuses me,
> because I looked through the manual for #+label and there's no mention
> of it at all, but a bunch of my Org files use it (for LaTeX export). "
#+label is an outdated equivalent for #+name.
In this case, you are referencing the source code block whereas you want
to reference the table. So #+name should go before the table.
Note that if you follow [[t1]] link, point will move to the source code
block, not the table.
Regards,
--
Nicolas Goaziou
Re: [Patch] to correctly sort the items with emphasis marks in a list
Maxim Nikulin writes: > On 19/04/2021 23:08, Nicolas Goaziou wrote: >>> + ;; Space role in sorting. >>> + ;; Test would fail for locales with ignored space, e.g. en_US, it >>> works >>> + ;; in C and currently rare locales having significant space (es_ES, >>> pl_PL) >>> + (should >>> + (equal "- Time stamp\n- Timer\n" >>> + (org-test-with-temp-text "- Timer\n- Time stamp\n" >>> +(org-sort-list t ?a) >>> +(buffer-string)) >> Since this test is bound to fail for some developers, I assume it >> shouldn't be included. > > Locale "C" is forced for this group of tests. Sorry, I don't understand. There is no locale change around this test, so it will fail, for example, for me. I wouldn't want to get a noisy failure each time I run tests. Regards,
Re: [Patch] to correctly sort the items with emphasis marks in a list
Tom, thanks! i assumed something like that.
Re: Bug: redundant and undocumented #label is required to link to a table [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]
If I put #+name before the table, the link does indeed work, but now
the table is reproduced twice in the latex output and also C-c C-c in
the code block writes a new table into the file instead of updating
the current table.
Before C-c C-c in the code block, this org snippet produces the table
twice in the latex output:
<>
#+begin_src R :exports both
library(tidyverse)
x <- tribble(~a, ~b, 1, 3)
x
#+end_src
#+NAME: t1
#+CAPTION: Org Table
#+RESULTS: t1
| 1 | 3 |
I want to refer to Table [[t1]].
<>
After C-c C-c in the code block, the table appears twice in the org mode
file:
<>
#+begin_src R :exports both
library(tidyverse)
x <- tribble(~a, ~b, 1, 3)
x
#+end_src
#+RESULTS:
| 1 | 3 |
#+NAME: t1
#+CAPTION: Org Table
#+RESULTS: t1
| 1 | 3 |
I want to refer to Table [[t1]].
<>
The literature and the Library of Babel do not seem to address the
case, which is so common in peer-reviewed literature, of a captioned
and referenced table that was produced by code. It was only through a
large investment in trial and error and searching that I was able to
build the example above, in which the code does indeed generate a
table that is captioned and referenced.
- JP
On 4/19/21 10:45 AM, Nicolas Goaziou wrote:
Hello,
James Powell writes:
Using Org mode version 9.4.4 I build this document:
<>
#+NAME: t1
#+begin_src R :exports both
library(tidyverse) x <- tribble(~a, ~b, 1, 3) x #+end_src
#+CAPTION: Org Table
#+RESULTS: t1
| 1 | 3 |
I want to refer to Table [[t1]].
<>
What I expect: the latex export will include the table and link to it.
What happens instead: the code and table appear, numbered and captioned.
However, the link is broken ("I want to refer to Table ??"). Looking in
the latex, this line reads
> I want to refer to Table \ref{org993764c}.
but that label org993764c appears nowhere else in the file.
Org-lint doesn't complain about the file at all. I posted this
earlier to this list and learned about a workaround
" It works if you put a #+label on the table ... which confuses me,
because I looked through the manual for #+label and there's no mention
of it at all, but a bunch of my Org files use it (for LaTeX export). "
#+label is an outdated equivalent for #+name.
In this case, you are referencing the source code block whereas you want
to reference the table. So #+name should go before the table.
Note that if you follow [[t1]] link, point will move to the source code
block, not the table.
Regards,
--
James E. Powell, MS
Pronouns: he/him/his
Applied Physics PhD Candidate
Department of Physics
Portland State University
Home page: http://web.pdx.edu/~powellj
Office: SRTC 409B Phone: +1-503-725-8515
Re: Bug: redundant and undocumented #label is required to link to a table [9.4.4 (9.4.4-dist @ /home/powellj/elisp/org-9.4.4/lisp/)]
James Powell writes: > If I put #+name before the table, the link does indeed work, but now > the table is reproduced twice in the latex output and also C-c C-c in > the code block writes a new table into the file instead of updating > the current table. > > Before C-c C-c in the code block, this org snippet produces the table > twice in the latex output: > <> > > #+begin_src R :exports both > library(tidyverse) > x <- tribble(~a, ~b, 1, 3) > x > #+end_src > > #+NAME: t1 > #+CAPTION: Org Table > > #+RESULTS: t1 > | 1 | 3 | > > > I want to refer to Table [[t1]]. > <> OK. My explanation was a bit short. Let me expound it a bit. There are two important keywords in this situation: #+name and #+results. The former is used to reference a specific element in a document. The latter is used to know what source code block produced an element. #+results keywords are automatically generated by Org whereas #+name keywords are always written by the user. When you see "#+results: t1" above a table in the previous example, you and Org know a source block named (with #+name) "t1" generated this table. Example: #+name: some name #+begin_src R :exports both library(tidyverse) x <- tribble(~a, ~b, 1, 3) x #+end_src generates #+results: some name | 1 | 3 | If you then write "tribble(~a, ~b, 1, 4)" in the source block, evaluating it again will replace the table because Org knows what table you are generating: #+results: some name | 1 | 4 | Note that since the table itself doesn't have any "#+name", you cannot reference it with an internal link yet. Had you seen "#+results:" instead, you would have known that an unnamed source block, located right above the table, had created the table. Example: #+begin_src R :exports both library(tidyverse) x <- tribble(~a, ~b, 1, 3) x #+end_src #+results: | 1 | 3 | > After C-c C-c in the code block, the table appears twice in the org mode > file: Let's analyze your document, which I paste here for easier reading: #+begin_src R :exports both library(tidyverse) x <- tribble(~a, ~b, 1, 3) x #+end_src #+NAME: t1 #+CAPTION: Org Table #+RESULTS: t1 | 1 | 3 | Your source block is now unnamed. Upon evaluating it, Org looks for some generated structure right below it. Unfortunately, the table below claims (per #+results keyword) to come from a source block named "t1". Consequently, it cannot be the output of the code block Org is currently evaluating, and Org deduces no previous output has been created so far by the code block: it inserts a new table in the document. Moreover, an element, here the table, cannot realistically have both #+name and #+results set to the same value, as it raises a chicken and egg problem. It is not really an error though. So, the correct document would be the following: #+name: t1 #+begin_src R :exports both library(tidyverse) x <- tribble(~a, ~b, 1, 3) x #+end_src #+caption: Org Table #+results: t1 | 1 | 3 | With it, evaluating (with C-c C-c) the source code block will not create a new table, because references are appropriately set. If you later want to refer to the table, you can write, e.g., #+name: t1 #+begin_src R :exports both library(tidyverse) x <- tribble(~a, ~b, 1, 3) x #+end_src #+name: t1_output #+caption: Org Table #+results: t1 | 1 | 3 | so [[t1_output]] links jump to the table. HTH, -- Nicolas Goaziou
Re: Concerns about community contributor support
Tim Cross writes: > I suspect the best model for moving forward is for new features and > enhancements to be initially implemented as add on contribution packages > rather than as extensions/enhancement to the core 'org-mode' package. > Such packages, if found to be popular or useful to a large number of > org-mode users could then be considered for inclusion as part of the > main org-mode package. The nature of elisp makes this type of model very > suitable as you can modify almost any aspect of org-mode via add on > packages in a consistent and stable manner and avoid impacting the core > functionality until the extension/enhancement has matured > sufficiently. What is the current status of having a BNF (or...?) parser for Org files? In particular, the parser rules that could then be adopted by tools that use Org files on other systems (iPhone, Android, ...)? Given the availability of parser generators (bison...), this would be good for breaking into smartphones where Emacs doesn't run. -- David Masterson
Re: Concerns about community contributor support
You didn't ask me, but since I'm currently here and reading the list I might just give 2c to the topic. My understanding is that a BNF-grammar is virtually impossible for Org. The org language is ambiguous and writing a context free grammar for it hence is not possible. For reference, see [1]. It deals with the topic, but with markdown instead of Org as the language. Both languages face the same issue. [1]: https://roopc.net/posts/2014/markdown-cfg/ Kindly, Gustav From: Emacs-orgmode on behalf of David Masterson Sent: Monday, April 19, 2021 23:43 To: Tim Cross Cc: emacs-orgmode@gnu.org Subject: Re: Concerns about community contributor support Tim Cross writes: > I suspect the best model for moving forward is for new features and > enhancements to be initially implemented as add on contribution packages > rather than as extensions/enhancement to the core 'org-mode' package. > Such packages, if found to be popular or useful to a large number of > org-mode users could then be considered for inclusion as part of the > main org-mode package. The nature of elisp makes this type of model very > suitable as you can modify almost any aspect of org-mode via add on > packages in a consistent and stable manner and avoid impacting the core > functionality until the extension/enhancement has matured > sufficiently. What is the current status of having a BNF (or...?) parser for Org files? In particular, the parser rules that could then be adopted by tools that use Org files on other systems (iPhone, Android, ...)? Given the availability of parser generators (bison...), this would be good for breaking into smartphones where Emacs doesn't run. -- David Masterson
Re: Concerns about community contributor support
Hi Tim, Another data point from me. I agree with your concerns, although they are difficult to solve! Since we're talking about voluntary work and non-paid work. And maintenance can take a lot of time and effort. This is not the first time this topic comes up on the list. Both you and me took part of the discussion after the 9.4.2 release, that hinted at similar topics [1]. And since Bastien has been in the process of handing over the maintenance role to someone else for quite some time now, it's not strange that the issue will continue to resurface until that process is done. What I take away from this thread is mainly one thing: Another hand raised, eager to take on community work! Since you mentioned that you're interested. The more the merrier! Open source is tough though. It's very much a meritocracy. But by doing stuff that is considered to be good, and good stuff will come back to you. Org mode isn't "finished". And I for one hope the community can continue to surprise with new, nice functionality. Even though some are perfectly happy where it is right now. In my world this is dual property of stability and extensibility is enabled by refactoring into a stable, small(er), less entangled and functional core while also encouraging extension packages/modes. Like org-roam and the likes. A suggestion from me, fwiw, and if you're serious about getting more involved in the community, is to see if Bastien has some time to discuss this maintenance transition, and to see if there is anywhere where you can fit into that picture. But start small. ;) I'm very interested in hearing more on how the thoughts are going in that department - and if there are others who have similar thoughts as you in terms of maybe putting more time into the project. But maybe don't see how help out, and with what. Personally I'm also still hoping for "Org mode maintainer/advocate/whatever" to be something that someone out there can be occupied full time with. The value of the ideas and the software surely is there to warrant it. The question is only how to make it interesting enough for people to help out with funding! [1]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-12/msg00511.html Best, Gustav From: Emacs-orgmode on behalf of Timothy Sent: Friday, April 16, 2021 20:43 To: org-mode-email Subject: Concerns about community contributor support Dear all, Over the last few months I have felt an increasing level of concern over the lack of response to patches. This email is rather long, but please, bear with me. The goal is to start a discussion on the problems this creates, and consider short and long-term solutions. When both community and maintainer response to new patches is lacking, many first-time contributors are actively dissuaded from contributing again. Furthermore, each patch represents a considerable time investment --- particularly if it's from an individual who is new to the mailing list / patch workflow. Org-mode is not "done" and still requires the support of long-term contributors to keep improving, anything that discourages them from contributing back to the community needs to be carefully understood and resolved if we want to continue harmoniously. Take for example Jay Bosamiya's patch from September last year [1]. It appears to be his first submission to this mailing list, and yet there has been absolutely no response to it. There are currently 24 other patches listed on the updates.orgmode.org which have seen no response from this community, some of which are from first-time contributors. There are 36 other patches with at least two replies, but yet to be resolved. Bastien's updates.orgmode.org is fantastic in helping prevent contributions slip through the cracks, but it is also highlighting the lack of community response to a significant number of patches. This mailing list was my first experience with an email+patch based contribution workflow. Thankfully, I received prompt and friendly feedback and was guided through the adjustments needed so it could be merged in a timely manner. Should my patch have been similarly ignored, I would have been quite disheartened; it is not an overstatement to say I would likely have written off this mailing list and not tried again. Simply put, this is not good enough. This does a disservice to those that have dedicated time and effort to try and better this project only to be ignored. Not rejected, not even acknowledged, nothing. It is imperative that this community improves our response to contributions for the long-term health of this project. Do not take me to be a doomsayer; I have faith that Org is going to keep on improving regardless. However, failing to welcome and encourage contributors has a deleterious effect on the health of the project. I do not blame the maintainers in the slightest. As Bastien brought up in a recent worg discussion, as time goes on we find ourselves taking
Re: Concerns about community contributor support
David Masterson writes: > Tim Cross writes: > >> I suspect the best model for moving forward is for new features and >> enhancements to be initially implemented as add on contribution packages >> rather than as extensions/enhancement to the core 'org-mode' package. >> Such packages, if found to be popular or useful to a large number of >> org-mode users could then be considered for inclusion as part of the >> main org-mode package. The nature of elisp makes this type of model very >> suitable as you can modify almost any aspect of org-mode via add on >> packages in a consistent and stable manner and avoid impacting the core >> functionality until the extension/enhancement has matured >> sufficiently. > > What is the current status of having a BNF (or...?) parser for Org > files? In particular, the parser rules that could then be adopted by > tools that use Org files on other systems (iPhone, Android, ...)? Given > the availability of parser generators (bison...), this would be good for > breaking into smartphones where Emacs doesn't run. While not BNF, Tom Gillespie has been working on documentation of the org grammar as part of a broader objective to make it easier for other external tools to parse org files. Below is a message he recently posted to the list. Note that I think this is a slightly different topic to the development/maintenance of org-mode. The external packages I was referring to are still Elisp based packages. Non-Elisp tools which can parse and possibly edit org files would be a good thing for accessing org files on other devices and outside of Emacs. However, such tools will always be more limited because of the complexity of adding things like multiple export formats, babel tangling of src blocks etc (most of which was really only viable in Emacs because Emacs already had support for much of that functionality - a subtle point of org mode often overlooked is that what it primarily did was take existing Emacs functionality and 'wrapped' it in a UI layer to provide a more consistent and 'directed' interface to existing Emacs functionality). > From Tom Gillespie > Dear all, >Here is a draft of a formal grammar for Org mode [1]. It is still > in a rough state, despite quite a bit of work. However, following some > changes to improve performance for parsing real (big) Org files, I > think it is time to share it with the community so that we can start > to gather feedback. There are a number of opportunities that I have > found for simplifying the org grammar (sometimes by extending it to > make it more regular, and in the process adding useful features) that > are much easier to understand with this grammar in hand as a > reference. The grammar itself is implemented using Racket's #lang brag > (see [2] for an overview of brag's syntax). I had considered trying to > break it up into literate sections in an Org file, but for now decided > to leave it as a single file to simplify the development workflow. As > a result the full implementation is fairly long [3]. Comments and > feedback would be greatly appreciated. Best! > Tom > 1. https://github.com/tgbugs/laundry > 2. https://docs.racket-lang.org/brag/#%28part._.The_language%29 > 3. https://github.com/tgbugs/laundry/blob/master/org-mode/parser.rkt -- Tim Cross
Re: stability of toc links
thank you. i use export. e.g. export a subtree to html and paste into blogger. i don't use publish. for me [and some others on this thread iirc] tec's fix looks good, fwiw. it would not proliferate custom id or id, and would fix both. On 4/18/21, Nicolas Goaziou wrote: > Hello, > > Samuel Wales writes: > >> when you link to a section using toc, you get a link like >> >> >> https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab >> >> will these links break if somebody copies them and pastes them >> elsewhere? what if you add a section? > > These links should be stable in a publishing context (i.e., you use > `org-publish' to generate the document), even if you add a section. > > Regards, > -- > Nicolas Goaziou > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag
Tim Visher writes: > On Wed, Jan 20, 2021 at 11:10 PM Kyle Meyer wrote: >> >> It's been applied to master (f4b9f9808). Please report back if you >> still encounter the problem in your use case. >> > > I (finally) got around to testing this out. Initially I thought it had been > released in 9.4.5 but AFAICT that's not the case. Does org not get released > from `master`? For version X.Y.Z, Z ticks happen from maint. > Unfortunately, the title now is essentially the exact text of the org > heading, which is awkward in terms of readability for a general audience > (and probably for SEO etc.). I know I said in my original message that I > think stripping all the markup characters would be going too far but now I > think I've come full circle and rendering the title as nothing but the > plain text without any markup information feels like the right solution > given what the title is supposed to convey. > > So, would we be willing to accept a patch to that effect? :) I don't have an informed opinion about the above, but providing a patch might prompt those that do (including TEC, the author of the above commit, as well as Jens, who provided reviews) to give their input.
Re: List of ob-* maintainers
Thomas S. Dye writes: > Aloha all, > > Is there a list of current ob-* maintainers? Bastien updated the "Maintainer" field of the source files: $ git grep -i maintainer lisp/ob-* | cut -d'<' -f1 lisp/ob-C.el:;; Maintainer: Thierry Banel lisp/ob-J.el:;; Maintainer: Joseph Novakovich lisp/ob-R.el:;; Maintainer: Jeremie Juste lisp/ob-abc.el:;; Maintainer: William Waites lisp/ob-clojure.el:;; Maintainer: Bastien Guerry lisp/ob-dot.el:;; Maintainer: Justin Abrahms lisp/ob-eshell.el:;; Maintainer: stardiviner lisp/ob-groovy.el:;; Maintainer: Palak Mathur lisp/ob-haskell.el:;; Maintainer: Lawrence Bottorff lisp/ob-java.el:;; Maintainer: Ian Martins lisp/ob-mscgen.el:;; Maintainer: Justin Abrahms lisp/ob-perl.el:;; Maintainer: Corwin Brust lisp/ob-python.el:;; Maintainer: Jack Kamm lisp/ob-screen.el:;; Maintainer: Ken Mankoff $ git describe release_9.4.5-317-g3d5284326 The oldest addition is from September 2020, so that should be a fairly current list. > Perhaps it would be useful to add and populate a Maintainer column to > the language table on Worg (org-contrib/babel/languages/index.html)? Hmm, I suppose it's nice to have just one spot to avoid information becoming out of sync, but that's a minor issue, so no objections from me if you or others think it'd be helpful to have the information on Worg.
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
Jorge P. de Morais Neto writes: > Hi. The HTML export has JavaScript that LibreJS does not recognize as > free. Thanks for noting this. That's certainly not ideal. > My first attempt at an workaround (inspired by the Org Mode mailing > list) was merely encoding the ampersand in the magnet link, but that > *did not make LibreJS happy*. Then I checked LibreJS manual and saw > this excerpt: > > https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1 > > Public domain is not a license (see > https://www.gnu.org/licenses/license-list.html#PublicDomain). If > you want to release your work to the public domain, the FSF > recommends using CC0. > > Then I came up with a successful workaround. I included the following > code in my Org Mode customization file: Hmm, the public domain switched happen with 471054136 (ox-html.el: Use classList and put in the public domain, 2020-09-05) and the associated thread is https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/ (+cc author and committer) > ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS > (with-eval-after-load 'ox-html > (setq org-html-scripts > (string-replace "\ > // @license > magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt > Public Domain" > "\ > // @license > magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08&dn=cc0.txt > CC0-1.0" > org-html-scripts))) > > This works; it makes LibreJS happy. Okay. Anthony/Bastien/others, thoughts on using CC0 instead?
Re: Bug: wrong font for checkboxes in org-mouse mode org-odt-data-dir not defined correctly [9.4.4 (9.4.4-dist @ /Users/administrator/.emacs.d/packages/elpa/org-plus-contrib-20210322/)]
Yaroslav Rogov writes:
> Currenty there’re following lines in org-mouse.el:
>
> (font-lock-add-keywords
>nil
>`(("^[ \t]*\\([-+*]\\|[0-9]+[.)]\\) +\\(\\[[ X]\\]\\)"
> (2 `(face bold keymap ,org-mouse-map mouse-face highlight)
> t)))
>t))
>
> https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-mouse.el#L893-L897
>
> Yet there’s special org-checkbox face obviously not used here.
> Relic from the past?
Thanks for noticing. It does look like a relic, and org-checkbox should
be used here for a consistent appearance. Updated (9b4dbe5f0).
What's the "org-odt-data-dir not defined correctly" bit in the subject
about?
Re: Bug: table header line mode misaligned in org-indent-mode
Oorja Sandhu writes: > Steps : > 1. emacs -Q > Latest Emacs cloned and built from master today. > > 2. Open the attached org file > > 3. M-x org-table-header-line-mode > > 4. M-x org-indent-mode > > 5. Resize emacs window very small such that horizontal as well as vertical > scrolling is required to see it fully. > > 6. Go to end of line in a row in the table when the header line overlay is > active. > > Observation : the header is misaligned proportional to depth of current > headline, attached screenshot. > > Expectation : header be indented as much as the table. Thanks for the report. I can trigger it, though I haven't been able to come up with a fix. It seems like it must be some interaction between text properties (org-indent-mode) and overlays (org-table-header-line-mode), but I don't have a good idea of what that would be. Perhaps others have ideas.
More use of lexical-binding in ox.el
Here's another patch to remove some more use of the old dynamically scoped dialect of ELisp. Stefan * lisp/ox.el: Fix various uses of the non-lexical-binding ELisp dialect. (org-export--get-global-options, org-export-insert-default-template): Use lexical-binding. (org-export--generate-copy-script): Return a closure rather than list starting with `lambda`. (org-export-async-start): Turn it into a function (there seems to be no reason this was a macro). Use `write-region` rather than `with-temp-file`. Always use `utf-8-emacs-unix` coding system since it's more efficient and is guaranteed to handle all chars. Use lexical-binding in the temp file as well. Actually set `debug-on-error` if `org-export-async-debug` says so. (org-export-to-buffer, org-export-to-file): Pass a closure rather than list starting with `lambda` to `org-export-async-start`. diff --git a/lisp/ox.el b/lisp/ox.el index 758b9370b3..2ce8985a9e 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -1571,7 +1571,7 @@ process." plist prop ;; Evaluate default value provided. -(let ((value (eval (nth 3 cell +(let ((value (eval (nth 3 cell) t))) (if (eq (nth 4 cell) 'parse) (org-element-parse-secondary-string value (org-element-restriction 'keyword)) @@ -2561,51 +2561,59 @@ another buffer, effectively cloning the original buffer there. The function assumes BUFFER's major mode is `org-mode'." (with-current-buffer buffer -`(lambda () - (let ((inhibit-modification-hooks t)) -;; Set major mode. Ignore `org-mode-hook' as it has been run -;; already in BUFFER. -(let ((org-mode-hook nil) (org-inhibit-startup t)) (org-mode)) -;; Copy specific buffer local variables and variables set -;; through BIND keywords. -,@(let ((bound-variables (org-export--list-bound-variables)) -vars) -(dolist (entry (buffer-local-variables (buffer-base-buffer)) vars) +(let ((str (org-with-wide-buffer (buffer-string))) + (narrowing + (if (org-region-active-p) + (list (region-beginning) (region-end)) +(list (point-min) (point-max + (pos (point)) + (varvals + (let ((bound-variables (org-export--list-bound-variables)) +varvals) +(dolist (entry (buffer-local-variables (buffer-base-buffer))) (when (consp entry) (let ((var (car entry)) (val (cdr entry))) (and (not (memq var org-export-ignored-local-variables)) (or (memq var '(default-directory -buffer-file-name -buffer-file-coding-system)) + buffer-file-name + buffer-file-coding-system)) (assq var bound-variables) (string-match "^\\(org-\\|orgtbl-\\)" (symbol-name var))) ;; Skip unreadable values, as they cannot be ;; sent to external process. (or (not val) (ignore-errors (read (format "%S" val - (push `(set (make-local-variable (quote ,var)) - (quote ,val)) - vars)) -;; Whole buffer contents. -(insert ,(org-with-wide-buffer (buffer-string))) -;; Narrowing. -,(if (org-region-active-p) - `(narrow-to-region ,(region-beginning) ,(region-end)) - `(narrow-to-region ,(point-min) ,(point-max))) -;; Current position of point. -(goto-char ,(point)) -;; Overlays with invisible property. -,@(let (ov-set) -(dolist (ov (overlays-in (point-min) (point-max)) ov-set) + (push (cons var val) varvals + varvals))) + (ols + (let (ov-set) +(dolist (ov (overlays-in (point-min) (point-max))) (let ((invis-prop (overlay-get ov 'invisible))) (when invis-prop - (push `(overlay-put - (make-overlay ,(overlay-start ov) -,(overlay-end ov)) - 'invisible (quote ,invis-prop)) -ov-set) + (push (list (overlay-start ov) (overlay-end ov) + invis-prop) +ov-set +ov-set))) + (lambda () + (let ((inhibit-modification-hooks t)) + ;; Set major mode. Ignore `org-mode-hook' as it has been run + ;; already in BUFFER.
Re: Concerns about community contributor support
Hi Eric, Thanks for writing in and sharing your thoughts. I have some specific comments that you may find below, but more generally: I get the impression you approached this from the view of Org development and patch merging. In short, while I appreciate that Org development should be a considered process and that maintainer time is limited --- I think we could improve how well we communicate this to contributors, and maybe even our treatment of contributions. Eric S Fraga writes: > Hello all, > > I've avoided saying anything in this discussion but not from lack of > empathy with the initial post. Many valid points have been made in the > thread and I understand the frustrations. My own view is that org is > now at a different stage than it was some years ago. It is a > feature-full package which generally works well for a very *large* set > of use cases. As a result, it is being used by many people and so is no > longer a niche product. I can't say I see how being used by a large number of people and growing beyond a niche product means that we can't set expectations for patches and/or responsiveness. Though I see you go in a slightly different direction below... > And, hence: > > On Saturday, 17 Apr 2021 at 23:29, Thomas S. Dye wrote: >> But, my sense is that patches to Org mode proper will continue to be >> adopted slowly and deliberately. > > and this is as it should be. I *rely* on org for my work these days. I > would not want the type of chaotic development we had in the early days, > development that would affect the stability of the package. New > features need to be considered very carefully. Indeed, but a lot don't seem considered, they just seem ignored. Particularly with a lack of communication, this can leave the contributor wondering whether they need to resend there email, bump it, wait for a particular maintainer to have a look at it, explain the intent further, etc. and I don't think leaving such uncertainty to grow is very nice. > But, also, as has also been said: the "maintainers" are volunteers and > do have other things to do. Stating that there is an expectation for > them to answer within a particular time frame is not fair. Maybe I'm not being entirely reasonable, but I would have thought something like "a cursory response within two months of submitting your patch" wouldn't be too hard to uphold; particularly when a cursory response could just be "we've been rather busy as of late, we'll get back to you on this in the future". > If there is a feature *you* need that is not there, the beauty of Emacs > is that you can have that feature, if you have implemented it, > regardless of whether it is accepted in the main org package. A large > part of my org environment is code that I have written myself to meet my > needs; my org specific config file is 3000 lines. Some bits along the > way have migrated into org or have informed org features but I can work > the way I want to or need to regardless of whether the features are in > the main code or in my own config. > > The excellent work that was done in creating version 9 (or maybe 8?) in > providing a wide range of hooks and filters means that practially > everything is customisable without requiring changes to org itself. > > And this leads back to the first point: I want org to exhibit a certain > level of stability now as otherwise much of my workflow would break. I > suspect many others have this same requirement. And the maintainers are > very good at avoiding breakage when new features are accepted but this > takes time to evaluate the impact of those new features. I too appreciate the versatility of elisp, and the way Org has been constructed that allow it to be modified so heavily by the end user --- I should know, I have ~4k lines of Org modification in my config. However, this does not preclude good ideas for Org modification being merged in. If I have a bugfix, or a very useful modification to Org, that's great for me, but it's good to share the improvement upstream. Isn't this a large part of the benefit of an open source development model? And when a patch does need to be carefully considered over a period of months or years, surely it's good to communicate that to the author instead of leaving them with silence? Please let me know what your thoughts are, Timothy.
Re: List of ob-* maintainers
Aloha Kyle, Thanks for this. I think the Worg list might be useful to indicate which languages don't have maintainers. Or, is the information in the source files sufficient? I'm happy not to work on the Worg table in that case. All the best, Tom Kyle Meyer writes: Thomas S. Dye writes: Aloha all, Is there a list of current ob-* maintainers? Bastien updated the "Maintainer" field of the source files: $ git grep -i maintainer lisp/ob-* | cut -d'<' -f1 lisp/ob-C.el:;; Maintainer: Thierry Banel lisp/ob-J.el:;; Maintainer: Joseph Novakovich lisp/ob-R.el:;; Maintainer: Jeremie Juste lisp/ob-abc.el:;; Maintainer: William Waites lisp/ob-clojure.el:;; Maintainer: Bastien Guerry lisp/ob-dot.el:;; Maintainer: Justin Abrahms lisp/ob-eshell.el:;; Maintainer: stardiviner lisp/ob-groovy.el:;; Maintainer: Palak Mathur lisp/ob-haskell.el:;; Maintainer: Lawrence Bottorff lisp/ob-java.el:;; Maintainer: Ian Martins lisp/ob-mscgen.el:;; Maintainer: Justin Abrahms lisp/ob-perl.el:;; Maintainer: Corwin Brust lisp/ob-python.el:;; Maintainer: Jack Kamm lisp/ob-screen.el:;; Maintainer: Ken Mankoff $ git describe release_9.4.5-317-g3d5284326 The oldest addition is from September 2020, so that should be a fairly current list. Perhaps it would be useful to add and populate a Maintainer column to the language table on Worg (org-contrib/babel/languages/index.html)? Hmm, I suppose it's nice to have just one spot to avoid information becoming out of sync, but that's a minor issue, so no objections from me if you or others think it'd be helpful to have the information on Worg. -- Thomas S. Dye https://tsdye.online/tsdye
Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]
Kyle Meyer writes: > Jorge P. de Morais Neto writes: > >> Hi. The HTML export has JavaScript that LibreJS does not recognize as >> free. > > Thanks for noting this. That's certainly not ideal. > >> My first attempt at an workaround (inspired by the Org Mode mailing >> list) was merely encoding the ampersand in the magnet link, but that >> *did not make LibreJS happy*. Then I checked LibreJS manual and saw >> this excerpt: >> >> https://www.gnu.org/software/librejs/manual/librejs.html#Free-Licenses-Detection-1 >> >> Public domain is not a license (see >> https://www.gnu.org/licenses/license-list.html#PublicDomain). If >> you want to release your work to the public domain, the FSF >> recommends using CC0. >> >> Then I came up with a successful workaround. I included the following >> code in my Org Mode customization file: > > Hmm, the public domain switched happen with 471054136 (ox-html.el: Use > classList and put in the public domain, 2020-09-05) and the associated > thread is > > https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/ > > (+cc author and committer) > >> ;; [2021-04-16 sex]: HACK Work around a bug that confuses LibreJS >> (with-eval-after-load 'ox-html >> (setq org-html-scripts >> (string-replace "\ >> // @license >> magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt >> Public Domain" >> "\ >> // @license >> magnet:?xt=urn:btih:90dc5c0be029de84e523b9b3922520e79e0e6f08&dn=cc0.txt >> CC0-1.0" >> org-html-scripts))) >> >> This works; it makes LibreJS happy. > > Okay. Anthony/Bastien/others, thoughts on using CC0 instead? The error from libreJS is correct - public domain is not a valid license. As this is a GNU project and correct licensing is important, I don't think there is any option other than to change the line to reference the CC license (or any appropriate free license). If 'public domain' was used due to some other issue, either we have to verify the code is covered by a free (not just open source) license or replace it with code that is and is acceptable by the FSF. -- Tim Cross
