[PATCH]

[PATCH]

[Evgeny Boykov]

===========================================================================

I want org-publish-current-file ~/git/org/filename.org in ~/pub/org/

Some setup:

(setq org-publish-project-alist
...
         :base-directory "~/git/org"
         :publishing-directory "~/pub/org"
         :publishing-function org-publish-org-to-pdf
...

or just

(org-export-as-pdf 3 nil nil "*Org LaTeX Export*" nil "~/pub/org")

Before patch, incorrectly: 

all pdf-creating files: filename.aux, filename.out, etc,
apart from filename.tex, are here:
../base-directory/

After patch, correctly:

all pdf-creating files are here:
../publishing-directory/

======================================================================

Solution:

All 'cmds' must be called in 'lbuf', but not in filename.org's buffer context.

======================================================================


diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 1d6e042..5270943 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1043,26 +1043,28 @@ when PUB-DIR is set, use this as the publishing directory."
     (with-current-buffer outbuf (erase-buffer))
     (message (concat "Processing LaTeX file " file "..."))
     (setq output-dir (file-name-directory file))
-    (if (and cmds (symbolp cmds))
-	(funcall cmds (shell-quote-argument file))
-      (while cmds
-	(setq cmd (pop cmds))
-	(while (string-match "%b" cmd)
-	  (setq cmd (replace-match
-		     (save-match-data
-		       (shell-quote-argument base))
-		     t t cmd)))
-	(while (string-match "%f" cmd)
-	  (setq cmd (replace-match
-		     (save-match-data
-		       (shell-quote-argument file))
-		     t t cmd)))
-	(while (string-match "%o" cmd)
-	  (setq cmd (replace-match
-		     (save-match-data
-		       (shell-quote-argument output-dir))
-		     t t cmd)))
-	(shell-command cmd outbuf)))
+    (with-current-buffer lbuf
+      (save-excursion
+	(if (and cmds (symbolp cmds))
+	    (funcall cmds (shell-quote-argument file))
+	  (while cmds
+	    (setq cmd (pop cmds))
+	    (while (string-match "%b" cmd)
+	      (setq cmd (replace-match
+			 (save-match-data
+			   (shell-quote-argument base))
+			 t t cmd)))
+	    (while (string-match "%f" cmd)
+	      (setq cmd (replace-match
+			 (save-match-data
+			   (shell-quote-argument file))
+			 t t cmd)))
+	    (while (string-match "%o" cmd)
+	      (setq cmd (replace-match
+			 (save-match-data
+			   (shell-quote-argument output-dir))
+			 t t cmd)))
+	    (shell-command cmd outbuf)))))
     (message (concat "Processing LaTeX file " file "...done"))
     (setq errors (org-export-latex-get-error outbuf))
     (if (not (file-exists-p pdffile))

__________________________

С уважением,
Бойков Евгений Алексеевич
сот. 8-924-202-25-65
e-mail: artscan@list.ru

Re: [PATCH]

[Bastien]

Hi Evgeny,

thanks a lot for the analysis and the patch, I just applied it.

If you can, please use git format-patch when submitting patch
and make sure the subject line of the email containing the patch
is a short description of it -- it will help me a lot.

Best,

-- 
 Bastien

[PATCH]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-html.el-remove-CDATA-strings.patch --]
[-- Type: text/x-patch, Size: 2679 bytes --]

From 635bd77cd7a2dc55cc0705c5bbf2e11091bfbaf3 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
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
   "<script type=\"text/javascript\">
 // @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
 </script>"
   "Basic JavaScript that is needed by HTML files produced by Org mode.")
 
 (defconst org-html-style-default
   "<style type=\"text/css\">
- <!--/*--><![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: #ffff00; color: #000000; font-weight: bold; }
   .org-svg { width: 90%; }
-  /*]]>*/-->
 </style>"
   "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."
 
 <script type=\"text/javascript\">
 // @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&amp;dn=gpl-3.0.txt GPL-v3-or-Later
-<!--/*--><![CDATA[/*><!--*/
 %MANAGER_OPTIONS
 org_html_manager.setup();  // activate after the parameters are set
-/*]]>*///-->
 // @license-end
 </script>"
   "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:
 
    <style type=\"text/css\">
-    /*<![CDATA[*/
       p { font-weight: normal; color: gray; }
       h1 { color: black; }
       .title { text-align: center; }
       .todo, .timestamp-kwd { color: red; }
       .done { color: green; }
-    /*]]>*/
    </style>
 
 If you want to refer to an external style, use something like
-- 
2.29.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-ox-html.el-limit-maximum-content-width-and-center.patch --]
[-- Type: text/x-patch, Size: 895 bytes --]

From 5bef340093102936efe831f85fabdb589070ce43 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
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
   "<style type=\"text/css\">
+  #content { max-width: 60em; margin: auto; }
   .title  { text-align: center;
              margin-bottom: .2em; }
   .subtitle { text-align: center;
-- 
2.29.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-ox-html.el-format-CSS-more-consistently.patch --]
[-- Type: text/x-patch, Size: 2278 bytes --]

From 2c0f648ae87e789f21c24b645b2049f05d084799 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Wed, 20 Jan 2021 17:58:38 +0800
Subject: [PATCH 3/5] ox-html.el: format CSS more consistently

