| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
When predisplay_right is empty (which is the case when vcs_aware is
off), the separator should be omitted. This fixes the error introduced
by my last commit.
|
| |/ /
| |
| |
| |
| | |
This reverts commit ff909fab98f5941d9e59c983fed787256c35e12d, reversing
changes made to fb449326663baa91f5ce91b996778cfd5501030e.
|
| |\ \ |
|
| |/ /
| |
| |
| |
| |
| | |
Not all versions of Python we test with support installing the PyLint
version we need and the tests don't require PyLint anyway, so no need to
install any version of PyLint at all.
|
| |\ \ |
|
| |/ /
| |
| |
| |
| | |
It looks like the separator is being unexpectedly flattened by the list
concatenation.
|
| |\ \ |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| | |
As of 2.14.0 PyLint dropped the python3 port checker. This means many of
the features we want to disable, because we need syntax compatible with
Python 2 are gone and we can no longer disable the checks.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|