[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42930: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load e
From: |
Phil Sainty |
Subject: |
bug#42930: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors |
Date: |
Thu, 20 Aug 2020 00:52:14 +1200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
When `large-file-warning-threshold' is set to nil (meaning "never
request confirmation"), the definition for `vlf-tune-max' calls `max'
with nil as an argument. This then signals "Wrong type argument:
number-or-marker-p, nil" when byte-compiling or loading any of the
libraries which (require 'vlf-tune).
On 27.1 with that var set to nil, M-x package-install RET vlf RET gives:
Compiling file /path/to/vlf-1.7.1/vlf-base.el at Thu Aug 20 00:06:31 2020
vlf-base.el:30:1:Error: Wrong type argument: number-or-marker-p, nil
Compiling file /path/to/vlf-1.7.1/vlf-ediff.el at Thu Aug 20 00:06:31 2020
vlf-ediff.el:30:1:Error: Wrong type argument: number-or-marker-p, nil
Compiling file /path/to/vlf-1.7.1/vlf-follow.el at Thu Aug 20 00:06:31 2020
vlf-follow.el:30:1:Error: Wrong type argument: number-or-marker-p, nil
Compiling file /path/to/vlf-1.7.1/vlf-occur.el at Thu Aug 20 00:06:32 2020
vlf-occur.el:30:1:Error: Wrong type argument: number-or-marker-p, nil
Compiling file /path/to/vlf-1.7.1/vlf-pkg.el at Thu Aug 20 00:06:32 2020
Compiling file /path/to/vlf-1.7.1/vlf-search.el at Thu Aug 20 00:06:32 2020
vlf-search.el:30:1:Error: Wrong type argument: number-or-marker-p, nil
Compiling file /path/to/vlf-1.7.1/vlf-setup.el at Thu Aug 20 00:06:32 2020
Compiling file /path/to/vlf-1.7.1/vlf-tune.el at Thu Aug 20 00:06:32 2020
Compiling file /path/to/vlf-1.7.1/vlf-write.el at Thu Aug 20 00:06:32 2020
vlf-write.el:30:1:Error: Wrong type argument: number-or-marker-p, nil
Compiling file /path/to/vlf-1.7.1/vlf.el at Thu Aug 20 00:06:32 2020
vlf.el:42:1:Error: Wrong type argument: number-or-marker-p, nil
I've attached a patch to make it use the *standard* value (currently
10000000) of `large-file-warning-threshold' in that scenario. There's
probably an argument to use something bigger, given that the nil value
is really saying that the user will happily cope with much *larger*
file sizes than the standard value; but as this piece of code is only
determining a fallback value in case `vlf-tune-ram-size' failing to
produce a value[1], and the user can simply customize the option if
they're not happy with the default, I concluded it was fine.
-Phil
[1] Or if `vlf-tune-ram-size' produces a value which isn't 20 times
larger than `large-file-warning-threshold' -- that part of the logic
seems slightly iffy, but the issue is probably moot in 2020, given
that 20 x 10,000,000 is only 200M of RAM :)
0001-packages-vlf-Fix-byte-compilation-and-load-errors.patch
Description: Text Data
- bug#42930: [PATCH][ELPA] 27.1; 'vlf' package byte-compilation and load errors,
Phil Sainty <=