From: Jean Louis <bugs@gnu.support>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Ihor Radchenko <yantar92@posteo.net>,
"Dr. Arne Babenhauserheide" <arne_bab@web.de>,
58774@debbugs.gnu.org, emacs-orgmode@gnu.org
Subject: Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly
Date: Wed, 26 Oct 2022 11:21:10 +0300 [thread overview]
Message-ID: <Y1jt9vLO7yb597zj@protected.localdomain> (raw)
In-Reply-To: <CADwFkm=zOc6K6=eOa_WgXrnnpCRa47wKHeB+yfDM4Q0Fjzjd8A@mail.gmail.com>
* Stefan Kangas <stefankangas@gmail.com> [2022-10-26 09:08]:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
> > The "problem" with shell links you are describing is a question of
> > setting variables and is also disabled by default.
> >
> > eww-mode, when loading Org page, could simply set
> > org-link-shell-confirm-function to its default value.
>
> Note that with the suggested feature, any link you follow risks being
> loaded in Org mode, before the user even has a chance to inspect the
> file.
See my previous e-mail to Arne and explanation that in almost any
browser, it is user's choice on how to open various content types.
It implies, there are numerous risks involved, and users customizing
their browsers have responsibility for their computing.
Does user need group of people to dictate what is safe and what is not
safe? That is contrary to free software principles, let users decide
how they wish to open their files.
I maybe have Common Lisp on my server and wish to open it with SBLC on
my computer. That is my choice.
Let me have that choice in EWW, which is native to Emacs for Org mode,
which is native to Emacs. It is natural.
Note that I can open Org files with other browser. But I wish to
browse my Org notes directly from within Emacs , and not just invoke
external browser, which in turn invokes again `emacsclient'. That
works well already. I hope you understand it.
> Which Org features, currently existing or introduced in the
> future, would EWW have to add workarounds for?
Only to recognize content type text/x-org and invoke Org mode. And let
users decide if to invoke org mode on content type "text/x-org".
I am even now convinced that I should be able to customize how to open
various content types, but I do not get it.
I was thinking eww will recognize at least mailcap file, as in email
client I open Org files without problems.
I see in eww.el that there is function `mailcap-view-mime' but I do
not see it is used to recognize my mailcap file where I have this
line:
text/x-org; edit %s; nametemplate=%s.org;
my "edit" script invokes emacsclient
> It is very hard to foresee which parts of Org will be problematic and
> have to be disabled. See the security vulnerability in enriched-mode
> that prompted the release of Emacs 25.3, for example.
There is no need to disable anything by default please, leave that to
user choice.
I can open ALL kinds of files from WWW servers and decide how to open
them. That was since beginning of Internet user's choice. It is not
up to browser to tell me I should not open specific content type, or
for browser to disable how I view or use the file.
- EWW is browser
- it shall recognize content-type
- it shall then invoke ANY application by users' choice for that
content-type
Maybe I wish to open text/x-org with mousepad editor, so let me do
that. Maybe I wish to invoke different Emacs instance, let me do
that. If I wish to isolate the Emacs instance I can isolate it
without problems, but that shall be my users' choice.
Sample method of isolation of browser on single computer:
(defun browse-safe-url (url &optional arg)
"Browse URL with b"
(let ((username "joedoe")) ;; different username than my own
;; Insecurity settings for personal DISPLAY only
(shell-command "xhost +")
;; Browse URL with different username
(async-start-process "sudo" "sudo" nil "su" "-c" "--" username "-c"
(format "exec iceweasel \"%s\"" url))))
> Adding this opens a can of worms that will expose unsuspecting users to
> a whole class of new problems.
It does not.
Review well customization of content types on various browsers, it
existed since beginning of WWW.
Browser is not for HTML only, there are many content types.
> And the only benefit is to sapve some users from having to type "M-x
> org-mode RET", or adding call to a suitable hook.
It is not only benefit. Every browser shall give option to users to
decide how to open any content type.
> All in all, this seems like a bad trade-off. So I don't think we should
> add such a feature.
What if I want to open Gnumeric spreadsheet with eww? You do not want
to add that feature?
Help me open Gnumeric spreadsheet by using eww and its content type by
customization, and I will not ask you to open Org by eww, because at
that point of time I will be able to customize how to open Org content
type myself.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
next prev parent reply other threads:[~2022-10-26 8:25 UTC|newest]
Thread overview: 53+ 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 ` Jean Louis
2022-10-25 21:54 ` Dr. Arne Babenhauserheide
2022-10-26 7:57 ` Jean Louis
2022-10-26 11:55 ` Dr. Arne Babenhauserheide
2022-10-26 12:20 ` Jean Louis
2022-10-26 12:45 ` Andreas Schwab
2022-10-26 13:19 ` bug#58774: " Jean Louis
2022-10-26 13:55 ` Andreas Schwab
2022-10-26 17:36 ` Jean Louis
2022-10-27 7:58 ` Andreas Schwab
2022-10-27 8:40 ` Jean Louis
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
2022-10-26 6:52 ` Ihor Radchenko
2022-10-26 8:24 ` Jean Louis
2022-10-26 20:22 ` indieterminacy
2022-10-26 11:30 ` Dr. Arne Babenhauserheide
2022-10-26 21:41 ` Tim Cross
2022-10-27 10:43 ` Dr. Arne Babenhauserheide
2022-10-26 13:15 ` Stefan Kangas
2022-10-26 8:21 ` Jean Louis [this message]
2022-10-26 17:07 ` Max Nikulin
2022-10-26 18:37 ` Jean Louis
2022-10-26 21:16 ` Dr. Arne Babenhauserheide
2022-10-27 4:25 ` tomas
2022-10-27 11:10 ` Dr. Arne Babenhauserheide
2022-10-26 21:56 ` indieterminacy
2022-10-26 20:00 ` Tim Cross
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
2022-10-27 21:43 ` Dr. Arne Babenhauserheide
2022-10-27 15:35 ` bug#58774: " Max Nikulin
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
2022-10-27 22:18 ` Jean Louis
2022-10-27 23:14 ` Dr. Arne Babenhauserheide
2022-10-27 23:20 ` Ihor Radchenko
2022-10-28 8:28 ` Dr. Arne Babenhauserheide
2022-11-02 4:09 ` Ihor Radchenko
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=Y1jt9vLO7yb597zj@protected.localdomain \
--to=bugs@gnu.support \
--cc=58774@debbugs.gnu.org \
--cc=arne_bab@web.de \
--cc=emacs-orgmode@gnu.org \
--cc=stefankangas@gmail.com \
--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).