emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Suhail Singh <suhailsingh247@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Suhail Singh <suhailsingh247@gmail.com>,
	 TEC <orgmode@tec.tecosaur.net>,
	 Org mailing list <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks
Date: Mon, 22 Jul 2024 14:45:06 -0400	[thread overview]
Message-ID: <87cyn52rm5.fsf@gmail.com> (raw)
In-Reply-To: <87a5i9mh19.fsf@localhost> (Ihor Radchenko's message of "Mon, 22 Jul 2024 18:13:22 +0000")

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


  reply	other threads:[~2024-07-22 18:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cyn52rm5.fsf@gmail.com \
    --to=suhailsingh247@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=orgmode@tec.tecosaur.net \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).