| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The width of the widest line number, which is often the last one visible
in the list is not always the same thing as the width of the item that
would be at the very bottom of the screen. When a directory contains
fewer items than lines are available for display, the former can have
fewer digits.
|
|
|
|
|
| |
Line number width calculation was ignoring the one_indexed setting. This
meant recalculating the width one line too late.
|
|
|
|
|
|
| |
The `line_numbers` setting is a string but case shouldn't matter,
especially for caching, this is handled in branches already but the
caching key was overlooked.
|
|
|
|
|
|
| |
The calculation isn't difficult but the lines were long and there's
several branches involved. Giving `len(str())` a name and introducing
names for intermediate results should make it easier to comprehend
|
|
|
|
|
|
|
|
| |
For relative line numbers the width that actually matters is the width
for all the displayed line numbers. The width of the largest index of
the displayed files doesn't matter. Only the width of the relative
indices and the width of the currently highlighted item's index, unless
`relative_current_zero` is enabled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The width of an item needs to be recalculated if the width of the line
numbers changes. This happens every time we get to another order of
magnitude (an additional digit).
This is based on [review
comments](https://github.com/ranger/ranger/pull/2346#issuecomment-1062257526)
from markus-bauer. The solution opted for here is basically their second
bullet point. I tried the third bullet point first, replacing
`line_numbers` by `linum_text_len` in the key but this requires
recalculating `linum_text_len` to be zero when line numbers are
disabled, which feels like a somewhat clunky overloading while we have a
perfectly usable boolean flag available.
Closes #2346
Co-authored-by: markus-bauer <mail.markus.bauer@gmail.com>
|
|
|
|
|
|
| |
The file size was always followed by a space in case it needed to be
separated from other trailing information but this should only happen if
anything actually follows it.
|
| |
|
|
|
|
|
|
|
| |
The status bar wasn't taken into account when calculating the width of
the visible line numbers. This meant the width would change right before
a number with an extra digit appeared or one later than when it
disappeared.
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Implementations need the `self` parameter and PyLint complains when the
number of arguments changes. Since it's never used without
reimplementation, `@abstractmethod` is appropriate.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
The `use` method has always been decorated as being a `@staticmethod`.
Many colorschemes use fields to store certain properties, these then
need to be accessed using `self`. This isn't possible with a static
method so they override it with a regular method. This is fine as far as
Python is concerned but PyLint doesn't like the `self` parameters adding
an argument to the method.
All colorschemes should actually implement the `use` method anyway so
making it an `@abstractmethod` seems appropriate and allows us to
include the `self` argument.
|
|\ |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I believe at some point I added the `README.md` to the prerequisites for
the man pages so we wouldn't forget to update them whenever the README
was touched. This hasn't worked very well and it often makes
particularly the rifle man page regenerate when not needed.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes #2548
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I believe at some point I added the `README.md` to the prerequisites for
the man pages so we wouldn't forget to update them whenever the README
was touched. This hasn't worked very well and it often makes
particularly the rifle man page regenerate when not needed.
|
| | | | |
|
|/ / / |
|
|\ \ \
| |/ /
|/| | |
|
|/ /
| |
| |
| | |
Fixes #2548
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
We need to test f-strings now and it's a bother making that compatible
with Python 2.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
These were introduced in 3.6 so they're not an option. Otherwise they'd
be a good idea.
|
| | |
| | |
| | |
| | | |
This reverts commit 8372a7602d93eb7fc3d18c8ac071ea9cd6349501.
|
| | |
| | |
| | |
| | | |
This reverts commit abcdb9b6d76cf56be55c037d90b1c299468d006a.
|
| | |
| | |
| | |
| | | |
This reverts commit 8110d6990ae12e4e55d2ceaefabdb63b39238b6c.
|
| | |
| | |
| | |
| | | |
This reverts commit 8b462b245399af66bb2b7dd31ed360548804416b.
|
| | |
| | |
| | |
| | | |
This reverts commit 742d02c05890c9d2477cad6138853088a28a83e8.
|
| | |
| | |
| | |
| | | |
This reverts commit 90380564ca41429771441f1e3cb3cc606ca5e101.
|
| | |
| | |
| | |
| | | |
This reverts commit ade69eb05c5791fe02736cf761d3162dd04fb412.
|