When change panel mode to listing one, in addition to reset of
panelization, reset panel filter too.
Optimization: get rid of double panel reload.
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
* 2942_panelize_absolutize:
do_panelize_cd() is missing call to panelize_absolutize_if_needed().
Introduce panelize_absolutize_if_needed(), plus documentation.
Fix assumptions of "dir.list->len == 0".
Ticket #2942: External panelize: opening a file with an absolute path fails.
Whenever we populate a panelized panel, we have to call
panelize_absolute_if_needed().
Note: do_panelize_cd() implements the "Restore last panelization" command
(see #3767).
Note: We move the `panel->is_panelized = TRUE` line to the bottom for stylistic
reason: to make it parallel to the other places where we have similar code. We
may factor out this common code in the future.
Signed-off-by: Mooffie <mooffie@gmail.com>
`dir.list->len` can't be zero because we're always checking it after a call to
dir_list_init(), which populated the list with "..".
Therefore any code that checks for zero is either superfluous or a bug.
As for the modifications in find.c:
- The bug caused us not to call panel_clean_dir(), and this caused:
- Memory leaks resulting from calling dir_list_init() without
dir_list_clean() first.
- The "total size" of selected files (for example) wasn't getting cleared.
- We remove the `if (list->len != 0)` around the
`current_panel->is_panelized = TRUE; ...` for several reasons:
- The code isn't called anyway if no files were found.
- Conceptually, there's no point in distinguishing an empty listing from an
empty panelized listing.
- It's the de-facto current behavior (as `list->len != 0` always)
Signed-off-by: Mooffie <mooffie@gmail.com>
We fix the detection of absolute paths in the panel's list. `list[0]` is "..",
so we need to inspect `list[1]`.
Signed-off-by: Mooffie <mooffie@gmail.com>
Before the patch: --help shows the same text for all tools, only "mc"
is replaced by tool name. For example, "mcedit --help" says:
Usage:
mcedit [OPTION...] [+number] [this_dir] [other_panel_dir]
+number - Set initial line number for the internal editor
which is wrong: mcedit does not take [this_dir] [other_panel_dir]
syntax, that's mc syntax.
After the patch, each tool has its own syntax string shown.
"Usage:" message for each tool is as follows now:
mc [OPTION...] [this_dir] [other_panel_dir]
mcedit [OPTION...] [+lineno] file1[:lineno] [file2[:lineno]...]
mcview [OPTION...] file
mcdiff [OPTION...] file1 file2
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Andrew Borodin <aborodin@vmail.ru>
We switch to using 'echo' instead of 'printf', for the reason described in a
previous commit.
This time, however, we don't do this in order to preserve the value of the
DESCRIPTION field (because we retrieve it using some other command). We do this
for two reasons:
* As chance would have it, we have the string '\c' in our DESCRIPTION. It turns
out that Dash's echo interprets '\c' to mean the end of the data[1], so
fields stored in $AllTAGS after DESCRIPTION aren't seen by our sed script
(resulting in the helper not reporting a few file entries).
* We also have '\n' in DESCRIPTION. This would translate, by echo, into
newline, failing the naive sed script.
[1] See "\c as in SYSV echo - abort all processing..." in the source code of
Dash: https://github.com/gioele/dash/blob/master/src/bltin/printf.c
Signed-off-by: Mooffie <mooffie@gmail.com>
Our goal is to replace the 'echo' with 'printf' on this line, for the reason
described in the previous commit. But before we do this we need to wrap one
variable in quotes.
This preliminary step does not affect the output of the helper.
As for using "tr \n ' '": this mimics the current behavior (when using no
quotes around the variable, newlines are converted to spaces by the shell; now
that we do have quotes we need to do this conversion ourselves). An alternative
is to tweak the sed script to be smarter, but it turns out it's not a simple
task.
Signed-off-by: Mooffie <mooffie@gmail.com>
Out test input intentionally contains weird characters in the DESCRIPTION field
(see the file 'test.spec'[1]).
It turns out that backslash sequences, as in our DESCRIPTION field, are
processed by the 'echo' command in some shells (i.e., Dash). In other words,
'echo' can't be used to print arbitrary data verbatim. Indeed, the standard
says[2] that "if any of the operands contain a <backslash> character, the
results are implementation-defined". You can see the problem by running:
$ echo "one \\a two"
under both Bash and Dash: you'll get different results.
The solution: we replace 'echo' with 'printf'.
[1] https://midnight-commander.org/browser/tests/src/vfs/extfs/helpers-list/misc/rpm/test.spec#L34
[2] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
Signed-off-by: Mooffie <mooffie@gmail.com>
As will be explained in a following commit, our rpm helper has a bug stemming
from the use of 'echo'.
Before we fix it, we update the test's "expected output" to reflect the
intended output (as it's currently reflects a faulty output).
Signed-off-by: Mooffie <mooffie@gmail.com>
The "expected output" files we provide must be generated in the same locale the
tester (that is, the helpers) are run. Otherwise helpers using the 'sort'
utility may generate output different than our provided "expected output",
hence failing the tests.
Therefore we:
(1) Regenerate the "expected output" files in the C locale.
(2) Make sure the tester is run in the C locale.
(Tip: to regenerate the "expected output" files we deleted all the *.output
files and run the tester with "LC_ALL=C ./run --create-output".)
Signed-off-by: Mooffie <mooffie@gmail.com>
Upon seeing a tab, the help viewer effectively pushes the *current* word
forward.
Instead, it should first finish handling the current word (that is, print it on
screen) and only then adjust the column.
Signed-off-by: Mooffie <mooffie@gmail.com>
Andrew Borodin