| 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.
|
| | |
| |
| |
| |
| | |
It looks like the separator is being unexpectedly flattened by the list
concatenation.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This reverts commit 8b462b245399af66bb2b7dd31ed360548804416b.
|
| | |
| |
| |
| | |
This reverts commit 742d02c05890c9d2477cad6138853088a28a83e8.
|
| | |
| |
| |
| | |
This reverts commit 90380564ca41429771441f1e3cb3cc606ca5e101.
|
| | |
| |
| |
| | |
This reverts commit ade69eb05c5791fe02736cf761d3162dd04fb412.
|
| | |
| |
| |
| | |
This reverts commit 7ae3f6e2ed2ff6648f4a13d276b6e6b586592720.
|
| | |
| |
| |
| | |
This reverts commit 05af3b99d87ade639cfb8dd33acda9c76d5e93e5.
|
| | |
| |
| |
| | |
This reverts commit c3824a59b28fa4895e44718edebc144859eac233.
|
| | |
| |
| |
| | |
This reverts commit 3f5cae584e56ca47e7460dd2634d0b10b3787a9d.
|
| | |
| |
| |
| | |
This reverts commit aa98a9a39eb2c5df10bb19b94ade3a98863470c4.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
| |
`rsvg-convert` works much more reliably for SVGs than ImageMagick's `convert`, which freezes with large SVGs (seems to convert formats first, and resize only after that), and can drop out text during the conversion. Support for SVGs isn't great in ImageMagick, since it's a raster graphics program.
`rsvg-convert` only supports conversion to PNG. The image preview works fine with PNGs, but Ranger assumes/requires a .jpg extension, so the file is just renamed from `xxx.jpg.png` to `xxx.jpg`. It's a bit of an ugly hack, but it works, and it's faster than a second image conversion from PNG to JPEG (and vector graphics usually look better with PNG than with JPEG, which is meant more for photos).
On Ubuntu and Debian, `rsvg-convert` is in the `librsvg2-bin` package.
|
| | |
|
| | |
|
| | |
|