RE: Split `simple.el'?

[Drew Adams <drew.adams@oracle.com>]

> > I understand the problem now, I think.  With my setup I
> > automatically fit frames with buffers to their text.
> > This happens after the buffer is visited (and thus
> > displayed).
> 
> You mean, before it is displayed, right?

No, afterward.  I essentially tack on frame-fitting at the
end of `switch-to-buffer'.  (Among other reasons for this,
I use `image-display-size' to accommodate frames showing
images.)

> > The frame-fitting code moves point through the buffer,
> > at eol (`end-of-line'), within a `save-excursion', to
> > get the longest line length.  That movement presumably
> > means that fonts are looked for to render the chars in
> > each line.
> 
> That must slow down visiting very large files, even if they don't have
> special characters in them.

No, not noticeably.  As I said, if I remove that problematic
defcustom from `simple.el' then there is no delay at all -
the buffer appears instantly.  But sure, with a big enough
buffer it could be noticeable.  I could always add an option
to not fit when `buffer-size' is "too big", but I haven't yet
run into buffers that are too big in this regard.

> Why not just use a wide-enough frame?  Your monitor limits the width
> you could set anyway.

Dunno what you mean.  The idea is to shrink-fit the frame to
its buffer(s).  A one-window-p buffer with short lines has
its frame fit to the width of its widest line, resulting in
a narrow frame.

(There are user options to limit the max frame width and height
and to do other things, but within such constraints the frame
is shrink-fit to its content.)

If I could easily detect the presence of text that would prove
problematic to work with then I could avoid fitting in that
case.  Dunno how to do that.

I could search for a fancy (e.g. non-ASCII) char, but that
wouldn't test whether there is a potential problem, which
depends on the particular fonts installed and the particular
non-ASCII chars present.