unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: 58774@debbugs.gnu.org, emacs-orgmode@gnu.org
Subject: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly
Date: Thu, 27 Oct 2022 20:41:10 +0300	[thread overview]
Message-ID: <Y1rCtmEOOwhvCNB3@protected.localdomain> (raw)
In-Reply-To: <87wn8lpl2p.fsf@web.de>

* Dr. Arne Babenhauserheide <arne_bab@web.de> [2022-10-27 14:23]:
> 
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Jean Louis <bugs@gnu.support> [2022-10-25 15:14]:
> >> 
> >> This wish request is related to Emacs EWW and Org mode.
> >> 
> >> Please make EWW recognize Org file when served by WWW server. Currently
> >> it does not recognize the MIME type text/x-org and opens the file as
> >> text, it does not invoke the org mode. In my opinion, it should.
> >
> > Now is clear that main problem here is that Org advertises somewhere
> > to be "text" in MIME context, while it is not, it is by default
> > "application" and thus unsafe, see:
> >
> > Application Media Types
> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
> >
> > and understand difference to:
> >
> > Text Media Types
> > https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1
> >
> > Thus I suggest that Org changes its MIME type and stop falsely
> > claiming to be "text" in MIME context, but that content type:
> > "application/x-org" become adopted, as that way it will become clear
> > that it is unsafe opening Org as falsely claimed "plain" text.
> 
> You are mixing up text/plain and text/*. Orgmode is clearly text/* but
> not text/plain. From your link:

How do I mix it?

>    Beyond plain text, there are many formats for representing what might
>    be known as "rich text".  An interesting characteristic of many such
>    representations is that they are to some extent readable even without
>    the software that interprets them.  It is useful to distinguish them,
>    at the highest level, from such unreadable data as images, audio, or
>    text represented in an unreadable form.  In the absence of
>    appropriate interpretation software, it is reasonable to present
>    subtypes of "text" to the user, while it is not reasonable to do so
>    with most non-textual data.  Such formatted textual data can be
>    represented using subtypes of "text".

Org is not just rich text for reason as explained here:
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5 so I
suggest reading it.

Examples of content types for some "rich" text formats:

.odt 	OpenDocument text document
application/vnd.oasis.opendocument.text

.rtf 	Rich Text Format (RTF) 	application/rtf

.xhtml 	XHTML 	application/xhtml+xml

xml 	XML 	application/xml is recommended as of RFC 7303 (section
4.1), but text/xml is still used sometimes. You can assign a specific
MIME type to a file with .xml extension depending on how its contents
are meant to be interpreted. For instance, an Atom feed is
application/atom+xml, but application/xml serves as a valid default.

Review definition of "application/*" type.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/





  reply	other threads:[~2022-10-27 17:41 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 12:06 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly Jean Louis
2022-10-25 15:02 ` Dr. Arne Babenhauserheide
2022-10-25 19:56   ` bug#58774: " Jean Louis
2022-10-25 21:54     ` Dr. Arne Babenhauserheide
2022-10-26  7:57       ` bug#58774: " Jean Louis
2022-10-26 11:55         ` Dr. Arne Babenhauserheide
2022-10-26 12:20           ` Jean Louis
2022-10-26 12:45             ` bug#58774: " Andreas Schwab
2022-10-26 13:19               ` Jean Louis
     [not found]               ` <Y1kz5PKQh1SMr1BO@protected.localdomain>
2022-10-26 13:55                 ` Andreas Schwab
     [not found]                 ` <mvmh6zqadu9.fsf@suse.de>
2022-10-26 17:36                   ` Jean Louis
     [not found]                   ` <Y1lwNABImLQnQojU@protected.localdomain>
2022-10-27  7:58                     ` Andreas Schwab
     [not found]                     ` <mvma65hae9p.fsf@suse.de>
2022-10-27  8:40                       ` Jean Louis
     [not found]                       ` <Y1pD/h1INh3457ou@protected.localdomain>
2022-10-27 11:22                         ` Andreas Schwab
2022-10-27 11:23                         ` Dr. Arne Babenhauserheide
2022-10-26  7:59       ` Jean Louis
2022-10-25 23:03   ` Ihor Radchenko
2022-10-26  6:07     ` bug#58774: " Stefan Kangas
     [not found]     ` <CADwFkm=zOc6K6=eOa_WgXrnnpCRa47wKHeB+yfDM4Q0Fjzjd8A@mail.gmail.com>
2022-10-26  6:52       ` Ihor Radchenko
2022-10-26  8:21       ` Jean Louis
2022-10-26 17:07         ` Max Nikulin
2022-10-26 18:37           ` Jean Louis
2022-10-26 21:16             ` Dr. Arne Babenhauserheide
2022-10-26 21:56             ` indieterminacy
     [not found]       ` <87zgdjoz3r.fsf@localhost>
2022-10-26  8:24         ` Jean Louis
2022-10-26 20:22           ` indieterminacy
2022-10-26 11:30         ` Dr. Arne Babenhauserheide
2022-10-26 13:15         ` Stefan Kangas
2022-10-25 22:13 ` Ag Ibragimov
2022-10-26  8:28   ` Jean Louis
2022-10-26 13:00     ` Rudolf Adamkovič
2022-10-26 13:42       ` bug#58774: " Jean Louis
2022-10-27  4:55 ` Jean Louis
2022-10-27 11:13   ` Dr. Arne Babenhauserheide
2022-10-27 17:41     ` Jean Louis [this message]
2022-10-27 21:43       ` Dr. Arne Babenhauserheide
2022-10-27 15:35   ` Max Nikulin
     [not found]   ` <d8bead8c-f97d-1de5-ae06-df81fefb7389@gmail.com>
2022-10-27 17:58     ` Jean Louis
2022-10-27 21:49       ` Dr. Arne Babenhauserheide
2022-10-27 18:25     ` Jean Louis
2022-10-27 19:53       ` Quiliro Ordóñez
2022-10-27 19:58       ` Quiliro Ordóñez
2022-10-27 21:57     ` Dr. Arne Babenhauserheide
     [not found]     ` <87y1t0or6q.fsf@web.de>
2022-10-27 22:18       ` Jean Louis
     [not found]       ` <Y1sD0bXYnDCY2Yw4@protected.localdomain>
2022-10-27 23:14         ` Dr. Arne Babenhauserheide
2022-10-27 23:20       ` Ihor Radchenko
     [not found]       ` <87zgdgn9av.fsf@localhost>
2022-10-28  8:28         ` Dr. Arne Babenhauserheide
     [not found]         ` <87h6zony3p.fsf@web.de>
2022-11-02  4:09           ` Ihor Radchenko
2023-09-02  8:53 ` Stefan Kangas

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.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=Y1rCtmEOOwhvCNB3@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=58774@debbugs.gnu.org \
    --cc=arne_bab@web.de \
    --cc=emacs-orgmode@gnu.org \
    /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.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).