From: Jean Louis <bugs@gnu.support> To: Stefan Kangas <stefankangas@gmail.com> Cc: 58774@debbugs.gnu.org, Ihor Radchenko <yantar92@posteo.net>, emacs-orgmode@gnu.org, "Dr. Arne Babenhauserheide" <arne_bab@web.de> Subject: 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/
WARNING: multiple messages have this Message-ID (diff)
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:21 UTC|newest] Thread overview: 94+ 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 19:56 ` Jean Louis 2022-10-25 21:54 ` Dr. Arne Babenhauserheide 2022-10-26 7:57 ` bug#58774: " Jean Louis 2022-10-26 7:57 ` Jean Louis 2022-10-26 11:55 ` bug#58774: " Dr. Arne Babenhauserheide 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 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:22 ` Andreas Schwab 2022-10-27 11:23 ` Dr. Arne Babenhauserheide 2022-10-27 11:23 ` Dr. Arne Babenhauserheide 2022-10-27 8:40 ` Jean Louis 2022-10-27 7:58 ` Andreas Schwab 2022-10-26 17:36 ` Jean Louis 2022-10-26 13:55 ` Andreas Schwab 2022-10-26 13:19 ` Jean Louis 2022-10-26 7:59 ` Jean Louis 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 8:24 ` Jean Louis 2022-10-26 20:22 ` indieterminacy 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 11:30 ` Dr. Arne Babenhauserheide 2022-10-26 13:15 ` Stefan Kangas 2022-10-26 13:15 ` Stefan Kangas 2022-10-26 6:52 ` Ihor Radchenko 2022-10-26 8:21 ` Jean Louis [this message] 2022-10-26 8:21 ` Jean Louis 2022-10-26 17:07 ` Max Nikulin 2022-10-26 17:07 ` Max Nikulin 2022-10-26 18:37 ` Jean Louis 2022-10-26 18:37 ` Jean Louis 2022-10-26 21:16 ` Dr. Arne Babenhauserheide 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 21:56 ` indieterminacy 2022-10-26 20:00 ` Tim Cross 2022-10-26 6:07 ` 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-26 13:42 ` Jean Louis 2022-10-27 4:55 ` Jean Louis 2022-10-27 4:55 ` Jean Louis 2022-10-27 11:13 ` bug#58774: " Dr. Arne Babenhauserheide 2022-10-27 11:13 ` Dr. Arne Babenhauserheide 2022-10-27 17:41 ` bug#58774: " Jean Louis 2022-10-27 17:41 ` Jean Louis 2022-10-27 21:43 ` bug#58774: " Dr. Arne Babenhauserheide 2022-10-27 21:43 ` Dr. Arne Babenhauserheide 2022-10-27 15:35 ` bug#58774: " Max Nikulin 2022-10-27 15:35 ` Max Nikulin 2022-10-27 17:58 ` Jean Louis 2022-10-27 17:58 ` Jean Louis 2022-10-27 21:49 ` Dr. Arne Babenhauserheide 2022-10-27 21:49 ` Dr. Arne Babenhauserheide 2022-10-27 18:25 ` Jean Louis 2022-10-27 18:25 ` Jean Louis 2022-10-27 19:53 ` Quiliro Ordóñez 2022-10-27 19:53 ` Quiliro Ordóñez 2022-10-27 19:58 ` Quiliro Ordóñez 2022-10-27 19:58 ` Quiliro Ordóñez 2022-10-27 21:57 ` Dr. Arne Babenhauserheide 2022-10-27 21:57 ` Dr. Arne Babenhauserheide 2022-10-27 22:18 ` Jean Louis 2022-10-27 22:18 ` Jean Louis 2022-10-27 23:14 ` Dr. Arne Babenhauserheide 2022-10-27 23:14 ` Dr. Arne Babenhauserheide 2022-10-27 23:20 ` Ihor Radchenko 2022-10-27 23:20 ` Ihor Radchenko 2022-10-28 8:28 ` Dr. Arne Babenhauserheide 2022-11-02 4:09 ` Ihor Radchenko 2022-11-02 4:09 ` Ihor Radchenko 2022-10-28 8:28 ` Dr. Arne Babenhauserheide 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 * 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: linkBe 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.