* lisp/ox-html.el (org-html-style-default): Format CSS declarations more
consistently.
---
 lisp/ox-html.el | 26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 9bbfad678..14f023e87 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -257,8 +257,8 @@ property on the headline itself.")
 (defconst org-html-style-default
   "<style type=\"text/css\">
   #content { max-width: 60em; margin: auto; }
-  .title  { text-align: center;
-             margin-bottom: .2em; }
+  .title { text-align: center;
+           margin-bottom: .2em; }
   .subtitle { text-align: center;
               font-size: medium;
               font-weight: bold;
@@ -282,13 +282,11 @@ property on the headline itself.")
     padding: 8pt;
     font-family: monospace;
     overflow: auto;
-    margin: 1.2em;
-  }
+    margin: 1.2em; }
   pre.src {
     position: relative;
     overflow: auto;
-    padding-top: 1.2em;
-  }
+    padding-top: 1.2em; }
   pre.src:before {
     display: none;
     position: absolute;
@@ -296,8 +294,7 @@ property on the headline itself.")
     top: -10px;
     right: 10px;
     padding: 3px;
-    border: 1px solid black;
-  }
+    border: 1px solid black; }
   pre.src:hover:before { display: inline; margin-top: 14px;}
   /* Languages per Org manual */
   pre.src-asymptote:before { content: 'Asymptote'; }
@@ -410,22 +407,17 @@ property on the headline itself.")
   .equation-container {
     display: table;
     text-align: center;
-    width: 100%;
-  }
-  .equation {
-    vertical-align: middle;
-  }
+    width: 100%; }
+  .equation { vertical-align: middle; }
   .equation-label {
     display: table-cell;
     text-align: right;
-    vertical-align: middle;
-  }
+    vertical-align: middle; }
   .inlinetask {
     padding: 10px;
     border: 2px solid gray;
     margin: 10px;
-    background: #ffffcc;
-  }
+    background: #ffffcc; }
   #org-div-home-and-up
    { text-align: right; font-size: 70%; white-space: nowrap; }
   textarea { overflow-x: auto; }
-- 
2.29.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-ox-html.el-tweak-styling-of-src-blocks.patch --]
[-- Type: text/x-patch, Size: 1617 bytes --]

From c341a278291be3c6a4fcca77fede476a04417a69 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Wed, 20 Jan 2021 18:17:06 +0800
Subject: [PATCH 4/5] ox-html.el: tweak styling of src blocks

* lisp/ox-html.el (org-html-style-default): Apply the following changes
to the styling of src blocks:
- Remove box shadow.
- Lighten border.
- Add very light grey background colour.
- Make lang label (visible on hover) less obtrusive by removing border.
---
 lisp/ox-html.el | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 14f023e87..e83648726 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -277,24 +277,24 @@ property on the headline itself.")
   #postamble p, #preamble p { font-size: 90%; margin: .2em; }
   p.verse { margin-left: 3%; }
   pre {
-    border: 1px solid #ccc;
-    box-shadow: 3px 3px 3px #eee;
+    border: 1px solid #e6e6e6;
+    border-radius: 3px;
+    background-color: #f2f2f2;
     padding: 8pt;
     font-family: monospace;
     overflow: auto;
     margin: 1.2em; }
   pre.src {
     position: relative;
-    overflow: auto;
-    padding-top: 1.2em; }
+    overflow: auto; }
   pre.src:before {
     display: none;
     position: absolute;
-    background-color: white;
-    top: -10px;
-    right: 10px;
+    top: -8px;
+    right: 12px;
     padding: 3px;
-    border: 1px solid black; }
+    color: #555;
+    background-color: #f2f2f299; }
   pre.src:hover:before { display: inline; margin-top: 14px;}
   /* Languages per Org manual */
   pre.src-asymptote:before { content: 'Asymptote'; }
-- 
2.29.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0005-ox-html.el-add-lang-label-to-authinfo-src-blocks.patch --]
[-- Type: text/x-patch, Size: 931 bytes --]

From b8eb175c709ad9cff259b4326d8c9a344a4381ba Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Wed, 20 Jan 2021 18:22:58 +0800
Subject: [PATCH 5/5] ox-html.el: add lang label to authinfo src blocks

