[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs as word processor
From: |
Eli Zaretskii |
Subject: |
Re: Emacs as word processor |
Date: |
Fri, 22 Nov 2013 23:38:43 +0200 |
> From: "Pascal J. Bourguignon" <address@hidden>
> Date: Fri, 22 Nov 2013 22:06:23 +0100
> Cc: address@hidden
>
> 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.
> >> - define styles, apply styles to tags.
> >
> > Isn't a "style" just another word for a "face"?
>
> For a character, perhaps. For higher level nodes, a style may be more
> complex, up to procedural styles, were you call up a lisp function to
> "font-lock" and justify the node (paragraph, chapter, etc). For paragraphs
> you would have margins and indentations and perhaps drop cap styles, etc.
I see no reason for these features to be connected to a style. They
can easily be separate; keeping them separate will make it easier for
users to specify arbitrary combinations of them.
> >> - 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: <section> <title> <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.
> >> - 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??
And why are you talking about truncate-lines, when Emacs has word-wrap
for quite some time now?
> >> 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.
> > 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?
> 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.
- Re: Emacs as word processor, (continued)
- Re: Emacs as word processor, John Yates, 2013/11/25
- Re: Emacs as word processor, Lennart Borgman, 2013/11/25
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/25
- Re: Emacs as word processor, Lennart Borgman, 2013/11/25
- Re: Emacs as word processor, Jambunathan K, 2013/11/25
- Re: Emacs as word processor, Jambunathan K, 2013/11/26
- Re: Emacs as word processor, Pascal J. Bourguignon, 2013/11/22
- Re: Emacs as word processor,
Eli Zaretskii <=
- Re: Emacs as word processor, John Yates, 2013/11/22
- Re: Emacs as word processor, Pascal J. Bourguignon, 2013/11/22
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/23
- Re: Emacs as word processor, Pascal J. Bourguignon, 2013/11/22
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/23
- Re: Emacs as word processor, Pascal J. Bourguignon, 2013/11/23
- Re: Emacs as word processor, PJ Weisberg, 2013/11/24
- RE: Emacs as word processor, Drew Adams, 2013/11/24
- Re: Emacs as word processor, Allen S. Rout, 2013/11/25
- Re: Emacs as word processor, Eli Zaretskii, 2013/11/25