Notice: change of my email address
Hi All, Short version t...@tecosaur.com ⟶ g...@tecosaur.net (in commits) * tecos...@gmail.com ⟶ orgm...@tec.tecosaur.net (in communications here) * I've sent this email from the (old) commit address to leave a paper trail so it's (hopefully) clear to anybody who searches for the address what's happened, and that the FSF copyright assignment continues on with the new address. Long(er) version It was recently brought to my attention that the email forwarding I set up for this address (t...@tecosaur.com) is a tad borked. Its domain and email hosting was set up years ago on a shared VPS, and it's become increasingly fragile over the past ~year. I'm currently shifting to a new (better) setup, and have grabbed a new domain (tecosaur.net) so I can do this gradually without breaking anything currently on tecosaur.com. I've taken this as a push to get a move on with my email migration, and shift a bit more of my communication away from google (with a bit of extra organisation too). Hopefully, if anybody emails t...@tecosaur.com the email will actually be forwarded (I switched the method) or you'll see an auto-responder (just set up) directing you to try my new address. At some point, this will likely stop working completely. On this mailing list, I'll still get emails to my Gmail address just as before, so it's no problem if any of you auto-complete that address (I'm liable to accidentally use it every now), but I'll be trying to use the orgmode@ email for less google and better filtering :) All the best, Timothy.
Re: The fate of ditaa.jar (9.4.5.)
Tim Cross writes: > I also had to install textlive, plantuml, graphviz, taskjuggler, > ledger, sqlite and many other things. Perhaps it would be good to make a table of | software | needed for | package name | download page | and/or prompt users when an action requiring another executable is undertaken if it isn't found. -- Timothy
Re: Google SoC organisation application
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
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
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"
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
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"
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
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 :-)
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
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
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]
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&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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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?
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?
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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
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
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?
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
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.
