* [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
@ 2024-06-18 2:55 Suhail Singh
2024-06-18 15:33 ` Ihor Radchenko
0 siblings, 1 reply; 14+ messages in thread
From: Suhail Singh @ 2024-06-18 2:55 UTC (permalink / raw)
To: Org mailing list
[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]
Unlike example blocks, source code and fixed-width blocks don't support
the attr_html keyword. Contrast these outputs:
#+begin_src emacs-lisp :results value replace :wrap src html
(require 'org)
(require 'ox-html)
(org-export-string-as
"#+attr_html: :class foo
,#+begin_src sh :exports code
pwd
,#+end_src"
'html t)
#+end_src
#+RESULTS:
#+begin_src html
<div class="org-src-container">
<pre class="src src-sh"><span style="color: #e090d7;">pwd</span>
</pre>
</div>
#+end_src
#+begin_src emacs-lisp :results value replace :wrap src html
(require 'org)
(require 'ox-html)
(org-export-string-as
"#+attr_html: :class foo
,#+RESULTS:
: blah"
'html t)
#+end_src
#+RESULTS:
#+begin_src html
<pre class="example">
blah
</pre>
#+end_src
With the output for example blocks:
#+begin_src emacs-lisp :results value replace :wrap src html
(require 'org)
(require 'ox-html)
(org-export-string-as
"#+attr_html: :class foo
,#+begin_example
hello world!
,#+end_example"
'html t)
#+end_src
#+RESULTS:
#+begin_src html
<pre class="example foo" id="org2d25618">
hello world!
</pre>
#+end_src
The attached patches are a straight-forward copy-paste of relevant code
from org-html-example-block. It may be better to refactor this logic
and ensure that it is applied on all relevant AST nodes (others are
probably affected as well).
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-html-Add-support-for-attr_html-for-source-code-bl.patch --]
[-- Type: text/x-patch, Size: 2019 bytes --]
From 7a61bb6a7c7e1122199232a1c01885fb270dd370 Mon Sep 17 00:00:00 2001
From: Suhail <suhail@bayesians.ca>
Date: Mon, 17 Jun 2024 21:04:18 -0400
Subject: [PATCH 1/2] ox-html: Add support for attr_html for source code blocks
* lisp/ox-html.el (org-html-src-block): Handle attr_html in a manner
similar to example blocks.
TINYCHANGE
---
lisp/ox-html.el | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d1687cf5a..675d85ffe 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -3667,14 +3667,24 @@ (defun org-html-src-block
contextual information."
(if (org-export-read-attribute :attr_html src-block :textarea)
(org-html--textarea-block src-block)
- (let* ((lang (org-element-property :language src-block))
+ (let* ((attributes (org-export-read-attribute :attr_html src-block))
+ (lang (org-element-property :language src-block))
(code (org-html-format-code src-block info))
(label (let ((lbl (org-html--reference src-block info t)))
(if lbl (format " id=\"%s\"" lbl) "")))
(klipsify (and (plist-get info :html-klipsify-src)
(member lang '("javascript" "js"
"ruby" "scheme" "clojure" "php" "html")))))
- (format "<div class=\"org-src-container\">\n%s%s\n</div>"
+ (if-let ((class-val (plist-get attributes :class)))
+ (setq attributes (plist-put attributes :class (concat "org-src-container " class-val)))
+ (setq attributes (plist-put attributes :class "org-src-container")))
+ (format "<div%s>\n%s%s\n</div>"
+ (let* ((reference (org-html--reference src-block info))
+ (a (org-html--make-attribute-string
+ (if (or (not reference) (plist-member attributes :id))
+ attributes
+ (plist-put attributes :id reference)))))
+ (if (org-string-nw-p a) (concat " " a) ""))
;; Build caption.
(let ((caption (org-export-get-caption src-block)))
(if (not caption) ""
--
2.45.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-ox-html-Add-support-for-attr_html-in-fixed-width-blo.patch --]
[-- Type: text/x-patch, Size: 1796 bytes --]
From 5d4fa5c3e0a7933d10d8f1ece3e368d35e4838ad Mon Sep 17 00:00:00 2001
From: Suhail <suhail@bayesians.ca>
Date: Mon, 17 Jun 2024 22:00:35 -0400
Subject: [PATCH 2/2] ox-html: Add support for attr_html in fixed-width blocks
* lisp/ox-html.el (org-html-fixed-width): Handle attr_html in a manner
similar to example blocks.
TINYCHANGE
---
lisp/ox-html.el | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 675d85ffe..848017f1d 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2728,13 +2728,23 @@ (defun org-html-export-block
;;;; Fixed Width
-(defun org-html-fixed-width (fixed-width _contents _info)
+(defun org-html-fixed-width (fixed-width _contents info)
"Transcode a FIXED-WIDTH element from Org to HTML.
CONTENTS is nil. INFO is a plist holding contextual information."
- (format "<pre class=\"example\">\n%s</pre>"
- (org-html-do-format-code
- (org-remove-indentation
- (org-element-property :value fixed-width)))))
+ (let ((attributes (org-export-read-attribute :attr_html fixed-width)))
+ (if-let ((class-val (plist-get attributes :class)))
+ (setq attributes (plist-put attributes :class (concat "example " class-val)))
+ (setq attributes (plist-put attributes :class "example")))
+ (format "<pre%s>\n%s</pre>"
+ (let* ((reference (org-html--reference fixed-width info))
+ (a (org-html--make-attribute-string
+ (if (or (not reference) (plist-member attributes :id))
+ attributes
+ (plist-put attributes :id reference)))))
+ (if (org-string-nw-p a) (concat " " a) ""))
+ (org-html-do-format-code
+ (org-remove-indentation
+ (org-element-property :value fixed-width))))))
;;;; Footnote Reference
--
2.45.2
[-- Attachment #4: Type: text/plain, Size: 309 bytes --]
Suhail (2):
ox-html: Add support for attr_html for source code blocks
ox-html: Add support for attr_html in fixed-width blocks
lisp/ox-html.el | 34 +++++++++++++++++++++++++++-------
1 file changed, 27 insertions(+), 7 deletions(-)
base-commit: e666660c7d9fa3a74a7f5246d72e6020ab33cfd2
--
2.45.2
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-06-18 2:55 [PATCH] [BUG] Support attr_html in source code and fixed-width blocks Suhail Singh
@ 2024-06-18 15:33 ` Ihor Radchenko
2024-07-19 15:28 ` Suhail Singh
0 siblings, 1 reply; 14+ messages in thread
From: Ihor Radchenko @ 2024-06-18 15:33 UTC (permalink / raw)
To: Suhail Singh, TEC; +Cc: Org mailing list
Suhail Singh <suhailsingh247@gmail.com> writes:
> Unlike example blocks, source code and fixed-width blocks don't support
> the attr_html keyword. Contrast these outputs:
> ...
> The attached patches are a straight-forward copy-paste of relevant code
> from org-html-example-block. It may be better to refactor this logic
> and ensure that it is applied on all relevant AST nodes (others are
> probably affected as well).
Sounds reasonable.
Timothy, may you have a look?
I am not sure if we want to add all the attributes to every transcoded
element. At least in some cases, we do discard them
(`org-html--textarea-block').
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-06-18 15:33 ` Ihor Radchenko
@ 2024-07-19 15:28 ` Suhail Singh
2024-07-22 13:49 ` Ihor Radchenko
0 siblings, 1 reply; 14+ messages in thread
From: Suhail Singh @ 2024-07-19 15:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Suhail Singh, TEC, Org mailing list
Ihor Radchenko <yantar92@posteo.net> writes:
>> Unlike example blocks, source code and fixed-width blocks don't support
>> the attr_html keyword. Contrast these outputs:
>> ...
>> The attached patches are a straight-forward copy-paste of relevant code
>> from org-html-example-block. It may be better to refactor this logic
>> and ensure that it is applied on all relevant AST nodes (others are
>> probably affected as well).
>
> Sounds reasonable.
> Timothy, may you have a look?
Any updates on this?
--
Suhail
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-19 15:28 ` Suhail Singh
@ 2024-07-22 13:49 ` Ihor Radchenko
2024-07-22 17:11 ` Suhail Singh
0 siblings, 1 reply; 14+ messages in thread
From: Ihor Radchenko @ 2024-07-22 13:49 UTC (permalink / raw)
To: Suhail Singh; +Cc: TEC, Org mailing list
Suhail Singh <suhailsingh247@gmail.com> writes:
>>> The attached patches are a straight-forward copy-paste of relevant code
>>> from org-html-example-block. It may be better to refactor this logic
>>> and ensure that it is applied on all relevant AST nodes (others are
>>> probably affected as well).
>>
>> Sounds reasonable.
>> Timothy, may you have a look?
>
> Any updates on this?
No comments from TEC.
Please address my concern about :textarea attribute. I do not see why we
should ignore it here.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 13:49 ` Ihor Radchenko
@ 2024-07-22 17:11 ` Suhail Singh
2024-07-22 18:13 ` Ihor Radchenko
0 siblings, 1 reply; 14+ messages in thread
From: Suhail Singh @ 2024-07-22 17:11 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Suhail Singh, TEC, Org mailing list
Ihor Radchenko <yantar92@posteo.net> writes:
> Please address my concern about :textarea attribute. I do not see why
> we should ignore it here.
I don't understand your concern. Could you please elaborate on what you
mean by "why we should ignore it here"? What is the "it" and what is
the "here"?
From your email on 18th June:
> I am not sure if we want to add all the attributes to every transcoded
> element. At least in some cases, we do discard them
> (`org-html--textarea-block').
From the manual:
#+CAPTION: [[info:org#Text areas in HTML export][org#Text areas in HTML export]]
#+begin_quote
The HTML export backend can create such text areas. It requires an
‘#+ATTR_HTML’ line as shown in the example below with the ‘:textarea’
option. This must be followed by either an example or a source code
block. Other Org block types do not honor the ‘:textarea’ option.
#+end_quote
The current processing of :textarea does special handling for width and
height attributes and discards the rest (based on my understanding of
the code in `org-html--textarea-block'). Said support for :textarea
attribute exists in `org-html-src-block' and `org-html-example-block'
which is consistent with the manual.
The patches I shared did not interfere with the handling of :textarea in
the blocks that support it.
In order to make the code more robust, one may wish to remove :textarea
from the list of attributes (or issue a user-error or warning if it's
present) in blocks that were never intended to support it (such as
`org-html-fixed-width'). I do not have any opinion on this matter.
Similarly, one may wish to add additional error checking based on the
specifics of the transcoded element. I do not believe this to be
worthwhile (HTML validation often has errors, and if a user is so
interested they always have the option of validating the generated
HTML).
There is an open question regarding what attributes to support in
`org-html--textarea-block' (i.e., in the presence of `:textarea'
option). I believe the "correct" thing would be to filter out `:width'
and `:height' (since, if present, they are translated into `rows' and
`cols' attributes in the generated HTML) and include the rest "as is" in
the generated HTML
Regardless of the specifics above regd. :textarea, I believe support for
#+ATTR_HTML ought to be added for most blocks to allow for CSS class
and/or inline style to be specified when exporting to HTML.
Additionally, I consider the absence of such support to be a bug.
--
Suhail
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 17:11 ` Suhail Singh
@ 2024-07-22 18:13 ` Ihor Radchenko
2024-07-22 18:45 ` Suhail Singh
0 siblings, 1 reply; 14+ messages in thread
From: Ihor Radchenko @ 2024-07-22 18:13 UTC (permalink / raw)
To: Suhail Singh; +Cc: TEC, Org mailing list
Suhail Singh <suhailsingh247@gmail.com> writes:
>> Please address my concern about :textarea attribute. I do not see why
>> we should ignore it here.
>
> I don't understand your concern. Could you please elaborate on what you
> mean by "why we should ignore it here"? What is the "it" and what is
> the "here"?
Your request, in its core, is asking to make treatment of verbatim blocks
more regular in ox-html.
So, if we start allowing arbitrary attributes in more blocks, may as
well include specially handled attributes like :textarea.
As a bonus, it will be possible to factor out common code handling
attributes (including :textarea) into a new internal function that can
then be reused.
>> I am not sure if we want to add all the attributes to every transcoded
>> element. At least in some cases, we do discard them
>> (`org-html--textarea-block').
>
> From the manual:
>
> #+CAPTION: [[info:org#Text areas in HTML export][org#Text areas in HTML export]]
> #+begin_quote
> The HTML export backend can create such text areas. It requires an
> ‘#+ATTR_HTML’ line as shown in the example below with the ‘:textarea’
> option. This must be followed by either an example or a source code
> block. Other Org block types do not honor the ‘:textarea’ option.
> #+end_quote
>
> The current processing of :textarea does special handling for width and
> height attributes and discards the rest (based on my understanding of
> the code in `org-html--textarea-block'). Said support for :textarea
> attribute exists in `org-html-src-block' and `org-html-example-block'
> which is consistent with the manual.
Yup. But since you are asking to add new features to ox-html, we may as
well do it in full (support all attributes, including special attributes).
> In order to make the code more robust, one may wish to remove :textarea
> from the list of attributes (or issue a user-error or warning if it's
> present) in blocks that were never intended to support it (such as
> `org-html-fixed-width'). I do not have any opinion on this matter.
My opinion here is not to remove :textarea, but to treat it as we do in
other places.
> There is an open question regarding what attributes to support in
> `org-html--textarea-block' (i.e., in the presence of `:textarea'
> option). I believe the "correct" thing would be to filter out `:width'
> and `:height' (since, if present, they are translated into `rows' and
> `cols' attributes in the generated HTML) and include the rest "as is" in
> the generated HTML
+1
> Regardless of the specifics above regd. :textarea, I believe support for
> #+ATTR_HTML ought to be added for most blocks to allow for CSS class
> and/or inline style to be specified when exporting to HTML.
+1
> Additionally, I consider the absence of such support to be a bug.
Since we do not promise it anywhere, it is not necessarily a bug.
But it would make sense to support setting arbitrary attributes, yes.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 18:13 ` Ihor Radchenko
@ 2024-07-22 18:45 ` Suhail Singh
2024-07-22 19:10 ` Ihor Radchenko
0 siblings, 1 reply; 14+ messages in thread
From: Suhail Singh @ 2024-07-22 18:45 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Suhail Singh, TEC, Org mailing list
Ihor Radchenko <yantar92@posteo.net> writes:
> Your request, in its core, is asking to make treatment of verbatim
> blocks more regular in ox-html.
I would phrase it differently.
Just to be clear, my concern isn't simply "verbatim blocks", and it
isn't simply to make handling "more regular". Apologies for the
innacuracy in the subject line which may have led to the confusion.
My concern is that when exporting to HTML, for some HTML elements that
are generated there is no straightforward way to add HTML attributes
(e.g. "class", "style" etc). It is the inability to do so for some AST
nodes that I consider a bug. Importantly, my concern isn't the handling
of things that are NOT HTML attributes such as `:textarea'. Also,
notably, my concern extends to possibly other blocks that aren't
verbatim that lack the appropriate handling of #+ATTR_HTML keyword.
> So, if we start allowing arbitrary attributes in more blocks, may as
> well include specially handled attributes like :textarea.
Yes, it is possible to address my concern while also extending support
for non-HTML attributes like :textarea. However, they still are
distinct things. For instance, it's possible that extending support for
:textarea is considered a feature request (as opposed to a bug), and
thus that support is added to the main branch as opposed to bugfix.
> As a bonus, it will be possible to factor out common code handling
> attributes (including :textarea) into a new internal function that can
> then be reused.
No disagreement here.
> Yup. But since you are asking to add new features to ox-html, we may
> as well do it in full (support all attributes, including special
> attributes).
I believe, that's perhaps the core of the disagreement. To me the
request isn't about adding new features (though it's /related/ to a more
general feature request that you seem to be considering), but about
resolving what I consider a buggy behaviour.
>> Additionally, I consider the absence of such support to be a bug.
>
> Since we do not promise it anywhere, it is not necessarily a bug.
We also don't, as far as I am aware, mention that support for
#+ATTR_HTML is ONLY available for some AST nodes and NOT others. Given
that for the treatment of :textarea we are very clear on this point, the
fact that we don't for #+ATTR_HTML suggested to me that this was a bug.
I suppose it's debatable, however, whether it's a bug in the
documentation or the code. But, given most (all?) HTML elements support
attributes, it would be odd if the intent of ox-html was to provide a
way to support it via #+ATTR_HTML while simultaneously /intentionally/
restricting its use to only a few nodes. Since `:textarea' is a "custom"
attribute with special signifance, it makes sense that support for it
may be limited in scope.
Do you still consider this to be a feature request instead of a bug?
--
Suhail
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 18:45 ` Suhail Singh
@ 2024-07-22 19:10 ` Ihor Radchenko
2024-07-22 19:35 ` Suhail Singh
0 siblings, 1 reply; 14+ messages in thread
From: Ihor Radchenko @ 2024-07-22 19:10 UTC (permalink / raw)
To: Suhail Singh; +Cc: TEC, Org mailing list
Suhail Singh <suhailsingh247@gmail.com> writes:
>> So, if we start allowing arbitrary attributes in more blocks, may as
>> well include specially handled attributes like :textarea.
>
> Yes, it is possible to address my concern while also extending support
> for non-HTML attributes like :textarea. However, they still are
> distinct things. For instance, it's possible that extending support for
> :textarea is considered a feature request (as opposed to a bug), and
> thus that support is added to the main branch as opposed to bugfix.
FYI, regardless how we categorize this (bug or feature), it is not for
bugfix because we are changing the existing behavior. Some users might
have #+ATTR_HTML being present and ignored. Not ignoring them, even if
it is a bug fix, is not acceptable for bugfix branch - it is not a
_trivial_ bug fix. So, it has to go on main.
>> Since we do not promise it anywhere, it is not necessarily a bug.
>
> We also don't, as far as I am aware, mention that support for
> #+ATTR_HTML is ONLY available for some AST nodes and NOT others. Given
> that for the treatment of :textarea we are very clear on this point, the
> fact that we don't for #+ATTR_HTML suggested to me that this was a bug.
> I suppose it's debatable, however, whether it's a bug in the
> documentation or the code. But, given most (all?) HTML elements support
> attributes, it would be odd if the intent of ox-html was to provide a
> way to support it via #+ATTR_HTML while simultaneously /intentionally/
> restricting its use to only a few nodes. Since `:textarea' is a "custom"
> attribute with special signifance, it makes sense that support for it
> may be limited in scope.
>
> Do you still consider this to be a feature request instead of a bug?
AFAIU, your main point is that you want the patch to land on bugfix. It
will not, regardless whether we add :textarea support or not.
Next, if you are not interested in adding :textarea support, it is
OK. Adding #+ATTR_HTML support for code blocks and fixed width elements
will still be a welcome improvement (I was just hoping to push you to
contribute a bit more ;))
Now, back to your original patch.
May you please factor out adding attributes into a separate function, so
that we avoid duplicating the code? And please announce the change in
the news - people aware of the current behavior might need to know about
the change.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 19:10 ` Ihor Radchenko
@ 2024-07-22 19:35 ` Suhail Singh
2024-07-22 19:49 ` Ihor Radchenko
2024-09-02 13:03 ` Suhail Singh
0 siblings, 2 replies; 14+ messages in thread
From: Suhail Singh @ 2024-07-22 19:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Suhail Singh, TEC, Org mailing list
Ihor Radchenko <yantar92@posteo.net> writes:
> AFAIU, your main point is that you want the patch to land on bugfix. It
> will not, regardless whether we add :textarea support or not.
While not the answer I had hoped for, I appreciate the clarification.
> Next, if you are not interested in adding :textarea support, it is
> OK. Adding #+ATTR_HTML support for code blocks and fixed width elements
> will still be a welcome improvement (I was just hoping to push you to
> contribute a bit more ;))
>
> Now, back to your original patch.
> May you please factor out adding attributes into a separate function, so
> that we avoid duplicating the code? And please announce the change in
> the news - people aware of the current behavior might need to know about
> the change.
Given that I already have some contributions in Org mode and I don't, at
present, intend to do the copyright assignment to FSF, could you please
confirm:
1. How many lines worth of changes I can still introduce without going
over the limit?
2. When implementing such refactoring changes, which lines are counted?
From a feasibility perspective, I suspect it might be better for you (or
someone else who's signed the FSF copyright assignment paperwork) to
take on the work of applying changes that are similar in spirit to the
patch.
--
Suhail
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 19:35 ` Suhail Singh
@ 2024-07-22 19:49 ` Ihor Radchenko
2024-07-22 20:05 ` Suhail Singh
2024-09-02 13:03 ` Suhail Singh
1 sibling, 1 reply; 14+ messages in thread
From: Ihor Radchenko @ 2024-07-22 19:49 UTC (permalink / raw)
To: Suhail Singh; +Cc: TEC, Org mailing list
Suhail Singh <suhailsingh247@gmail.com> writes:
> Given that I already have some contributions in Org mode and I don't, at
> present, intend to do the copyright assignment to FSF, could you please
> confirm:
>
> 1. How many lines worth of changes I can still introduce without going
> over the limit?
I do not see any commits under "suhailsingh247@gmail.com" or under
"Suhail Singh".
Commits under similar names are:
Suhail 96eb9f0b4 * piem/s/org-lint-add-function-to-removeJun6 org-lint: Add function to remove checker(s)
Suhail Shergill 3b2abfce7 * bugfix: fix `org-babel-execute-src-block' on remote hosts
Suhail Shergill 28582bfa0 * org-html.el: Make footnotes unique to an entry
Utkarsh Singh e62618508 * org-table.el: Fix usage of user-error
Utkarsh Singh 7c99d1555 * org-table.el: Allow to import files with no .txt, .tsv or .csv
I assume that 96eb9f0b4 is yours.
It has 9 LOC.
~6LOC remaining until aproximate 15LOC limit we can accept without
copyright assignment.
> 2. When implementing such refactoring changes, which lines are counted?
More or less all lines, except things like blank lines, query replace,
or copy-pasted code (or, in other words, trivial changes)
> From a feasibility perspective, I suspect it might be better for you (or
> someone else who's signed the FSF copyright assignment paperwork) to
> take on the work of applying changes that are similar in spirit to the
> patch.
Maybe, but that's a subject of my time and priorities.
This particular bug/feature request will not be high in the priority
list. Unless we get more users jumping to this thread and asking for
#+ATTR_HTML support.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 19:49 ` Ihor Radchenko
@ 2024-07-22 20:05 ` Suhail Singh
0 siblings, 0 replies; 14+ messages in thread
From: Suhail Singh @ 2024-07-22 20:05 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Suhail Singh, TEC, Org mailing list
Ihor Radchenko <yantar92@posteo.net> writes:
> Commits under similar names are:
>
> Suhail 96eb9f0b4 * piem/s/org-lint-add-function-to-removeJun6 org-lint: Add function to remove checker(s)
> ...
>
> I assume that 96eb9f0b4 is yours.
> It has 9 LOC.
Yes.
> ~6LOC remaining until aproximate 15LOC limit we can accept without
> copyright assignment.
Noted, thanks. With comments, documentation etc. this will go over the
limit, so I won't be sending any revisions to the patch.
>> 2. When implementing such refactoring changes, which lines are counted?
>
> More or less all lines, except things like blank lines, query replace,
> or copy-pasted code (or, in other words, trivial changes)
Understood.
>> From a feasibility perspective, I suspect it might be better for you (or
>> someone else who's signed the FSF copyright assignment paperwork) to
>> take on the work of applying changes that are similar in spirit to the
>> patch.
>
> Maybe, but that's a subject of my time and priorities.
> This particular bug/feature request will not be high in the priority
> list. Unless we get more users jumping to this thread and asking for
> #+ATTR_HTML support.
Understandable.
--
Suhail
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
2024-07-22 19:35 ` Suhail Singh
2024-07-22 19:49 ` Ihor Radchenko
@ 2024-09-02 13:03 ` Suhail Singh
2024-09-07 18:10 ` Ihor Radchenko
1 sibling, 1 reply; 14+ messages in thread
From: Suhail Singh @ 2024-09-02 13:03 UTC (permalink / raw)
To: Suhail Singh; +Cc: Ihor Radchenko, TEC, Org mailing list
Suhail Singh <suhailsingh247@gmail.com> writes:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Next, if you are not interested in adding :textarea support, it is
>> OK. Adding #+ATTR_HTML support for code blocks and fixed width elements
>> will still be a welcome improvement (I was just hoping to push you to
>> contribute a bit more ;))
>>
>> Now, back to your original patch.
>> May you please factor out adding attributes into a separate function, so
>> that we avoid duplicating the code? And please announce the change in
>> the news - people aware of the current behavior might need to know about
>> the change.
>
> Given that I already have some contributions in Org mode and I don't, at
> present, intend to do the copyright assignment to FSF, ...
>
> From a feasibility perspective, I suspect it might be better for you (or
> someone else who's signed the FSF copyright assignment paperwork) to
> take on the work of applying changes that are similar in spirit to the
> patch.
I was checking up to see what the current status of this issue was when
I noticed that it doesn't show up in the "Woof!" tracker as I would
expect. Both <https://tracker.orgmode.org/bugs?search=attr_html> and
<https://tracker.orgmode.org/requests?search=attr_html> don't yield any
results, though <https://tracker.orgmode.org/patches?search=attr_html>
does. Are patches not allowed to be bugs or requests as well?
--
Suhail
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-09-07 19:46 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-18 2:55 [PATCH] [BUG] Support attr_html in source code and fixed-width blocks Suhail Singh
2024-06-18 15:33 ` Ihor Radchenko
2024-07-19 15:28 ` Suhail Singh
2024-07-22 13:49 ` Ihor Radchenko
2024-07-22 17:11 ` Suhail Singh
2024-07-22 18:13 ` Ihor Radchenko
2024-07-22 18:45 ` Suhail Singh
2024-07-22 19:10 ` Ihor Radchenko
2024-07-22 19:35 ` Suhail Singh
2024-07-22 19:49 ` Ihor Radchenko
2024-07-22 20:05 ` Suhail Singh
2024-09-02 13:03 ` Suhail Singh
2024-09-07 18:10 ` Ihor Radchenko
2024-09-07 19:45 ` Suhail Singh
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).