Re: ox-* vs org-* naming convention?

[Diego Zamboni]

Hi Kaushal and Jens,

Thanks for your feedback, and also for the idea for the workaround
used in ox-re-reveal - that's a nice one :)

Given the special meanings of both the org- and ox- prefixes, I will
insist on keeping the current naming, and maybe take a stab at coming
up with a PR for https://github.com/purcell/package-lint/issues/89.

Cheers,
--Diego

On Mon, Jun 8, 2020 at 7:54 AM Jens Lechtenboerger
 wrote:
>
> On 2020-06-07, Diego Zamboni wrote:
>
> > Hi,
> >
> > I am working on submitting a new set of exporters I've been working on
> > (https://gitlab.com/zzamboni/ox-leanpub) to MELPA, and I received
> > feedback [1] about the discrepancy between the package names
> > (ox-leanpub-*) and the functions they define (org-leanpub-*). This is
> > also flagged by =package-lint=.
> >
> > [1] https://github.com/melpa/melpa/pull/6942
> >
> > [...]
> >
> > I would appreciate any feedback about this - what are strong arguments
> > for or against insisting in this convention vs just adapting to the
> > rules suggested by package-lint?
>
> Hi there,
>
> for org-re-reveal, I use a small wrapper ox-re-reveal.el [2], whose
> commentary explains this:
>
> ;; Org export back-ends have file names starting with "ox-".
> ;; However, such files typically define variables and functions
> ;; starting with "org-", which causes errors by package-lint.  To
> ;; define variables and functions with the usual prefix "org-" while
> ;; avoiding errors by package-lint, code is located in
> ;; org-re-reveal.el.
> ;; However, the prefix "ox-" is hard-coded in org.el and used to load
> ;; back-ends in `org-export-backends'.  With this file, you can
> ;; customize `org-export-backends' and add `re-reveal'.  Then, when
> ;; pressing `C-c C-e', this file will be loaded, which loads
> ;; org-re-reveal.el.
>
> Best wishes
> Jens
>
> [2] https://gitlab.com/oer/org-re-reveal/-/blob/master/ox-re-reveal.el

Re: [join rows] (was: join tables from different files)

[tbanelwebmin]

Le 07/06/2020 à 17:09, Uwe Brauer a écrit :

> "t" == tbanelwebmin   writes:
>
> Yes you can.
> Use an org-id
>
> Thanks! Nice!
>
>
> I have a another question in this context:
> can I join, say 4 tables, but row wise?
> Say I have  
>
> #+TBLNAME: RK
> #+ATTR_HTML: :border 2 :rules all :frame border
> | met | Q1 | Q2 |  Q3 | total |
> |-+++-+---|
> | RK  |  1 |  1 | 0.5 |   2.5 |
> #+TBLFM: $5=$2+$3+$4
>
> #+TBLNAME: SVD
> #+ATTR_HTML: :border 2 :rules all :frame border
>  | met | Q1: | Q2 | Q3 | total |
>  |-+-+++---|
>  | SVD | 0.5 |  1 |  1 |   2.5 |
> #+TBLFM: $5=$2+$3+$4;f1
>
> #+TBLNAME: MIN
> #+ATTR_HTML: :border 2 :rules all :frame border
> | met | Q1 |  Q2 | total |
> |-++-+---|
> | MIN |  2 | 0.5 |   2.5 |
> #+TBLFM: $4=$2+$3
>
> #+TBLNAME: BDF
> #+ATTR_HTML: :border 2 :rules all :frame border
> | met |   Q1 |   Q2 | total |
> |-+--+--+---|
> | MIN | 0.75 | 1.75 |   2.5 |
> #+TBLFM: $4=$2+$3
>
> Since they don't have the same amount of columns, I'd like to join the 4 
> tables like this
> #+TBLNAME: Total1
> #+ATTR_HTML: :border 2 :rules all :frame border
> | met |  Q1 | Q2 |  Q3 | total |
> |-+-++-+---|
> | RK  |   1 |  1 | 0.5 |   2.5 |
> |-+-++-+---|
> | SVD | 0.5 |  1 |   1 |   2.5 |
> #+TBLFM: $5=$2+$3+$4;f1
>
> #+TBLNAME: Total2
> #+ATTR_HTML: :border 2 :rules all :frame border
> | met |   Q1 |   Q2 | total |
> |-+--+--+---|
> | MIN |2 |  0.5 |   2.5 |
> |-+--+--+---|
> | MIN | 0.75 | 1.75 |   2.5 |
> #+TBLFM: $4=$2+$3
>
> Is this possible?
>
> regards
> Uwe Brauer 

I'm not aware of anything specific for this purpose. A starting point could be 
the `append' lisp function:

#+begin_src elisp :var table1=RK :var table2=SVD :colnames t
(append table1 table2)
#+end_src

#+RESULTS:
| met | Q1: | Q2 |  Q3 | total |
|-+-++-+---|
| RK  |   1 |  1 | 0.5 |   2.5 |
| SVD | 0.5 |  1 |   1 |   2.5 |

Re: ox-* vs org-* naming convention?

[Jens Lechtenboerger]

On 2020-06-07, Diego Zamboni wrote:

> Hi,
>
> I am working on submitting a new set of exporters I've been working on
> (https://gitlab.com/zzamboni/ox-leanpub) to MELPA, and I received
> feedback [1] about the discrepancy between the package names
> (ox-leanpub-*) and the functions they define (org-leanpub-*). This is
> also flagged by =package-lint=.
>
> [1] https://github.com/melpa/melpa/pull/6942
>
> [...]
>
> I would appreciate any feedback about this - what are strong arguments
> for or against insisting in this convention vs just adapting to the
> rules suggested by package-lint?

Hi there,

for org-re-reveal, I use a small wrapper ox-re-reveal.el [2], whose
commentary explains this:

;; Org export back-ends have file names starting with "ox-".
;; However, such files typically define variables and functions
;; starting with "org-", which causes errors by package-lint.  To
;; define variables and functions with the usual prefix "org-" while
;; avoiding errors by package-lint, code is located in
;; org-re-reveal.el.
;; However, the prefix "ox-" is hard-coded in org.el and used to load
;; back-ends in `org-export-backends'.  With this file, you can
;; customize `org-export-backends' and add `re-reveal'.  Then, when
;; pressing `C-c C-e', this file will be loaded, which loads
;; org-re-reveal.el.

Best wishes
Jens

[2] https://gitlab.com/oer/org-re-reveal/-/blob/master/ox-re-reveal.el

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

Github link to the patch:
https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef 

Ihor Radchenko  writes:

> Hello,
>
> [The patch itself will be provided in the following email]
>
> I have four more updates from the previous version of the patch:
>
> 1. All the code handling modifications in folded drawers/blocks is moved
>to after-change-function. It works as follows:
>- if any text is inserted in the middle of hidden region, that text
>  is also hidden;
>- if BEGIN/END line of a folded drawer do not match org-drawer-regexp
>  and org-property-end-re, unfold it; 
>- if org-property-end-re or new org-outline-regexp-bol is inserted in
>  the middle of the drawer, unfold it;
>- the same logic for blocks.
>
> 2. The text property stack is rewritten using char-property-alias-alist.
>This is faster in comparison with previous approach, which involved
>modifying all the text properties every timer org-flag-region was
>called. 
>
> 3. org-toggle-custom-properties-visibility is rewritten using text
>properties. I also took a freedom to implement a new feature here.
>Now, setting new `org-custom-properties-hide-emptied-drawers' to
>non-nil will result in hiding the whole property drawer if it
>contains only org-custom-properties.
>
> 4. This patch should work against 1aa095ccf. However, the merge was not
>trivial here. Recent commits actively used the fact that drawers and
>outlines are hidden via 'outline invisibility spec, which is not the
>case in this branch. I am not confident that I did not break anything
>during the merge, especially 1aa095ccf.
>
> ---
> ---
>
> More details on the new implementation for tracking changes:
>
>> I gave you a few ideas to quickly check if a change requires expansion,
>> in an earlier mail. I suggest to start out from that. Let me know if you
>> have questions about it.
>
> All the code lives in org-after-change-function. I tried to incorporate
> the earlier Nicholas' suggestions, except the parts related to
> intersecting blocks and drawers. I am not sure if I understand the
> parsing priority of blocks vs. drawers.
>
> ---
> ---
>
> More details on the text property stack:
>
> The earlier version of the code literally used stack to save
> pre-existing 'invisibility specs in org-flag-region. This was done on
> every invocation of org-flag-region, which made org-flag-region
> significantly slower. I re-implemented the same feature using
> char-property-alias-alist. Now, different invisibility specs live in
> separate text properties and can be safely modified independently. The
> specs are applied according to org--invisible-spec-priority-list. A side
> effect of current implementation is that char-property-alias-alist is
> fully controlled by org. All the pre-existing settings for 'invisible
> text property will be overwritten by org.
>
>> `gensym' is just a shorter, and somewhat standard way, to create a new
>> uninterned symbol with a given prefix. You seem to re-invent it. What
>> you do with that new symbol is orthogonal to that suggestion, of course.
>
> I do not think that `gensym' is suitable here. We don't want a new
> symbol every time org--get-buffer-local-invisible-property-symbol is
> called. It should return the same symbol if it is called from the same
> buffer multiple times.
>
> ---
> ---
>
> More details on the org-toggle-custom-properties-visibility:
>
> The implementation showcases how to introduce new invisibility specs to
> org. Apart from expected (add-to-invisibility-spec 'org-hide-custom-property) 
> one also needs to add the spec into org--invisible-spec-priority-list:
>
> (add-to-list 'org--invisible-spec-priority-list 'org-hide-custom-property)
>
> Searching for text with the given invisibility spec is done as
> follows:
>
> (text-property-search-forward 
> (org--get-buffer-local-invisible-property-symbol 'org-hide-custom-property) 
> 'org-hide-custom-property t)
>
> This last piece of code is probably not the most elegant. I am thinking
> if creating some higher-level interface would be more reasonable here.
> What do you think?
>
>
> The new customisation `org-custom-properties-hide-emptied-drawers'
> sounds logical for me since empty property drawers left after invoking
> org-toggle-custom-properties-visibility are rather useless according to
> my experience. If one already wants to hide parts of property drawers, I
> do not see a reason to show leftover
>
> :PROPERTIES:
> :END:
>
> ---
> -

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

The patch (against 1aa095ccf) is attached.

diff --git a/contrib/lisp/org-notify.el b/contrib/lisp/org-notify.el
index 9f8677871..ab470ea9b 100644
--- a/contrib/lisp/org-notify.el
+++ b/contrib/lisp/org-notify.el
@@ -246,7 +246,7 @@ seconds.  The default value for SECS is 20."
   (switch-to-buffer (find-file-noselect file))
   (org-with-wide-buffer
(goto-char begin)
-   (outline-show-entry))
+   (org-show-entry))
   (goto-char begin)
   (search-forward "DEADLINE: <")
   (search-forward ":")
diff --git a/contrib/lisp/org-velocity.el b/contrib/lisp/org-velocity.el
index bfc4d6c3e..2312b235c 100644
--- a/contrib/lisp/org-velocity.el
+++ b/contrib/lisp/org-velocity.el
@@ -325,7 +325,7 @@ use it."
   (save-excursion
 (when narrow
   (org-narrow-to-subtree))
-(outline-show-all)))
+(org-show-all)))
 
 (defun org-velocity-edit-entry/inline (heading)
   "Edit entry at HEADING in the original buffer."
diff --git a/doc/org-manual.org b/doc/org-manual.org
index efad195e1..c6f167eac 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -509,11 +509,11 @@ Org uses just two commands, bound to {{{kbd(TAB)}}} and
   Switch back to the startup visibility of the buffer (see [[*Initial
   visibility]]).
 
-- {{{kbd(C-u C-u C-u TAB)}}} (~outline-show-all~) ::
+- {{{kbd(C-u C-u C-u TAB)}}} (~org-show-all~) ::
 
   #+cindex: show all, command
   #+kindex: C-u C-u C-u TAB
-  #+findex: outline-show-all
+  #+findex: org-show-all
   Show all, including drawers.
 
 - {{{kbd(C-c C-r)}}} (~org-reveal~) ::
@@ -529,18 +529,18 @@ Org uses just two commands, bound to {{{kbd(TAB)}}} and
   headings.  With a double prefix argument, also show the entire
   subtree of the parent.
 
-- {{{kbd(C-c C-k)}}} (~outline-show-branches~) ::
+- {{{kbd(C-c C-k)}}} (~org-show-branches~) ::
 
   #+cindex: show branches, command
   #+kindex: C-c C-k
-  #+findex: outline-show-branches
+  #+findex: org-show-branches
   Expose all the headings of the subtree, but not their bodies.
 
-- {{{kbd(C-c TAB)}}} (~outline-show-children~) ::
+- {{{kbd(C-c TAB)}}} (~org-show-children~) ::
 
   #+cindex: show children, command
   #+kindex: C-c TAB
-  #+findex: outline-show-children
+  #+findex: org-show-children
   Expose all direct children of the subtree.  With a numeric prefix
   argument {{{var(N)}}}, expose all children down to level
   {{{var(N)}}}.
@@ -7294,7 +7294,7 @@ its location in the outline tree, but behaves in the following way:
   command (see [[*Visibility Cycling]]).  You can force cycling archived
   subtrees with {{{kbd(C-TAB)}}}, or by setting the option
   ~org-cycle-open-archived-trees~.  Also normal outline commands, like
-  ~outline-show-all~, open archived subtrees.
+  ~org-show-all~, open archived subtrees.
 
 -
   #+vindex: org-sparse-tree-open-archived-trees
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 9fbeb2a1e..2f121f743 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6824,7 +6824,7 @@ and stored in the variable `org-prefix-format-compiled'."
 	(t "  %-12:c%?-12t% s")))
 	(start 0)
 	varform vars var e c f opt)
-(while (string-match "%\\(\\?\\)?\\([-+]?[0-9.]*\\)\\([ .;,:!?=|/<>]?\\)\\([cltseib]\\|(.+)\\)"
+(while (string-match "%\\(\\?\\)?\\([-+]?[0-9.]*\\)\\([ .;,:!?=|/<>]?\\)\\([cltseib]\\|(.+?)\\)"
 			 s start)
   (setq var (or (cdr (assoc (match-string 4 s)
 '(("c" . category) ("t" . time) ("l" . level) ("s" . extra)
@@ -9136,20 +9136,20 @@ if it was hidden in the outline."
  ((and (called-interactively-p 'any) (= more 1))
   (message "Remote: show with default settings"))
  ((= more 2)
-  (outline-show-entry)
+  (org-show-entry)
   (org-show-children)
   (save-excursion
 	(org-back-to-heading)
 	(run-hook-with-args 'org-cycle-hook 'children))
   (message "Remote: CHILDREN"))
  ((= more 3)
-  (outline-show-subtree)
+  (org-show-subtree)
   (save-excursion
 	(org-back-to-heading)
 	(run-hook-with-args 'org-cycle-hook 'subtree))
   (message "Remote: SUBTREE"))
  ((> more 3)
-  (outline-show-subtree)
+  (org-show-subtree)
   (message "Remote: SUBTREE AND ALL DRAWERS")))
 (select-window win)))
 
diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index d3e12d17b..d864dad8a 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -330,7 +330,7 @@ direct children of this heading."
 		  (insert (if datetree-date "" "\n") heading "\n")
 		  (end-of-line 0))
 		;; Make the subtree visible
-		(outline-show-subtree)
+		(org-show-subtree)
 		(if org-archive-reversed-order
 			(progn
 			  (org-back-to-heading t)
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index e50a4d7c8..e656df555 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -699,7 +699,7 @@ FUN is a function called with no argument."
 			  (move-beginning-of-line 2)
 			  (org-at-heading-p t)
 (unwind-protect (funcall fun)

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

Hello,

[The patch itself will be provided in the following email]

I have four more updates from the previous version of the patch:

1. All the code handling modifications in folded drawers/blocks is moved
   to after-change-function. It works as follows:
   - if any text is inserted in the middle of hidden region, that text
 is also hidden;
   - if BEGIN/END line of a folded drawer do not match org-drawer-regexp
 and org-property-end-re, unfold it; 
   - if org-property-end-re or new org-outline-regexp-bol is inserted in
 the middle of the drawer, unfold it;
   - the same logic for blocks.

2. The text property stack is rewritten using char-property-alias-alist.
   This is faster in comparison with previous approach, which involved
   modifying all the text properties every timer org-flag-region was
   called. 
   
3. org-toggle-custom-properties-visibility is rewritten using text
   properties. I also took a freedom to implement a new feature here.
   Now, setting new `org-custom-properties-hide-emptied-drawers' to
   non-nil will result in hiding the whole property drawer if it
   contains only org-custom-properties.

4. This patch should work against 1aa095ccf. However, the merge was not
   trivial here. Recent commits actively used the fact that drawers and
   outlines are hidden via 'outline invisibility spec, which is not the
   case in this branch. I am not confident that I did not break anything
   during the merge, especially 1aa095ccf.

---
---

More details on the new implementation for tracking changes:

> I gave you a few ideas to quickly check if a change requires expansion,
> in an earlier mail. I suggest to start out from that. Let me know if you
> have questions about it.

All the code lives in org-after-change-function. I tried to incorporate
the earlier Nicholas' suggestions, except the parts related to
intersecting blocks and drawers. I am not sure if I understand the
parsing priority of blocks vs. drawers.

---
---

More details on the text property stack:

The earlier version of the code literally used stack to save
pre-existing 'invisibility specs in org-flag-region. This was done on
every invocation of org-flag-region, which made org-flag-region
significantly slower. I re-implemented the same feature using
char-property-alias-alist. Now, different invisibility specs live in
separate text properties and can be safely modified independently. The
specs are applied according to org--invisible-spec-priority-list. A side
effect of current implementation is that char-property-alias-alist is
fully controlled by org. All the pre-existing settings for 'invisible
text property will be overwritten by org.

> `gensym' is just a shorter, and somewhat standard way, to create a new
> uninterned symbol with a given prefix. You seem to re-invent it. What
> you do with that new symbol is orthogonal to that suggestion, of course.

I do not think that `gensym' is suitable here. We don't want a new
symbol every time org--get-buffer-local-invisible-property-symbol is
called. It should return the same symbol if it is called from the same
buffer multiple times.

---
---

More details on the org-toggle-custom-properties-visibility:

The implementation showcases how to introduce new invisibility specs to
org. Apart from expected (add-to-invisibility-spec 'org-hide-custom-property) 
one also needs to add the spec into org--invisible-spec-priority-list:

(add-to-list 'org--invisible-spec-priority-list 'org-hide-custom-property)

Searching for text with the given invisibility spec is done as
follows:

(text-property-search-forward (org--get-buffer-local-invisible-property-symbol 
'org-hide-custom-property) 'org-hide-custom-property t)

This last piece of code is probably not the most elegant. I am thinking
if creating some higher-level interface would be more reasonable here.
What do you think?


The new customisation `org-custom-properties-hide-emptied-drawers'
sounds logical for me since empty property drawers left after invoking
org-toggle-custom-properties-visibility are rather useless according to
my experience. If one already wants to hide parts of property drawers, I
do not see a reason to show leftover

:PROPERTIES:
:END:

---
---

More details on the merge with the latest master:

I tried my best to not break anything. However, I am not sure if I
understand all the recent commits. Could someone take a look if there is
anything suspicious in org-next-visibl

Re: New mailing list archive at https://orgmode/list/

[Eric Abrahamsen]

Kyle Meyer  writes:

> [ +cc Eric Wong, mostly to say thanks for all the work he puts into
>   public-inbox, which is the software behind these archives, but also so
>   that he can correct me if I misrepresent any capabilities of or plans
>   for public-inbox ]

Thanks for this response, Kyle (and thanks for public-inbox, Eric)!

>> Bastien  writes:
>>
>>> with Kyle's help, I've set up a new mailing list archive:
>>>
>>> https://orgmode/list/
>>>
>>> References in https://orgmode.org and https://orgmode.org/list
>>> that pointed to gmane.org are now using this, so many links are
>>> functional again.
>>
>> Cool! I note that there's also NNTP access at news.yhetil.org, in
>> addition to gmane.io. Does yhetil have a search interface, or are there
>> other mechanisms for searching the archives (ideally in Gnus :))?
>
> The web interface ( or
> ) is the main mechanism for searching.  You
> don't necessarily have to leave Emacs for that, as public-inbox's pages
> render nicely in EWW.  But of course that's not the Gnus-based search
> you're hoping for.
>
> I use Gnus to follow some lists via NNTP, a mix of public-inbox archives
> and gmane.io, but I've never really done any fancy searching from it and
> don't use Gnus for my mail.  To try it out, I hit GG to search on a
> gmane.io list, but got an error [^1], so I suppose its search capability
> went away with Gmane's HTTP interface.

Yup, Gmane hasn't had in-Gnus search since then.

> Poking around a bit, I guess nnweb.el would be the main place that
> public-inbox's web search could be integrated into Gnus?  I've been
> (slowly) working on an Emacs package [^2] that adds public-inbox-related
> functionality to different "endpoints" (currently Notmuch, Gnus, EWW,
> Elfeed), and I'd be interested in any ideas for improving the Gnus
> support.

You wouldn't really use one backend (nnweb) to provide search support
for another (nntp). nnir can assign different search engines to
different backends -- what a "search engine" boils down to is a function
that accepts group search criteria, and returns groups and article
numbers (and optional relevance scoring) for matching messages. So if
public-inbox had some sort of an API that accepted a query and returned
the above information in some sort of easily-digestible format, it
wouldn't be hard to write a engine for it. Articles referenced in the
search results would then be retrieved via NNTP, so the article numbers
would need to correspond.

(Basically this is all the old Gmane search functionality did.)

> A couple of other notes:
>
>   * You can get the entire archive locally with a 'git clone', in which
> case you can transform it into a form that can be indexed/searched
> however you prefer (including with public-inbox, running a local
> public-inbox-httpd).  There are some pointers on extracting an
> archive to a Maildir at
> .

That would certainly be one approach! But not one that scales to many
users :)

>   * In the message above, Eric W. mentions that he is considering
> working on client tools with mairix-like search results.  That'd
> make the search capabilities available locally, and I'd imagine
> something like that could be nicely integrated with Gnus,
> considering it already has a mairix backend to use as a guide.

Yup, basically we'd just want a way to retrieve matching article numbers
that (ideally) didn't involve scraping a web page.

Thanks again,
Eric

Re: Bug: ob-python mangles multiline :var values [9.3.6 (release_9.3.6-397-ga089600)]

[Kyle Meyer]

Jack Kamm writes:

> My fix this time was to use functions from python.el to indent, and to
> detect whether we are in a string and shouldn't be indented.
>
> I also added a couple more unit tests, one for multiline strings, and
> one for the variable scope/assignment issue that Matt reported.

Thanks for working on this.

> diff --git a/lisp/ob-python.el b/lisp/ob-python.el
> index dbcfac08d..622f69ce3 100644
> --- a/lisp/ob-python.el
> +++ b/lisp/ob-python.el
> @@ -296,11 +296,15 @@ (defun org-babel-python-evaluate-external-process
>   (if (member "pp" result-params)
>   org-babel-python-pp-wrapper-method
> org-babel-python-wrapper-method)
> - (mapconcat
> -  (lambda (line) (format "\t%s" line))
> -  (split-string (org-remove-indentation (org-trim body))
> -"[\r\n]")
> -  "\n")
> + (with-temp-buffer
> +  (insert body)
> +  (goto-char (point-min))
> +  (while (< (point) (point-max))

nit-pick: In this code base, (not (eobp)) is the more common way to
spell this.

% git grep "(< (point) (point-max))" master | wc -l
1
% git grep "(not (eobp))" master | wc -l
44

> +(unless (python-syntax-context 'string)
> +  (python-indent-shift-right 
> (line-beginning-position)
> + (line-end-position)))

These lead to byte-compiler warnings:

Compiling /home/kyle/src/emacs/org-mode-devel/lisp/ob-python.el...

In end of data:
ob-python.el:391:1:Warning: the following functions are not known to be
defined: python-syntax-context, python-indent-shift-right

At the moment, python.el is only loaded for sessions (in
org-babel-python-initiate-session-by-key), assuming
org-babel-python-mode is set to `python'.  With the above change, you're
now using python.el functions in a non-session code path, so you'll need
a (require 'python) somewhere.

Also, just a note: I wondered whether python-syntax-context and
python-indent-shift-right are available in Emacs 24.3, the minimum Emacs
version we support.  They are.

Re: New mailing list archive at https://orgmode/list/

[Kyle Meyer]

[ +cc Eric Wong, mostly to say thanks for all the work he puts into
  public-inbox, which is the software behind these archives, but also so
  that he can correct me if I misrepresent any capabilities of or plans
  for public-inbox ]

> Bastien  writes:
>
>> with Kyle's help, I've set up a new mailing list archive:
>>
>> https://orgmode/list/
>>
>> References in https://orgmode.org and https://orgmode.org/list
>> that pointed to gmane.org are now using this, so many links are
>> functional again.
>
> Cool! I note that there's also NNTP access at news.yhetil.org, in
> addition to gmane.io. Does yhetil have a search interface, or are there
> other mechanisms for searching the archives (ideally in Gnus :))?

The web interface ( or
) is the main mechanism for searching.  You
don't necessarily have to leave Emacs for that, as public-inbox's pages
render nicely in EWW.  But of course that's not the Gnus-based search
you're hoping for.

I use Gnus to follow some lists via NNTP, a mix of public-inbox archives
and gmane.io, but I've never really done any fancy searching from it and
don't use Gnus for my mail.  To try it out, I hit GG to search on a
gmane.io list, but got an error [^1], so I suppose its search capability
went away with Gmane's HTTP interface.

Poking around a bit, I guess nnweb.el would be the main place that
public-inbox's web search could be integrated into Gnus?  I've been
(slowly) working on an Emacs package [^2] that adds public-inbox-related
functionality to different "endpoints" (currently Notmuch, Gnus, EWW,
Elfeed), and I'd be interested in any ideas for improving the Gnus
support.

A couple of other notes:

  * You can get the entire archive locally with a 'git clone', in which
case you can transform it into a form that can be indexed/searched
however you prefer (including with public-inbox, running a local
public-inbox-httpd).  There are some pointers on extracting an
archive to a Maildir at
.

  * In the message above, Eric W. mentions that he is considering
working on client tools with mairix-like search results.  That'd
make the search capabilities available locally, and I'd imagine
something like that could be nicely integrated with Gnus,
considering it already has a mairix backend to use as a guide.


[^1] open-network-stream: search.gmane.org/80 Name or service not known

 This was with Emacs 26.3, and it seems like this interface went
 away entirely in Emacs 27 with 37f0f114df (Remove the Gmane backend
 from nnir, 2018-04-11).

[^2] https://git.kyleam.com/piem/about/

Re: ox-* vs org-* naming convention?

[Kaushal Modi]

Hello,

This came up when I submitted ox-hugo to Melpa as well[1].

I stayed with the norm.. naming the package ox-hugo, but naming all the
functions and variables with org-hugo-* prefix.

[1] https://github.com/purcell/package-lint/issues/89

Re: 27.0.91; Avoid error on org-html-fontify-code

[Kyle Meyer]

Pierre Téchoueyres writes:

> Many thanks for that. If I've well understood it's on master.  Do you
> know (or guess) how long will this take to land in the next release ?

This month is the hope: https://orgmode.org/list/87pnaindwq@bzg.fr

> I had also open bugs #41641, may be will you close it ?

Done.

Re: bug#41641: 27.0.91; Avoid error on org-html-fontify-code

[Kyle Meyer]

Pierre Téchoueyres writes:

> I've also attached is a patch to fix this.

Thanks.

This patch was sent as a separate message to the Org mailing list [0]
and has been applied to the Org repo.  Closing.

[0]: https://orgmode.org/list/87eeqyyf4t@killashandra.ballybran.fr/

ox-* vs org-* naming convention?

[Diego Zamboni]

Hi,

I am working on submitting a new set of exporters I've been working on
(https://gitlab.com/zzamboni/ox-leanpub) to MELPA, and I received
feedback [1] about the discrepancy between the package names
(ox-leanpub-*) and the functions they define (org-leanpub-*). This is
also flagged by =package-lint=.

[1] https://github.com/melpa/melpa/pull/6942

I based these names on what I've observed in existing exporters - e.g.
ox-hugo, ox-latex, ox-reveal and most others define functions named
org-hugo-*, org-latex-*, org-reveal-* respectively.

I wouldn't mind renaming the package to org-leanpub, but I worry
whether this would affect its discoverability, and to diverge from
existing convention for exporter packages.

I would appreciate any feedback about this - what are strong arguments
for or against insisting in this convention vs just adapting to the
rules suggested by package-lint?

Thanks in advance,
--Diego

[join rows] (was: join tables from different files)

[Uwe Brauer]

>>> "t" == tbanelwebmin   writes:

   > Yes you can.
   > Use an org-id

Thanks! Nice!


I have a another question in this context:
can I join, say 4 tables, but row wise?

Say I have  


#+begin_src 

#+TBLNAME: RK
#+ATTR_HTML: :border 2 :rules all :frame border
| met | Q1 | Q2 |  Q3 | total |
|-+++-+---|
| RK  |  1 |  1 | 0.5 |   2.5 |
#+TBLFM: $5=$2+$3+$4



#+TBLNAME: SVD
#+ATTR_HTML: :border 2 :rules all :frame border
 | met | Q1: | Q2 | Q3 | total |
 |-+-+++---|
 | SVD | 0.5 |  1 |  1 |   2.5 |
#+TBLFM: $5=$2+$3+$4;f1

#+TBLNAME: MIN
#+ATTR_HTML: :border 2 :rules all :frame border
| met | Q1 |  Q2 | total |
|-++-+---|
| MIN |  2 | 0.5 |   2.5 |
#+TBLFM: $4=$2+$3


#+TBLNAME: BDF
#+ATTR_HTML: :border 2 :rules all :frame border
| met |   Q1 |   Q2 | total |
|-+--+--+---|
| MIN | 0.75 | 1.75 |   2.5 |
#+TBLFM: $4=$2+$3
#+end_src


Since they don't have the same amount of columns, I'd like to join the 4 tables 
like this

#+begin_src 
#+TBLNAME: Total1
#+ATTR_HTML: :border 2 :rules all :frame border
| met |  Q1 | Q2 |  Q3 | total |
|-+-++-+---|
| RK  |   1 |  1 | 0.5 |   2.5 |
|-+-++-+---|
| SVD | 0.5 |  1 |   1 |   2.5 |
#+TBLFM: $5=$2+$3+$4;f1

#+TBLNAME: Total2
#+ATTR_HTML: :border 2 :rules all :frame border
| met |   Q1 |   Q2 | total |
|-+--+--+---|
| MIN |2 |  0.5 |   2.5 |
|-+--+--+---|
| MIN | 0.75 | 1.75 |   2.5 |
#+TBLFM: $4=$2+$3
#+end_src

Is this possible?

regards

Uwe Brauer 


smime.p7s
Description: S/MIME cryptographic signature

Re: org-ref for html and blog ?

[Joseph Vidal-Rosset]

Hi again,

I just discovered that my problem came from citeproc-org

More exactly I had these lines in my init.el

(require 'citeproc)
(require 'citeproc-org)
(citeproc-org-setup)
(setq citeproc-org-html-bib-header "References\n")
(setq citeproc-org-default-style-file "~/Dropbox/Orgzly/ieee-with-url.csl")

The function (citeproc-org-setup) is the responsible of this new problem.

Sorry Andras to bother you with this problem with your package. I hope
that you will have a solution.

Best wishes,

Jo.

Le dim. 7 juin 2020 à 15:12, Joseph Vidal-Rosset
 a écrit :
>
> Hi everybody,
>
> The package org-ref  is a wonderful tool and I do not imagine working
> without its helps now (again many thanks to John Kitchin).
>
> But for some days now I meet a problem with bibliography html export
> with org-ref and I cannot no more use org-export-head that I used for
> my blog (https://github.com/itf/org-export-head thanks again to Ivan)
> : as soon as there is a bibliographical reference, emacs loops.
>
> I guess that the problem is very probably in my emacs setup but I do
> not find the solution.
>
> I would be happy to find help with html export with bibliographical
> references, and advices for the best solution for blogging with emacs
> (I've just tried Jekyll with org, but the problem with export
> bibliographical reference is the same, my emacs loops.)
>
> In advance, thanks for your help, because I am lost.
>
> Jo.

Re: issue tracker?

[Mario Frasca]

good day Bastien

On 07/06/2020 04:38, Bastien wrote:

anybody can
'vote-for' a bug, and you keep a counter on voted-for.

It would require people to register on updates.orgmode.org.
I'm not sure the expected benefit is really worth it for now.


why would it?  you already trust email senders on identity and integrity 
in all ways, you can also add this one.  a user is an email address.  
the benefit, in my eyes, is for you to have a measure of the opinion of 
(voiceful) users.



a maintainer can 'confirm' (that fixing that bug is
desirable).

I think it is important that anyone can confirm a bug.


I see differences among -confirming a behaviour, -confirming that a 
behaviour is a bug, -asserting that a maintainer would accept a 
"correction".  please drop the subject if you don't want me to argue in 
favour of something you have already discarded.



That said, I would love to organize a hackathon for Org-mode where
people would gather online for one day, exchange ideas, break and fix
things, propose new features, etc.  That is, IMHO, the way to recruit
new contributors, on top of simply formally asking "who would like to
be in charge of X, Y and Z?"


I like the `#emacs' irc chatroom on freenode, I discovered it recently.  
the more specific chatroom `#org-mode' is less active but not less 
welcoming.  it was there where I got the hint to write here, and where 
they told me "no need to subscribe".  or open a new temporary room, but 
I hope we stay with IRC, which we can use from within an emacs buffer.


ciao, Mario

org-ref for html and blog ?

[Joseph Vidal-Rosset]

Hi everybody,

The package org-ref  is a wonderful tool and I do not imagine working
without its helps now (again many thanks to John Kitchin).

But for some days now I meet a problem with bibliography html export
with org-ref and I cannot no more use org-export-head that I used for
my blog (https://github.com/itf/org-export-head thanks again to Ivan)
: as soon as there is a bibliographical reference, emacs loops.

I guess that the problem is very probably in my emacs setup but I do
not find the solution.

I would be happy to find help with html export with bibliographical
references, and advices for the best solution for blogging with emacs
(I've just tried Jekyll with org, but the problem with export
bibliographical reference is the same, my emacs loops.)

In advance, thanks for your help, because I am lost.

Jo.

Re: FWD: Org-Babel Support for Powershell

[tomas]

On Sun, Jun 07, 2020 at 01:47:45PM +0200, Russell Adams wrote:
> On Sat, Jun 06, 2020 at 11:38:38PM +, Gustav Wikström wrote:
> > #+begin_src powershell
> >   2+2
> > #+end_src
> >
> > #+RESULTS:
> > : 4
> 
> That's pretty easy. What executable should it run?
> 
> > /of topic It's safe to say the free software movement has gained a strong
> > footing [...]

> I think it's dangerously ignorant to choose to ignore 20+ years (in my career)
> of the actively user and OSS hostile actions that MS has taken. They are still
> an abusive monopoly.

Plus... they still are up to shenanigans. They just do it more quietly.

For a recent case, see their spat with the Privacy Commissioner of the City
of Berlin (sorry, German).

  https://t3n.de/news/microsoft-mahnt-berlin-wegen-ab-1281556/
  
https://www.tagesspiegel.de/berlin/warnung-vor-teams-skype-und-zoom-berlins-datenschutzbeauftragte-beugt-sich-vorlaeufig-microsoft/25841622.html

They're a corporation. They are out to make money. Other aspects
tend to stay behind. That's simple, ain't it?

Cheers
-- t


signature.asc
Description: Digital signature

Re: FWD: Org-Babel Support for Powershell

[Russell Adams]

On Sat, Jun 06, 2020 at 11:38:38PM +, Gustav Wikström wrote:
> #+begin_src powershell
>   2+2
> #+end_src
>
> #+RESULTS:
> : 4

That's pretty easy. What executable should it run?

> /of topic It's safe to say the free software movement has gained a strong
> footing in the software world. If it's "enemies" from the past are starting to
> walk in the same direction it would serve the free software advocates well to
> embrace and further encourage those steps. It would in my opinion be signs of
> maturity and true, good intentions. Judge not from where one comes, but for
> where one is heading.

I think it's dangerously ignorant to choose to ignore 20+ years (in my career)
of the actively user and OSS hostile actions that MS has taken. They are still
an abusive monopoly.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Align CJK characters in Org-table.

[Jeremie Juste]

Hello,

I just wanted to give more visibility to [0] valign which provides a way
to align CJK characters in org-table. It seems pretty recent but from
what I can tell it does the job. 

Best regards,
Jeremie
[0]: https://github.com/casouri/valign

Re: issue tracker?

[Bastien]

Hi Mario,

Mario Frasca  writes:

> very interesting approach. 

Thanks for looking more closely into it.

> sounds like you don't want to manage the status changes a bit
> tighter.  I know, I can check the code, but it's more practical if we
> mention it here explicitly.  anybody can send status change emails? 

Yes, anybody can confirm a bug and anybody can mark it as fixed.

> I mean, this is an open list, anybody who just knows how to put a
> header to an email can confirm a bug? 

Yes. The pattern I've seen in the last 15 ten years is that someone
sends a bug report and 50% of the time it is not really possible to
reproduce the bug.  And people who reproduce bugs are not always code
contributors, they can be "power users", so I think it's safe to allow
anyone to confirm a bug -- that's something that really helps.

> on the other hand, I never tried to add extra headers using
> thunderbird.

Yes, you can:

https://www.lifewire.com/arbitrary-custom-heading-email-thunderbird-1173089

> apart from the technical aspect, I would suggest: anybody can
> 'vote-for' a bug, and you keep a counter on voted-for.

It would require people to register on updates.orgmode.org.
I'm not sure the expected benefit is really worth it for now.

> but only a maintainer can 'confirm' (that fixing that bug is
> desirable). 

I think it is important that anyone can confirm a bug.

> then
> we new contributors can choose which confirmed bug is easy enough for
> us to make an attempt.  or which fits our interests and skills.  or
> which has accumulated most votes, hasn't been rejected, so we can
> remind the maintainer.
>
> … if the "main focus" is recruiting, I would also suggest a category
> "good first issue".

I have seen "good first issues" in many repositories and I don't think
it is sufficient as a way to attract new contributors: those tags are
useful when you also actively organize the contribution and the
onboarding of new contributors.

Also, "good first issues" are often those we can fix very easily and
there is no good reason not to fix them.

That said, I would love to organize a hackathon for Org-mode where
people would gather online for one day, exchange ideas, break and fix
things, propose new features, etc.  That is, IMHO, the way to recruit
new contributors, on top of simply formally asking "who would like to
be in charge of X, Y and Z?"

> I understand, not a bug "tracking" tool, but it sounds like it's able
> to shed some light in the dark.

Yes, I hope so!

-- 
 Bastien