* lisp/ox-html.el (org-html-style-default): `authinfo-mode' is defined
in Emacs 27. As such, in the CSS add an "Authinfo" lang label to
authinfo src blocks.
---
 lisp/ox-html.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index e83648726..e5e82a5d8 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -299,6 +299,7 @@ property on the headline itself.")
   /* Languages per Org manual */
   pre.src-asymptote:before { content: 'Asymptote'; }
   pre.src-awk:before { content: 'Awk'; }
+  pre.src-authinfo::before { content: 'Authinfo'; }
   pre.src-C:before { content: 'C'; }
   /* pre.src-C++ doesn't work in CSS */
   pre.src-clojure:before { content: 'Clojure'; }
-- 
2.29.2

Re: [PATCH] tweaks to ox-html style

[TEC]

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

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

--
Timothy

TEC <tecosaur@gmail.com> 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.

Re: [PATCH] tweaks to ox-html style

[Kyle Meyer]

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'm sure there are plenty of opinionated ox-html users on the list.  Is
anyone willing to provide feedback on this series?  Please don't assume
you need commit access to provide reviews.

Re: [PATCH] tweaks to ox-html style

[Jens Lechtenboerger]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On 2021-02-12, Kyle Meyer wrote:

> 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'm sure there are plenty of opinionated ox-html users on the list.  Is
> anyone willing to provide feedback on this series?  Please don't assume
> you need commit access to provide reviews.

Hi there,

I do not know why the CDATA lines exist.  I don’t see a reason to
keep them (patch 0001), but that might be a lack of understanding on
my part.

Patch 0003 is about whitespace fixes.

Patches 0002, 0004, 0005 change defconst styling.  I don’t have a
strong opinion here.  However, if they are changed now, what about
turning them into defcustoms?  Then each of us would be entitled to
their own opinion ;)

The docstring for org-html-head-include-default-style says that
org-html-style-default (a defconst proposed to be changed here)
should not be changed.  Why not?

Best wishes
Jens

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5290 bytes --]

Re: [PATCH] tweaks to ox-html style

[Jens Lechtenboerger]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On 2021-02-12, Jens Lechtenboerger wrote:

> I do not know why the CDATA lines exist.  I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.

OK, that is probably for XHTML, where < and & are only allowed
inside CDATA sections.

Timothy, did you try to validate XHTML output?

Best wishes
Jens

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5290 bytes --]

Re: [PATCH] tweaks to ox-html style

[Timothy]

Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:

> I do not know why the CDATA lines exist.  I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.

I'll cover this in my reply to your follow-up.

> Patch 0003 is about whitespace fixes.
>
> Patches 0002, 0004, 0005 change defconst styling.  I don’t have a
> strong opinion here.  However, if they are changed now, what about
> turning them into defcustoms?  Then each of us would be entitled to
> their own opinion ;)
>
> The docstring for org-html-head-include-default-style says that
> org-html-style-default (a defconst proposed to be changed here)
> should not be changed.  Why not?

The defconst is left a defsconst because I don't really know why it is
one, and when I don't know why something is the way it is, I try to leave
it alone.  In my own config I actually overwrite it, but oh well.

I'm guessing this is just a case of "User beware, this contains
important stuff to have Org look reasonable. Don't remove that."

Perhaps this should be a defcustom? It would be good to hear from
someone else on this. If this ends up being a hold up though I'd rather
resolve this separately.

--
Timothy.

Re: [PATCH] tweaks to ox-html style

[Timothy]

Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:

> On 2021-02-12, Jens Lechtenboerger wrote:
>
>> I do not know why the CDATA lines exist.  I don’t see a reason to
>> keep them (patch 0001), but that might be a lack of understanding on
>> my part.
>
> OK, that is probably for XHTML, where < and & are only allowed
> inside CDATA sections.
>
> Timothy, did you try to validate XHTML output?

If you look at the commit message for 001, you can see the following:

> remove CDATA strings, as they are now
> considered obsolete --- see
> https://developer.mozilla.org/en-US/docs/Web/API/CDATASection#specifications

Does that page clear things up for you?

I did a bit more googling and found
https://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5
which mentions CDATA:

> The CDATA code is then seen as text by the HTML parser (and can thus
> interfere with the scripting or styling language!), while the XML
> parser sees the content as text without markup semantics.

In other words, CDATA allows you to keep XML comparability, but now
breaks strict HTML comparability. IMO the latter is much more important
for an org-html export.

--
Timothy

Re: [PATCH] tweaks to ox-html style

[Tim Cross]

Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:

> On 2021-02-12, Kyle Meyer wrote:
>
>> 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'm sure there are plenty of opinionated ox-html users on the list.  Is
>> anyone willing to provide feedback on this series?  Please don't assume
>> you need commit access to provide reviews.
>
> Hi there,
>
> I do not know why the CDATA lines exist.  I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.
>
> Patch 0003 is about whitespace fixes.
>
> Patches 0002, 0004, 0005 change defconst styling.  I don’t have a
> strong opinion here.  However, if they are changed now, what about
> turning them into defcustoms?  Then each of us would be entitled to
> their own opinion ;)
>
> The docstring for org-html-head-include-default-style says that
> org-html-style-default (a defconst proposed to be changed here)
> should not be changed.  Why not?
>

I think I pretty much agree here. IMO I think all the CSS styling in an
export should be defined with defcustom. CSS has come a long way since
the original HTML exporter was written and I think it is best to put
this power in the hands of the author. I realise some of this CSS
styling can be complex if we want good looking HTML exports and making
it available to be changed by the user could result in an increase in
issues relating to inconsistent or ugly output, but I think provided the
defaults are good, this risk is warranted.

My only question is whether we should continue to modify the current
html exporter or whether it would be better to rename the existing
exporter as xhtml exporter and do a new clean html exporter that is just
html5 and css3 and which does not attempt to be xhtml compliant?

Others have mentioned on the list that they believe it is important to
keep xhtml compatibility. This would satisfy that requirement and at the
same time, enable a new html exporter that can take full advantage of
changes introduced with html5 while keeping the exporter smaller and
cleaner (and easier to maintain).

BTW I think it would be nice if the html export was able to produce/use
a separate CSS file rather than in-line styles. This would make it
easier to drop exported HTML files into existing sites with custom
styles or update the look of exported files without needing to re-export
or manually edit. The complication is with exporting of HTML snippets,
where you probably want in-line styles.

--
Tim Cross

Re: [PATCH] tweaks to ox-html style

[Eric S Fraga]

On Saturday, 13 Feb 2021 at 08:46, Tim Cross wrote:
> BTW I think it would be nice if the html export was able to produce/use
> a separate CSS file rather than in-line styles. This would make it
> easier to drop exported HTML files into existing sites with custom
> styles or update the look of exported files without needing to re-export
> or manually edit. 

I would like this.

> The complication is with exporting of HTML snippets, where you
> probably want in-line styles.

Actually, I often use org -> HTML to create HTML snippets (especially
tables as they are so much easier to write in org than in HTML) that I
can include within a hand-crafted HTML file and then I typically spend
quite a bit of time removing all the in-line style information!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f

Re: [PATCH] tweaks to ox-html style

[Christian Moe]

Tim Cross writes:

> BTW I think it would be nice if the html export was able to produce/use
> a separate CSS file rather than in-line styles. This would make it
> easier to drop exported HTML files into existing sites with custom
> styles or update the look of exported files without needing to re-export
> or manually edit. The complication is with exporting of HTML snippets,
> where you probably want in-line styles.

Isn't this already covered by existing capabilities? From the manual:

   The HTML export back-end includes a compact default style in each
   exported HTML file.  To override the default style with another
   style, use these keywords in the Org file.  They will replace the
   global defaults the HTML exporter uses.

     #+HTML_HEAD: <link rel="stylesheet" type="text/css" href="style1.css" />
     #+HTML_HEAD_EXTRA: <link rel="alternate stylesheet" type="text/css" href="style2.css" />

   To just turn off the default style, customize
   ‘org-html-head-include-default-style’ variable, or use this option
   line in the Org file.

     #+OPTIONS: html-style:nil

The only thing I don't think it does is export the default style as a
separate .css file rather than inline. Maybe there's a use case where
that would be better than turning it off and specifying a linked style,
but I can't really think of one. I suppose one would need a new option
to specify a path for the exported stylesheet, so it wouldn't save a lot
on option lines.

Yours,
Christian

Re: [PATCH] tweaks to ox-html style

[Jens Lechtenboerger]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On 2021-02-13, Timothy wrote:

> Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:
>
>> On 2021-02-12, Jens Lechtenboerger wrote:
>>
>>> I do not know why the CDATA lines exist.  I don’t see a reason to
>>> keep them (patch 0001), but that might be a lack of understanding on
>>> my part.
>>
>> OK, that is probably for XHTML, where < and & are only allowed
>> inside CDATA sections.
>>
>> Timothy, did you try to validate XHTML output?
>
> If you look at the commit message for 001, you can see the following:
>
>> remove CDATA strings, as they are now
>> considered obsolete --- see
>> https://developer.mozilla.org/en-US/docs/Web/API/CDATASection#specifications
>
> Does that page clear things up for you?

No, sorry, I don’t get it.  I see:
“Re-added in issue #295 due to web breakage”

> I did a bit more googling and found
> https://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5
> which mentions CDATA:
>
>> The CDATA code is then seen as text by the HTML parser (and can thus
>> interfere with the scripting or styling language!), while the XML
>> parser sees the content as text without markup semantics.
>
> In other words, CDATA allows you to keep XML comparability,

Exactly.  In fact, the “&” in the magnet URI should be “&amp;” or
it might be placed into the CDATA section.

> but now breaks strict HTML comparability.

What do you mean?  If I use html5 as HTML_DOCTYPE, the validator at
https://validator.w3.org/nu/ does not complain.

Best wishes
Jens

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5290 bytes --]

Re: [PATCH] tweaks to ox-html style

[Timothy]

Regarding any use case which would benefit from turning
org-html-style-default into a defcustom, IMO there are two:
+ When you don't want to have to add a #+HTML_HEAD to every file you
  export
+ When you want to include a long inline style (my use case)

--
Timothy

Re: [PATCH]

[Bastien]

Hi Timothy,

TEC <tecosaur@gmail.com> writes:

> 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).

thanks for the patches and sorry for the slow reply.

Feel free to install changes when they have reached consensus, 
or to ask for decisions when not.

Thanks!

Re: [PATCH]

[Timothy]

Bastien <bzg@gnu.org> writes:

> Feel free to install changes when they have reached consensus, 
> or to ask for decisions when not.

Thanks for the reply Bastien, would you mind elaborating on this a bit
more? I'm comfortable with the idea of what I can do with org-plot.el as
the maintainer (directly push, but field patches to the ML for
non-trivial changes), but as a non-core-contributor I didn't think I
could push my own patches for other things.

Also, with the batch of patches I sent a plea about recently, how would
you recommend I proceed with that? There doesn't seem to be any
consensus or decision despite prompting.

Thanks,

Timothy

Re: [PATCH]

[Bastien]

Hi Timothy,

TEC <tecosaur@gmail.com> writes:

> 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

Thanks for these patch.  I've applied most of them, sometimes updating
the changelog entries -- in particular, 

* lisp/ox-html.el (org-html-scripts, org-html-style-default,
                                                            ^^^
This should be: 

* lisp/ox-html.el (org-html-scripts, org-html-style-default)
                                                            ^^^

Fill-paragraph in change-log-mode should do the right thing.

I've not applied the change about moving from

 {
  ... : ...
 }

to 

 {
  ... : ... }

As I think the former looks more consistent.

Thanks!

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy <tecosaur@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Feel free to install changes when they have reached consensus, 
>> or to ask for decisions when not.
>
> Thanks for the reply Bastien, would you mind elaborating on this a bit
> more? I'm comfortable with the idea of what I can do with org-plot.el as
> the maintainer (directly push, but field patches to the ML for
> non-trivial changes), but as a non-core-contributor I didn't think I
> could push my own patches for other things.

Regular contributors can commit patches themselves whenever the
maintainers say so.

> Also, with the batch of patches I sent a plea about recently, how would
> you recommend I proceed with that? There doesn't seem to be any
> consensus or decision despite prompting.

Perhaps that's because such plea contains too many different issues.

I will reply there.  Thanks,

-- 
 Bastien

[PATCH]

[Timothy]

[-- Attachment #1.1: Type: text/plain, Size: 1370 bytes --]

Hi Everyone,

I’ve recently been wondering why it is that for sensibly sized images in a
LaTeX-export-oriented document I need to do both:
┌────
│ #+attr_org: :width 400
│ #+attr_latex: :width 0.4\linewidth
└────

When in HTML, just
┌────
│ #+attr_html: :width 400px
└────
is fine.

This has lead me to have a look at `org-display-inline-images', and I’ve realised
that the `#+attr_latex' width of `0.4\linewidth' is actually picked up, and
interpreted as a width of `0.4' pixels. I think it would make much more sense for
fractional values between zero and one to be interpreted as that portion of the
text width in the buffer. On second thoughts, given that the document width can
be slightly larger than the text width, perhaps an upper bound just a bit higher
— say 2, could be better.

I’ve prepared a patch which implements this logic, by converting extracted
widths that are:
⁃ floats, and
⁃ within the range [0,2]
and sizes them as that proportion of the text width in the buffer, which is
determined by checking
1. `visual-fill-column-width', when that package is installed and the mode active
2. `fill-column', when auto fill is active
3. `(window-text-width)', if neither of the above two cases hold

