[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mode-line size and position indicator
From: |
Eli Zaretskii |
Subject: |
Re: mode-line size and position indicator |
Date: |
Thu, 24 Aug 2017 19:55:41 +0300 |
> 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'?