Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 23, 2020 at 4:51 PM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Richard Stallman" <rms@gnu.org>
> Cc: ghe@sdf.org, eliz@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Richard Stallman <rms@gnu.org> writes:
>
> > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> > [[[ whether defending the US Constitution against all enemies,     ]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >
> >   >  There is need to tell Emacs: "I wish a buffer of this pixel
> >   > width and height".
> >
> > LibreOffice doesn't ask that question, and it lets you start editing
> > text and knows what size to use by default for the page.
> Somewhere under the hood in it's source code it does. :-)
>
> I don't think you have understood what I ment there. Maybe I was too
> flumsy when writing.
>
> What I ment is that somewhere in the application code there have to be a
> database of papersizes, so that application can draw that representation
> of a page on the screen such as they do in Writer for example and how
> wide lines will be so it can break lines properly, where user text would
> start on those line, on the page, when to break to next page etc.

Texinfo does things that way.

> One annoyance is also renderer which in Emacs can't draw an "empty
> buffer". Libre Office draws a white rectangle and some lines
> around. Emacs can't do that since we can't draw things in layers, at
> least what I am aware of (Mr. Eli? ).
>
> Maybe that itself is not that desirable, and could be a "nice ot have "
> feature but which can easily be lived without. As a poor man version,
> one can just draw lines with unicode chars '|' where say width of page
> ends for visual representation and simply insert ^L styled vid svg image
> where page ends.
>
> > One interesting question is how to make text flow between pages.  In
> > Emacs, a page boundary is a ^L character (formfeed).  To make text
> > flow between pages would require deleting and inserting ^L characters
> > as needed.  Is that workable?
> I think that would be conceptually trivial, but labourous as now, that
> is what I tried to say in mail with demo I sent. I had idea the idea to
> do in that demo, but I never got back to work more on it.
>
> Insertion routine would need to know where pages starts and ends. I
> think a page can be modelled just as a range between two points (a
> region). There are more details of course; printer margins have to be
> taken account, headers, footers, client area and what not.
>
> But roughly insertion, deletion and other text routines whichever they
> are, would need to check if text in a page has reached to certain point
> and if it is to insert ^L and reflow the page(s) as needed.
>
>
> > (I remember when ^L made the line printer skip to the next page.)
> >
> >   > For example deleteion would delete
> >   > a character but insert a filler-character, insertion would insert a
> >   > character but delete a filler-character and so on.
> >
> > I don't follow that.  Could you give a concrete example and say
> > what these fillers would do, what benefit would result.
> > I think they would be a pain in the neck
> > for all the editing commands.
> Yes, they would be pain, but all editing commands would have to be
> changed anyway. There would be some document mode or wysiwyg mode or
> whatever which would have to either overwrite or advise insertion,
> deletion, etc.
>
> Those filler spaces was my compensation for how Emacs buffer and renderer
> works.
>
> I had an idea to emulate visually a page as in a wyswyg editor. Emacs
> can't render an empty buffer of certain size, not what I know. Maybe it
> is possible to do something with child frames, or fringes or some other
> trick, I don't know. But it was a compensation, I calculated a number of
> columns with default font to fill a certain width in pixels. It is a
> flawed approach, but it was just an experiment. So I insert just white
> space characters which I call "filler space".
>
> The idea was also to use them conceptually like spacers so I can tell
> the insertion routine to really start from column X and not from first
> char in line, and to break at column Y and not the last column.
>
> I see page as consising of header, client and footer areas which are all
> just ranges, so it really is just checking some integers; not very
> hard. I also see those areas start at some margins (printer margins),
> since printers can't print directly from the edge of the paper.
>
> Also insertion deletion would have to take into account they work in a
> page, header etc, so when character is inserted somewhere in a page, one
> would have to delete a character at the end of page or rather client
> area. But that would all be just a hierarchical delegation when it comes
> to implementation.
>
> Also since we are inserting in a buffer, inserting a char in first page
> could potentially move all chars in a 100 pages long book. That is
> probably now what we want. We just want to move text on that page. Filler
> space was ment to be used there as spacer too. Insertion would delete a
> space at the end of line or client area to make room for user character
> so not entire Emacs buffer is moved around.
>
> I also wanted to see if I can give them similar property as invisible
> text in Emacs has; I wanted to restrict cursor to move into filler
> space, but I never got to that part, so I don't know if it is possible.
>
> It was just an experiment. If I remember, in demo I posted, one can
> break page at arbitrary point and insert new ones. But what I noticed is
> that it was very slow after few pages were added. Also there are other
> problems, for example most important is how to calculate width of
> columns to start with? Take a space character and see how many fit into
> given pixel width? Or some average size? I took space for the
> experiment, but it is not acceptable approach in general.
>
> Maybe it is more effective to not visually model a page, but to just
> render a line where line ends so user can see text has got out of page
> width and can reflow things themselves. It could be cheap start at least
> and probably not so hard to implement.
>
>