* Tim Cross <theophil...@gmail.com> [2020-11-25 23:54]: > I guess this is probably the main point where we disagree. > > Emacs is first and foremost a programmers editor. It was never designed > as a general purpose editor, but rather specifically as an editor for > programmers.
Yes. And when I was born as baby I was designed for milk, not for typing, times change. People use GNU/Linux and Emacs is not advertised as programmers or exclusively programmers editor. Some other editors are advertised that way. So think how many hundreds of thousands of users are working with Emacs. Here is how Debian GNU/Linux describes it: https://packages.debian.org/buster/emacs If there are 10 programmers there are probably 100 if not 500 non-programmers. > If you jump into a formula 1 race car, you would find it almost > impossible to drive. The gearbox would be unfamiliar and difficult to > use, the clutch would be difficult to use etc. If you got it going, you > would have a high likelihood of crashing. Luckily, you would probably > just stall and get nowhere. > > Is this the fault of the design of the race car or the driver? Race cars are not distributed through GNU/Linux operating systems and are not easily downloadable by everybody, in general, they are also expensive. While it all sounds entertaining, Emacs is not a race car. And we cannot say to users not to use it if they are not Formula One Drivers. > With respect to your email example, the number of people who are exposed > is even less - it is really only those who are using it in the same > manner as you. That is, where they have configured their mail client > (such as Mutt) to use Emacs as the external editor. None of the Emacs > mail clients I have used do this (this includes VM, mu4e, gnus, > wonderlust and mew). I do not need to use Emacs with Mutt to invoke local variables. I can get files by any means and by any opening of the file with Emacs it will be invoked. Somebody could send me file to download and open. File can come from anywhere, it is not Mutt related really. Gnus buffers and email clients do not invoke local variables and that is fine. But security issue is not email centric, but file centric. > anyone who has gone to the effort to configure their mail system to use > an external editor and who then answers yes to the statement > "...contains values that may not be safe. Do you want to apply it?" is > someone with inherently unsafe practices. That is very rigid assumption. People set editors for various email clients since decades. Try to think from another people's view points. Here is example: https://stackoverflow.com/questions/15865495/opening-a-file-in-emacs-values-that-are-not-safe That person has quite different view point. Person asks "Why it would not be safe?" and one should know when one person writes there for an answer there are probably thousand other persons who did not write for the answer. Other person asked: "Thanks, that's very helpful. Why would a file (i.e. the author of the file) require or ask Emacs to apply configuration values when just opening/visiting the file? – Amelio Vazquez-Reina" I know why, but people using Emacs are asking why. Many will not ask and will say, damn YES, as I feel safe! Denial of Service Attacks possible: https://github.com/aquamacs-emacs/aquamacs-emacs/issues/147 https://gitmemory.com/issue/davidswelt/aquamacs-emacs/147/478196367 .emacs considered not safe: https://www.cs.ait.ac.th/~on/O/oreilly/tcpip/puis/ch11_05.htm OK then now back to Org discussions. Jean
