Re: mode-line size and position indicator

[Eli Zaretskii]

> From: Nick Helm <address@hidden>
> Date: Wed, 23 Aug 2017 15:20:27 +1200
> 
> I've been trying to improve my C skills lately, so I thought I'd take a
> crack at adding a small feature to xdisp.c.
> 
> I've written a simple mode-line indicator to visually show the relative
> size and position of the window view on the current buffer. It works by
> adding a new %-spec construct to decode_mode_spec.
> 
> The result is akin to a vertical scroll-bar, but it appears as a
> horizontal mark on the mode-line. It may be useful to terminal users or
> those who prefer to run with traditional scroll-bars turned off. I've
> attached a screen-grab of what it looks like on my system.
> 
> The indicator is activated by adding %N~ to mode-line-format, where N is
> a positive integer that sets the desired width of the indicator in char.
> 
> I'm under no illusions that this should be included in Emacs, and
> admittedly, it is a very simple feature, but I'd appreciate any
> comments or suggestions to improve the code. Patch attached.

Looks good, although there's a fundamental problem with putting on the
mode line an indicator that must use a significant part of the screen
estate to be useful: the mode line is pretty crowded these days, even
in the default configuration.

> +      /* Indicate the relative size and position of the current window. */ 
> +    case '~':
> +      {
> +     ptrdiff_t toppos = marker_position (w->start);
> +     ptrdiff_t botpos = BUF_Z (b) - w->window_end_pos;
> +     ptrdiff_t total = BUF_ZV (b) - BUF_BEGV (b) + 1;
> +     ptrdiff_t open;
> +     ptrdiff_t close;
> +     int i;
> +     char *p = decode_mode_spec_buf;
> +
> +     /* It makes little sense to pad with spaces, so use WIDTH to
> +        enable the user to specify the size of the indicator. */
> +
> +     if (width < 3) width = 3; /* Set a minimum indicator size. */
> +     width -= 2; /* Reserve space for open and close marks. */
> +
> +     if (total >= 1000000)
> +       /* Do it differently for a large value, to avoid overflow. */
> +       {
> +         open = ((toppos - BUF_BEGV (b)) + (total / width) - 1) / (total / 
> width);
> +         close = ((botpos - BUF_BEGV (b) + 1) + (total / width) - 1) / 
> (total / width);
> +       }
> +     else
> +       {
> +         open = ((toppos - BUF_BEGV (b)) * width + total - 1) / total;
> +         close = ((botpos - BUF_BEGV (b) + 1) * width + total - 1) / total;
> +       }

I wonder whether it would have made sense to reuse the code we have
for computing the scroll-bar thumb.

Also, why two different code fragments? why not use the former for
both small and large values of 'total'?