bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#68687: [PATCH] Use text/org media type


From: Eli Zaretskii
Subject: bug#68687: [PATCH] Use text/org media type
Date: Tue, 30 Jan 2024 14:52:16 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]