Re: Line wrapping issues
On 8/21/17 1:29 PM, Leon Klingele wrote: >> Please send your typescript to the list. > > Here you go (see attachment). Thanks. I'll see if it reveals anything I don't expect. >> If these steps leave the cursor in a different position than readline >> expects it to be (before step 4), even the redraw-current-line at the >> end of the macro may not help. You could try replacing the key sequence >> to redraw the current line with \c-l and see if that helps. > > I can't quite follow you. Which "key sequence" are you referring to? > Pressing Ctrl+l indeed fixes the issue but also clears the screen > which I'd try to avoid -> only a workaround. The fzf redefinition of the ^R key sequence as a macro. That macro ends with \C-x\C-r, which it redefines to bind to "redraw-current-line". If you replace those characters with \C-l, does it redraw correctly (after clearing the screen, of course)? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: Line wrapping issues
> That macro ends with \C-x\C-r Actually it ends in \e^\er, it lands in the if-block for me: https://github.com/junegunn/fzf/blob/55ee4186aa688e524e041971d588a6f002486deb/shell/key-bindings.bash#L83 Replacing \C-r with \C-l "solves" the issue, but again clears the screen which I'd try to avoid. Are you unable to reproduce the issue? signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Line wrapping issues
On 8/22/17 2:26 PM, Leon Klingele wrote: >> That macro ends with \C-x\C-r > > Actually it ends in \e^\er, it lands in the if-block for me: > https://github.com/junegunn/fzf/blob/55ee4186aa688e524e041971d588a6f002486deb/shell/key-bindings.bash#L83 Ah, you're using the vi-mode binding. Yes, it applies equally to that version, replacing the `\er', which is bound to redraw-current-line, with \C-l. > > Replacing \C-r with \C-l "solves" the issue, but again clears the > screen which I'd try to avoid. I understand you'd like to avoid that. > > Are you unable to reproduce the issue? I'd prefer not to install the ton of software I need to try and replicate it, so I'm looking at what those who have can tell me. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: extension of file-test primitives?
Chet Ramey wrote:
[this would] create an incompatibility between
the shell's builtin test and a test binary. That incompatibility would be
almost impossible to resolve.
Agreed. So I agree that limiting this to use with '[['
would be a better choice that would eliminate such problems.
(reordered this to be first so I could 'reword' following
examples for clarity)
On 8/19/17 8:30 PM, L A Walsh wrote:
Curious, but how difficult or problematic would it be
to allow using brace-expansion (ex. {f,x} ) as a short-hand
to test/combine file-op tests like allowing:
[[ -{f,x} /bin/ls ]] && ...
or
if [[ -{f,x} $file ]]; then ... ; fi
instead of:
[[ -f /bin/ls && test -x /bin/ls ]] && ...
Regarding:
... changing the established meaning of brace expansion,
On a conceptual level, brace expansion expands
a string like '[[\ -{f,x}\ /bin/ls\ ]]' to:
[[ -f /bin/ls ]] [[ -x /bin/ls ]]
I wasn't thinking of the current brace expansion routines
changing to implement this, but only in adding a new file-op
meta test -{X,Y[,Z[,...]]} that allows existing file operators
to be used in place of X, Y, Z. This meta-op would only
be added to '[[' to avoid equivalent syntax expectations
out of external binaries.
As an example of conceptual equivalence of brace-expansion
in the two cases, this already works, using the standard
meaning for brace expansion (line numbers added for
ease of reference):
1) eval "
2)[[ -"{f,x}" /bin/ls ]] &&
3) :" &&
4)...(true case)...
For use as a file-op in a conditional test, operator I was suggesting
removing lines 1 & 3 and the quotes, leaving
2) [[ -{f,x} /bin/ls ]] &&
4) ...(true case)...
The brace expansion would function, conceptually, the same (even
though I'm not envisioning the implementation being done through
a modification of brace expansion).
Re: extension of file-test primitives?
Oops: meant to include this w/other response, but oh well..
Chet Ramey wrote:
PePa wrote:
In that case, would not [[ -fx $file ]] be more workable and in line with
common GNU short commandline option practice??
No. If you're going to propose different functionality, don't use
something that can easily be confused with something that already
exists.
---
That's why I suggested the {f,x} instead as noted in my response
to PePa. I too thought it might be confused w/something that already
exists.
Re: extension of file-test primitives?
Chet Ramey wrote:
On 8/21/17 9:27 AM, Greg Wooledge wrote:
You could write your own helper functions for this:
-fx() { test -f "$1" && test -x "$1"; }
This is indeed a quick and easy way to implement desired functionality.
Shell functions can do a lot.
Alas, they don't work inside [[...]] with other
file-test operators:
[[ -fx /bin/ls && -s /bin/ls ]] && echo ok
-bash: conditional binary operator expected
-bash: syntax error near `/bin/ls'
