From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: 68687@debbugs.gnu.org, manikulin@gmail.com,
emacs-orgmode@gnu.org, stefankangas@gmail.com
Subject: bug#68687: [PATCH] Use text/org media type
Date: Tue, 30 Jan 2024 14:52:16 +0200 [thread overview]
Message-ID: <86jznr2dbz.fsf@gnu.org> (raw)
In-Reply-To: <E1rUfF4-00069N-Gu@fencepost.gnu.org> (message from Richard Stallman on Mon, 29 Jan 2024 22:56:58 -0500)
> From: Richard Stallman <rms@gnu.org>
> Cc: manikulin@gmail.com, 68687@debbugs.gnu.org, emacs-orgmode@gnu.org,
> stefankangas@gmail.com
> Date: Mon, 29 Jan 2024 22:56:58 -0500
>
> I am concerned that the actions described above would tend to embed
> Org format and Org mode more deeply into Emacs usage.
>
> Suppose A and B are Org users. If A knows this, and mails B a message
> which contains text labaled as text/org, that won't make anyone
> unhappy. No one would have a reason to complain.
>
> But what if C mails a message to D with text labeled as text/org and D
> is not an Org user? Will that cause Emacs to load Org? It should
> not.
>
> What will Gnus do when the user readss a message with text labaled as
> text/org? What will Rmail do? What will MH-E do?
This happens to me all the time (because our mailing lists are full of
such C's, and I'm one example of D), so I know what happens, at least
in Rmail: you see the text with Org markup uninterpreted, as plain
text. Here's a random example:
#+begin_src emacs-lisp
(add-hook 'before-save-hook 'time-stamp)
(require 'org-refile)
(setq org-refile-use-cache t)
(setq org-refile-use-outline-path t)
(setq org-refile-targets '((nil :maxlevel . 5)))
(setq org-goto-interface 'outline-path-completion)
(setq large-file-warning-threshold 15000000)
(find-file "foo.org")
(org-refile-get-targets)
#+end_src
With Org, the header and footer should be removed from display, and
the Lisp code should be displayed with lisp-mode fontifications. What
I see is just plain text, including the pesky header and footer.
It isn't a catastrophe, IMO.
> These are crucial questions because the answers would determine
> whether this feature pressures people to use Org mode or not. We need
> concrete answers because only that would enable us to see cleary now
> whether the feature would do that if in use.
In any case, we already have this in the wild, it just uses
Content-type that current standards frown on. This proposal is just
to use a different, more standard-compliant Content-type.
next prev parent reply other threads:[~2024-01-30 12:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6d94fff4-4d30-4121-bfd1-f267cb5b637c@gmail.com>
[not found] ` <8734uqpvgn.fsf@tec.tecosaur.net>
2024-01-24 14:43 ` bug#68687: [PATCH] Use text/org media type Max Nikulin
2024-01-25 23:10 ` Stefan Kangas
2024-01-25 23:43 ` Ihor Radchenko
2024-01-26 7:23 ` Eli Zaretskii
2024-01-26 10:39 ` Max Nikulin
2024-01-26 12:22 ` Eli Zaretskii
2024-01-31 16:30 ` Max Nikulin
2024-01-27 3:38 ` Richard Stallman
[not found] ` <E1rTZWZ-0008Ca-EM@fencepost.gnu.org>
2024-01-28 16:35 ` Max Nikulin
2024-01-28 16:47 ` Eli Zaretskii
[not found] ` <8634uh5rrq.fsf@gnu.org>
2024-01-30 3:56 ` Richard Stallman
[not found] ` <E1rUfF4-00069N-Gu@fencepost.gnu.org>
2024-01-30 12:13 ` Ihor Radchenko
2024-01-30 17:12 ` bug#68687: Org mode code evaluation (was: bug#68687: [PATCH] Use text/org media type) Mike Kupfer
2024-01-30 17:51 ` Ihor Radchenko
[not found] ` <87mssmvhdw.fsf@localhost>
2024-02-02 3:38 ` Richard Stallman
2024-02-02 4:58 ` bug#68687: Org mode code evaluation Max Nikulin
2024-01-31 16:18 ` bug#68687: [PATCH] Use text/org media type Max Nikulin
[not found] ` <3c8e8b77-77d1-4522-85d5-5cce2cc020ca@gmail.com>
2024-01-31 16:32 ` Ihor Radchenko
2024-02-02 3:40 ` Richard Stallman
[not found] ` <E1rVkPO-0008LA-RN@fencepost.gnu.org>
2024-02-02 7:15 ` Eli Zaretskii
2024-01-30 12:52 ` Eli Zaretskii [this message]
[not found] ` <87h6j1f08d.fsf@localhost>
2024-01-26 7:40 ` Eli Zaretskii
2024-01-26 10:52 ` Max Nikulin
[not found] ` <86h6j0bl0m.fsf@gnu.org>
2024-01-26 14:00 ` Ihor Radchenko
2024-01-30 19:39 ` Stefan Kangas
[not found] ` <CADwFkm=9EwTZwa3F4wGJVPAVgcW4KXS1kPzXLPg1msYDjJL2cw@mail.gmail.com>
2024-01-30 20:34 ` Ihor Radchenko
2024-01-31 20:00 ` Stefan Kangas
2024-02-01 10:40 ` Max Nikulin
2024-02-02 7:09 ` Stefan Kangas
[not found] ` <CADwFkmknBZj0Y4H=Nwqa4sH0uQAsP70kWtMU33ZgfRiuWkX9_w@mail.gmail.com>
2024-02-02 16:28 ` bug#68687: [PATCH v2] " Max Nikulin
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=86jznr2dbz.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=68687@debbugs.gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=rms@gnu.org \
--cc=stefankangas@gmail.com \
/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).