Re: Emacs Survey: Toolbars

[Arthur Miller]

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.

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.