From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.devel Subject: Re: Emacs as word processor Date: Sat, 23 Nov 2013 14:42:34 +0100 Organization: Informatimago Message-ID: <87bo1bw7xx.fsf@informatimago.com> References: <5288A59E.7030109@dancol.org> <87vbzqfgd6.fsf@uwakimon.sk.tsukuba.ac.jp> <87mwl04w3k.fsf@zigzag.favinet> <87iovo4caz.fsf@zigzag.favinet> <877gc14vzs.fsf@zigzag.favinet> <878uwhxnqe.fsf@informatimago.com> <83txf4cw9z.fsf@gnu.org> <416D7143-AE4A-45FF-A3A3-AA208D268D97@informatimago.com> <83hab4ce1o.fsf@gnu.org> <87vbzkvyiz.fsf@informatimago.com> <83bo1bcysn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1385214236 10844 80.91.229.3 (23 Nov 2013 13:43:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Nov 2013 13:43:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 23 14:44:02 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 1VkDVB-0001Io-Bj for ged-emacs-devel@m.gmane.org; Sat, 23 Nov 2013 14:44:01 +0100 Original-Received: from localhost ([::1]:43712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkDVA-0006Ls-Ts for ged-emacs-devel@m.gmane.org; Sat, 23 Nov 2013 08:44:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkDV3-0006DE-CF for emacs-devel@gnu.org; Sat, 23 Nov 2013 08:43:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkDUv-0007I9-6w for emacs-devel@gnu.org; Sat, 23 Nov 2013 08:43:53 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:43577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkDUu-0007Ho-Sl for emacs-devel@gnu.org; Sat, 23 Nov 2013 08:43:45 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VkDUs-0001Ao-Fl for emacs-devel@gnu.org; Sat, 23 Nov 2013 14:43:42 +0100 Original-Received: from 90.24.199.117 ([90.24.199.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Nov 2013 14:43:42 +0100 Original-Received: from pjb by 90.24.199.117 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Nov 2013 14:43:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 135 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 90.24.199.117 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:MTkyNjk1MTk1NWI4NmMxOGFhODhkZmI0NzZjMjk5MzA2NDY2NGQ0OQ== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:165615 Archived-At: Eli Zaretskii writes: >> From: "Pascal J. Bourguignon" >> Date: Fri, 22 Nov 2013 23:53:40 +0100 >> >> Eli Zaretskii writes: >> >> >> From: "Pascal J. Bourguignon" >> >> Date: Fri, 22 Nov 2013 22:06:23 +0100 >> >> Cc: emacs-devel@gnu.org >> >> >> >> My point is that WYSIWIG doesn't mean anything when you don't consider an "external" medium. >> > >> > I cannot disagree more. The main features of a document change very >> > little with paper size changes. >> >> The structure of the document doesn't change (it's mostly unrelated to >> the presentation or layout). But the layout of the document depends >> obviously on the target medium. > > The layout depends on the medium in very minor ways, as long as we are > talking about the "usual" page sizes. If what you have in mind is A3 > paper or greeting cards, then the layout is indeed greatly affected, > but that's taking the issue to its extreme. > > IOW, WYSIWYG is much more than just layout. > >> So I persist, WYSIWIG = target medium representation. > > And I insist that this is a myopic view of WYSIWYG. > >> If you don't specify target medium representation, then you don't need >> WYSIWIG. > > Entirely wrong. > > You seem to think that visual appearance of the text itself is not an > important part of WYSIWYG. Nothing can be farther from truth. > >> What I'm asking, is what you do once the user specified a DTD containing >> elements such as: , and ? How do you edit them? > > I have no idea what these are or why would the user need to edit them. Exactly my point. The user specified as a structuring element for his kind of documents, and you and emacs don't know what it means, and how it should represented in a WYSIWIG way and how it should be manipulated from a WYSIWIG view. Nonetheless, a structure editor can edit them, adding nodes and childrens, as specified by the user-supplied DTD. That's why it seems obvious to me, once we've specified that we allowed users to supply their own DTD, that we need to provide an explicit set of commands to edit the structure of the document, in additionnal to the usual text editing command set translated to usual structure editing. >> >> We'd have to disable removing truncate-lines mode >> > >> > What? why?? >> >> Because otherwise it's not WYSIWIG anymore: without truncate-lines, the >> lines are flowed and are not displayed anymore like they appear on the >> printed page. >> >> >> > And why are you talking about truncate-lines, when Emacs has word-wrap >> > for quite some time now? >> >> I'm not sure what you mean by word-wrap exactly? > > "C-h v word-wrap RET" will tell you. "This variable has no effect if long lines are truncated (see" And this is not a WYSIWIG feature, since it changes the layout depending on the width of the emacs window, instead of depending on the width of the page set up. >> - open some text file. >> - M-x set-fill-column RET 40 RET -- characters not 12.5 cm! >> - C-x h M-x set-justification-left RET >> - reduce the width of the frame or window to 30 characters wide. >> >> Without truncate-line mode, each line is wrapped over, which is not >> WYSIWIG. >> >> With M-x visual-line-mode RET it's the same thing. > > So we need to add a feature whereby word-wrap happens at a fixed > column. That should be easy. Yes, if you think that word-wrap can be safely integrated into a word processor. But this is an implementation detail, why do you discuss it now? >> Type: M-x shell RET libreoffice RET >> Click on: Text document >> Type: Hello world! >> Select the paragraph, >> Click on the left margin knob above and move it 0.5 inch to the right. >> >> Notice how the page is represented, as a white rectangle, how the >> margins are represented as L shapes offset from the four corners, how >> rules are graphical representations with graphical graduations, >> unrelated to the font sizes, notice how scrolling occurs pixel by pixel, graphically. >> >> Select the word Hello, click on the style popup menu, select More…, >> scroll down and click on Vertical Numbering Symbols. >> >> Notice how the word Hello is rotated 90 degree counter clock wise. >> >> All those representations could not occur no a normal textual terminal: >> they are in essence graphical. > > Wrong. Text can be laid out vertically as well (if we decide that's > an important feature to have in Emacs) without treating it as a > picture. What about the drawing of the margins and other signs that don't occur in character cells? -- __Pascal Bourguignon__ http://www.informatimago.com/