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: Fri, 22 Nov 2013 23:53:40 +0100 Organization: Informatimago Message-ID: <87vbzkvyiz.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> 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 1385160896 2922 80.91.229.3 (22 Nov 2013 22:54:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 22:54:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 23:55: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 1Vjzcr-0004rK-Fo for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 23:55:01 +0100 Original-Received: from localhost ([::1]:41418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjzcr-0003BV-2j for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 17:55:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjzcj-0003Ae-Oh for emacs-devel@gnu.org; Fri, 22 Nov 2013 17:54:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vjzce-000512-HY for emacs-devel@gnu.org; Fri, 22 Nov 2013 17:54:53 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:45102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vjzce-00050y-2M for emacs-devel@gnu.org; Fri, 22 Nov 2013 17:54:48 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vjzcc-0004gl-NW for emacs-devel@gnu.org; Fri, 22 Nov 2013 23:54:46 +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 ; Fri, 22 Nov 2013 23:54:46 +0100 Original-Received: from pjb by 90.24.199.117 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Nov 2013 23:54:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 209 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:ZjMwMzBkNTMzZDkwNjgzMWM1YTkyNzM3YmY4YTZlNjc0ZjI3MTg5MA== 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:165585 Archived-At: 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. And the user of a WYSIWIG word processor uses the information provided by the layout output graphic view, to edit the text and structure of its document so it presents well. For example, if you have small sections that fit several on a page, you would use a style where they flow on a page. But if you have some bigger sections, you may rather choose a style where each section starts on its own page. And in both cases, you may have exceptions, and bad cases, such as the section that takes exactly one page and one line on the following page, followed by another section started on the next page. If that other section is bigger than one page, you may want to keep it starting on its own page, so you'll edit the first section so that it takes one line less and fit on one page. Switching to legal paper size is not an option, here all the paper pages are A4 size, this is the norm. :-) (Ok, an alternative would be to reduce the vertical margin, but this may open a can of worm in the rest of the document). So I persist, WYSIWIG = target medium representation. If you don't specify target medium representation, then you don't need WYSIWIG. You may just use a structure editor (perhaps enriched with fonts, bold and italic), and have a batch layout processor, eg. a web browser (modulo my remarks concerning the common use of fixed size web pages). >> >> - assign parenthesized tags to text ranges (in a hierarchical structure >> >> similar to SGML). >> > >> > Not sure what for. This is a solution to what problem? >> >> What I mean here is some kind of structured editing. >> >> To split a paragraph in two, we can admit the usual RET key. >> >> To split a section in two, we can admit the usual insertion of a section title. >> But already here, most probably the user will enter a new paragraph >> containing the section title, and then select it and apply a header >> "style". Well, it's not style, it's the specification of a section >> header tag to this text, and by inference, the spitting of the >> current section in two. >> >> Those two examples have conventional "width of the ass of the horse" >> user interfaces, for conventional pre-defined tags:
>> <para>. >> >> But with the introduction of XSL and DTD, the user can be allowed to >> edit documents with a structure not pre-wired, with tags having now >> pre-defined conventional user interface. >> >> Therefore we need a standard way to edit the document tree. > > I think you confuse user interface with implementation. I can easily > envision commands that insert a section header that don't need any > idea about the document tree. That's exactly what I've described above. What I'm asking, is what you do once the user specified a DTD containing elements such as: <xlorf>, <grlyb> and <ashur>? How do you edit them? >> >> - then for the WYSIWIG aspect, we'd need to implement a rendering >> >> engine. We have the basis with font faces, but more work is needed to >> >> give a WISIWIG representation of the page, and its computed layout. >> > >> > I think you underestimate the power and feature-richness of the >> > current Emacs display engine. We should try using it first, before we >> > decide that it is inadequate and should be replaced or significantly >> > changed. >> >> Perhaps. It's true that with truncate-lines mode, we'd get a a >> homothetic space, but can we adjust the height of the lines, can we >> adjust margins (to subpixel sizes). > > The former is possible today, the latter can be added (but I really > don't see a need). > >> 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? - 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. >> >> Scrolling and zooming would behave differently in those WISIWIG >> >> windows, since they're would contain essentially a graphic >> >> representation of the page, like when we render PDF files. >> > >> > I see no need for abandoning graphical text display we use now. >> >> WYSIWIG. >> >> What we have now is not. > > But we can have WYSIWIG without that. Well, of course. We ALREADY have a WYSIWIG editor! Just M-x ps-print-buffer RET and see how the printed page is exactly like the screen. So we have it without that. Sure. We even have a WYSIWIG web renderer with M-x htmlize-buffer RET. But this is not with that that we want to attract new users, and that is not this kind of text files document that we want to present to our co-workers who are expecting word processed documents. >> > None of the leading word processors does, AFAIK. Switching to displaying >> > pictures has many drawbacks; e.g., you cannot easily copy/paste with >> > it, and the display complexities will grow by orders of magnitude, for >> > now good reason. >> >> Any WYSIWIG word processor displays a picture on the screen, and let >> you edit the underlying text data structure. Even emacs does just >> that, only it has a more direct correspondance between character >> cells on screens and character slots in the buffer. > > Of course, a character on glass is just a bunch of pixels. But if > that is what you are talking about, then what exactly are you saying > that we need to change from what we have today? 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. >> For example, in scrolling a word processor let you scroll pixel by >> pixel, while emacs let you only scroll line by line, even in the >> splash window. > > Emacs has pixel-level scrolling for a long time, it just is activated > in very rare cases, so you perhaps don't know it exists. > >> Just take a good look at any WYSIWIG word processor window, and >> count the character pixels vs. the graphic pixels. There's a lot of >> graphics on them: rulers, margins, > > Emacs can display images as well, you know. We just need to use that. > >> I wouldn't mind a text editor that would let us edit enriched text. >> But strangely, I doubt that would attract new users. > > Let's care about the features first, and talk about attractors later. I won't deny that some pieces are already implemented. Happily! Again, for now, let's concentrate on specifications and see if that makes something that would be worth implementing. -- __Pascal Bourguignon__ http://www.informatimago.com/