Re: Google SoC organisation application

2021-02-02 Thread TEC


All good points, but I'll just quickly respond to this:

Daniele Nicolodi  writes:

> Please understand that the GSoC is not a way to get labor for the
> project sponsored by Google: it is very likely that the time investment
> required to the mentors would be more than enough to implement what the
> students will do during the GSoC. The GSoC is more an opportunity to
> form a possible future long term contributor to the project.

As it happens, this is precisely why I decided to start this thread. I
see GSoC as a great chance to help people who have been tentatively
considering getting into Org development a little push and hopefully
create some new long-term contributors :)

With projects, I know I at least have no shortage of ideas; mentors
might be hard though 樂.

--
Timothy



Re: Google SoC organisation application

2021-02-02 Thread TEC


Jose E. Marchesi  writes:

>> Google's SoC organisation applications are currently open, and close on
>> <2020-02-20>. I know that Org participated once, in 2012.
>>
>> Would it be a good idea to submit an application to do so again?
>> With the rise in interest in computational notebooks, blogging tools,
>> and other features that Org possesses I'd imagine we have a decent shot.
>>
>> If so, we have just over two weeks to do so.
>
> Note that, as always, the GNU Project will be applying as a mentoring
> organization [1] [2].

That's nice, I don't see Org listed under
https://www.gnu.org/software/soc-projects/ideas-2020.html but good to
know (particularly for any SoC eligible people reading this ML) :)

If nothing else, I think it could be worth applying separately for the
extra recognition, and perhaps Google might approve more applications
when Org and GNU are both listed? I don't really know how this works in
depth though.

--
Timothy



Google SoC organisation application

2021-02-02 Thread TEC
Hello All,

Google's SoC organisation applications are currently open, and close on
<2020-02-20>. I know that Org participated once, in 2012.

Would it be a good idea to submit an application to do so again?
With the rise in interest in computational notebooks, blogging tools,
and other features that Org possesses I'd imagine we have a decent shot.

If so, we have just over two weeks to do so.

All the best,

Timothy.



Re: http links translated to html : target "_blank"

2021-02-01 Thread TEC


Uwe Brauer  writes:

> Aha, thanks, it works, sometimes:
>
> The first two work, the last two not. Not sure what to think about it

Mmm, you need to have #+attr_html immediately followed by the link on
the next line.

It would be nice if there was a way to set these attributes inline with
the link, but AFAIK that's not currently possible.

--
Timothy



Re: emphasizing source code words

2021-02-01 Thread TEC


Luca Ferrari  writes:

> Hi all,
> I'm using org to produce beamer presentations, and I've a lot of src blocks.
> Is there any way to emphasize words or lines within such blocks? For
> example to place the command arguments in bold face?
>
> Thanks,
> Luca

I'd have to look at the manual for specifics, but I know that you can
highlight lines when using the minted backend.

Hope that might be of some help,

--
Timothy.



Re: http links translated to html : target "_blank"

2021-02-01 Thread TEC


Uwe Brauer  writes:

> I need to produce a html file, with links opening new tabs (pages) as in 
>
> https://apps.apple.com/es/app/radar-covid/id1520443509; 
> target="_blank">Descarga Directa
>
> However 
>
>  [[https://www.mpic.de/4747361/risk-calculator target="_blank"][Simulador de 
> riesgo con más detalle]]
>
> Did not work
>
> Any ideas?

Have you tried:
#+attr_html: :target _blank

That may work.

--
Timothy



[PATCH] document org-html-meta-tags

2021-01-31 Thread TEC
Hi Kyle, All,

As requested, here's a small documentation entry for the new setting :)

>From 636330422eef59f448a60b933be9a5581af9 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 1 Feb 2021 03:01:12 +0800
Subject: [PATCH] manual, news: Document org-html-meta-tags

* docs/org-manual.org, etc/ORG-NEWS: Document and announce the new
setting `org-html-meta-tags'.
---
 doc/org-manual.org | 3 +++
 etc/ORG-NEWS   | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 20a0d1d7a..a82b0f9a4 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12624,6 +12624,9 @@ settings described in [[*Export Settings]].
   multiple =DESCRIPTION= lines.  The exporter takes care of wrapping
   the lines properly.
 
+  The exporter includes a number of other meta tags, which can be customised
+  by modifying ~org-html-meta-tags~.
+
 - =HTML_DOCTYPE= ::
 
   #+cindex: @samp{HTML_DOCTYPE}, keyword
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ba769224f..a2f1667b2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -81,6 +81,13 @@ block. ~org-babel-latex-preamble~, ~org-babel-latex-begin-env~ and
 the user to specify the preamble and code that preceedes and proceeds
 the contents of the source block.
 
+*** New option ~org-html-meta-tags~  allows for HTML meta tags customisation
+
+New variable ~org-html-meta-tags~ makes it possible to customise the
+== tags used in an HTML export. Accepts either a static list of
+values, or a function that generates such a list (see
+~org-html-meta-tags-default~ as an example of the latter).
+
 ** New features
 *** =ob-python= improvements to =:return= header argument 
 
-- 
2.30.0


Oh, by the way --- regarding your commits on commit/code conventions.
With (what seem like to me) quite a few "best practices" to keep in
mind, has anyone created a patch lint tool to make sure they're being
adhered to? I imagine it wouldn't be hard to check for blank lines in
functions or commits without a sentence case commit message.

For someone who isn't aware of all the nits that may be picked :P this
would be rather useful, and far better than a list of guidelines (I'm
not actually any such list though).

Oh dear, I sense myself diverging but I'm now considering the
possibility of setting up CI for the org-mode repo to check for as many
such concerns as we can to try to make the code base more consistent
(from my experience, every time I'm told to check for a specific issue
in a patch I wrote, I find many other matches in the file).

Perhaps it could be possible to hook up the ML to a process that runs
the CI script on a copy of Org with the patch(es) applied and replies
with any errors that may come up?

I should really stop here, before I really get going and start
explaining why I think it could be good to migrate to Gitea and other
ideas :P

Feel free to disregard my ramble, I've just been accumulating thoughts
on the state of Org development, and a few are liable to spill out.

All the best,

Timothy


Re: Microsoft Excel getting features we have had for a long time in org :-)

2021-01-31 Thread TEC


Eric S Fraga  writes:

> I actually tell (warn?) my students that spreadsheets are an example of
> a "write-only programming language", the other being APL (for those with
> long memories).

I may not be of the right generation to remember APL, but I used to love
spreadsheets ... until I had to look at the same spreadsheet later
[shudder].

Using Org tables for small things and an actual program (python, R,
julia, etc.) for anything medium-large I've found vastly superior to
spreadsheets.

Good for Excel, but as far as I'm concerned it's a bit like making a
pitcher plant smell nicer . The trap is more enticing, but you still
end up in the same mess.

--
Timothy



Re: [PATCH] Enhance org-html--build-meta-info

2021-01-20 Thread TEC


Kyle Meyer  writes:

> I've applied this (a8df7670c) with two minor changes (shown in the diff
> at end): s/with with/with/ in a docstring and move an element to its own
> line to avoid the warning from lisp-mode's lisp--match-hidden-arg.

Thanks :)

> This thread has gone on long enough that I'll avoid requesting changes
> for convention/style nits, but some things to keep in mind for future
> patches:

I'll try to keep these in mind in future. Might there be a Worg page or
something listing all of these little things so I don't keep on being
told of them a few at a time as I violate them?

> Also, it'd be good for this to be accompanied by a NEWS entry.  I'd
> appreciated if that were sent in a separate thread, though.  For some
> reason I haven't debugged, my usual MUA can't load this thread.

Will do .

--
Timothy



Re: [PATCH] tweaks to ox-html style

2021-01-20 Thread TEC


Gah! I left the subject as a placeholder [shame emoji].
Apologies for that.

Why do I always seem to notice these things as the Email is sending...

--
Timothy

TEC  writes:

> Hi All,
>
> This is just some tweaks to the styling in ox-html that I think may
> appeal (and prevent ridiculously long lines on non-small displays, which
> are an issue for legibility).
>
> I also took the opportunity to remove the (obsolete) CDATA strings and
> make the CSS more consistently formatted. If you don't want this to
> get its own commit, please just squash it.
>
> Style changes:
> - Restrict max content width, and centre
> - tweak styling of source code blocks
>
> I took some screenshots (1440p monitor, 120% zoom, Firefox).
> Current: https://0x0.st/-iW9.png
> This patch: https://0x0.st/-iWp.png
>
> All the best,
>
> Timothy.




[PATCH]

2021-01-20 Thread TEC
Hi All,

This is just some tweaks to the styling in ox-html that I think may
appeal (and prevent ridiculously long lines on non-small displays, which
are an issue for legibility).

I also took the opportunity to remove the (obsolete) CDATA strings and
make the CSS more consistently formatted. If you don't want this to
get its own commit, please just squash it.

Style changes:
- Restrict max content width, and centre
- tweak styling of source code blocks

I took some screenshots (1440p monitor, 120% zoom, Firefox).
Current: https://0x0.st/-iW9.png
This patch: https://0x0.st/-iWp.png

All the best,

Timothy.

>From 635bd77cd7a2dc55cc0705c5bbf2e11091bfbaf3 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 20 Jan 2021 16:37:29 +0800
Subject: [PATCH 1/5] ox-html.el: remove CDATA strings

* lisp/ox-html.el (org-html-scripts, org-html-style-default,
org-html-infojs-template): remove CDATA strings, as they are now
considered obsolete --- see
https://developer.mozilla.org/en-US/docs/Web/API/CDATASection#specifications
---
 lisp/ox-html.el | 8 
 1 file changed, 8 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e35c..0cf3425df 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -234,7 +234,6 @@ property on the headline itself.")
 (defconst org-html-scripts
   "
 // @license magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt Public Domain
-<!--/*--><![CDATA[/*><!--*/
  function CodeHighlightOn(elem, id)
  {
var target = document.getElementById(id);
@@ -251,14 +250,12 @@ property on the headline itself.")
  target.classList.remove(\"code-highlighted\");
}
  }
-/*]]>*///-->
 // @license-end
 "
   "Basic JavaScript that is needed by HTML files produced by Org mode.")
 
 (defconst org-html-style-default
   "
- <!--/*--><![CDATA[/*><!--*/
   .title  { text-align: center;
  margin-bottom: .2em; }
   .subtitle { text-align: center;
@@ -439,7 +436,6 @@ property on the headline itself.")
   .org-info-js_search-highlight
 { background-color: #00; color: #00; font-weight: bold; }
   .org-svg { width: 90%; }
-  /*]]>*/-->
 "
   "The default style specification for exported HTML files.
 You can use `org-html-head' and `org-html-head-extra' to add to
@@ -515,10 +511,8 @@ means to use the maximum value consistent with other options."
 
 
 // @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&amp;dn=gpl-3.0.txt GPL-v3-or-Later
-<!--/*--><![CDATA[/*><!--*/
 %MANAGER_OPTIONS
 org_html_manager.setup();  // activate after the parameters are set
-/*]]>*///-->
 // @license-end
 "
   "The template for the export style additions when org-info.js is used.
@@ -1448,13 +1442,11 @@ done, timestamp, timestamp-kwd, tag, target.
 For example, a valid value would be:
 

-/*<![CDATA[*/
   p { font-weight: normal; color: gray; }
   h1 { color: black; }
   .title { text-align: center; }
   .todo, .timestamp-kwd { color: red; }
   .done { color: green; }
-/*]]>*/

 
 If you want to refer to an external style, use something like
-- 
2.29.2

>From 5bef340093102936efe831f85fabdb589070ce43 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 20 Jan 2021 16:45:20 +0800
Subject: [PATCH 2/5] ox-html.el: limit maximum content width and center

* lisp/ox-html.el (org-html-style-default): To improve the appearance
and legibility on larger screens:
 1. Limit the content width to the upper end of advised line width, ~140
 characters.
 2. Centre the content.
---
 lisp/ox-html.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 0cf3425df..9bbfad678 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -256,6 +256,7 @@ property on the headline itself.")
 
 (defconst org-html-style-default
   "

Ready to merge! Re: [PATCH] Enhance org-html--build-meta-info

2021-01-14 Thread TEC


This thread has dragged on ages, and if no-one else is following this
chain I wouldn't blame them in the slightest.

To help indicate that this is actually ready (at last) now, I'm just
going to add that info the the subject line in the hope it helps Bastien
or any others notice that this is actually good to go now :)

--
Timothy

Jens Lechtenboerger  writes:

> This looks fine to me.  Many thanks!
>
> Best wishes
> Jens




Re: [PATCH] Enhance org-html--build-meta-info

2021-01-14 Thread TEC

TEC  writes:

>> Sorry, I still see the flycheck warning and "amp;" for "&".
> Maybe I accidently sent you the old patches? I'll check tomorrow.

Hah, I check and guess what I see? The changes were unstaged .

Sorry about that, here's an actual revision.

--
Timothy

>From 3ab8b4f108c8cfa4b0bf11842907c31846832f1a Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the  element, which would violate W3C.
---
 lisp/ox-html.el | 118 
 1 file changed, 60 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e35c..f18f8a2ef 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,80 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry
+(label identity  content-format  content-formatters)
+  "Build a meta tag using the provided information.
+
+Construct  tag of form , or when CONTENT-FORMAT
+is present: 
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the
+CONTENT-FORMAT and encoding the result as plain text."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-plain-text
+		 (org-element-interpret-data (plist-get info :title)) info))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-html-plain-text
+   (org-element-interpret-data auth) info)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "charset=\"%s\"" info)
-	(org-html-close-tag
-	 "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
-	 info))
-  charset) "\n"
+
+ (if (org-html-html5-p info)
+	 (org-html--build-meta-entry "charset" charset)
+   (org-html--build-meta-entry "http-equiv" "Content-Type"
+   (concat "text/html;charset=" charset)))
+
  (let ((viewport-options
 	(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
 			  (plist-get info :html-viewport
-   (and viewport-options
-	(concat
-	 (org-html-close-tag
-	  "meta"
-	  (format "name=\"viewport\" content=\"%s\""
-		  (mapconcat
-		   (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
-		   viewport-options ", "))
-	  info)
-	 "\n")))
+   (if viewport-options
+	   (org-html--build-meta-entry "name" "viewport"
+   (mapconcat
+	(lambda (elm)
+  (format "%s=%s" (car elm) (cadr elm)))
+	viewport-options ", "
+
  (format "%s\n" title)
- (org-html-close-tag "meta" "name=\"generator\" content=\"Org mode\"" info)
- &quo

Re: [PATCH] Enhance org-html--build-meta-info

2021-01-10 Thread TEC


Jens Lechtenboerger  writes:

> Sorry, I still see the flycheck warning and "amp;" for "&".

Maybe I accidently sent you the old patches? I'll check tomorrow.

--
Timothy.



Re: [PATCH] Enhance org-html--build-meta-info

2021-01-10 Thread TEC

Jens Lechtenboerger  writes:

> On line 1432 I get this suggestion from flycheck:
> There should be two spaces after a period (emacs-lisp-checkdoc)
>
> More importantly, I just realized that for author information,
> org-html-plain-text is applied twice, leading to "amp;" when
> translating "&".  (Once inside org-html-meta-tags-default, then in
> org-html--build-meta-entry.)  This should not happen.
>
> Best wishes
> Jens

Fixed. [exhales]

Thanks for consistently getting back to me on this patch Jens :)

--
Timothy

>From 3ab8b4f108c8cfa4b0bf11842907c31846832f1a Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the  element, which would violate W3C.
---
 lisp/ox-html.el | 118 
 1 file changed, 60 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e3..f18f8a2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,80 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry
+(label identity  content-format  content-formatters)
+  "Build a meta tag using the provided information.
+
+Construct  tag of form , or when CONTENT-FORMAT
+is present: 
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the
+CONTENT-FORMAT and encoding the result as plain text."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-plain-text
+		 (org-element-interpret-data (plist-get info :title)) info))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-html-plain-text
+   (org-element-interpret-data auth) info)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "charset=\"%s\"" info)
-	(org-html-close-tag
-	 "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
-	 info))
-  charset) "\n"
+
+ (if (org-html-html5-p info)
+	 (org-html--build-meta-entry "charset" charset)
+   (org-html--build-meta-entry "http-equiv" "Content-Type"
+   (concat "text/html;charset=" charset)))
+
  (let ((viewport-options
 	(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
 			  (plist-get info :html-viewport
-   (and viewport-options
-	(concat
-	 (org-html-close-tag
-	  "meta"
-	  (format "name=\"viewport\" content=\"%s\""
-		  (mapconcat
-		   (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
-		   viewport-options ", "))
-	  info)
-	 "\n")))
+   (if viewport-options
+	   (org-html--build-meta-entry "name" "viewport"
+   (mapconcat
+	(lambda (elm)
+

Re: [PATCH] Enhance org-html--build-meta-info

2021-01-03 Thread TEC

Jens Lechtenboerger  writes:

> org-html--build-meta-entry and org-html--build-meta-info include some long 
> lines.

Hehe. We've had a lot of back-and-forth haven't we.
At least it feels like it's coming to a close now.

> For org-html-meta-tags-default, I suggest this as last line for the doc
> string (typos, active voice):
> Use document's plist INFO to derive relevant information for the tags.

Sounds good. Done.

--
Timothy

>From f3f7325ea77cc443387e69f65e899a9537606d80 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the  element, which would violate W3C.
---
 lisp/ox-html.el | 118 
 1 file changed, 60 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e3..f18f8a2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,80 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry
+(label identity  content-format  content-formatters)
+  "Build a meta tag using the provided information.
+
+Construct  tag of form , or when CONTENT-FORMAT
+is present: 
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the
+CONTENT-FORMAT and encoding the result as plain text."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-plain-text
+		 (org-element-interpret-data (plist-get info :title)) info))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-html-plain-text
+   (org-element-interpret-data auth) info)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "charset=\"%s\"" info)
-	(org-html-close-tag
-	 "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
-	 info))
-  charset) "\n"
+
+ (if (org-html-html5-p info)
+	 (org-html--build-meta-entry "charset" charset)
+   (org-html--build-meta-entry "http-equiv" "Content-Type"
+   (concat "text/html;charset=" charset)))
+
  (let ((viewport-options
 	(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
 			  (plist-get info :html-viewport
-   (and viewport-options
-	(concat
-	 (org-html-close-tag
-	  "meta"
-	  (format "name=\"viewport\" content=\"%s\""
-		  (mapconcat
-		   (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
-		   viewport-options ", "))
-	  info)
-	 "\n")))
+   (if viewport-options
+	   (org-html--build-meta-entry "name" "viewport"
+   (mapconcat
+	(lambda (elm)
+  (format "%s=%s" (car elm) (cadr elm)))
+	viewport-options ", "
+
  (format "%s\n" titl

Re: [PATCH] Enhance org-html--build-meta-info

2021-01-03 Thread TEC

Jens Lechtenboerger  writes:

> The doc strings of org-html-meta-tags and org-html-meta-tags-default
> need to be updated, they still mention author and title.

Ah, yep. Fixed.

> Also, please try checkdoc ;)

Ahhh yes. Checkdoc, my old ~enemy~ /friend/.

I may have shied away from using this because of the litany of issues it
raises for the file.  How I'd love to see a PR making the Org codebase
more consistently follow these guidelines.  Then we could potentially do
something like integrate CI into the patch acception workflow.

Enough of that digression, as before: patches attached :)

--
Timothy.

>From de74dcbd51703439faafe96cbc1c60965f064eaa Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the  element, which would violate W3C.
---
 lisp/ox-html.el | 116 
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e3..4d277a2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,78 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry (label identity  content-format  content-formatters)
+  "Build a meta tag using the provided information.
+
+Construct  tag of form , or when CONTENT-FORMAT is present:
+
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the CONTENT-FORMAT and encoding
+the result as plain text."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-plain-text
+		 (org-element-interpret-data (plist-get info :title)) info))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-html-plain-text
+   (org-element-interpret-data auth) info)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "charset=\"%s\"" info)
-	(org-html-close-tag
-	 "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
-	 info))
-  charset) "\n"
+
+ (if (org-html-html5-p info)
+	 (org-html--build-meta-entry "charset" charset)
+   (org-html--build-meta-entry "http-equiv" "Content-Type"
+   (concat "text/html;charset=" charset)))
+
  (let ((viewport-options
 	(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
 			  (plist-get info :html-viewport
-   (and viewport-options
-	(concat
-	 (org-html-close-tag
-	  "meta"
-	  (format "name=\"viewport\" content=\"%s\""
-		  (mapconcat
-		   (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
-		   viewport-options ", "))
-	  info)
-	 "\n")))
+   (if viewport-options
+	   (org-html--build-meta-entry "name" "viewport"
+   (mapconcat
+	(la

Re: [PATCH] A proposal to add LaTeX attributes to verse blocks

2021-01-03 Thread TEC


Juan Manuel Macías  writes:

> Thank you very much for your response and your comments.

Seriously, thanks for the patch. I think the ML is usually a bit more
responsive, but it seems to be a bit quiet at the moment.

> I agree to name "Insert, include, etc." the attribute to include
> arbitrary LaTeX code, better than "options".

Glad my feedback seems to have gone down well :). If the only likely use
of this is adjusting the font, perhaps for the sake of consistency we
can match the behaviour of tables, which take a :font LaTeX attribute?

> Of course, I can add the necessary documentation to the files you tell
> me. As I am new to submitting patches, I don't really know how to
> proceed: do I have to send you the new version of the patch, with the
> documentation? Should I send a new email with all of it to this list?

Thanks for asking. Sometimes it seems the maintainers take the trouble of
adding an ORG-NEWS entry or minor touching ups to the patch, but I think
it's nice to leave as little for them to do as possible :)

Announce changes in: etc/ORG-NEWS
Document new/different behaviour in: doc/org-manual.org

I think Markup for /Rich Contents > Paragraphs/ may be the right place
to add a description of this functionality --- verse blocks are
discussed around line 10750.

Regarding how patches on this ML work, this is what I've observed:
- Initial version of patch submitted, with justification/explanation
- Feedback may be given
- Revisions of the patch are attached in replies to feedback
- Process repeats until everyone's happy
- Patch is merged

i.e. it all tends to happen in the same thread.

Hope this helps,

Timothy.



Re: [PATCH] A proposal to add LaTeX attributes to verse blocks

2021-01-03 Thread TEC


Hi Juan,

Thanks for your patch. 

This looks like a fairly sensible addition. Two comments from me:

1. I'm not sure that "options" is a good name for arbitrary LaTeX which
   is included inside the verse block. Perhaps something like "insert"
   or "include", etc. may be a better fit.
2. It's considered generally nice to document features like this :) The
   two documents which I'd think to note this in are ORG-NEWS and the
   manual (docs/manual.org).

All the best,

Timothy.

Juan Manuel Macías  writes:

> (Sorry, due to a mistake, the text of my message did not appear in my 
> previous email)
>
> Hi,
>
> I would like to propose this patch to add some LaTeX attributes to the verse 
> block,
> especially to be able to apply certain features from the verse.sty package, 
> which is an
> extension (widely used in Humanities) of the standard LaTeX 'verse' 
> environment.
>
> These attributes would be:
>
> - `:lines' to add verse numbers, according to any numbering sequence
> - `:center' to apply the optical centering of the poem, which is a 
> typographic convention
>   whereby a poem or a group of verses is centered on the page, taking the 
> width of the
>   longest verse as a reference. In fact, optical centering is the correct 
> arrangement of
>   verses in a document.
> - `:versewidth' which expects a text string that is the longest verse of the 
> poem,
>   required when applying the `:center' attribute.
>
> As I said, these three attributes require the LateX package verse.sty. A 
> fourth `:options'
> attribute would be used to add arbitrary code within the verse environment.
>
> Consider this complete example with Shakespeare's first sonnet:
>
> #+begin_src org
>   ,#+ATTR_LaTeX: :center t :options \small :lines 5
>   ,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial 
> fuel,
>   ,#+begin_verse
>   From fairest creatures we desire increase,
>   That thereby beauty’s rose might never die,
>   But as the riper should by time decrease,
>   His tender heir mught bear his memeory:
>   But thou, contracted to thine own bright eyes,
>   Feed’st thy light’st flame with self-substantial fuel,
>   Making a famine where abundance lies,
>   Thyself thy foe, to thy sweet self too cruel.
>   Thou that art now the world’s fresh ornament
>   And only herald to the gaudy spring,
>   Within thine own bud buriest thy content
>   And, tender churl, makest waste in niggarding.
>   Pity the world, or else this glutton be,
>   To eat the world’s due, by the grave and thee.
>   ,#+end_verse
> #+end_src
>
> when exporting to LaTeX we get:
>
> #+begin_src latex
> \settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial 
> fuel,}
> \begin{verse}[\versewidth]
> \poemlines{5}
> \small
> From fairest creatures we desire increase,\\
> That thereby beauty’s rose might never die,\\
> But as the riper should by time decrease,\\
> His tender heir mught bear his memeory:\\
> But thou, contracted to thine own bright eyes,\\
> Feed’st thy light’st flame with self-substantial fuel,\\
> Making a famine where abundance lies,\\
> Thyself thy foe, to thy sweet self too cruel.\\
> Thou that art now the world’s fresh ornament\\
> And only herald to the gaudy spring,\\
> Within thine own bud buriest thy content\\
> And, tender churl, makest waste in niggarding.\\
> Pity the world, or else this glutton be,\\
> To eat the world’s due, by the grave and thee.\\
> \end{verse}
> #+end_src
>
> In an attached image I send a screenshot with the typographic result
>
> And finally, this is the patch I would propose
>
> #+begin_src diff
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 2a14b25d5..bc6b64e78 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3506,6 +3506,16 @@ channel."
>"Transcode a VERSE-BLOCK element from Org to LaTeX.
>  CONTENTS is verse block contents.  INFO is a plist holding
>  contextual information."
> +(let*
> +  ((lin (org-export-read-attribute :attr_latex verse-block :lines))
> +   (opt (org-export-read-attribute :attr_latex verse-block :options))
> +   (cent (org-export-read-attribute :attr_latex verse-block :center))
> +   (attr (concat
> +   (if cent "[\\versewidth]" "")
> +   (if lin (format "\n\\poemlines{%s}" lin) "")
> +   (if opt (format "\n%s" opt) "")))
> +   (versewidth (org-export-read-attribute :attr_latex verse-block 
> :versewidth))
> +   (vwidth-attr (if versewidth (format 
> "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
>(concat
> (org-latex--wrap-label
>  verse-block
> @@ -3513,7 +3523,9 @@ contextual information."
>  ;; character and change each white space at beginning of a line
>  ;; into a space of 1 em.  Also change each blank line with
>  ;; a vertical space of 1 em.
> -(format "\\begin{verse}\n%s\\end{verse}"
> +(format "%s\\begin{verse}%s\n%s\\end{verse}"
> +   vwidth-attr
> +   attr
>   (replace-regexp-in-string
>  

Re: [patch] A proposal to add LaTeX attributes to verse blocks

2021-01-03 Thread TEC


Hi Juan,

Since you've resent this in a second email, let's discuss this patch
there.

As such, I'm marking this patch as closed.

--
Timothy.



Re: [PATCH] ox-md.el/preserve radio target hyperlink

2021-01-03 Thread TEC


Hi turbo.

As this appears to be an exact duplicate of your other email, I'm going
to mark this as closed and hope that any/all conversation on your patch
happens there.

--
Timothy



Re: [PATCH] ox-md.el/markdown-hyperlink

2021-01-03 Thread TEC


Thanks for the patch turbo.

I was able to test this with a simple Org file, and both observed the
issue with radio targets in generated markdown files, and observed the
patch fixing it, as intended.

--
Timothy

turbo.c...@clovermail.net  writes:

> exporting to markdown loses radio target hyperlinks.



Re: [PATCH] Async session eval (2nd attempt)

2021-01-03 Thread TEC


Hi Jack,

I love the look of this! Thanks for submitting a patch.

Sorry it's taken so long for someone to take a look at it, I think a lot
of the 'main' Org people have been pretty busy over the last few months.

I just tried to give this a shot.
First up, I had to remove the ORG-NEWS part of the patch to be able to
provide it. It would be nice if you could update the patch so this
applies cleanly.

#+begin_example
error: patch failed: etc/ORG-NEWS:88
error: etc/ORG-NEWS: patch does not apply
#+end_example

To test this, after applying your patch (with ORG-NEWS removed), I
started emacs -Q, loaded Org, and opened a new file.

I was initially unable to get this to seem to work, until I changed the
:results type to "output".

See a excerpt from my test file below:

- excerpt start -

#+begin_src python :async :session blah :results output
from time import sleep

a=2

sleep(2)
print("Hi")
#+end_src

#+RESULTS:
: Hi

#+begin_src python :async :session blah
return(a)
#+end_src

#+RESULTS:
: /tmp/babel-62cQRX/python-EfJ4o4

#+begin_src python :async :session blah :results output
print(a)
#+end_src

#+RESULTS:
: 2

- excerpt end -


I'm surprised this didn't work with the non-output block though.

Other than this, I'm rather happy to see that when I tried to execute
two long running blocks at once, the second one was not executed until
the first completed :)

Finally, I see that this requires :session to be set in order to work.
Might it be possible to have this work for non-session blocks too? It
seems odd that what I'd imagine is the harder case (session blocks) is
supported, but one-shot (non-session) blocks aren't.

Thanks again for your work, and I look forward to seeing what else you
have in the future!

--
Timothy

p.s. After this is merged, it would be great to see support for other
languages grow :)

Jack Kamm  writes:

> This patch adds asynchronous evaluation for session blocks in
> Python. It also adds functionality to implement async session eval for
> other languages using ob-comint.el.
>
> To test the attached patch, add ":async" to a Python session block
> with a long computation (or "time.sleep") in it. Upon evaluation, your
> Emacs won't freeze to wait for the result -- instead, a placeholder
> will be inserted, and replaced with the true result when it's ready.
>
> I'll note how this is different from some related projects. ob-async
> implements asynchronous evaluation for Babel, but it doesn't work with
> sessions. emacs-jupyter, ein, and ob-ipython all implement
> asynchronous session evaluation, but only for Jupyter kernels. Jupyter
> is great for some cases, but sometimes I prefer to use the built-in
> org-babel languages without jupyter.
>
> The new functionality is mainly implemented in
> `org-babel-comint-async-filter', which I've defined in ob-comint.el,
> and added as a hook to `comint-output-filter-functions'.  Whenever new
> output is added to the comint buffer, the filter scans for an
> indicator token (this is inspired by
> `org-babel-comint-with-output'). Upon encountering the token, the
> filter uses a regular expression to extract a UUID or temp-file
> associated with the result, then searches for the appropriate location
> to add the result to.
>
> This is my 2nd attempt at this patch [0]. I have also ported it to an
> external package [1], but would like to have this functionality in Org
> proper, to permit better code reuse between async and sync
> implementations. The external package also includes an R
> implementation that I regularly use, as well as a Ruby implementation,
> but I've left these out to keep this initial patch smaller, and also I
> need to confirm copyright assignment on the Ruby implementation which
> was externally contributed.
>
> [0] 
> https://orgmode.org/list/87muj04xim.fsf@jaheira.i-did-not-set--mail-host-address--so-tickle-me/
> [1] https://github.com/jackkamm/ob-session-async



Re: [PATCH] Enhance org-html--build-meta-info

2021-01-02 Thread TEC

After considering the information passed to a meta info generation
function, I'm now in agreement with you that just passing `info' is the
most sensible way forward.

Attached is a (final?) set of patches, which is as described.

--
Timothy.

>From e8c9646ae6c5083417a927bd2b23bb0f837930d2 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the  element, which would violate W3C.
---
 lisp/ox-html.el | 114 
 1 file changed, 56 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e3..f74c6a4 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,76 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry (label identity  content-format  content-formatters)
+  "Construct  tag of form , or when CONTENT-FORMAT is present:
+
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the CONTENT-FORMAT and encoding
+the result as plain text."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-plain-text
+		 (org-element-interpret-data (plist-get info :title)) info))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-html-plain-text
+   (org-element-interpret-data auth) info)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "charset=\"%s\"" info)
-	(org-html-close-tag
-	 "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
-	 info))
-  charset) "\n"
+
+ (if (org-html-html5-p info)
+	 (org-html--build-meta-entry "charset" charset)
+   (org-html--build-meta-entry "http-equiv" "Content-Type"
+   (concat "text/html;charset=" charset)))
+
  (let ((viewport-options
 	(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
 			  (plist-get info :html-viewport
-   (and viewport-options
-	(concat
-	 (org-html-close-tag
-	  "meta"
-	  (format "name=\"viewport\" content=\"%s\""
-		  (mapconcat
-		   (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
-		   viewport-options ", "))
-	  info)
-	 "\n")))
+   (if viewport-options
+	   (org-html--build-meta-entry "name" "viewport"
+   (mapconcat
+	(lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
+	viewport-options ", "
+
  (format "%s\n" title)
- (org-html-close-tag "meta" "name=\"generator\" content=\"Org mode\"" info)
- "\n"
- (and (org-string-nw-p author)
-	  (concat
-	   (org-html-close-tag "meta"
-			   (format "name=\"author\" content=\"%s

Re: Release Org 9.4.2

2020-12-29 Thread TEC


Gustav Wikström  writes:

> It is my believe that Org would benefit from a counter that would "tic
> up" even if no one collects the money. Like it or not, money has an
> effect. Better to allocate it to open source work than anything else! Or?

I've never used it, but could something like https://opencollective.com
be good for this?

Just a thought,

Timothy.



Re: [PATCH] Apply emacs manual css to org pages

2020-12-27 Thread TEC


Hi Samuel,

We could add some of our own CSS, but that would have us deviate from
the Emacs manual. It's worth asking if we want to do that IMO.

--
Timothy

Samuel Wales  writes:

> i wonder if css makes it possible to have wider margins /except/ for
> tables and stuch.  or perhaps that is consiedered bad style.  but it
> would be accessible/functional.  but i am just glad that it is only
> tables that need horizontal scrolling.
>
> On 12/27/20, Samuel Wales  wrote:
>> if i were to make any /tiny nit-level/ suggestions from my pov it
>> would be somewhat wider margins, not pure white but slightly [so still
>> /very/ high contrast] warmer for fg, and some less-blue for links [but
>> i realize blue is common].
>>
>> i would also do [ha ha, as if i knew what to do or even whether it is
>> possible] wrapping for left columns that go under text rather than
>> bullet for e.g this line: "• Extracting Agenda Information   
>>  Post-processing agenda information."  set fonts large.
>>
>> these are without regard for emacs manual as i have not seen that
>> online recently.  great job.  thank you.
>>
>>
>> On 12/27/20, Samuel Wales  wrote:
>>> i like the black bg, the no issues with paragraph width.
>>>
>>>
>>> On 12/22/20, TEC  wrote:
>>>> Hi all,
>>>>
>>>> This is a quick patch to use the Emacs manual CSS with our generated Org
>>>> manual.
>>>>
>>>> You can see what the single-page version of this looks like here:
>>>> https://tecosaur.com/resources/org/doc/manual.html and the multi-page
>>>> here: https://tecosaur.com/resources/org/doc/manual/
>>>>
>>>> This should be an easy upgrade to our online documentation :)
>>>>
>>>> --
>>>> Timothy
>>>>
>>>>
>>>
>>>
>>> --
>>> The Kafka Pandemic
>>>
>>> Please learn what misopathy is.
>>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> Please learn what misopathy is.
>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>>




Re: [PATCH] org-plot abstractions and extension

2020-12-23 Thread TEC

Kyle Meyer  writes:

> Regardless of what you tend to use, you used "case" here in 73c99bf42;
> the minimal fix is to add a cl- prefix, and any other switch with the
> justification that "case is obsolete" is likely to raise a reviewer's
> eyebrow.

This makes sense.

> cl-case isn't in cl-lib, and there is no need to load anything.

Huh, interesting.

> recent org-plot example from 8d5122fc5:
> [...]
> That could be rewritten as [...]

Would you like me to bundle that change in somewhere?

>>>> @@ -210,9 +210,9 @@ values, namely regarding the range."
>>>>"From a the values in a TABLE of data, attempt to guess an appropriate 
>>>> number of ticks."
>>>>(let* ((row-data
>>>>  (mapcar (lambda (row) (org--plot/values-stats
>>>> -  (mapcar #'string-to-number (cdr row))
>>>> -  hard-min
>>>> -  hard-max)) table))
>>>> +   (mapcar #'string-to-number (cdr row))
>>>> +   hard-min
>>>> +   hard-max)) table))
>>>
>>> Please drop this unrelated space change.
>>
>> Erm, this isn't unrelated. As the function being called changed length,
>> the indentation of the arguments is thus also changed.
>
> This change is in org--plot/sensible-tick-num.  I don't spot any
> non-whitespace changes there.  Git appears to agree with me:
>
>   $ git show | grep '@@ -210,9'
>   @@ -210,9 +210,9 @@ (defun org--plot/sensible-tick-num (table  
> hard-min hard-max)
>   $ git show -w | grep '@@ -210,9'

Ooops, I thought you were referring to one of the other regions (I saw
the "let" and "mapcar" and my brain pattern-matched the rest :P)

One question, I saw Bastien say that we didn't want whitespace-only
commits, so how should whitespace-fixups be done?

>> Subject: [PATCH] org-plot.el: fix compiler warnings
>>
>> * (org--plot/values-stats): Replace `log10' with `log'.
>
> Please add a file name ("lisp/org-plot.el") to the start of the
> changelog entry.

Ah, forgot I needed that. Sorted :)

(final?) patch revision attached.

--
Timothy

>From c4c7b835f27b65111859d030af58a8317a82b0a0 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Thu, 24 Dec 2020 02:26:17 +0800
Subject: [PATCH] org-plot.el: fix compiler warnings

* lisp/org-plot.el (org--plot/values-stats): Replace `log10' with
`log'.
(org--plot/nice-frequency-pick): Replace obsolete `case' with `pcase`.
(org--plot/radar): Replace `s-join' with `mapconcat', removing the
implicit dependency on s.el.
(org-plot/gnuplot-script): Remove unused let bindings.
(org-plot/gnuplot-script): Replace free variable reference with
expression only using given variables.
---
 lisp/org-plot.el | 109 ++-
 1 file changed, 52 insertions(+), 57 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 4aa8276..5c6c834 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -196,7 +196,7 @@ values, namely regarding the range."
 	 (maximum (or hard-max (apply #'max nums)))
 	 (range (- maximum minimum))
 	 (rangeOrder (if (= range 0) 0
-		   (ceiling (- 1 (log10 range)
+		   (ceiling (- 1 (log range 10)
 	 (range-factor (expt 10 rangeOrder))
 	 (nice-min (if (= range 0) (car nums)
 		 (/ (float (floor (* minimum range-factor))) range-factor)))
@@ -229,34 +229,34 @@ values, namely regarding the range."
 (defun org--plot/nice-frequency-pick (frequencies)
   "From a list of frequences, try to sensibly pick a sample of the most frequent."
   ;; TODO this mosly works decently, but counld do with some tweaking to work more consistently.
-  (case (length frequencies)
-	(1 (list (car (nth 0 frequencies
-	(2 (if (<= 3 (/ (cdr (nth 0 frequencies))
-			(cdr (nth 1 frequencies
-	   (make-list 2
-			  (car (nth 0 frequencies)))
-	 (list (car (nth 0 frequencies))
-		   (car (nth 1 frequencies)
-	(t
-	 (let* ((total-count (apply #'+ (mapcar #'cdr frequencies)))
-		(n-freq (mapcar (lambda (freq) `(,(car freq) . ,(/ (float (cdr freq)) total-count))) frequencies))
-		(f-pick (list (car (car n-freq
-		(1-2-ratio (/ (cdr (nth 0 n-freq))
-			  (cdr (nth 1 n-freq
-		(2-3-ratio (/ (cdr (nth 1 n-freq))
-			  (cdr (nth 2 n-freq
-		(1-3-ratio (* 1-2-ratio 2-3-ratio))
-		(1-val (car (nth 0 n-freq)))
-		(2-val (car (nth 1 n-freq)))
-		(3-val (car (nth 2 n-freq
-	   (when (> 1-2-ratio 4) (push 1-val f-pick))
-	   (when (and (< 1-2-ratio 2-val)
-		  (< (* (apply #'* f-pick) 2-val) 30))
-	 (push 2-val f-pick))
-	   (when (and (< 1-3-ratio 3-val)
-		  (< (* (apply #'* f-pick) 3-val) 30))
-	 (push 3-val f-pick))
-	   f-pick
+  (c

Re: [PATCH] org-plot abstractions and extension

2020-12-23 Thread TEC

Kyle Meyer  writes:

> case is still available under the cl- prefix.  If you wanted to use it
> in 73c99bf42 (org-plot.el: add utility functions for range,ticks), I
> don't see a reason not to use it now.

I tend to use pcase over cl-case (since it's completely built in, i.e.
no (require 'cl-lib) required). I'm not sure if there's any argument for
cl-case over pcase, let me know if so.

> s/refence/reference/

Done

>> @@ -210,9 +210,9 @@ values, namely regarding the range."
>>"From a the values in a TABLE of data, attempt to guess an appropriate 
>> number of ticks."
>>(let* ((row-data
>>(mapcar (lambda (row) (org--plot/values-stats
>> -(mapcar #'string-to-number (cdr row))
>> -hard-min
>> -hard-max)) table))
>> + (mapcar #'string-to-number (cdr row))
>> + hard-min
>> + hard-max)) table))
>
> Please drop this unrelated space change.

Erm, this isn't unrelated. As the function being called changed length,
the indentation of the arguments is thus also changed.

> The mapcar is unnecessary; you can reposition (lambda ...) as
> mapconcat's FUNCTION argument.

Thanks for spotting that. Resolved.

Updated patch attached. Let me know how it looks to you :)

--
Timothy

>From 22717d0750e2c001003b45f1d4834571f21287ef Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 23 Dec 2020 14:13:24 +0800
Subject: [PATCH] org-plot.el: fix compiler warnings

* (org--plot/values-stats): Replace `log10' with `log'.
(org--plot/nice-frequency-pick): Replace obsolete `case' with `pcase`.
(org--plot/radar): Replace `s-join' with `mapconcat', removing the
implicit dependency on s.el.
(org-plot/gnuplot-script): Remove unused let bindings.
(org-plot/gnuplot-script): Replace free variable reference with expression
only using given variables.
---
 lisp/org-plot.el | 115 +++
 1 file changed, 55 insertions(+), 60 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 4aa8276..1c7ee43 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -196,7 +196,7 @@ values, namely regarding the range."
 	 (maximum (or hard-max (apply #'max nums)))
 	 (range (- maximum minimum))
 	 (rangeOrder (if (= range 0) 0
-		   (ceiling (- 1 (log10 range)
+		   (ceiling (- 1 (log range 10)
 	 (range-factor (expt 10 rangeOrder))
 	 (nice-min (if (= range 0) (car nums)
 		 (/ (float (floor (* minimum range-factor))) range-factor)))
@@ -210,9 +210,9 @@ values, namely regarding the range."
   "From a the values in a TABLE of data, attempt to guess an appropriate number of ticks."
   (let* ((row-data
 	  (mapcar (lambda (row) (org--plot/values-stats
-			(mapcar #'string-to-number (cdr row))
-			hard-min
-			hard-max)) table))
+ (mapcar #'string-to-number (cdr row))
+ hard-min
+ hard-max)) table))
 	 (row-normalised-ranges (mapcar (lambda (r-data)
 	  (let ((val (round (*
 			 (plist-get r-data :range-factor)
@@ -229,34 +229,34 @@ values, namely regarding the range."
 (defun org--plot/nice-frequency-pick (frequencies)
   "From a list of frequences, try to sensibly pick a sample of the most frequent."
   ;; TODO this mosly works decently, but counld do with some tweaking to work more consistently.
-  (case (length frequencies)
-	(1 (list (car (nth 0 frequencies
-	(2 (if (<= 3 (/ (cdr (nth 0 frequencies))
-			(cdr (nth 1 frequencies
-	   (make-list 2
-			  (car (nth 0 frequencies)))
-	 (list (car (nth 0 frequencies))
-		   (car (nth 1 frequencies)
-	(t
-	 (let* ((total-count (apply #'+ (mapcar #'cdr frequencies)))
-		(n-freq (mapcar (lambda (freq) `(,(car freq) . ,(/ (float (cdr freq)) total-count))) frequencies))
-		(f-pick (list (car (car n-freq
-		(1-2-ratio (/ (cdr (nth 0 n-freq))
-			  (cdr (nth 1 n-freq
-		(2-3-ratio (/ (cdr (nth 1 n-freq))
-			  (cdr (nth 2 n-freq
-		(1-3-ratio (* 1-2-ratio 2-3-ratio))
-		(1-val (car (nth 0 n-freq)))
-		(2-val (car (nth 1 n-freq)))
-		(3-val (car (nth 2 n-freq
-	   (when (> 1-2-ratio 4) (push 1-val f-pick))
-	   (when (and (< 1-2-ratio 2-val)
-		  (< (* (apply #'* f-pick) 2-val) 30))
-	 (push 2-val f-pick))
-	   (when (and (< 1-3-ratio 3-val)
-		  (< (* (apply #'* f-pick) 3-val) 30))
-	 (push 3-val f-pick))
-	   f-pick
+  (pcase (length frequencies)
+(1 (list (car (nth 0 frequencies
+(2 (if (<= 3 (/ (cdr (nth 0 frequencies))
+		(cdr (nth 1 frequencies
+	   (make-list 2
+		  (car (nth 0 frequencies)))
+	 (list (car (nth 0 frequencies))
+	   (car (nth 1 frequencies)
+(_
+ (let* ((total-count (apply #'+ (mapcar #'cdr frequencies)))
+	(n-freq (mapcar (lambda (freq) `(,(car freq) . ,(/ (fl

Re: [PATCH] org-plot abstractions and extension

2020-12-22 Thread TEC

TEC  writes:

> Kyle Meyer  writes:
>
>> This series introduced some compiler warnings.
>>
>> Timothy, could you please submit a follow-up patch to address these?
>
> Absolutely. Thanks for raising this, I'll take a look shortly.

Here we go :)

>From 309907af5e76818753b85af84b3e304d8cb4568c Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 23 Dec 2020 14:13:24 +0800
Subject: [PATCH] org-plot.el: fix compiler warnings

* (org--plot/values-stats): Replace `log10' with `log'.
(org--plot/nice-frequency-pick): Replace obsolete `case' with `pcase`.
(org--plot/radar): Replace `s-join' with `mapconcat', removing the
implicit dependency on s.el.
(org-plot/gnuplot-script): Remove unused let bindings.
(org-plot/gnuplot-script): Replace free variable refence with expression
only using given variables.
---
 lisp/org-plot.el | 117 +++
 1 file changed, 57 insertions(+), 60 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 4aa8276..80700e0 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -196,7 +196,7 @@ values, namely regarding the range."
 	 (maximum (or hard-max (apply #'max nums)))
 	 (range (- maximum minimum))
 	 (rangeOrder (if (= range 0) 0
-		   (ceiling (- 1 (log10 range)
+		   (ceiling (- 1 (log range 10)
 	 (range-factor (expt 10 rangeOrder))
 	 (nice-min (if (= range 0) (car nums)
 		 (/ (float (floor (* minimum range-factor))) range-factor)))
@@ -210,9 +210,9 @@ values, namely regarding the range."
   "From a the values in a TABLE of data, attempt to guess an appropriate number of ticks."
   (let* ((row-data
 	  (mapcar (lambda (row) (org--plot/values-stats
-			(mapcar #'string-to-number (cdr row))
-			hard-min
-			hard-max)) table))
+ (mapcar #'string-to-number (cdr row))
+ hard-min
+ hard-max)) table))
 	 (row-normalised-ranges (mapcar (lambda (r-data)
 	  (let ((val (round (*
 			 (plist-get r-data :range-factor)
@@ -229,34 +229,34 @@ values, namely regarding the range."
 (defun org--plot/nice-frequency-pick (frequencies)
   "From a list of frequences, try to sensibly pick a sample of the most frequent."
   ;; TODO this mosly works decently, but counld do with some tweaking to work more consistently.
-  (case (length frequencies)
-	(1 (list (car (nth 0 frequencies
-	(2 (if (<= 3 (/ (cdr (nth 0 frequencies))
-			(cdr (nth 1 frequencies
-	   (make-list 2
-			  (car (nth 0 frequencies)))
-	 (list (car (nth 0 frequencies))
-		   (car (nth 1 frequencies)
-	(t
-	 (let* ((total-count (apply #'+ (mapcar #'cdr frequencies)))
-		(n-freq (mapcar (lambda (freq) `(,(car freq) . ,(/ (float (cdr freq)) total-count))) frequencies))
-		(f-pick (list (car (car n-freq
-		(1-2-ratio (/ (cdr (nth 0 n-freq))
-			  (cdr (nth 1 n-freq
-		(2-3-ratio (/ (cdr (nth 1 n-freq))
-			  (cdr (nth 2 n-freq
-		(1-3-ratio (* 1-2-ratio 2-3-ratio))
-		(1-val (car (nth 0 n-freq)))
-		(2-val (car (nth 1 n-freq)))
-		(3-val (car (nth 2 n-freq
-	   (when (> 1-2-ratio 4) (push 1-val f-pick))
-	   (when (and (< 1-2-ratio 2-val)
-		  (< (* (apply #'* f-pick) 2-val) 30))
-	 (push 2-val f-pick))
-	   (when (and (< 1-3-ratio 3-val)
-		  (< (* (apply #'* f-pick) 3-val) 30))
-	 (push 3-val f-pick))
-	   f-pick
+  (pcase (length frequencies)
+(1 (list (car (nth 0 frequencies
+(2 (if (<= 3 (/ (cdr (nth 0 frequencies))
+		(cdr (nth 1 frequencies
+	   (make-list 2
+		  (car (nth 0 frequencies)))
+	 (list (car (nth 0 frequencies))
+	   (car (nth 1 frequencies)
+(_
+ (let* ((total-count (apply #'+ (mapcar #'cdr frequencies)))
+	(n-freq (mapcar (lambda (freq) `(,(car freq) . ,(/ (float (cdr freq)) total-count))) frequencies))
+	(f-pick (list (car (car n-freq
+	(1-2-ratio (/ (cdr (nth 0 n-freq))
+			  (cdr (nth 1 n-freq
+	(2-3-ratio (/ (cdr (nth 1 n-freq))
+			  (cdr (nth 2 n-freq
+	(1-3-ratio (* 1-2-ratio 2-3-ratio))
+	(1-val (car (nth 0 n-freq)))
+	(2-val (car (nth 1 n-freq)))
+	(3-val (car (nth 2 n-freq
+   (when (> 1-2-ratio 4) (push 1-val f-pick))
+   (when (and (< 1-2-ratio 2-val)
+		  (< (* (apply #'* f-pick) 2-val) 30))
+	 (push 2-val f-pick))
+   (when (and (< 1-3-ratio 3-val)
+		  (< (* (apply #'* f-pick) 3-val) 30))
+	 (push 3-val f-pick))
+   f-pick
 
 (defun org--plot/merge-alists (function default alist1 alist2  alists)
   "Using FUNCTION, combine the elements of all given ALISTS. When an element is
@@ -473,34 +473,36 @@ EOD
 
 (defun org--plot/radar (table params)
   (let* ((data
-	  (concat "\"" (s-join "\" \"" (plist-get params :labels)) "\""
+	  (concat "\"" (mapconcat #'identity (plist-get params :labels) "\" \"") "\""
 		  "\

Re: [PATCH] org-plot abstractions and extension

2020-12-22 Thread TEC


Kyle Meyer  writes:

> This series introduced some compiler warnings.
>
> Timothy, could you please submit a follow-up patch to address these?

Absolutely. Thanks for raising this, I'll take a look shortly.

--
Timothy



[PATCH] Apply emacs manual css to org pages

2020-12-22 Thread TEC
Hi all,

This is a quick patch to use the Emacs manual CSS with our generated Org
manual.

You can see what the single-page version of this looks like here:
https://tecosaur.com/resources/org/doc/manual.html and the multi-page
here: https://tecosaur.com/resources/org/doc/manual/

This should be an easy upgrade to our online documentation :)

--
Timothy

>From fc57ea88432ea119d063906cc29cc51ee591031d Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 23 Dec 2020 10:30:09 +0800
Subject: [PATCH] mk/default.mk: use same html doc style as emacs

* mk/default.mk: Add CSS stylesheet ref to HTML generated by TEXI2HTML,
specifically the stylesheet used with the online Emacs manual.
---
 mk/default.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/default.mk b/mk/default.mk
index fbfdaf5..e92d58c 100644
--- a/mk/default.mk
+++ b/mk/default.mk
@@ -139,7 +139,7 @@ MKDIR	= install -m 755 -d
 MAKEINFO = makeinfo
 
 # How to create the HTML file
-TEXI2HTML = makeinfo --html --number-sections
+TEXI2HTML = makeinfo --html --number-sections --css-ref "https://www.gnu.org/software/emacs/manual.css;
 
 # How to find files
 FIND	= find
-- 
2.29.2



Re: Release Org 9.4.2

2020-12-22 Thread TEC


I've been following this conversation, and I'm glad to see it happening.

However, we've really stayed quite far from the subject of our emails :P

I think this conversation deserves it's own thread, perhaps something
like "Org's development forge".

--
Timothy

Lennart C. Karssen  writes:

> I'm not an expert in web technologies and their licenses, but given that
> Debian, KDE and Gnome use Gitlab [1,2] this Github alternative may be an
> option to consider too. The open core of Gitlab is licensed under the
> MIT license [1] (which may or may not be acceptable for this community...).



Re: [PATCH] Enhance org-html--build-meta-info

2020-12-19 Thread TEC


Jens Lechtenboerger  writes:

>> For people who want to customise this to add metadata, the page title is
>> something they're probably interested in.
>
> What metadata would you derive from the title?

In my earlier example, I use the "og:title" property.

>> If so, I think it's work giving the title processed by
>> org-html--build-meta-info as it's not so simple as
>> (plist-get info :title).
>
> Extracting it from ~info~ might be more flexible as it would not be
> tied to the current implementation.

My thoughts are just that its seems like title/author may be handy, and
we've already worked those out, so why not just pass them along?

Could probably reduce to just info, not sure what's best though.

Other than this, is there anything else you think might be worth
considering before merging?

--
Timothy



Re: [PATCH] Enhance org-html--build-meta-info

2020-12-19 Thread TEC


Jens Lechtenboerger  writes:

>> For people who want to customise this to add metadata, the page title is
>> something they're probably interested in.
>
> What metadata would you derive from the title?

In my earlier example, I use the "og:title" property.

>> If so, I think it's work giving the title processed by
>> org-html--build-meta-info as it's not so simple as
>> (plist-get info :title).
>
> Extracting it from ~info~ might be more flexible as it would not be
> tied to the current implementation.

My thoughts are just that its seems like title/author may be handy, and
we've already worked those out, so why not just pass them along?

Could probably reduce to just info, not sure what's best though.

Other than this, is there anything else you think might be worth
considering before merging?

--
Timothy



Re: W3C violations in Org's HTML export

2020-12-17 Thread TEC


I don't think this should be forgotten about, so I'm adding it to
https://updates.orgmode.org/#help for now.



Re: [PATCH] Enhance org-html--build-meta-info

2020-12-15 Thread TEC


Jens Lechtenboerger  writes:

> I like this!

:)

>> Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
>> I'm not sure.
>
> I’m not sure either.  Maybe people expect their typed characters,
> maybe not.  This might call for a new variable.

I'm tempted to leave the current behaviour as-is, and then we can
introduce a new variable if we want later :)

> I like the new variant much better.  However, I still do not
> understand why you pass the title into org-html-meta-tags-default
> just to ignore it.  The title is already dealt with elsewhere, isn’t
> it?

For people who want to customise this to add metadata, the page title is
something they're probably interested in. If so, I think it's work
giving the title processed by org-html--build-meta-info as it's not so
simple as (plist-get info :title). Worst case, the argument just sits
there and is ignored :P

> Some comments raise complaints by checkdoc (lines too long, no
> sentence in fist line).  (Actually, the file has more problems in
> that regard.)

Ooops, I thought I took care of that. Looks like I'll be taking another
look...

Would be nice my issues weren't one of dozens throughout the file, it
makes it a bit harder to notice errors coming from /my/ section.

> Many thanks for your continued work!

Thanks for your testing and feedback!

--
Timothy



Re: Release Org 9.4.2

2020-12-15 Thread TEC


Hello. I just have a few cents I'd like to add.

Bastien  writes:

> Thanks a lot for the kind words, appreciated.

You deserve them! :)

> ... but I'm very receptive to the real questions: how can we expose
> the latest Org to more testers? how can we recruit more contributors?

I actually have a few thoughts on this.  I'm afraid that I don't think
Org/Emacs are doing a good job of being accessible to younger
individuals who have never used a ML / sent patches before (I should
know, I'm one such individual, and the lack of familiarity was a
significant deterrent). Whether a ML is a more efficient way of doing
things or not ultimately doesn't matter in this regard, because it's
simply not something I or many others are used to.

Just to be clear, I'm not advocating for getting rid of the ML and
jumping on GitHub etc. :P

I do however think we can do better in serving younger (potential)
contributors, without degrading the time-tested ML experience.

I'm doing a little investigation on this front, and hopefully will have
something to start a thread about in a few weeks :)

All the best,

Timothy.



Re: [PATCH] Enhance org-html--build-meta-info

2020-12-15 Thread TEC

Thanks for testing Jens. I think I've managed to resolve the issues
you've raised.

Jens, Bastien, you can find the latest revision of the patches attached :)

Jens Lechtenboerger  writes:

> [title export being dodgy, how about treating like author?]

Yep, ~org-element-interpret-data~ is necessary. I found that wrapping it
in ~org-html-plain-text~ seems better again though, as it encodes
entities like "---" (org) to "", and doesn't seem to introduce
any nested tags. I've also applied this to the author field as a result.

Maybe it should be applied to the rest (in ~org-html--build-meta-info~)?
I'm not sure.

> The keywords export as follows, where the name attribute is missing:
> 

Fixed.

> The current lambda functions in org-html-meta-tags all accept three
> arguments, where the first one is ignored in all cases.  The second
> one is used in exactly one case.  Why not add four calls to
> org-html--build-meta-entry (for author, description, keywords,
> generator) in org-html--build-meta-info?

I had an idea on this, I think the new form is cleaner.
Either have a list where each item generates a meta entry, or a function
that generates such a list. No more mixing of the two.

How does this look?

Timothy.

>From 9848af808752bc03404befaab7ab5ebb902aa1d0 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the  element, which would violate W3C.
---
 lisp/ox-html.el | 114 
 1 file changed, 56 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d2f24f5c6..005703f60 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,76 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry (label identity  content-format  content-formatters)
+  "Construct  tag of form , or when CONTENT-FORMAT is present:
+
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the CONTENT-FORMAT and encoding
+the result as plain text."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-plain-text
+		 (org-element-interpret-data (plist-get info :title)) info))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-html-plain-text
+   (org-element-interpret-data auth) info)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "charset=\"%s\"" info)
-	(org-html-close-tag
-	 "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
-	 info))
-  charset) "\n"
+
+ (if (org-html-html5-p info)
+	 (org-html--build-meta-entry "charset" charset)
+   (org-html--build-meta-entry "http-equiv" "Content-Type"
+   (concat "text/html;charset=" charset)))
+
  (let ((viewport-options
 	(cl-remove-

Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Hi Jean,

Please read my previous emails before re-iterating the same points.

LSP is not patented, it's just referenced in a patent about MS's fancy
remote development extension.

Jean Louis  writes:

> Enrich it with unencumbered patent-free solutions.

That's what I'm doing :)

--
Timothy.



Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Jean Louis  writes:

> Microsoft have filed patent for LSP languag server protocol:
> https://uspto.report/patent/app/20190149346

This isn't a patent for LSP (it's an open standard), this is a patent
for their Remote Development package:
https://code.visualstudio.com/docs/remote/remote-overview.

Rather different.

> Why should Emacs develop and be built on protocol that Microsoft wish
> to protect as their own, to control and use to subjugate population of
> developers?

This simply isn't what's happening here. I'm just starting work on my
own little project to give non-emacs people a taste of Org's
capabilities. I didn't think the way I spend my time was such a matter
of public concern to the Emacs community.

I guess this criticism may apply to the lsp-mode / eglot packages, but
neither of those have any relation to me.

--
Timothy.



Re: TEC: update the new website ML page?

2020-12-14 Thread TEC


Russell Adams  writes:

>> I do see your point. I think in order to warrant being presented as a
>> one-step-from-the-homepage target it would be good to tidy up the Worg
>> homepage.
>
> That's a valid criticism. Worg's main page could use an update to look
> more like the main site.
>
> Does Worg's landing page updates need to be addressed before we link
> to it in the header?

I'd like to see it get a little attention along those lines before hand,
yes :)

> Any improvements to Worg will require additional volunteer efforts and
> will take some time.

As it just so happens, I've previously volunteered ;)

All the best,

Timothy.



Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Russell Adams  writes:

> REST API calls to a remote server as a core part of editing text in
> your editor isn't concerning? How remote? How would you know? If they
> use HTTPS could you even see what is sent?

I'm not concerned about REST API calls to a remote server, because:
1. There are no REST API calls
2. There is no remote server

> Microsoft doesn't make standards that it can't corrupt or take
> advantage of. See LDAP/AD, HTML extensions, programming language
> extensions that makes their solutions incompatible with standards.

Sure, but I can choose not to support a certain standard, as can other
LSP-Client/Server FLOSS devs, and you can install a particular version
of either.


> REST = web server. Using to make JSON requests over what you are
> editing and your editor requiring the ability to send/receive to a
> potential remote web server is a valid concern.

No REST, just JSON-RPC, which is just a data format. I don't think JSON
is evil. Oh, and once again, no web servers.

> Emacs daemon is a local socket interface (by default) for
> communication between processes on the same box.

Yep, like LSP. Hence the analogy.

> [ MS Taint ]

I'm a stats student, so if you'll excuse the slightly odd perspective, I
see the chance of MS being dodgy as a bayesian process. Previous
knowledge creates an informed prior. It does not allow you to make
conclusions without examining each instance on a case-by-case basis,
only predictions. To do otherwise is to commit the genetic fallacy.

--
Timothy



Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Hi Neil,



Nope! That’s the nice thing, those are all currently features of the LSP
protocol .




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Tue, 15 Dec 2020 01:57:27 +0800
Yes, thanks, I'm seeing the picture now.  I guess that some of those things would require extensions to the LSP standard/protocol, as well as just implementation, wouldn't they?On Mon, 14 Dec 2020 at 17:31, TEC <tecos...@gmail.com> wrote:

Hi Neil,



Ah, I see what you’re getting at now. I’ll try to give you an idea of what I
think could apply.


Provide nice text manipulation actions, e.g. structural editing
Completion, with company
Org Export
Run Babel blocks
Org syntax highlighting (potentially)
Folding (maybe)
All the nice stuff like table alignment, checkbox state propagation…

Does that help?




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" <emacs-orgmode@gnu.org>
Date: Tue, 15 Dec 2020 01:22:55 +0800
I'm afraid things still aren't clear for me.  Is there a reason it's so hard to give a concrete example?If I try to analogise from how LSP works for golang, I believe the LSP server does things like- complete symbol beginning with "Xyz"- tell me where so-and-so function is defined (e.g. so that the client editor can jump to it).I'm not sure if operations like that make sense for Org.Another possibility might be interacting, from a 3rd party editor, with a body of Org content that has been primarily written and managed in Emacs.  If so, what would those interactions be?  Marking a task as done?  Something more complex than that?Or is it like: 3rd party editor opens an Org file and the user types some .  Editor asks the LSP server (Emacs) "what does  mean?", and the server replies "it means the Org entry should now look like this: ..."On Mon, 14 Dec 2020 at 15:58, TEC <tecos...@gmail.com> wrote:

Hi Neil,



Good to hear that you did take a look at the readme .



You can think of the LSP as a specification for cross-editor/IDE extensions. The
intent of this is to make some of Org’s functionality accessible to the ~95% of
people who don’t use Emacs, by hooking into Emacs itself.



Does that clear things up for you? You can also see https://langserver.org/.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" <emacs-orgmode@gnu.org>
Date: Mon, 14 Dec 2020 23:46:12 +0800
Thanks Timothy.  I did read the README, but I'm afraid I still can't quite picture a specific use.On Mon, 14 Dec 2020 at 15:28, TEC <tecos...@gmail.com> wrote:

Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" <emacs-orgmode@gnu.org>
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC <tecos...@gmail.com> wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC <tecos...@gmail.com> writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 





Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Russell Adams  writes:

> LSP is also REST based, so your editor how has to talk to a web
> *server* over a network. This could be central, and not just on your
> machine. How would you know in an update that didn't happen?

This just ... isn't right.
It's not even REST based, it's using JSON-RPC, and most servers use
stdout + stdin. I'm afraid this simply isn't accurate.


I'm going to ignore the genetic fallacy re: Microsoft.

> I'm not interested in spending any time improving an LSP for Org which
> would give non-free editors additional functionality with Org files.

Because I feel that the rest of the points have been addressed, I'll
just cover this. Looking at https://langserver.org/, the list of current
editors that have LSP clients is:

- Acme
- PROPRIETRY! C++ Builder
- PROPRIETRY! Delphi
- Eclipse
- Eclipse Che
- Emacs (x2)
- GNATStudio
- PROPRIETRY! IntelliJ
- Kakoune
- Kate
- Moonshine IDE
- Oni
- VSCode
- NeoVim (x5)
- PROPRIETRY! Sublime Text 3
- Atom
- CodeMirror
- Theia
- Spyder IDE
- Qt Creator
- Ycmd
- Brackets
- JupyterLab

Note that the majority of the above, (and if considering usage: vast
majority), are *free*.

If your issue is that there is the potential for some non-free
applications to also benefit from this ... the logical conclusion is
that we should stop using the GPL licence, because it allows *anyone*
(including non-free applications) to benefit --- thus inherently making
the work itself /less/ free .

--
Timothy.



Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Hi Neil,



Ah, I see what you’re getting at now. I’ll try to give you an idea of what I
think could apply.


Provide nice text manipulation actions, e.g. structural editing
Completion, with company
Org Export
Run Babel blocks
Org syntax highlighting (potentially)
Folding (maybe)
All the nice stuff like table alignment, checkbox state propagation…

Does that help?




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Tue, 15 Dec 2020 01:22:55 +0800
I'm afraid things still aren't clear for me.  Is there a reason it's so hard to give a concrete example?If I try to analogise from how LSP works for golang, I believe the LSP server does things like- complete symbol beginning with "Xyz"- tell me where so-and-so function is defined (e.g. so that the client editor can jump to it).I'm not sure if operations like that make sense for Org.Another possibility might be interacting, from a 3rd party editor, with a body of Org content that has been primarily written and managed in Emacs.  If so, what would those interactions be?  Marking a task as done?  Something more complex than that?Or is it like: 3rd party editor opens an Org file and the user types some .  Editor asks the LSP server (Emacs) "what does  mean?", and the server replies "it means the Org entry should now look like this: ..."On Mon, 14 Dec 2020 at 15:58, TEC <tecos...@gmail.com> wrote:

Hi Neil,



Good to hear that you did take a look at the readme .



You can think of the LSP as a specification for cross-editor/IDE extensions. The
intent of this is to make some of Org’s functionality accessible to the ~95% of
people who don’t use Emacs, by hooking into Emacs itself.



Does that clear things up for you? You can also see https://langserver.org/.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" <emacs-orgmode@gnu.org>
Date: Mon, 14 Dec 2020 23:46:12 +0800
Thanks Timothy.  I did read the README, but I'm afraid I still can't quite picture a specific use.On Mon, 14 Dec 2020 at 15:28, TEC <tecos...@gmail.com> wrote:

Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" <emacs-orgmode@gnu.org>
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC <tecos...@gmail.com> wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC <tecos...@gmail.com> writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 




Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Jean Louis  writes:

> [LSP is a evil plot from microsoft]

Hi Jean,

I can see that you're overly concerned about Microsoft being able to
somehow exert control over this. It may assuage your concerns to see an
example "technology stack" that Org-LSP could fit into.

1. Org / Emacs, all GPL-3
2. Rust LSP server + Rust cargo extensions, none of which are written by M$ 
(all GPL-compatable)
3. Kakoune LSP = Rust, using the "unlicence" licence
4. Kakoune (an experimental text editor, with /no/ relation to M$)

Microsoft has provided a /standard/ that a huge number of editors/IDEs
have adopted with /independent implementations/. At this point there is
/nothing/ M$ could do to interfere with how the above works.

You seem to be focusing on the term "server" in the name. This seems to
be a red herring in this case. In LSP the server is analogous to "emacs
--daemon" and the client to "emacsclient".

I appreciate your concerns Jean, and am aware of Microsoft's history,
however I do not believe there is any factual basis for your conclusions
in this instance.

There is no need to loose sleep over an LSP Server for Org existing :)
On the contrary, I think it has the potential to ultimately enrich the
Org community (see previous discussions).

--
Timothy.




Re: TEC: update the new website ML page?

2020-12-14 Thread TEC


Russell Adams  writes:

> One could argue that "Releases", "Updates", and "Install" should be
> merged into a common download link. They all are the same thing. ;]

Hmmm. "Updates" seems like a bit of a special thing, but perhaps some
merging could happen sensibly. If that could be worked out, I'd
definitely be much more receptive to the idea of adding another link.

> I completely agree with you that not everything can live in the
> header.

Oh good :)

> However Worg is a key component because it's community maintained
> documentation. Not just anyone can upload to the main site, but Worg
> is as "wiki" as we have. As an integral part of the community
> supported documentation I thought it should be in the header.

I do see your point. I think in order to warrant being presented as a
one-step-from-the-homepage target it would be good to tidy up the Worg
homepage.

At the moment I suspect it would be a bit overwhelming to newcomers ---
everything splurged onto on page seems a bit much :P

How does that sound?

Timothy.



Re: TEC: update the new website ML page?

2020-12-14 Thread TEC


Eric S Fraga  writes:

> Conclusion is that there is no conclusion.

Sounds about right .

Thanks for the link Eric.

--
Timothy



Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Hi Neil,



Good to hear that you did take a look at the readme .



You can think of the LSP as a specification for cross-editor/IDE extensions. The
intent of this is to make some of Org’s functionality accessible to the ~95% of
people who don’t use Emacs, by hooking into Emacs itself.



Does that clear things up for you? You can also see https://langserver.org/.




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 23:46:12 +0800
Thanks Timothy.  I did read the README, but I'm afraid I still can't quite picture a specific use.On Mon, 14 Dec 2020 at 15:28, TEC <tecos...@gmail.com> wrote:

Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" <emacs-orgmode@gnu.org>
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC <tecos...@gmail.com> wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC <tecos...@gmail.com> writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 



Re: TEC: update the new website ML page?

2020-12-14 Thread TEC


Bastien  writes:

> FWIW, I just slightly updated this page with this paragraph:
>
> If you are not a subscriber to the list, you can still send an email
> to emacs-orgmode@gnu.org, we will add you to the whitelist of people
> who can reach the list.



>> As a second request, can we get a link to Worg on the top level bar?
>
> I'd rather let Timothy decide on this, as he has the whole picture.

Thanks Bastien :)

Hi Russel, while I appreciate the significance of Worg, I currently
don't feel that adding it to the header improves the site.

There are two concerns I have on this.

1. I'm very wary of "header creep", see https://0x0.st/iFS7.png for a
   mock up of an "extreme" example.
   IMO the current state is "bulging", with 4-6 items as the ideal.
   Adding Worg would take us to 8. In addition to the increased number
   of visual elements, it also lessens the individual significance of
   the per-existing items. If a "features" item has 3 other items, it is
   much more emphasised than when it has 7 other items.

   This is just a long winded way of me expressing the view that adding
   to the header affects the perception of the rest of the header, and
   thus the overall effect may be negative, as I suspect it would be in
   this case.

2. Worg is usually linked to in very specific instances, e.g.
   "(scientific) papers [about Org]", "The FAQ", "Using Org as a
   spreadsheet".
   It is also often linked, 11 times on the index page for instance.
   This makes me suspect that there is not sufficient benefit in adding
   it to the header.

I could well be missing something obvious, but those are my current
thoughts.

--
Timothy



Re: Emacs as an Org LSP server

2020-12-14 Thread TEC


Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC <tecos...@gmail.com> wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC <tecos...@gmail.com> writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 


Re: [PATCH] Enhance org-html--build-meta-info

2020-12-13 Thread TEC


Bastien  writes:

> Can we approach this with two patches, one with the refactoring and
> one with the added functionality?

Sure :) I'll take care of this when I get home in a few hours.

> This sounds useful.

Glad to hear!

> I think "Org Export" as the default is counter-intuitive, let's stick
> to the empty string.  (Also, this kind of "small" changes should be
> made with consideration of all exporters.)

In case of confusion, this isn't replacing the #+title in the document,
just the ... which is used as the tab content.
I just find blank tabs to be quite unhelpful, particularly when nestled
among others.

I'm not really aware of anything analogous in other exporters. Maybe the
metadata in exported PDFs ... but that doesn't exactly show up in
browser tabs :P

> Nope, the first line of a docstring should be a sentence.  You'll have
> to reformulate the beginning of the docstring...

I'll take care of this with the patch separation.

Thanks for the feedback!

Timothy.



Re: [PATCH] Enhance org-html--build-meta-info

2020-12-13 Thread TEC


Bastien  writes:

> Let's wait for Jens feedback on this patch, since he took care of
> testing it so far.

Assuming Jens responds as he usually has (relatively promptly), this
sounds good to me :)

> In a nutshell, can you restate what problem is this patch fixing?

There are two things I intend to achieve with this patch:
1. DRY* out the existing code. The existing code is quite repetitive in
   structure, and easily lends itself to being extracted to a function.
   This is easier to read, and work with IMO.
2. Make use of the DRYer code in (1) to provide a make the meta building
function more versatile, and then add in the ability for user
customisation at low-cost (again, thanks to (1)).

*DRY is an acronym for "Don't Repeat Yourself", in case there's a french
 equivalent you're more familiar with.

> Is a new option really necessary here?

Necessary? Not really, I mean the export /works/ without it. I'd argue
that it's desirable though, as it provides an easy way for a user (such
as myself) to add useful meta tags not included by default. For example
I currently make use of this to add information that parsed by a large
number of services/apps to create rich embeds for exported Org files I
link to (see
https://tecosaur.github.io/emacs-config/config.html#extra-header-content,code--2
).

Furthermore, I consider it to be very low cost, since it's basically
just taking advantage of the restructuring already performed for code
QOL reasons.

I expect most users not to have any reason to touch this, but for some
to find it handy.

> Are there backward compatibility considerations we should take care of?

None AFAIK. Barring this errors that Jens raised, and now have hopefully
been addressed, this should function /exactly/ as the current
implementation does, with a minor (beneficial) caveat, mentioned below.
Just with nicer-to-work-with code and a bit more versatility (IMO, of
course).

These are the two changes to be mentioned:
1. The (or {title} "Org Export") bit I added.
   I believe the current behaviour when no #+title is given is to have a
   blank one (""). I think "Org Export" is preferable, as it's more
   informative than ... nothing.
2. Using org-html-encode-plain-text for formatting the content of the
   meta tags. From Jens, I take it that the current org-export-data can
   cause nested HTML tags, which are invalid in this context. Plain text
   should be safer.

>> +(defun org-html--build-meta-entry (label identity  content-format 
>>  content-formatters)
>> +  "Construct  tag with LABEL=\"IDENTITY\" and content from 
>> CONTENT-FORMAT and CONTENT-FORMATTER."
>
> The first line of this defun is too long.  You can try M-x checkdoc
> RET on your elisp files to catch those issues.
>
> Thanks,

I see, I'm guessing I'll just need to add a line break.

I hope that clarifies things!

Timothy



Re: [PATCH] org-plot abstractions and extension

2020-12-13 Thread TEC


Bastien  writes:

> Applied, with minor modifications of the changelog entries:
>
> - You need to add an entry when creating a new custom variable.
>
> - I suggest saying "option" instead of "custom variable".
>
> - Sentences should be separated by two spaces and start with an
>   uppercase letter.
>
> Also, the convention in Emacs is to avoid whitespaces-only commits,
> you need to fix whitespaces within other non-whitespaces changes in
> a commit.

Thanks for the feedback on the patches! I tried to get it right after my
previous (and first) attempt, but it looks like there are a few things I
still need to take note of. Big improvement though, nonetheless,
hopefully next time they'll be nothing to change :)

All the best,

Timothy



Re: Org Capture Menu cannot be fully viewed

2020-12-13 Thread TEC


Hi Jean, a few thoughts.

Jean Louis  writes:

> In other words program like Org capture is not meant for people having
> too many templates and that shall be explained right away both in
> function definitions and in the manual. Important people lose their
> time and effort in customizing org capture which was not meant to be
> used by people with too many templates.

Categorising your capture templates can help a lot with this I think.
See [1].

> Can interface be improved that people with larger number of templates
> become free to use it?

IMO just styling it nicer can make it easier to use. For instance, I
find symbols and colour help with at-a-glance use. Also see [1].

> My proposal is to quit using blocking interface where user cannot move
> from buffer to buffer, instead to open up new buffer with new key mode
> map that assigns those keys to those capture template functions. That
> way the buffer becomes unlimited, user can open it, it is familiar
> org-mode buffer and it can be unlimited.

This sounds like a good idea IMO .

> Why not provide completing-read for Org capture templates? That would
> solve the problem fully.

Eh, personally I'm not convinced this is the way to go. I find
category use is sufficiant to keep a number of templates well-organised
and accesible.

All the best,

Timothy.


[1]: https://www.reddit.com/r/emacs/comments/fzuv4f/my_prettified_orgcapture/



Re: Emacs as an Org LSP server

2020-12-13 Thread TEC


Jean Louis  writes:

> * TEC  [2020-12-13 13:44]:
>> 
>> A little progress update.
>> 
>> https://github.com/tecosaur/org-lsp now exists.
>
> As Org-mode does not have collaboration neither was initially designed
> for other editor, such idea is welcome.
>
> From a perspective that some server has to know what user is writing
> it is advisable to use one own's servers. But if idea gets popular
> some company will commercialize it and centralize user's data and
> privacy is gone.

FYI the nature of LSP (as I understand it) is that the "server" is a
locally running service that responds to signals from a "client" (code
editor / IDE).

Hope that clears things up,

Timothy



Re: [PATCH] Enhance org-html--build-meta-info

2020-12-13 Thread TEC

Jens Lechtenboerger  writes:

> Without the second argument I get an error “Wrong type argument:
> stringp,” when evaluating regular expressions against the cons cell
> that is returned as title.
>
> As I see now, author and title are cons cells, which is why
> org-element-interpret-data is necessary to produce strings with Org
> syntax.
>
> Also, after fixing the title, I get “wrong-type-argument sequencep
> utf-8” for “(concat "text/html;charset=" charset)”.

Thanks for testing this :) I haven't forgotten about this.

Next version!

>From 1289e381aff7562df96945aa58838ad966aa9211 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Thu, 17 Sep 2020 21:27:18 +0800
Subject: [PATCH] lisp/ox-html.el: make html meta func nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The opportunity was taken to extract most metadata info to custom
variable `org-html-meta-tags', allowing for easy end-user modification.
---
 lisp/ox-html.el | 131 +++-
 1 file changed, 73 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d2f24f5c6..93014e9c7 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1425,6 +1425,31 @@ not be modified."
 
  Template :: Styles
 
+(defcustom org-html-meta-tags
+  '((lambda (_title author _info)
+  (when (org-string-nw-p author)
+	(list "name" "author" author)))
+(lambda (_title _author info)
+  (when (org-string-nw-p (plist-get info :description))
+	(list "name" "description"
+	  (plist-get info :description
+(lambda (_title _author info)
+  (when (org-string-nw-p (plist-get info :keywords))
+	(list "keywords" (plist-get info :keywords
+("name" "generator" "Org Mode"))
+  "A list of arguments to be passed to `org-html--build-meta-entry'.
+Each argument can either be an list which is applied, or a function which
+generates such a list with signature (TITLE AUTHOR INFO) where TITLE and AUTHOR
+are strings, and INFO a communication plist."
+  :group 'org-export-html
+  :package-version '(Org . "9.5")
+  :type '(repeat
+	  (choice
+	   (list (string :tag "Meta label")
+		 (string :tag "label value")
+		 (string :tag "Content value"))
+	   function)))
+
 (defcustom org-html-head-include-default-style t
   "Non-nil means include the default style in exported HTML files.
 The actual style is defined in `org-html-style-default' and
@@ -1835,78 +1860,68 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry (label identity  content-format  content-formatters)
+  "Construct  tag with LABEL=\"IDENTITY\" and content from CONTENT-FORMAT and CONTENT-FORMATTER."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-encode-plain-text (or (car (plist-get info :title)) "Org Export")))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-element-interpret-data auth)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "char

Re: org-plot line colors

2020-12-13 Thread TEC


Hi Ian,

Sorry for the slow response, I'm marked your email though, so I'm now
getting back to you :)

ian martins  writes:

> I wanted to change line colors but didn't find a way. Is there a way?

Indeed! Though I do it with lisp, and using my patches.

I think I saw a patch about multiline #+plot / set but I forget (ment
to send an email about that actually...).

In case it helps, here's the sort of thing I have:

#+begin_src emacs-lisp
(defun org-plot/generate-theme (_type)
  "Use the current Doom theme colours to generate a GnuPlot preamble."
  (format "[...]
set linetype 1 lw 2 lc rgb '%s' # red
set linetype 2 lw 2 lc rgb '%s' # blue
[...]")
  (doom-color 'red)
  (doom-color 'blue))
(setq org-plot/gnuplot-script-preamble #'org-plot/generate-theme)
#+end_src

org-plot/gnuplot-script-preamble can be either a function, or a plain
string.

Regarding the "with lines" bit, I'm not exactly sure what's required to
be changed without looking over my patches again  but I know I added
the capability to adapt the existing plot types quite easily.

If a particular modification seems like a good idea, do feel free to
share .

Hope that helps a bit,

Timothy.



Re: Sv: New startup options, showlevels

2020-12-13 Thread TEC


Just a quick note on the values proposed.

All of the Alt Ns have overview + N-in-the-name options for N >= 2.
e.g. show2levels, show3levels...

For the sake of completeness/consistency I would suggest having a N=1
variant with that format too. This would duplicate the behaviour of
"overview", but if say I currently have "levels:2" and I want to bump it
down to 1, then I'd naturally go to "levels:1" and expect it to work.

--
Timothy.

Gustav Wikström  writes:

> Already in master (Alt 0): 
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `show2levels' Headline levels 1-2.   
>  `show3levels' Headline levels 1-3.   
>  `show4levels' Headline levels 1-4.   
>  `show5levels' Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents. 
>
> Alt 1:
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `show:2'  Headline levels 1-2.   
>  `show:3'  Headline levels 1-3.   
>  `show:4'  Headline levels 1-4.   
>  `show:5'  Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents. 
>
> Alt 2:
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `levels:2'Headline levels 1-2.   
>  `levels:3'Headline levels 1-3.   
>  `levels:4'Headline levels 1-4.   
>  `levels:5'Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents. 
>
> Alt 3:
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `content:2'   Headline levels 1-2.   
>  `content:3'   Headline levels 1-3.   
>  `content:4'   Headline levels 1-4.   
>  `content:5'   Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents.
>
> To me no option is perfect. There are incongruencies for all. Maybe a fourth 
> option?
>
> Alt 4:
> `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `2levels' Headline levels 1-2.   
>  `3levels' Headline levels 1-3.   
>  `4levels' Headline levels 1-4.   
>  `5levels' Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents.
>
> Since show in showall and showeverything seems to symbolize the unfolding of 
> things.
>
> That would be an improvement based on all three principles above, in that it 
> removes the ambiguity of "show" (and how it relates to unfolding), makes the 
> names shorter, and stays in line with the naming convention (i.e. no ':'). 
> Not sure what the syntax says about names starting with numerals though.
>
> Your call. Personally I'd prefer Alt 4 or the existing one.
>
> /Gustav
>
>> -Ursprungligt meddelande-
>> Från: Eric S Fraga 
>> Skickat: den 13 december 2020 10:49
>> Till: Bastien 
>> Kopia: Gustav Wikström ; emacs-orgmode@gnu.org
>> Ämne: Re: New startup options, showlevels
>> 
>> On Saturday, 12 Dec 2020 at 18:54, Bastien wrote:
>> > In this case, I think we could come up with better option names than
>> > "show2levels", even if I don't have a better suggestion right now.
>> 
>> I agree.  I had started responding to Gustav when the original post
>> appeared but then aborted my response.  I wonder whether something like
>> levels:N or show:N or content:N is possible in a startup setting, akin
>> to H:N in options?
>> 
>> I do have (org-content N) often in my file local variables in any case.
>> --
>> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce




Re: Emacs as an Org LSP server

2020-12-13 Thread TEC


A little progress update.

https://github.com/tecosaur/org-lsp now exists.

I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.

TEC  writes:

> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>want to pick it? LSP library? Lisp? Are there any outstanding
>contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 




Re: New startup options, showlevels

2020-12-13 Thread TEC


Eric S Fraga  writes:

> I wonder whether something like levels:N or show:N or content:N is
> possible in a startup setting, akin to H:N in options?

If I may toss my opinion into the ring, "show:N" seems like the most
intuitive syntax to me :)

--
Timothy



Re: New startup options, showlevels

2020-12-13 Thread TEC


Eric S Fraga  writes:

> I wonder whether something like levels:N or show:N or content:N is
> possible in a startup setting, akin to H:N in options?

If I may toss my opinion into the ring, "show:N" seems like the most
intuitive syntax to me :)

--
Timothy



Re: stability of toc links

2020-12-10 Thread TEC


> There are a few touch ups I'll do to my code shortly

I'm pleased to say that I've improved the readability and documentation
of my code (hopefully) in
https://github.com/tecosaur/emacs-config/commit/dc873d3

I hope this may be of some help,

Timothy



Re: stability of toc links

2020-12-10 Thread TEC


Carsten Dominik  writes:

> Yes, I mean this code, or something like this, to aid the automatic
> creation of links that are somewhat stable.  I have been missing this very
> much.

Hi Carsten, glad to hear that there /does/ seem to be interest in this after 
all :)

A few things worth saying I think:
- I'm quite happy with the idea of my code being used verbatim, with any
  modifications others think are a good idea (of course)
- I am have FSF assignment, and the repo is MIT licensed already. In
case it needs saying, I'm quite happy to waive any annoying licence
terms (inclusion of copyright notice is the only thing that comes to
mind) for any code that may be used in Org.
- There are a few touch ups I'll do to my code shortly

All the best,

Timothy.



Re: new website: not easy to find how to ask for help

2020-12-08 Thread TEC


Tom Gillespie  writes:

> Hi Eric,
>Good point, we are indeed missing a line that says "You can mail
> the list directly at mailto:emacs-orgmode@gnu.org.; Here's a patch. I
> assume it is probably ok to put the raw email on the site. Best,
> Tom

Seems sensible :) Thanks for raising this Eric & Tom.

I've taken note of your comments in
https://code.orgmode.org/bzg/orgweb/commit/a493257b

--
Timothy



Re: [PATCH] org-plot abstractions and extension

2020-12-08 Thread TEC


It's now been 1.5 months, so I'm going to bump this thread.

--
Timothy

TEC  writes:

> Bastien  writes:
>
>> I'm not an org-plot.el user so I cannot test, but by reading the
>> patches, they look okay.
>>
>> Let's go in "optimistic merging" mode and commit your patches?
>
> Sounds good then. I don't expect the changes to compromise any 
> existing
> functionality.
>
>> Is https://orgmode.org/list/87lfhbhfhe@gmail.com/ the latest
>> version I should use?
>
> I've smoothed a rough edge or two, and added a documentation 
> entry.
>
> I'll attach all the patches to this email, so there's no 
> ambiguity.
> (crosses fingers for attachments working as expected)




Re: stability of toc links

2020-12-08 Thread TEC


Hi Sam, link stability is a concern I've had too. I currently have a fix
(or at the very least, an improvement) for this in my config where I
overwrite org-export-get-reference. (see:
https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading).

I raised this on the list a while ago ---
https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ but there
didn't seem to be much interest.

All the best,
Timothy

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?
>
> there doesn't seem to be a perfect solution, short of adding custom id
> or id to everything, but perhaps a fuzzy hash of the header and
> contents of the section could be used?  or a strict hash of the
> header?  is anything like this being done?  just curious.




Re: [PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation

2020-11-18 Thread TEC



I have 2c on the use of "interpolated".

1. I tend to think of "interpolated" in terms of it's mathematical
  meaning
2. The other denotations relate to insertion and renewing, which 
simply

  doesn't fit.

I appreciate that other people may have used this too, but as I 
see it
that just means that other people have engaged in strange word 
choices.


Suggested alternatives: Substituted, transpiled, or translated.

Timothy.

-

For context, here's the definition, etymology, and symonyms.

Definition
 Intransitive Verb
   1. To renew; to carry on with intermission. [Obs.] 
   2. To alter or corrupt by the insertion of new or foreign 
 matter; especially, to change, as a book or text, by the
 insertion of matter that is new, or foreign to the purpose
 of the author.
   3. (Mathematics) To fill up intermediate terms of, as of a 
series, 

 according to the law of the series; to introduce, as a
 number or quantity, in a partial series, according to the
 law of that part of the series.
 Adjective
   1. Inserted in, or added to, the original; introduced; 
 foisted in; changed by the insertion of new or spurious
 matter.

   2. (Math.) 
​  (a) Provided with necessary interpolations; as, an 
 interpolated table.
​  (b) Introduced or determined by interpolation; as, 
 interpolated quantities or numbers.

​​Etymology
 
​​​interpolate verb 

1610s, "to alter or enlarge (a writing) by inserting new 
material," from Latin 
interpolatus, past participle of interpolare "alter, freshen up, 
polish;" of 
writing, "falsify," from inter "among, between" (see inter-) + 
polare, which is 
related to polire "to smoothe, polish," from PIE root *pel- ( 5) 
"to thrust, 
strike, drive," the connecting notion being "to full cloth" 
[Watkins].


Sense evolved in Latin from "refurbish," to "alter appearance of," 
to "falsify 
(especially by adding new material)." Middle English had 
interpolen (early 15c.) 
in a similar sense. Related: Interpolated; interpolating.


​​Synonyms
 
​​​verb adjective 
1. Insert (wrongfully),  foist in.
2. (Math .) Introduce, intercalate (terms to complete a series).


Tim Cross  writes:


Daniele Nicolodi  writes:


On 16/11/2020 11:25, Eric S Fraga wrote:

Daniele,

this looks good.  One minor pedantic point: I think you mean
"interpreted" when you say "interpolated" (several times in 
the
text).  Otherwise, this is a very useful addition to the 
manual.


Thank you for reading and for the comment.

"interpolated" looks strange to me in this context too, but it 
is the
word that is currently used in the manual. I decided to stick 
to this
term for consistency, however, I haven't check if it is used 
with the

same meaning elsewhere.

I don't think it is wrong to use "interpolated", but if you 
thing it
should be changed I can change it and check the manual for 
consistency.
However, I don't think "interpreted" is the right word either. 
Probably

"replaced" or "substituted" are better choices in this context.



I agree. Interpolated is consistent with manuals for other 
programming
languages which have similar functionality. However, org is also 
used by
a more diverse community than typical programming languages, so 
perhaps

'replaced' or 'substituted' would be a better choice?





Re: export +A+ to latex, xout and not sout

2020-11-08 Thread TEC



Hi Uwe,

Uwe Brauer  writes:


I'd rather prefer to have \xout{A} instead of \sout{A}
How can I achieve that?


How about this:
(setcdr (assoc 'strike-through org-latex-text-markup-alist)
   "\\xout{%s}")

Hope that helps,

Timothy.



Re: Tables: missing multi-col/row syntax

2020-11-04 Thread TEC



I think we may be able get something promising by merging your
(Christian + Tom) ideas and David's. What if we have have a
#+TBLCELLMERGE key which acts as you describe, and /just using the
current table syntax/ have something like this (using the example 
from

my first email)

| a | b  | c |
|---++---|
| hi|| a |
| two x || . |
| three || b |
|  c | - | . |
#+TBLCELLMERGE: @2$1..@4$2

This is /currently/ a valid Org table, which /currently/ 
autoformats to:

| a | b | c |
|---+---+---|
| hi|   | a |
| two x |   | . |
| three |   | b |
| c | - | . |

So with an autoformatting change + an overlay, perhaps we can do 
this

nicely without any syntax changes .

Thoughts?

Christian Moe  writes:

+1 for enabling table-cell merges in export. I imagine this 
would be a
tricky job for developers, but it would relieve me as a user of 
much

repeated fiddling with exported drafts.

+1 for doing it without adding clutter to the table syntax, but
specifying merges on a separate line like formulas, like Tom's

  #+TBLCELLMERGE: @2..3$1

(amended here to use the established '..' rather than hyphen for 
range)


Though if we do add such a line, we might also think of a more 
general
solution that could over time be extended with additional 
formatting

options, e.g. something like

  #+TBLSTYLE: @2..3$1='(:merge t)::@4$1='(:bgcolor yellow :color 
  red)


But obviously that could open a can of worms, aka potentially 
endless
feature requests requiring different implementations for each 
backend.


Yours,
Christian



Tom Gillespie writes:

Any support for something like this would need to retain 
backward
compatibility as well to avoid older versions reformatting the 
tables
due to e.g. the presence of a double pipe. I also think that 
extending
the table syntax in ways that makes it more complex than it 
already
is, will be a non-starter. Thus, an alternate but more likely 
approach
would be to allow specification of what cells to merge outside 
the
table as is done for formulas. It is not elegant, but it would 
be a
layer on top of existing syntax, and it would allow the 
fundamental

structure of the table to remain the same -- rows of cells. For
example #+TBLCELLMERGE: @2-3$1 or something like that. 
Thoughts?

Tom

On Mon, Nov 2, 2020 at 1:37 PM TEC  wrote:


Hi all,

This is a pretty major 'feature request', but I think also an
important
one.

When developing large tables, it can often be /necessary/ to 
start

using
multi-column/row cells for clarity, and sensible exporting
results.

As far as I am aware, in Org does not currently have any
multi-col/row
syntax. The only viable method seems to be re-implementing the
table
using export blocks in every backend you may want to export to 
(in

my
case, usually TeX + HTML). This is clumsy, difficult to work 
with,

and
could be avoided should org gain support for multi-col/row 
syntax.


I appreciate that this would constitute a major change both 
the

Org's
syntax and the codebase, but I believe such a change is 
warranted

by the
advantages it would provide.

Both how this can be implemented while minimising/eliminating 
the

chance
of breaking well-formed current table elements, and what 
syntax

may be
both acceptable and seem sensible to use.

I would anticipate such a feature working by designating two
characters
to indicate "add row" and "add column". For example "|" and 
"-".

These
characters would take affect when /immediately following/ (no
space) a
cell separator ("|"), and designate the dimensions of the top
right cell.

Example:
| a | b | c |
|---+---+---|
| a | - | | |
| - | b | . |
| . | | | c |

Would be interpreted just as any current table is.

However,

| hello | there | you  |
|---+---+--|
|| two column   | cell |

Contains a 2x1 cell.

| a little | test |
|--+--|
|- hello   | hi   |
| two row  | you  |

Contains a 1x2 cell. In a more complex example:

| a | b | c |
|---+---+---|
||-- hi | a |
| two x | . |
| three | b |
| c | - | . |

Contains a 2x3 cell.

This is just the first syntax that comes to mind, but 
hopefully

the
general form of this idea seems viable.

All the best,

Timothy.






Re: Thoughts on the standardization of Org

2020-11-03 Thread TEC



Eric S Fraga  writes:


On Tuesday,  3 Nov 2020 at 05:31, Ken Mankoff wrote:
But I'm weary of seeing all my colleagues say "Jupyter" and not 
"Org"


+1 (not to mention the case of MSWord instead of Jupyter)

濫

So, yes, if TEC or others can get us there, I'm all for it but 
they'll

have to prise emacs out of hands when I expire...


Hehe. I'll have a look and see how hard it seems. I'm hoping at 
least
someone else finds it interesting enough to reply to my call for 
help

and give me some company .

No need to pry Emacs out of anything ... after all, his idea is 
all

about sneakily inserting it into people's workflow .

--
Timothy



Re: Tables: missing multi-col/row syntax

2020-11-03 Thread TEC



David Rogers  writes:

IMO this can (and definitely should) be regarded as a purely 
cosmetic problem,
to be resolved by purely cosmetic methods. I think the idea that 
each table cell
is exactly one unit of information (and can’t be a collection or 
array of units

of information) is more important than this issue.

In other words, I think it’s better to ridiculously overload 
fontification and
output formatting, than to sacrifice the main logic of how 
tables currently

work. I just don’t believe that it could be worth it.


The appearance of the tables is purely cosmetic ... however when 
one
ends up maintaining three copies of the same table, I don't think 
that
dismissing it offhand as a "cosmetic problem" is a productive 
approach.


--
Timothy



Re: Tables: missing multi-col/row syntax

2020-11-02 Thread TEC



Tom Gillespie  writes:

Any support for something like this would need to retain 
backward
compatibility as well to avoid older versions reformatting the 
tables
due to e.g. the presence of a double pipe. I also think that 
extending
the table syntax in ways that makes it more complex than it 
already

is, will be a non-starter.


I am also concerned with avoiding disrupting previous table. I 
think
that non-space double+ pipes should be alright (hence their part 
in my
suggestion) as it still maintains that the number of columns is 
equal to

the number of pipes. E.g. currently
|| a| b | = 3 columns, and is reformatted to |  | a | b |
proposal
|| a| b | = 2 cells, 2+1=3 columns (same)


Thus, an alternate but more likely approach
would be to allow specification of what cells to merge outside 
the
table as is done for formulas. It is not elegant, but it would 
be a
layer on top of existing syntax, and it would allow the 
fundamental

structure of the table to remain the same -- rows of cells. For
example #+TBLCELLMERGE: @2-3$1 or something like that. Thoughts?
Tom


I like how this seems to address the issue while keeping backwards
compatibility, but I have two big concerns:
1. I think this could make it hard to see which cells are 
'masked' by a

merge at a glance, and would make associated errors easy
2. I think that for say a table with 2-3 large sub-sections this 
could

lead to problematic formating.

Regarding 2, E.g. (content and form made up on the spot)

| Powerpoint | Voltage ripple while drawing 2A continuous load 
 over Xs || | | | Current ripple while drawing 
 24V continuous load over Xs ||| || |
|| 
1s | 5s | 10s | 20s | 30s | 
1s | 2s | 5s | 10s | 20 | 30s |

|+-++-+-+-+--+++-++-|
| Kitchen| 
 3% | 2% |  3% |  1% |  2% | 
 1% | 4% | 3% |  5% | 3% |  2% |
| Bedroom| 
 1% | 2% |  1% |  2% |  1% | 
 2% | 1% | 1% |  1% | 2% |  1% |

#+TBLCELLMERGE: @2-6$1,@7-11$1

vs.

| Powerpoint | Voltage ripple while drawing 2A continuous load 
 over Xs || Current ripple while drawing 24V continuous load 
 over Xs |
|| 1s | 5s | 10s | 20s | 30s 
  | 1s | 2s | 5s | 10s | 20 | 30s 
  |

|+++-+-+---++++-++-|
| Kitchen| 3% | 2% |  3% |  1% |  2% 
 | 1% | 4% | 3% |  5% | 3% |  2% 
 |
| Bedroom| 1% | 2% |  1% |  2% |  1% 
 | 2% | 1% | 1% |  1% | 2% |  1% 
 |


(NB: clearer without line wrapping, more concise examples 
definitely

available if I thought about it a tad more)


On Mon, Nov 2, 2020 at 1:37 PM TEC  wrote:


Hi all,

This is a pretty major 'feature request', but I think also an
important
one.

When developing large tables, it can often be /necessary/ to 
start

using
multi-column/row cells for clarity, and sensible exporting
results.

As far as I am aware, in Org does not currently have any
multi-col/row
syntax. The only viable method seems to be re-implementing the
table
using export blocks in every backend you may want to export to 
(in

my
case, usually TeX + HTML). This is clumsy, difficult to work 
with,

and
could be avoided should org gain support for multi-col/row 
syntax.


I appreciate that this would constitute a major change both the
Org's
syntax and the codebase, but I believe such a change is 
warranted

by the
advantages it would provide.

Both how this can be implemented while minimising/eliminating 
the

chance
of breaking well-formed current table elements, and what syntax
may be
both acceptable and seem sensible to use.

I would anticipate such a feature working by designating two
characters
to indicate "add row" and "add column". For example "|" and 
"-".

These
characters would take affect when /immediately following/ (no
space) a
cell separator ("|"), and designate the dimensions of the top
right cell.

Example:
| a | b | c |
|---+---+---|
| a | - | | |
| - | b | . |
| . | | | c |

Would be interpreted just as any current table is.

However,

| hello | there | you  |
|---+---+--|
|| two column   | cell |

Contains a 2x1 cell.

| a little | test |
|--+--|
|- hello   | hi   |
| two row  | you  |

Contains a 1x2 cell. In a more complex example:

| a | b | c |
|---+---+---|
||-- hi | a |
| two x | . |
| three | b |
| c | - | . |

Contains a 2x3 cell.

This is just the first syntax that comes to mind, but hopefully
the
general form of this idea seems viable.

All the best,

Timothy.






Tables: missing multi-col/row syntax

2020-11-02 Thread TEC

Hi all,

This is a pretty major 'feature request', but I think also an 
important

one.

When developing large tables, it can often be /necessary/ to start 
using
multi-column/row cells for clarity, and sensible exporting 
results.


As far as I am aware, in Org does not currently have any 
multi-col/row
syntax. The only viable method seems to be re-implementing the 
table
using export blocks in every backend you may want to export to (in 
my
case, usually TeX + HTML). This is clumsy, difficult to work with, 
and

could be avoided should org gain support for multi-col/row syntax.

I appreciate that this would constitute a major change both the 
Org's
syntax and the codebase, but I believe such a change is warranted 
by the

advantages it would provide.

Both how this can be implemented while minimising/eliminating the 
chance
of breaking well-formed current table elements, and what syntax 
may be

both acceptable and seem sensible to use.

I would anticipate such a feature working by designating two 
characters
to indicate "add row" and "add column". For example "|" and "-". 
These
characters would take affect when /immediately following/ (no 
space) a
cell separator ("|"), and designate the dimensions of the top 
right cell.


Example:
| a | b | c |
|---+---+---|
| a | - | | |
| - | b | . |
| . | | | c |

Would be interpreted just as any current table is.

However,

| hello | there | you  |
|---+---+--|
|| two column   | cell |

Contains a 2x1 cell.

| a little | test |
|--+--|
|- hello   | hi   |
| two row  | you  |

Contains a 1x2 cell. In a more complex example:

| a | b | c |
|---+---+---|
||-- hi | a |
| two x | . |
| three | b |
| c | - | . |

Contains a 2x3 cell.

This is just the first syntax that comes to mind, but hopefully 
the

general form of this idea seems viable.

All the best,

Timothy.



Emacs as an Org LSP server

2020-11-02 Thread TEC

Hi Everyone,

From the Org standardisation effort the idea of using Emacs as the 

basis
of an LSP server for Org has been mentioned a few times.

I thought this deserved it's own thread so here it is :)

I'm quite keen to investigate the viability of this idea.
Some key questions that I think need addressing are:
1. How can we 'package' Emacs into an LSP client?
2. Assuming we use some language as the basis for the host how do 
we

   want to pick it? LSP library? Lisp? Are there any outstanding
   contenders.
3. How much effort is involved? Is it worth it to try to make Org 
more

   approachable* (without Emacs)?

Lastly, but perhaps even more crucially --- who would be 
interested in
working on this? I certainly am, but this feels like something 
that

would be more viable with a small working group.

Who's interested?

Timothy.


* I can't help but think that this hypothetical LSP server may 
 serve as

 a 'gateway drug' to Org in Emacs 



Re: Thoughts on the standardization of Org

2020-11-02 Thread TEC



Russell Adams  writes:


On Mon, Nov 02, 2020 at 02:56:58PM +, Eric S Fraga wrote:
(as an aside, Emacs as an LSP could be interesting, especially 
if

network based)


LSP is a standard from Microsoft:
https://github.com/Microsoft/language-server-protocol/

It allows networked JSON and telemetry, as well as all the other
problems that come from trusting the remote server:
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#telemetry_event

Either of these items would provide justification for me to 
exclude
LSP from any personal consideration, and for me to strongly 
recommend

against it's use in any capacity.

Microsoft and related technologies have no place in my Emacs. I 
don't

care to see Org made easy or functional in Visual Studio.

Why contribute to layers which allow an illegal monopoly more
market share? Why code for them for free?


Because it's supported by: Atom, Brackets, Delphi, Eclipse, Emacs, 
Kakoune, Kate,

VSCode, NeoVim, Sublime Text 3, JupyterLab, and more .

--
Timothy



Re: Thoughts on the standardization of Org

2020-11-02 Thread TEC



Daniele Nicolodi  writes:


On 02/11/2020 10:02, TEC wrote:

I think there are absolutely some benefits for Org users. I am
personally interested in registering Org as an IANA MIME type.


I don't think that registering Org as IANA MIME type will have 
the

consequences you hope it has.


Hmmm. I'm glad you've brought this up. I wouldn't want to put in 
hours

of effort for a unlikely benefit.
My hope is that registering org as an IANA MIME type will cause it 
to

trickle down into individual MIME registries.

The benefit I see here is Org being able to be treated more as a 
'first
class' plaintext format --- like I see markdown being treated 
today.
Open a ".md" file in Ocular and you see a nice rendered version (I 
use

this as a general, not specific example).

Then, if we can package Emacs into an LSP client, we can provide a 
very
well-featured Org experience to dozens of editors, and the 
"text/*"
association will be important to ensure that Org files are opened 
in

those text editors.

For people who use editors like VSCode, being able to send an Org 
file

and have it open in VSCode will likely prompt them to install an
extension that provides support for .org files...

This may be a bit unrealistic, and I'm hugely appreciative of any 
effort

to inform me of any aspects that I may be overlooking.


Finally, even if you get your attachment automatically tagged as
"text/org", the receiving side needs to have a mime type handler
configured to display it. As far as I know, not even Emacs (on 
the
platforms that allow it) registers itself as an handler for any 
MIME
type. Therefore, what you get, assuming that the mail client on 
the

other side behaves correctly and uses "text/*" as a fallback for
"text/org" is that your attachment will be displayed in a 
generic text

editor.


1. Could Emacs change to register itself as a text/org handler?
2. See above for why I don't think that opening it in a generic 
text

editor would necessarily be a bad idea.

I send Org files as "text/plain" (often even using ".txt" 
extension to
avoid confusion on the receiving side) and I think this is the 
best
choice as it puts the least burden on the receiving side to 
consume the

content and it is displayed inline by most email clients.


This seems like a good idea, thanks for sharing it!

I don't think that registering "text/org" with the IANA will 
have the

consequences that you hope it has.


Thanks for highlighting some potential pitfalls that I haden't
considered. As outlined above, in light of your comments I still 
see
this being potentially beneficial/worth the effort, but you've 
opened my

eyes to some complications that I was previously unaware of.

Thank you,

Timothy.




Re: Thoughts on the standardization of Org

2020-11-02 Thread TEC


Daniele Nicolodi  writes:


Acceptance criterion for what? Adoption of what?

It seems to me that some see a the adoption of a simplified 
version of
the Org markup language outside Emacs and the org-mode 
implementation as
something desirable. However, I don't see what the Org community 
would

gain from that.

[...]

As explained many times now, you don't a formal specification 
for this:

the specification is the org-mode implementation itself.

However, I will not discourage anyone from working on some form 
of
standardization, other than pointing out that IMO it is an 
exercise with

very limited usefulness, impact and future.


I think there are absolutely some benefits for Org users. I am
personally interested in registering Org as an IANA MIME type.

What will this do? Well, for starters I'd like to be able to 
attach org

files without the type being recognised as
"application/vnd.lotus-organizer" 濫.



test.org
Description: Lotus Organizer


I also think it's to our benefit that non-Emacsers become more
comfortable with seeing an org file --- as I see it that improves 
our
chances that we can directly share Org files with them, which they 
might
be comfortable editing and sending back for example, or that a 
generic

tool might think to support Org files.

So I'd like to assure you that my interest in improving 
recognition and
support for Org is motivated by selfish reasons  which just so 
happen

to potentially benefit non-Emacsers.

I hope that clarifies my view of the proposal,

Timothy


Re: Thoughts on the standardization of Org

2020-11-01 Thread TEC



Dr. Arne Babenhauserheide  writes:


Asa Zeren  writes:
Also another note is that the worg syntax document does begin 
to specify

this. My point is to bring this out into a separate document.


Why should this be in a separate document? The obvious place for 
a
standard is worg, and the way forward is to improve what’s 
there.


I'll try to avoid interpreting others words for them :P but my 
take is
that it while documents like the worg syntax document are 
fantastic, we
may want to add a bit more into a single more comprehensive 
document.


I have a suggestion in this regard. #+include

Why not have the best of both worlds :P

--
Timothy



Re: Thoughts on the standardization of Org

2020-11-01 Thread TEC



I feel that this also ties into my earlier idea of putting Emacs
as/inside an LSP server for Org.  I suspect there may be a a lot 
of

potential in making it dead easy to use Emacs as a tool.

I'm rather busy over the next few weeks, but I'd be happy to 
spearhead a

project in this direction.

Timothy.

Dr. Arne Babenhauserheide  writes:


see discussion on Mauro's thread about
the fact that it is probably just easier to use Emacs directly 
if you

need to export
to a certain format in a specific way. It is free software 
after all.


I would like to add, that this is pretty easy to do, and also to 
make
independent of the users emacs environment. Here is an example 
that
uses the whole orgmode-babel-latex-html machinery to create 
derived
documents from source-of-truth org-mode files which get exported 
to a

book:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/Makefile.am?rev=b8e3899c6d8b#L121


chargen.tex: chargen.org $(ewstables_SOURCES) 
kasten-alter-groesse-gewicht.org ews30setup.el
	echo yes > $$(tty); Xvfb :3 -screen 0 1024x768x16 & time 
DISPLAY=:3 HOME=@abs_top_srcdir@ @EMACS@ -l 
"@abs_top_srcdir@/ews30setup.el" --eval '(setq 
vc-follow-symlinks nil)' --eval '(setq org-id-locations-file 
"@abs_top_builddir@/.org-id-locations")' "$<" -e 
org-latex-export-to-latex -e kill-emacs  < $$(tty) >> build.log 
&& rm -f "@abs_top_builddir@/.org-id-locations"


Note how this sets the HOME to the sourcedir (so a 
project-specific

.emacs.d setup is used) and loads ews30setup.el at startup for
additional customization. Also note the call to Xvfb which 
avoids

showing a graphical Emacs during build.


This uses an org-mode file that pulls data from tables in other 
org-mode

files by setting variables for code based on autotools-included
datafiles. Here’s an example of pulling the tables into 
variables:

https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L153

#+begin_src scheme :exports none :results output raw :prologue 
"(import (srfi srfi-1)(ice-9 match)(ice-9 receive))(set! 
*random-state*  (random-state-from-platform))\n" :tangle 
chargen.scm :noweb yes :var kernantriebe=tabelle-kernantriebe 
:var hautfarbe=tabelle-hautfarbe :var 
haarfarbe=tabelle-haarfarbe :var augenfarbe=tabelle-augenfarbe 
:var darstellung1=tabelle-darstellung1 :var 
darstellung2=tabelle-darstellung2 :var 
kleidung_oben_maenner=tabelle-kleidung-fantasy-oben-maenner 
:var 
kleidung_unten_maenner=tabelle-kleidung-fantasy-unten-maenner 
:var kleidung_oben_frauen=tabelle-kleidung-fantasy-oben-frauen 
:var kleidung_unten_frauen=tabelle-kleidung-fantasy-unten-frauen 
:var kleidung_oben_frauen=tabelle-kleidung-fantasy-oben-frauen 
:var kleidung_unten_frauen=tabelle-kleidung-fantasy-unten-frauen 
:var namen=tabelle-namen-fantasy-jetzt :var 
sex=tabelle-sexualitaet :var stichwort=tabelle-stichwort-fantasy

  (let ()
{{{chargen-setup}}}
{{{chargen-generic}}}
{{{chargen-colors}}}
{{{chargen-specifics-fantasy}}}
{{{chargen-print-char}}}
(chargen-print-char)
  )
#+end_src


Note the {{{…}}} blocks. Those use literate programming to 
include

blocks defined below, with customized separators:
chargen-setup block: 
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L360
customization of separators: 
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L638

# Local Variables:
# org-confirm-babel-evaluate: nil
# org-export-allow-bind-keywords: t
# org-babel-noweb-wrap-start: "{{{"
# org-babel-noweb-wrap-end: "}}}"
# End:


Here’s how it pulls tables:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L578
@tabelle_aussehen@


And this is an example of the datafiles that are used as 
source-of-truth

and also directly inluded in the main book as tables:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/tabelle-aussehen.org?rev=b8e3899c6d8b#L578

#+tblname: tabelle-hautfarbe
|  | -5 | direkt  | 6  |
|--++-+|
|   -3 | blass  | rosig   | sommersprossig |
|   -1 | grau   | gelblich| elfenbein  |
|2 | kupfer | rotbraun| bronze |
|4 | oliv   | dunkelbraun | schwarz|
| -5/6 | albino | -   | fleckig|


All this machinery can be invoked without ever seeing Emacs.


So yes, the Emacs implementation is the source of truth, and 
yes, this
can be used without requiring people to operate Emacs by simply 
using
Emacs as utility with project-specific setup — just as you would 
do it

with a compiler.


Best wishes,
Arne





Re: Thoughts on the standardization of Org

2020-11-01 Thread TEC



Hi all,

Following what I've read on the list I've developed thoughts on 
what the
best approach might be. My current thinking is that it may be 
possible
to have Org registered as a standard in such a way that it does 
not

constrain our development efforts.

How?

We forgo locking down the precise format and behaviour of every 
Org

element. Instead we only submit something like
https://orgmode.org/worg/dev/org-syntax.html which /just/ 
describes the
overall syntax. I don't imagine that 'locking' ourself into the 
current
syntax described in https://orgmode.org/worg/dev/org-syntax.html 
would
actually hurt development, but might be enough for a MIME type 
etc.


Then perhaps just say for description of how specific/special 
instances
of those structural elements are supposed to work see the 
reference

implementation.

Just a few thoughts from me.

All the best,
Timothy.

Asa Zeren  writes:


Hi,

Even though I am new to the org-mode community, I would like to 
share
some thoughts on the specification of org-mode, especially since 
I
have seen some recent discussion of it in relation to 
registering org

as a MIME type.

First, I would like to repeat the importance of developing 
standards
for org-mode. If we want to expand the influence of org, tooling 
must
expand beyond Emacs. While Emacs is an amazing tool, (a) we 
cannot
convince the entire world to use Emacs and (b) org-mode should 
be
integrated into tooling unrelated to text editing, and is 
outside of
the Emacs-Lisp environment. Without additional org 
implementations,
this is impossible. If org catches on before it is standardized, 
we
end up in the situation of Markdown, with many competing 
standards and

non-standards. Hence, standardization is essential.

Standardizing org is much harder than standardizing something 
like
Markdown, but I think by breaking it down as follows will 
maximize the

portability of org while not compromising on development of org.

I see three areas of standardization, which I think should be
standardized separately:
 - Org DOM
 - Org Syntax
 - Org Standard Environments

Before we get to that, a brief note on /how/ I think that org 
should
be specified. I think that org should be specified in terms of 
an
/environment/ that defines the properties, etc. that can be used 
in a
document. For instance, the org standard would say something to 
the
effect of "An environment may specify block bounding keywords 
that may
be used like #+\n...#+. and the environment would 
specify

"begin_src and end_src are a pair of block bounding keyword that
indicates a source code block." This is for two reasons. First, 
this

allows for development of org tool features independent of the
standard. Second, this separates the individual features of org 
mode

from the overall structure.

Org DOM:
The first thing to specify is the org DOM. (Maybe a different 
name

should be used to avoid confusion with the HTML DOM) This is the
structure of an org-mode document, without the textual
representation. Many org-related tools operate on org documents
without needing to use the textual representation. Specifying 
the DOM
separately would (a) create a separation of concerns and (b) 
allow for

better libraries built around org mode.

Org Syntax:
This would be specifying the mapping between the DOM and the 
textual

representation, specified in terms of an environment.

Org Standard Environments:
This is how I would specify elements such as 
#+begin_src..#+end_src
would be specified, as standardized elements of the environment. 
This
would be structured as a number of individual standard 
environments,
such as "Source Blocks" or "Standard Header Properties" 
(specifying

#+title, #+author, etc.)

I would appreciate thoughts on these ideas about how to develop 
and

org specification.

Thanks for reading,
Asa Zeren





Re: Org-Mode as DSL

2020-10-30 Thread TEC


Eric S Fraga  writes:

It's not a crazy idea but one which misses one of the best 
features of
org mode: it is part of Emacs.  For me, a markup language is not 
so
exciting: we have plenty of them.  What makes org mode powerful 
is that
it is infinitely customizable by being part of Emacs.  I can add 
code,
change existing code, advice code, etc.  The org I use is not 
the org

others use, as a result.


I have wondered whether it might be viable to create a LSP client 
by

putting Emacs /inside/ the LSP client. Checking ~ls -lh
/usr/bin/emacs-nox~ I am told that my terminal-only Emacs client 
is 5.3

MiB. This seems nice and small.

Hence, any and all concerns about feature parity etc. are 
completely
resolved. One 'just' needs to implement the bindings and piping 
(as

opposed to the whole shebang).

Maybe this is the real 'crazy idea' in this thread :P
Hopefully it's of some interest :)

All the best,
Timothy.



Re: New website - back to the old unicorn!

2020-10-28 Thread TEC



Hi Stefan,

This seems very suspicious for one reason. I cannot see "Canvas"
anywhere in the entire codebase of the website, or any loaded 
resources.
So I have no idea where on earth the JS you're finding has come 
from -
I'm guessing it's improperly injected by a extension. FWIW I also 
run

Decentraleyes in Firefox and fail to see your issue.

--
Timothy

Stefan Nobis  writes:


Hi.

Thanks for your great work and the wonderful new page!

A minor detail: I use the plugin "Decentraleyes" and with this
activated there is quite a bit JavaScript garbage at the end of 
the
page (below the "Created by" footer). The part below the footer 
is

this:

#+begin_src js
{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }{ const iframes = 
window.top.document.querySelectorAll("iframe[sandbox]"); for 
(var i = 0; i < iframes.length; i++) { if 
(iframes[i].contentWindow) { if 
(iframes[i].contentWindow.CanvasRenderingContext2D) { 
iframes[i].contentWindow.CanvasRenderingContext2D.prototype.getImageData 
= CanvasRenderingContext2D.prototype.getImageData; } if 
(iframes[i].contentWindow.HTMLCanvasElement) { 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toBlob = 
HTMLCanvasElement.prototype.toBlob; 
iframes[i].contentWindow.HTMLCanvasElement.prototype.toDataURL = 
HTMLCanvasElement.prototype.toDataURL; } } } }

#+end_src

When I deactivate Decentraleyes and reload the page, the above 
code
snippet vanishes. This glitch is present both on the official 
page and

on https://orgmode.tecosaur.com. It seems, there is some weird
interaction with some script from a CDN (maybe loaded partially 
due to

constraints from the plugin) or something like that.





Re: New website - back to the old unicorn!

2020-10-28 Thread TEC



Let's do two at once:

Daniele Nicolodi  writes:


Great work! it looks very nice and informative at the same time.

That's the idea! :D

If I can bikeshed a bit more: I like the lighter page background 
that is
currently on http://orgomode.org more than the darker one in the 
new

version.


See the current. It's slightly tweaked, but you're not getting 
#fff :P



Ken Mankoff  writes:

A few more minor comments based on the current version at 
https://orgmode.tecosaur.com/


1) Code block should use some coloring for header blocks and 
code body. The current theme highlights almost everything else 
but the header and code background.


WDYM? I took the current colouring from an Org file that I 
created.


2 and more important) Use the most popular language to get the 
most people interested. There are probably a lot more Python 
programmers than shell scripters. I suggest the code example 
should be a minimal (~6 lines?) of Python that produces either 
(or both) a simple graph or ~3 column table.


Hmmm. This seems sensible. I've tweaked the example. I may make it
something website-related later (to fit in with the other 
content).

Suggestions welcome.

Also, I just noticed you can click on the sections (sections, 
babel header, results) to collapse them! :).


Indeed! You can click on:
- the headers
- the #+begin_src and #+RESULTS
- the image and style.scss links
- oh, and the timestamp highlights

Which led me to an Org bug: The TODO Is 28 % complete, or 2/7, 
but 2/7*100 = 28.5714285714, so I think it should be 29 % 
complete.


Well, at least I'm accurate to Org :P

--
Timothy



Re: New website - back to the old unicorn!

2020-10-28 Thread TEC



Daniele Nicolodi  writes:

- (minor) I would add a background to the example in the home 
page to

make it stand out more as an example org-mode syntax buffer

- (very minor) why does the example on the home page need to be 
an SVG
file? It would be very cool if it could be copy and pasted, but 
right

now it is not possible (with Firefox, at least)


So, I've turned these "minor" comments into a major revamp of the 
demo
(that I am inordinately happy with) --- following a brilliant 
suggestion

from someone on HN.

In case it's of interest you can see the HEAD^ + unstaged changes
version of the site at https://orgmode.tecosaur.com/ I've also 
tweaked

some of the styling in light of other feedback I received (the
announcement has been great for feedback!).

--
Timothy



Re: New website - back to the old unicorn!

2020-10-27 Thread TEC



Hi JRSS, great to hear from you!

JRSS  writes:

I've been using org for two years and the new website made me 
realize I can maybe help (with the "yes. Do this" link) simply 
by joining the email list and help with documentation. I'm not a 
coder (baby steps, here and there) but I've been blogging about 
org for a while.


That's brilliant! We know that the documentation could do with 
some
work, so if that something you're willing to help improve that 
would be

fantastic! IIRC there's been some talk previously about what the
documentation could benefit most from --- perhaps someone else has 
a

link. Don't hesitate to reach out if you want any help.


The website is awesome. Thanks for making it! Also, hello world.


Thanks for the kind words, and for getting in touch. I look 
forward to

seeing you around the ML :)

Timothy.



Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



Eric S Fraga  writes:


On Monday, 26 Oct 2020 at 14:54, Daniele Nicolodi wrote:
- (minor) I would add a background to the example in the home 
page to

make it stand out more as an example org-mode syntax buffer


This bothered me as well when I visited the site.  I think it 
would help
to have something, however minor, to make it clear that the 
image stand
is not part of the text, e.g. even a thin border around the 
image would

do it.


How does this look?
https://i.imgur.com/peTajuN.png


Otherwise, the site looks great.
Thank you.


Thanks for the kind words :)

Timothy.




Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



Daniele Nicolodi  writes:


On 26/10/2020 14:54, Daniele Nicolodi wrote:

On 26/10/2020 11:27, TEC wrote:


TEC  writes:

there are a few teething issues that have appeared when 
deploying the

site on orgmode.org.


These issues have now been fixed! Go wild :P

I've taken the liberty of making a post on reddit:
https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/

Once again, thanks to everyone who's helped out with this!

Timothy.


I like the new design. Thank you for your work!


By the way, what's the theme used to create the GIFs in the 
Features page?


I've just added a section on creating the Gifs/Svgs to the 
colophon:

https://orgmode.org/worg/org-site-colophon.html

How's that?

It would be good to re-record them as webm files, but making the 
Gifs
was enough for me  (also would be nice to see something happen 
with

https://gitlab.com/ambrevar/emacs-gif-screencast/-/issues/24).

All the best,

Timothy



Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



Daniele Nicolodi  writes:


I like the new design. Thank you for your work!


Thanks for the kind words!


Two things:

*cough, Three 

- in Firefox on a macOS machine, the colophon renders as "Made 
with XX
by TEC" with the XX being an Unicode replacement character. What 
is it

supposed to be?


Currently a brown heart, though I've actually had a better, less 
tacky

idea. You'll see it in a day or two ;)

- (minor) I would add a background to the example in the home 
page to

make it stand out more as an example org-mode syntax buffer


Hmm, I've got mixed feelings about that. I kinda like how smoothly 
it
fits in at the moment, and I wouldn't want to jeopardise that. If 
we can
have it fit in smoothly, and more clearly be a example that would 
be

great though :)

- (very minor) why does the example on the home page need to be 
an SVG
file? It would be very cool if it could be copy and pasted, but 
right

now it is not possible (with Firefox, at least)


That sounds like a good idea! I'll see if I can do that 
(medium-term).

PRs welcome as usual of course 

Thanks for the feedback,

Timothy.



Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



Nick Dokos  writes:

One thing that I have done in the past (and I'm probably not the 
onlye
one) on the Emacs SE is refer people to the mailing list through 
the
old link: https://orgmode.ord/community.html which does not 
exist any
more, so we have a whole lot of broken links on Emacs SE at the 
moment:
can something be done to restore the functionality of those 
links?


Thanks!


A nginx redirect to 
https://orgmode.org/contribute.html#mailing-list or
https://orgmode.org/index.html#chatting is probably the best 
approach.


I'm not sure how Bastien feels about me adding redirects without 
asking,

so I'll talk to him about that.

How does that sound?

Timothy



Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



gyro funch  writes:


The new site looks really great!


Thanks 

If we stumble upon minor issues (e.g., typos), what would be the 
best

way to notify you?


A quick email works fine for that :) and I'm also happy with 
github

issues: https://github.com/tecosaur/orgmode.org/issues/new

All the best,
Timothy



Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



Leo Vivier  writes:

I really like the new design.  You’ve done some fantastic work, 
Timoty,

as well as all the people who’ve contributed. :)


Thanks for the kind words! It means a lot to hear that the revamp 
is

going down well .


I especially like the new page for Tools:
https://orgmode.org/tools.html

The only nitpick I’d have on that page is that we’re grabbing 
the
picture from remote domains, which means that users of uMatrix 
have to
greenlight them before they can be displayed.  A solution could 
be to

host them ourselves, which should have a minimal footprint.


The plan is actually to move this page over to Worg, once the 
stylesheet
for Worg has been adjusted to allow for such column layouts. I'll 
bear

this in mind for when it's ported over :)

--
Timothy



Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



TEC  writes:

there are a few teething issues that have appeared when 
deploying the

site on orgmode.org.


These issues have now been fixed! Go wild :P

I've taken the liberty of making a post on reddit:
https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/

Once again, thanks to everyone who's helped out with this!

Timothy.



Re: New website - back to the old unicorn!

2020-10-26 Thread TEC



Hi Everyone, just a quick note from me:

Regarding the intermediate state, there are a few teething issues 
that

have appeared when deploying the site on orgmode.org.*

If we could hold off from announcing this on some of the more
high-traffic forums till these get sorted out that would be 
appreciated

:) We want people to get the best possible first impression of the
revamp after all.

Timothy.


*The favicon, font, and .gif files are not served properly ATM for 
example




Re: [PATCH] org-plot abstractions and extension

2020-10-24 Thread TEC


Bastien  writes:


I'm not an org-plot.el user so I cannot test, but by reading the
patches, they look okay.

Let's go in "optimistic merging" mode and commit your patches?


Sounds good then. I don't expect the changes to compromise any 
existing

functionality.


Is https://orgmode.org/list/87lfhbhfhe@gmail.com/ the latest
version I should use?


I've smoothed a rough edge or two, and added a documentation 
entry.


I'll attach all the patches to this email, so there's no 
ambiguity.

(crosses fingers for attachments working as expected)

--
Timothy

>From 3743e507775b446f5f8188958c20f65861fac3fb Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 8 Jul 2020 18:34:46 +0800
Subject: [PATCH 01/15] org-plot.el: make indentation method consistent

* lisp/org-plot.el (org-plot/gnuplot): Make indentation consistent, by
replacing a few spaces with tabs.

Only 6 of 347 lines used spaces instead of tabs.
---
 lisp/org-plot.el | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 0ff96af67..c08bc144e 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -325,12 +325,12 @@ line directly before or after the table."
   (with-temp-buffer
 	(if (plist-get params :script)	; user script
 	(progn (insert
-(org-plot/gnuplot-script data-file num-cols params t))
-   (insert "\n")
-   (insert-file-contents (plist-get params :script))
-   (goto-char (point-min))
-   (while (re-search-forward "\\$datafile" nil t)
- (replace-match data-file nil nil)))
+		(org-plot/gnuplot-script data-file num-cols params t))
+		   (insert "\n")
+		   (insert-file-contents (plist-get params :script))
+		   (goto-char (point-min))
+		   (while (re-search-forward "\\$datafile" nil t)
+		 (replace-match data-file nil nil)))
 	  (insert (org-plot/gnuplot-script data-file num-cols params)))
 	;; Graph table.
 	(gnuplot-mode)
-- 
2.28.0

>From c62e817b04dfbe624ee8b2090ebcde257bbd3f23 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 8 Jul 2020 19:26:07 +0800
Subject: [PATCH 02/15] org-plot.el: add new option :transpose

* lisp/org-plot.el (org-plot/add-options-to-plist,
org-plot/add-options-to-plist): Add a new option :transpose, and a
shorter alias :trans. Transposition is performed if the argument is yes,
y, or t.  This treats the table as a matrix and performs matrix
transposition on it.  If an hline is present, it is assumed that it is a
marks a separation from a first header row.  The first row is then
treated as the new header by inserting a hline in the transposed data.
This is quite useful for some plots, where across multiple categories,
there are a large number of data points.  Without this, the data points
would be columns and the table can spread irritatingly wide.
---
 lisp/org-plot.el | 44 +---
 1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index c08bc144e..6ff633130 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -50,19 +50,21 @@
   "Parse an OPTIONS line and set values in the property list P.
 Returns the resulting property list."
   (when options
-(let ((op '(("type". :plot-type)
-		("script"  . :script)
-		("line". :line)
-		("set" . :set)
-		("title"   . :title)
-		("ind" . :ind)
-		("deps". :deps)
-		("with". :with)
-		("file". :file)
-		("labels"  . :labels)
-		("map" . :map)
-		("timeind" . :timeind)
-		("timefmt" . :timefmt)))
+(let ((op '(("type"  . :plot-type)
+		("script". :script)
+		("line"  . :line)
+		("set"   . :set)
+		("title" . :title)
+		("ind"   . :ind)
+		("deps"  . :deps)
+		("with"  . :with)
+		("file"  . :file)
+		("labels". :labels)
+		("map"   . :map)
+		("timeind"   . :timeind)
+		("timefmt"   . :timefmt)
+		("trans" . :transpose)
+		("transpose" . :transpose)))
 	  (multiples '("set" "line"))
 	  (regexp ":\\([\"][^\"]+?[\"]\\|[(][^)]+?[)]\\|[^ \t\n\r;,.]*\\)")
 	  (start 0))
@@ -289,8 +291,20 @@ line directly before or after the table."
 	(setf params (plist-put params (car pair) (cdr pair)
 ;; collect table and table information
 (let* ((data-file (make-temp-file "org-plot"))
-	   (table (org-table-collapse-header (org-table-to-lisp)))
-	   (num-cols (length (car table
+	   (table (let ((tbl (org-table-to-lisp)))
+		(when (pcase (plist-get params :transpose)
+			('y   t)
+			('yes t)
+			('t  

W3C violations in Org's HTML export

2020-10-23 Thread TEC

Hi everyone,

In developing my take on the Org website and my coFig file, it has 
come
to my attention that there seem to be a few W3C violations in the 
HTML

export.

I always export with these settings,
which may affect some of the items below.
#+begin_src emacs-lisp
(setq org-html-doctype "html5"
 org-html-html5-fancy t)
#+end_src

* Error: Element p not allowed as child of element h2 in this 
 context

 Org currently seems to put a p.subtitle inside the heading.
 This violates the "phrasing content" restriction.
 
https://html.spec.whatwg.org/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements

** Suggestion
  Make the subtitle an independent element, is can still be a
  p.subtitle, just not /inside/ the h2 title

* Warning: The type attribute is unnecessary for JavaScript 
 resources.

 This seems to be from the 

Re: Babel->Latex export: how to set includegraphics scale?

2020-10-22 Thread TEC



Hi Mirko

Mirko Vukovic  writes:

Instead specifying the width, I'd like to use the parameter 
\scale.


Have you tried #+attr_latex: :scale SCALE ?

Not sure how you'd put this in a header though I'm afraid - you'll
likely want to change a variable or add an export filter.

Hope something there may be of use,
Timothy.



Re: [PATCH] org-plot abstractions and extension

2020-10-16 Thread TEC



Hello all,

I'm still hoping that someone might get back to me ... eventually,
so here's another bump.

Timothy.

TEC  writes:

Hello everyone. Just in case this has slipped through the cracks 
/

fallen under the radar --- here's a little bump.

Timothy.

TEC  writes:

Oooops, I've just noticed my patch attachment re-send was only 
addressed

to Bastien (maybe this is why I haven't heard anything?).
This is what I get for mixing mail clients and not paying 
attention

I guess .

If someone would be willing to have a look through my work, and 
comment

- that would be fantastic.

I'd love to get my code into shape to be merged :)

All the best,

Timothy.





Re: best practices query: non-emacs packages based on tangled source

2020-10-16 Thread TEC



Hi Greg,

Just one little thing that occurs to me, for accepting PRs if you 
add

the header arg (globally would probably be best) :comments link
That with M-x org-babel-detangle should help with accepting PRs.

Hope that helps,

Timothy.

Greg Minshall  writes:

hi.  i apologize if this has been asked before (especially if by 
me).
but, since i had a question recently about Org Src... buffers, 
this came

up.

i'm wondering what people do who want to release a non-emacs'y 
package
(an R package, say, or ...), and who did their development "from 
within"

a .org file.

i can "build" whatever files are needed to release the package. 
but,
it's nice to be able to let people look at the sources, maybe 
submit

'pull requests', etc.

if anyone has any techniques they've used, liked (or hated), i'd 
love to

hear.

thank you very much, Greg





Re: Shower thought: submit an IETF RFC to register Org as a MIME type

2020-10-06 Thread TEC



Wes Hardaker  writes:

Ok, I'll try to create a template we can fill out in github next 
week

(I'm swamped this week with a deadline).


Sounds good :) I'm fairly busy for the next ~month and a half 
anyway so

I'm happy to accommodate delays.

Would it be a good idea to use the markdown RFC as a template? 
That's

what I was originally thinking.

Thanks,

Timothy.



  1   2   >