[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Split `simple.el'?

From: Drew Adams
Subject: RE: Split `simple.el'?
Date: Thu, 5 Apr 2018 14:56:01 -0700 (PDT)

> > 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.
> The movement doesn't care about the chars themselves (it's just looking
> for an end-of-line).  So it's probably the computation of the
> line-length which triggers it.  You can probably avoid the problem by
> using another way to compute the "length" (one which doesn't care about
> fonts).

So far, I've wanted to take the apparent (i.e., rendered)
char width into account.  I've just been counting columns,
to do that:

(while (not (eobp))
  (setq max-win-width  (max (current-column) max-win-width))
  (when (zerop (forward-line 1))
    (setq max-win-height  (1+ max-win-height))))

(The file is here, if you want a bigger picture:

`current-column' "is calculated by adding together the widths
of all the displayed representations of the character between
the start of the previous line and point (e.g., control
characters will have a width of 2 or 4, tabs will have a
variable width)."

That's TRT, I think: take into account rendered char widths.

But maybe I need an option, to calculate line width without
regard to rendering in some cases.  Even so, other than a
user choosing yes/no in general, I don't see a way for code
to tell whether or where it might makes sense to skip
requiring rendering.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]