Please let me know what you think 🙂.

All the best,
Timothy

[-- Attachment #1.2: Type: text/html, Size: 6912 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-Display-proportional-image-widths.patch --]
[-- Type: text/x-patch, Size: 4258 bytes --]

From bc8aa862f513946599efe4a9bb420e54c504ab3b Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Fri, 24 Sep 2021 01:39:31 +0800
Subject: [PATCH] org: Display proportional image widths

* lisp/org.el (org-display-inline-images): When the image width is given
as a float less than 2, interpret the value as that portion of the text
area width.  This works well with cases such as "#+attr_latex: :width
0.6\linewidth" as this will now be interpreted as 60% of the text area
width.  The upper bound is set to 2 not 1, as more than 100% of the text
width can be realistic, e.g. "1.2\linewidth" in LaTeX, but more than
200% seems unrealistic.
---
 lisp/org.el | 47 +++++++++++++++++++++++++++++++----------------
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 66ca73d5e..ce2ac7404 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16622,22 +16622,37 @@ (defun org-display-inline-images (&optional include-linked refresh beg end)
 			   (cond
 			    ((eq org-image-actual-width t) nil)
 			    ((listp org-image-actual-width)
-			     (or
-			      ;; First try to find a width among
-			      ;; attributes associated to the paragraph
-			      ;; containing link.
-			      (pcase (org-element-lineage link '(paragraph))
-				(`nil nil)
-				(p
-				 (let* ((case-fold-search t)
-					(end (org-element-property :post-affiliated p))
-					(re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
-				   (when (org-with-point-at
-					     (org-element-property :begin p)
-					   (re-search-forward re end t))
-				     (string-to-number (match-string 1))))))
-			      ;; Otherwise, fall-back to provided number.
-			      (car org-image-actual-width)))
+                             (let ((width
+                                    (or
+                                     ;; First try to find a width among
+                                     ;; attributes associated to the paragraph
+                                     ;; containing link.
+                                     (pcase (org-element-lineage link '(paragraph))
+                                       (`nil nil)
+                                       (par (let* ((case-fold-search t)
+                                                   (end (org-element-property :post-affiliated par))
+                                                   (re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
+                                              (when (org-with-point-at
+                                                        (org-element-property :begin par)
+                                                      (re-search-forward re end t))
+                                                (string-to-number (match-string 1)))))))
+                                    ;; Otherwise, fall-back to provided number.
+                                    (car org-image-actual-width))))
+                               (when width
+                                 (if (and (floatp width) (<= 0 width 2.0))
+                                     ;; A float in [0,2] should be interpereted as this portion of
+                                     ;; the text width in the window.  This works well with cases like
+                                     ;; #+attr_latex: :width 0.X\{line,page,column,etc.}width,
+                                     ;; as the "0.X" is pulled out as a float.  We use 2 as the upper
+                                     ;; bound as cases such as 1.2\linewidth are feasible.
+                                     (round (* width
+                                               (window-pixel-width)
+                                               (/ (or (and (bound-and-true-p visual-fill-column-mode)
+                                                           (or visual-fill-column-width auto-fill-function))
+                                                      (when auto-fill-function fill-column)
+                                                      (window-text-width))
+                                                  (float (window-total-width)))))
+                                   width))))
 			    ((numberp org-image-actual-width)
 			     org-image-actual-width)
 			    (t nil)))
