From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Fri, 22 Nov 2013 20:18:09 +0200 Message-ID: <83k3g0cnby.fsf@gnu.org> References: <2013-11-22T16-27-58@devnull.Karl-Voit.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1385144297 7825 80.91.229.3 (22 Nov 2013 18:18:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 18:18:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: news1142@Karl-Voit.at Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 19:18:21 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VjvJ5-0001OG-Mo for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 19:18:19 +0100 Original-Received: from localhost ([::1]:40456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjvJ5-0000iI-8u for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 13:18:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjvIx-0000i5-Td for emacs-devel@gnu.org; Fri, 22 Nov 2013 13:18:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjvIr-0002Rt-Gn for emacs-devel@gnu.org; Fri, 22 Nov 2013 13:18:11 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:61926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjvIr-0002Rf-90 for emacs-devel@gnu.org; Fri, 22 Nov 2013 13:18:05 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWO00300G243900@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 22 Nov 2013 20:18:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWO00277G63ZP50@a-mtaout22.012.net.il>; Fri, 22 Nov 2013 20:18:03 +0200 (IST) In-reply-to: <2013-11-22T16-27-58@devnull.Karl-Voit.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165573 Archived-At: > From: Karl Voit > Date: Fri, 22 Nov 2013 17:19:34 +0100 > > First of all, I claim that WYSIWYG has issues of its own. Please do > read [1]. I admit, that this text is very old but the key points are > still valid. Most people I know who know WYSIWYG *and* their > alternatives are not always very happy with using WYSIWYG. So why > follow this path which is know to be faulty? Because it is not necessarily faulty. That document presents a point of view. Some will agree with it, some won't. Emacs is not about forcing one particular POV on its users. Quite the contrary, it's about giving them as much freedom as possible to do things their way. > Second, there are technical issues I do see. GNU/Emacs lacks a *lot* > in terms of GUI widget-set. Yes, I do believe that ribbons are > better[2] than menus for WYSIWYG tools but it's not only ribbons > that are missing. Users of WYSIWYG-tools are heavily using buttons > (mainly) and menu items (seldom) as studies show. This is not the > way GNU/Emacs is working. The button bar is very static. Not every > functionality is reachable via menu bar. Besides, menu bars got the > severe issue mentioned in [2][3] and we should do better than this. Yes, the job at hand is not small. But does that mean we shouldn't take steps in that direction? I hope not. > Third, there is a huge difference in the typical group of GNU/Emacs > users and WYSIWYG-tool-users. GNU/Emacs users are happy to learn > keyboard shortcuts, tweak their environment to meet their > requirements, want to have absolutely control on what the computer > is doing, and so forth. It is a group of geeks[4] who is willing to > spend a certain time learning stuff in order to get a life-time > benefit. > > On the other side, typical WYSIWYG-users just want to get the thing > done without even thinking of investing some time into learning a > tool that might offer the same. Please do not misinterpret me: this > is completely fine for many cases. I am oversimplifying a bit but > this is how the situation is to me. I gave many talks, workshops, > did one-to-one teaching, talked to other geeks and non-geeks in > order to promote the best tool for each job. Sometimes it is a > WYSIWYG-tool I recommend, sometimes it is a power-tool like > GNU/Emacs. > > Maybe I lack a huge amount of fantasy here but I don't think that > GNU/Emacs is going to be used by Joe Average who has no special IT > knowledge when there are alternative tools like Microsoft Word or > LibreOffice. We want to attract Joe Average's. But what we want more is to give Emacs geeks a way to compose document in WYSIWYGy fashion. > Besides: if you want to attract non-geeks, prepare that they will > complain that there is no suitable support, that they do not want to > use mailing-lists or usenet (they prefer something which is called > Web Forum), and so forth. Let them complain, we've heard those complaints for many years and didn't care. But why shouldn't someone like RMS be able to compose a simple document without switching to LibreOffice or whatnot? There's no excuse for that. > For the typical GNU/Emacs user, there are alternatives that result > in results they are happy to live with: AucTeX/LaTeX, Org-mode [5], > or even LibreOffice. For a devoted Emacs user, an Emacs solution will always blow any 3rd-party solution out of the water. That's why there's Org mode, Gnus, Flymake, GUD, Flyspell, etc., even though alternatives to each one of these exist, and some of them might even be better/more sophisticated/whatever than what Emacs has to offer in these areas.