-- 
2.33.0

Re: [PATCH]

[Timothy]

How on earth did I remember to start writing the subject, then switch to the
message, and forget to finish it... (sigh). Ooops.

--
Timothy

Re: [PATCH]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]


Hello again,

> I’ve prepared a patch which implements this logic

I've just noticed that I had (when x (if (floatp x) ..)) which is a bit
silly, so I've removed the unnecessary when. Here's the updated patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-Display-proportional-image-widths.patch --]
[-- Type: text/x-patch, Size: 4155 bytes --]

From 2d8f151bb996e0159793b590baea50c530e3ed11 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Fri, 24 Sep 2021 01:39:31 +0800
Subject: [PATCH] org: Display proportional image widths

* lisp/org.el (org-display-inline-images): When the image width is given
as a float less than 2, interpret the value as that portion of the text
area width.  This works well with cases such as "#+attr_latex: :width
0.6\linewidth" as this will now be interpreted as 60% of the text area
width.  The upper bound is set to 2 not 1, as more than 100% of the text
width can be realistic, e.g. "1.2\linewidth" in LaTeX, but more than
200% seems unrealistic.
---
 lisp/org.el | 46 ++++++++++++++++++++++++++++++----------------
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 66ca73d5e..1a1feda78 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16622,22 +16622,36 @@ (defun org-display-inline-images (&optional include-linked refresh beg end)
 			   (cond
 			    ((eq org-image-actual-width t) nil)
 			    ((listp org-image-actual-width)
-			     (or
-			      ;; First try to find a width among
-			      ;; attributes associated to the paragraph
-			      ;; containing link.
-			      (pcase (org-element-lineage link '(paragraph))
-				(`nil nil)
-				(p
-				 (let* ((case-fold-search t)
-					(end (org-element-property :post-affiliated p))
-					(re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
-				   (when (org-with-point-at
-					     (org-element-property :begin p)
-					   (re-search-forward re end t))
-				     (string-to-number (match-string 1))))))
-			      ;; Otherwise, fall-back to provided number.
-			      (car org-image-actual-width)))
+                             (let ((width
+                                    (or
+                                     ;; First try to find a width among
+                                     ;; attributes associated to the paragraph
+                                     ;; containing link.
+                                     (pcase (org-element-lineage link '(paragraph))
+                                       (`nil nil)
+                                       (par (let* ((case-fold-search t)
+                                                   (end (org-element-property :post-affiliated par))
+                                                   (re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
+                                              (when (org-with-point-at
+                                                        (org-element-property :begin par)
+                                                      (re-search-forward re end t))
+                                                (string-to-number (match-string 1)))))))
+                                    ;; Otherwise, fall-back to provided number.
+                                    (car org-image-actual-width))))
+                             (if (and (floatp width) (<= 0 width 2.0))
+                                 ;; A float in [0,2] should be interpereted as this portion of
+                                 ;; the text width in the window.  This works well with cases like
+                                 ;; #+attr_latex: :width 0.X\{line,page,column,etc.}width,
+                                 ;; as the "0.X" is pulled out as a float.  We use 2 as the upper
+                                 ;; bound as cases such as 1.2\linewidth are feasible.
+                                 (round (* width
+                                           (window-pixel-width)
+                                           (/ (or (and (bound-and-true-p visual-fill-column-mode)
+                                                       (or visual-fill-column-width auto-fill-function))
+                                                  (when auto-fill-function fill-column)
+                                                  (window-text-width))
+                                              (float (window-total-width)))))
+                               width))
 			    ((numberp org-image-actual-width)
 			     org-image-actual-width)
 			    (t nil)))
-- 
2.33.0

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy <tecosaur@gmail.com> writes:

> I've just noticed that I had (when x (if (floatp x) ..)) which is a bit
> silly, so I've removed the unnecessary when. Here's the updated patch.

On a first look, it seems a bit hackish, but this is probably useful.

If a few others agree this is useful, feel free to commit.

Thanks,

-- 
 Bastien

Re: [PATCH]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Hi  Bastien,

Thanks for taking a look at my patch.

Bastien <bzg@gnu.org> writes:

> On a first look, it seems a bit hackish, but this is probably useful.

Taking a look at the commit, I can see how it doesn’t look particularly tidy. I
think this is more a function of the way that function is structured than my
change though. As such, I’ve had a second look at the code, and given how large
that function is, split off the width calculation into a new function, where
I’ve re-implemented the logic in (IMO) a cleaner way.

So now, in the original function there’s just
┌────
│ (let ((width (org-display-inline-image--width link))
└────

See the attached patch for the new function `org-display-inline-image--width' (to
be applied on top of my previous patch). Oh, and I’ve also added support for
`:width 70%'.

All the best,
Timothy

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0003-org-Support-displaying-X-width-images.patch --]
[-- Type: text/x-patch, Size: 1916 bytes --]

From d9c83a962c0ce26e3d7baf2a5b7a58ba054ef275 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Mon, 27 Sep 2021 19:16:58 +0800
Subject: [PATCH 3/3] org: Support displaying X% width images

* lisp/org.el (org-display-inline-image--width): Instead of interpreting
an image :width of X% as X pixels, take it as X% of the text width of
the buffer.
---
 lisp/org.el | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d61e74572..829df8cae 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16647,7 +16647,8 @@ (defun org-display-inline-image--width (link)
 - When `org-image-actual-width' is t, the image's pixel width is used.
 - When `org-image-actual-width' is a number, that value will is used.
 - When `org-image-actual-width' is nil or a list, the first :width attribute
-  set (if it exists) is used to set the image width.
+  set (if it exists) is used to set the image width.  A width of X% is
+  divided by 100.
   If no :width attribute is given and `org-image-actual-width' is a list with
   a number as the car, then that number is used as the default value.
   If the value is a float between 0 and 2, it interpreted as that proportion
@@ -16667,7 +16668,11 @@ (defun org-display-inline-image--width (link)
                              (re-search-forward attr-re par-end t)))
               (string-to-number (match-string 1))))
            (attr-width-val
-            (when attr-width (string-to-number attr-width)))
+            (cond
+             ((null attr-width) nil)
+             ((string-match-p "\\`[0-9.]+%")
+              (/ (string-to-number attr-width) 100.0))
+             (t (string-to-number attr-width))))
            ;; Fallback to `org-image-actual-width' if no explicit width is given.
            (width (or attr-width-val (car org-image-actual-width))))
       (if (and (floatp width) (<= 0 width 2.0))
-- 
2.33.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-org-Refactor-width-in-org-display-inline-images.patch --]
[-- Type: text/x-patch, Size: 6646 bytes --]

From 1fd5e43137a34418c149240b15fd4bdc311f4fd3 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Mon, 27 Sep 2021 18:46:03 +0800
Subject: [PATCH 2/3] org: Refactor width in `org-display-inline-images'

* lisp/org.el (org-display-inline-images,
org-display-inline-image--width): Extract the width determination in
`org-display-inline-images' into a new function
`org-display-inline-image--width' where I have taken the opportunity to
refactor the width-determination code.
---
 lisp/org.el | 85 +++++++++++++++++++++++++++++------------------------
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1a1feda78..d61e74572 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16617,44 +16617,7 @@ (defun org-display-inline-images (&optional include-linked refresh beg end)
 				  (ignore-errors (org-attach-expand path)))
                               (expand-file-name path))))
 		  (when (and file (file-exists-p file))
-		    (let ((width
-			   ;; Apply `org-image-actual-width' specifications.
-			   (cond
-			    ((eq org-image-actual-width t) nil)
-			    ((listp org-image-actual-width)
-                             (let ((width
-                                    (or
-                                     ;; First try to find a width among
-                                     ;; attributes associated to the paragraph
-                                     ;; containing link.
-                                     (pcase (org-element-lineage link '(paragraph))
-                                       (`nil nil)
-                                       (par (let* ((case-fold-search t)
-                                                   (end (org-element-property :post-affiliated par))
-                                                   (re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
-                                              (when (org-with-point-at
-                                                        (org-element-property :begin par)
-                                                      (re-search-forward re end t))
-                                                (string-to-number (match-string 1)))))))
-                                    ;; Otherwise, fall-back to provided number.
-                                    (car org-image-actual-width))))
-                             (if (and (floatp width) (<= 0 width 2.0))
-                                 ;; A float in [0,2] should be interpereted as this portion of
-                                 ;; the text width in the window.  This works well with cases like
-                                 ;; #+attr_latex: :width 0.X\{line,page,column,etc.}width,
-                                 ;; as the "0.X" is pulled out as a float.  We use 2 as the upper
-                                 ;; bound as cases such as 1.2\linewidth are feasible.
-                                 (round (* width
-                                           (window-pixel-width)
-                                           (/ (or (and (bound-and-true-p visual-fill-column-mode)
-                                                       (or visual-fill-column-width auto-fill-function))
-                                                  (when auto-fill-function fill-column)
-                                                  (window-text-width))
-                                              (float (window-total-width)))))
-                               width))
-			    ((numberp org-image-actual-width)
-			     org-image-actual-width)
-			    (t nil)))
+		    (let ((width (org-display-inline-image--width link))
 			  (old (get-char-property-and-overlay
 				(org-element-property :begin link)
 				'org-image-overlay)))
@@ -16679,6 +16642,52 @@ (defun org-display-inline-images (&optional include-linked refresh beg end)
 				(overlay-put ov 'keymap image-map))
 			      (push ov org-inline-image-overlays))))))))))))))))
 
+(defun org-display-inline-image--width (link)
+  "Determine the display width of the image LINK, in pixels.
+- When `org-image-actual-width' is t, the image's pixel width is used.
+- When `org-image-actual-width' is a number, that value will is used.
+- When `org-image-actual-width' is nil or a list, the first :width attribute
+  set (if it exists) is used to set the image width.
+  If no :width attribute is given and `org-image-actual-width' is a list with
+  a number as the car, then that number is used as the default value.
+  If the value is a float between 0 and 2, it interpreted as that proportion
+  of the text width in the buffer."
+  ;; Apply `org-image-actual-width' specifications.
+  (cond
+   ((eq org-image-actual-width t) nil)
+   ((listp org-image-actual-width)
+    (let* ((case-fold-search t)
+           (par (org-element-lineage link '(paragraph)))
+           (attr-re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)")
+           (par-end (org-element-property :post-affiliated par))
+           ;; Try to find an attribute providing a :width.
+           (attr-width
+            (when (and par (org-with-point-at
+                               (org-element-property :begin par)
+                             (re-search-forward attr-re par-end t)))
+              (string-to-number (match-string 1))))
+           (attr-width-val
+            (when attr-width (string-to-number attr-width)))
+           ;; Fallback to `org-image-actual-width' if no explicit width is given.
+           (width (or attr-width-val (car org-image-actual-width))))
+      (if (and (floatp width) (<= 0 width 2.0))
+          ;; A float in [0,2] should be interpereted as this portion of
+          ;; the text width in the window.  This works well with cases like
+          ;; #+attr_latex: :width 0.X\{line,page,column,etc.}width,
+          ;; as the "0.X" is pulled out as a float.  We use 2 as the upper
+          ;; bound as cases such as 1.2\linewidth are feasible.
+          (round (* width
+                    (window-pixel-width)
+                    (/ (or (and (bound-and-true-p visual-fill-column-mode)
+                                (or visual-fill-column-width auto-fill-function))
+                           (when auto-fill-function fill-column)
+                           (window-text-width))
+                       (float (window-total-width)))))
+        width)))
+   ((numberp org-image-actual-width)
+    org-image-actual-width)
+   (t nil)))
+
 (defun org-display-inline-remove-overlay (ov after _beg _end &optional _len)
   "Remove inline-display overlay if a corresponding region is modified."
   (let ((inhibit-modification-hooks t))
-- 
2.33.0

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy <tecosaur@gmail.com> writes:

> So now, in the original function there’s just
> ┌────
> │ (let ((width (org-display-inline-image--width link))
> └────
>
> See the attached patch for the new function `org-display-inline-image--width' (to
> be applied on top of my previous patch). Oh, and I’ve also added support for
> `:width 70%'.

It looks better, Thanks.  The two patches don't apply on main here.
Can you apply the change yourself and add an entry in etc/ORG-NEWS?

Thanks!

-- 
 Bastien

Re: [PATCH]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

Bastien <bzg@gnu.org> writes:

> It looks better, Thanks.  The two patches don’t apply on main here.
> Can you apply the change yourself and add an entry in etc/ORG-NEWS?

I’ve written an ORG-NEWS entry, verified it works (and fixed a trivial
oversight), and pushed :)

All the best,
Timothy

Re: [PATCH]

[Bastien]

Timothy <tecosaur@gmail.com> writes:

> I’ve written an ORG-NEWS entry, verified it works (and fixed a trivial
> oversight), and pushed :)

Great, thanks!

-- 
 Bastien

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy <tecosaur@gmail.com> writes:

> I’ve written an ORG-NEWS entry, verified it works (and fixed a trivial
> oversight), and pushed :)

This triggers a compiler warning about `visual-fill-column-width' not
being declared.

This variable comes from
https://github.com/joostkremers/visual-fill-column

Why relying on this package?  Any chance to avoid this dependency?

If not, can you please add the needed declaration?

-- 
 Bastien

Re: [PATCH]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Bastien <bzg@gnu.org> writes:

> This triggers a compiler warning about `visual-fill-column-width’ not
> being declared.
>
> This variable comes from
> <https://github.com/joostkremers/visual-fill-column>
>
> Why relying on this package?  Any chance to avoid this dependency?
>
> If not, can you please add the needed declaration?

Here I’m not relying on the package, but trying to make it so that this will
still function as intended if the package is used, as it can modify the area
used for text in a buffer (hence the bound-and-true-p). I think this is worth
having, but obviously byte-compile errors aren’t nice. Would adding a
declare-function statement be the best thing to do here?

All the best,
Timothy

Re: [PATCH]

[Bastien]

Hi Timothy,

Timothy <tecosaur@gmail.com> writes:

> Would adding a
> declare-function statement be the best thing to do here?

Since this is a variable, a simple (defvar visual-fill-column-width)
will silent the compiler. 

-- 
 Bastien

Re: [PATCH]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

Bastien <bzg@gnu.org> writes:

> Since this is a variable, a simple (defvar visual-fill-column-width)
> will silent the compiler.

I’ve just had another thought which wouldn’t add visual-fill-column-width to the
namespace (if that’s worth worrying about). Not sure if this is better or worse
though.

┌────
│ (/ (or (and (bound-and-true-p visual-fill-column-mode)
│             (or (bound-and-true-p visual-fill-column-mode) auto-fill-function))
└────

Might you have an opinion on this?

All the best,
Timothy

Re: [PATCH]

[Bastien]

Timothy <tecosaur@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Since this is a variable, a simple (defvar visual-fill-column-width)
>> will silent the compiler.
>
> I’ve just had another thought which wouldn’t add visual-fill-column-width to the
> namespace (if that’s worth worrying about). Not sure if this is better or worse
> though.
>
> ┌────
> │ (/ (or (and (bound-and-true-p visual-fill-column-mode)
> │             (or (bound-and-true-p visual-fill-column-mode) auto-fill-function))
> └────

(I don't understand the excerpt - why not a patch?)

It seems to me that the defvar declaration is good enough.

-- 
 Bastien

Re: [PATCH]

[Bastien Guerry]

Bastien <bzg@gnu.org> writes:

> It seems to me that the defvar declaration is good enough.

I just pushed this.

-- 
 Bastien

Re: [PATCH]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 198 bytes --]

Bastien Guerry <bzg@gnu.org> writes:

>> It seems to me that the defvar declaration is good enough.
>
> I just pushed this.

Ah, cool. Thanks for taking care of this Bastien.

All the best,
Timothy