zsh-users
 help / color / mirror / code / Atom feed
* line continuation with sed
@ 2022-10-13 18:25 Ray Andrews
  2022-10-14  6:35 ` Lawrence Velázquez
                   ` (3 more replies)
  0 siblings, 4 replies; 22+ messages in thread
From: Ray Andrews @ 2022-10-13 18:25 UTC (permalink / raw)
  To: Zsh Users

I'm wondering if this is a zsh issue or entirely sed's fault but:

$ var=$( print -l $var | sed \
-re 's/.../' \                                 # this is fine
-re 's/.../'\                                  # this  throws an error 
which I'd expect
-re 's/.../' \                                  # this throws an error ...
-re 's/.../' )

... if there is a bloody space AFTER the backslash and before the 
newline.  Thing is it's an invisible error, I just wasted the morning 
with some sed errors which refused to be found because they were 
invisible.  What logic would make a space before the newline an error?  
I'm thinking it must be a zsh issue because zsh is responsible for line 
continuation.  Multiple spaces between sed expressions are fine as one 
would expect so if the backslash simply wrapped the line, there should 
be no issue.  Mind, haven't I whined about this before?  Could there 
ever be a situation where backslash-space-newline was not logically 
reducible to backslash-newline?  If there was such a thing, then of 
course my complaint is void.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-13 18:25 line continuation with sed Ray Andrews
@ 2022-10-14  6:35 ` Lawrence Velázquez
  2022-10-14 11:20   ` Dominik Vogt
  2022-10-14 10:57 ` Marc Chantreux
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 22+ messages in thread
From: Lawrence Velázquez @ 2022-10-14  6:35 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Thu, Oct 13, 2022, at 2:25 PM, Ray Andrews wrote:
> I'm wondering if this is a zsh issue or entirely sed's fault but:
>
> $ var=$( print -l $var | sed \
> -re 's/.../' \                                 # this is fine
> -re 's/.../'\                                  # this  throws an error 
> which I'd expect
> -re 's/.../' \                                  # this throws an error ...
> -re 's/.../' )

As an aside, you only need to specify -r (or -E) once.  Repeating
it has no effect.

> ... if there is a bloody space AFTER the backslash and before the 
> newline.  Thing is it's an invisible error, I just wasted the morning 
> with some sed errors which refused to be found because they were 
> invisible.  What logic would make a space before the newline an error?  
> I'm thinking it must be a zsh issue because zsh is responsible for line 
> continuation.

It is not an "issue", but zsh is indeed responsible.

> Multiple spaces between sed expressions are fine as one 
> would expect so if the backslash simply wrapped the line, there should 
> be no issue.  Mind, haven't I whined about this before?  Could there 
> ever be a situation where backslash-space-newline was not logically 
> reducible to backslash-newline?

What makes you think they are equivalent?  They are not.

https://zsh.sourceforge.io/Doc/Release/Shell-Grammar.html#Quoting

	A character may be quoted (that is, made to stand for itself)
	by preceding it with a '\'.  '\' followed by a newline is
	ignored.

So the sequence \ SP LF is a quoted space followed by an unquoted
line feed.  In this example (and your original), the latter acts
in its common capacity as a sublist terminator:

	% eval $'printf "<%s>\n" foo \\\nbar'
	<foo>
	<bar>
	% eval $'printf "<%s>\n" foo \\ \nbar'
	<foo>
	< >
	zsh: command not found: bar

-- 
vq


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-13 18:25 line continuation with sed Ray Andrews
  2022-10-14  6:35 ` Lawrence Velázquez
@ 2022-10-14 10:57 ` Marc Chantreux
  2022-10-14 11:19 ` Peter Stephenson
  2022-10-15  2:34 ` Aaron Schrab
  3 siblings, 0 replies; 22+ messages in thread
From: Marc Chantreux @ 2022-10-14 10:57 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

hello Ray,

I don't know about the \ problem (maybe you should provide a real
non-working example so we can play ourselves: setting variables,
having working substitions ...)

also: here are some workarounds:

a) is there a reason not to use what I believe to be the common way to do it?

	var=$( print -l $var | sed -r '
		s/.../.../
		s/.../.../
		s/.../.../
		s/.../.../
	')

b) why not embbed in a function?

a and b are not exclusive, you can write

substitute_things() sed -r '
	s/.../.../
	s/.../.../
	s/.../.../
	s/.../.../
'

var=$( print -l $var | substitute_things )

c) dig into a pure zsh substitution ?

I imagine $var is an array as you use print -l so

	var=( those_are long_words )
	print -l ${var/???/AAA}

gimme

	AAAse_are
	AAAg_words

HTH

-- 
Marc Chantreux
Pôle de Calcul et Services Avancés à la Recherche (CESAR)
http://annuaire.unistra.fr/p/20200


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-13 18:25 line continuation with sed Ray Andrews
  2022-10-14  6:35 ` Lawrence Velázquez
  2022-10-14 10:57 ` Marc Chantreux
@ 2022-10-14 11:19 ` Peter Stephenson
  2022-10-14 17:15   ` Dominik Vogt
  2022-10-15  2:34 ` Aaron Schrab
  3 siblings, 1 reply; 22+ messages in thread
From: Peter Stephenson @ 2022-10-14 11:19 UTC (permalink / raw)
  To: Zsh Users

> On 13/10/2022 19:25 Ray Andrews <rayandrews@eastlink.ca> wrote:
> I'm wondering if this is a zsh issue or entirely sed's fault but:
> 
> $ var=$( print -l $var | sed \
> -re 's/.../' \                                 # this is fine
> -re 's/.../'\                                  # this  throws an error 
> which I'd expect
> -re 's/.../' \                                  # this throws an error ...
> -re 's/.../' )
> 
> ... if there is a bloody space AFTER the backslash and before the 
> newline.  Thing is it's an invisible error, I just wasted the morning 
> with some sed errors which refused to be found because they were 
> invisible.

You can configure a number of editors to show this up.  In emacs,
for example, I use:

(setq-default show-trailing-whitespace t)

to show it for all modes, since it's often useful and at worst
a minor distraction.

I think other editors have similar capabilities.

pws


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-14  6:35 ` Lawrence Velázquez
@ 2022-10-14 11:20   ` Dominik Vogt
  2022-10-14 15:44     ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Dominik Vogt @ 2022-10-14 11:20 UTC (permalink / raw)
  To: zsh-users

On Thu, Oct 13, 2022, at 2:25 PM, Ray Andrews wrote:
> Could there
> ever be a situation where backslash-space-newline was not logically
> reducible to backslash-newline?

Yes!  Of course there are situations where backslash-space-newline
is at the end of a line, e.g.

 $ ls filename\ ending\ with\ a\ space\ <enter>

Consider this:

 $ mkdir space-test
 $ cd space-test

 $ echo plain > a
 $ echo space > "a "
 $ echo space-newline > "a <enter>
 "<enter>

 # print hexdump of null separated filenames
 $ find -type f -print0 | od -t x1
 0000000 2e 2f 61 20 00 2e 2f 61 20 0a 00 2e 2f 61 00
 ...
 #       ^^^^^^^^^^^    ^^^^^^^^^^^^^^    ^^^^^^^^
 #       ./a<space>  ./a<space><newline>    ./a

 $ cat a*<TAB>
->
 $ cat a a\  a\ $'\n'
 plain
 space
 space-newline

 # backslash-space-newline
 $ cat a\ <enter>
 space
 # backslash-newline
 $ cat a\<enter>
 <enter>
 plain

--

To figure out "invisible" errors in a script, check it out with a
hex editor (emacs' hexl-mode, press <f4> in mc's file viewer, use
od, hexdump or hd etc.).

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-14 11:20   ` Dominik Vogt
@ 2022-10-14 15:44     ` Ray Andrews
  2022-10-14 17:10       ` Dominik Vogt
  2022-10-14 20:38       ` Lawrence Velázquez
  0 siblings, 2 replies; 22+ messages in thread
From: Ray Andrews @ 2022-10-14 15:44 UTC (permalink / raw)
  To: zsh-users

Thanks for the replies all:

	$ ls filename\ ending\ with\ a\ space\ <enter>

Ok, so it's an overload of the backslash, which might mean an escaped character, or might indicate line continuation.  I think in my example there'd be no difference but I understand your example where ... mind, people who end a filename with a space aren't fit to live ... but linux isn't going to stop you from doing it, so that case must be accommodated.  So then *only* 'backslash-newline' is a line continuation and any other variant leaves the backslash as an escape, yes?

Playing with it a bit more, sending the command to history and then recalling it I see the defect:


$ junk="now is the time
for all good men
to come to the aid
of the party"

... now run this script:

aa="print -l ${(q)junk} | sed \
-nre s/all/most/p \
-e s/men/persons/p \
-e s/aid/assistance/p"

print -rS "$aa"
eval $aa

... and get:

$ . test
for most good men
for most good persons
to come to the assistance

... recalling from history it works fine, but if I modify the '$aa' command with the 'backslash-space-newline' the recalled command looks like this:

print -l now\ is\ the\ time$'\n'for\ all\ good\ men$'\n'to\ come\ to\ the\ aid$'\n'of\ the\ party | sed -nre s/all/most/p -e s/men/persons/p \
-e s/aid/assistance/p

... so the bleeding backslash is literal ... I guess that's because the space does not 'escape'? ... but I thought you could put a backslash before any character?  Anyway we get a literal backslash and then a literal newline and naturally things go sour.  All this to accommodate servants of the Evil One who would end a filename with a space!

Seriously, I get it, thanks guys.  I don't like it, but i can see what gets feed to sed, and why it goes wrong, invisibly.

Peter:

You can configure a number of editors to show this up.  In emacs,
for example, I use:

(setq-default show-trailing-whitespace t)

... I know it, but after my Debian upgrade whereas my editor used to show a nice little 'return' character/icon, it now shows a 'LF" backlit in white that's so annoying I turned it off :( ... so I'm a victim of that mistake.  I'd normally remove trailing spaces just to be tidy, nevermind disasters like the above.








  



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-14 15:44     ` Ray Andrews
@ 2022-10-14 17:10       ` Dominik Vogt
  2022-10-14 20:38       ` Lawrence Velázquez
  1 sibling, 0 replies; 22+ messages in thread
From: Dominik Vogt @ 2022-10-14 17:10 UTC (permalink / raw)
  To: zsh-users

On Fri, Oct 14, 2022 at 08:44:08AM -0700, Ray Andrews wrote:
> mind, people who end a filename with a space aren't fit to live

Well, Unix allows any character in filenames excem null and slash.
I wouldn't have it any other way.  It's not the job of the
operating system to needlessly limit the character set.

> So then *only* 'backslash-newline' is a line continuation and
> any other variant leaves the backslash as an escape, yes?

Right.

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-14 11:19 ` Peter Stephenson
@ 2022-10-14 17:15   ` Dominik Vogt
  2022-10-14 22:21     ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Dominik Vogt @ 2022-10-14 17:15 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On Fri, Oct 14, 2022 at 12:19:01PM +0100, Peter Stephenson wrote:
> You can configure a number of editors to show this up.  In emacs,
> for example, I use:
>
> (setq-default show-trailing-whitespace t)
>
> to show it for all modes, since it's often useful and at worst
> a minor distraction.

Decades ago Paul D. Smith posted the attached script
"rm-tspaces.el" to the fvwm-workers mailing list:  When you try to
save a buffer with trailing whitespace, it asks you whether you
want to remove them before saving.  Very handy.  (Can also be
configured to do this automatically.)

My configuration:
-- ~/.emacs --
;; Removes all trailing whitespace at the end of all lines--this setting
;; makes it ask you by default.
;;
(require 'rm-tspaces)
(setq-default rm-trailing-spaces 1)
;; Turn it on unconditionally for various programming modes
;;
(add-hook 'emacs-lisp-mode-hook 'rm-trailing-spaces-always)
(add-hook 'cperl-mode-hook 'rm-trailing-spaces-always)
(add-hook 'c-mode-common-hook 'rm-trailing-spaces-always)
(add-hook 'makefile-mode-hook 'rm-trailing-spaces-always)
;; Turn it off unconditionally in other places
;;
(add-hook 'message-mode-hook  'rm-trailing-spaces-never)
(add-hook 'nnfolder-save-buffer-hook 'rm-trailing-spaces-never)
-- snip --

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt

[-- Attachment #2: rm-tspaces.el --]
[-- Type: text/plain, Size: 3639 bytes --]

;; rm-tspaces.el: Automatically clean trailing whitespace from buffers.
;;
;; Copyright (C) 1995  Paul D. Smith <psmith@BayNetworks.com>
;;
;; This file requires Emacs 19 or above.  It should work with both Emacs
;; and XEmacs.  Use (require 'rm-tspaces) to load this file (don't
;; autoload it).
;;
;; For user-invoked whitespace cleanup, the function rm-trailing-spaces
;; can be bound to a key or invoked via M-x.
;;
;; The variable rm-trailing-spaces controls behavior when the buffer is
;; saved.  By default nothing is done.  See the documentation of this
;; variable for details.
;;
;; The variable rm-trailing-spaces is buffer-local.  Use setq-default to
;; set the default value for all buffers.  Use setq to override the
;; default value for a particular buffer.  If you're going to put the
;; setq in a hook, use the handy hook functions at the end of this file
;; to avoid having to write your own.
;;
;; For example, to be asked about removal for all buffers, except
;; automatically remove spaces in C files, try something like this:
;;
;;  (require 'rm-tspaces)
;;  (setq-default rm-trailing-spaces 1) ; any non-nil, non-t value
;;
;;  (add-hook 'c-mode-hook 'rm-trailing-spaces-always)
;;
;; Note the user is only queried when there is actually trailing
;; whitespace in the buffer (e.g., the buffer would be modified).
;;
;;  This program is free software; you can redistribute it and/or modify
;;  it under the terms of the GNU General Public License as published by
;;  the Free Software Foundation; either version 2, or (at your option)
;;  any later version.
;;
;; Changes:
;;  1.2 - Add version info.
;;        Add simple functions to make installing in hooks simpler.


(defvar rm-trailing-spaces nil
  "*Value of t says silently remove all trailing spaces when a file is saved.
Non-nil but not t says ask user whether to remove trailing spaces or not.
nil means don't remove trailing spaces.")
(make-variable-buffer-local 'rm-trailing-spaces)


;; What are we?
;;
;(defconst rm-tspaces-version (substring "$Revision$" 11 -2)
;  "$Id$")


(defun rm-trailing-spaces-internal ()
  "Deletes trailing whitespace from all lines in the current buffer."
  (if (and (not buffer-read-only) rm-trailing-spaces)
      (save-excursion
	(goto-char (point-min))
	(if (or (eq rm-trailing-spaces t)
		(and (re-search-forward "[ \t]$" nil 1)
		     (y-or-n-p
		      (format "Remove trailing spaces in buffer %s? "
			      (buffer-name)))))
	    (list
	     (while (< (point) (point-max))
	       (end-of-line nil)
	       (delete-horizontal-space)
	       (forward-line 1))
	     (end-of-line nil)
	     (delete-horizontal-space))
	    )))
  nil) ; indicates buffer-not-saved for write-file-hooks

(defun rm-trailing-spaces ()
  "Deletes trailing whitespace from all lines in the current buffer."
  (interactive "*")
  (message "Deleting trailing spaces... ")
  (let ((rm-trailing-spaces t))
    (rm-trailing-spaces-internal))
  (message "Deleting trailing spaces... done"))


;; Apply this function automatically to all buffers before they're saved.
;;
(add-hook 'write-file-hooks 'rm-trailing-spaces-internal)


;; Provide some simple functions for inclusion in hooks variables
;;
(defun rm-trailing-spaces-never ()
  "Don't automatically delete trailing whitespace in this buffer."
  (setq rm-trailing-spaces nil))

(defun rm-trailing-spaces-ask ()
  "Ask before deleting trailing whitespace in this buffer."
  (setq rm-trailing-spaces 1))

(defun rm-trailing-spaces-always ()
  "Always automatically delete trailing whitespace in this buffer."
  (setq rm-trailing-spaces t))


(provide 'rm-tspaces)

;; rm-tspaces.el ends here

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-14 15:44     ` Ray Andrews
  2022-10-14 17:10       ` Dominik Vogt
@ 2022-10-14 20:38       ` Lawrence Velázquez
  2022-10-14 22:26         ` Ray Andrews
  1 sibling, 1 reply; 22+ messages in thread
From: Lawrence Velázquez @ 2022-10-14 20:38 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Oct 14, 2022, at 11:44 AM, Ray Andrews wrote:
> All this to accommodate 
> servants of the Evil One who would end a filename with a space!

Don't fixate on filenames ending in spaces.  The standard behavior
of backslash is to escape the following character, whatever it is,
with the exception of LF.  Having \ SP behave differently depending
on whether it is at the end of a line or not would be ridiculous.

-- 
vq


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-14 17:15   ` Dominik Vogt
@ 2022-10-14 22:21     ` Ray Andrews
  0 siblings, 0 replies; 22+ messages in thread
From: Ray Andrews @ 2022-10-14 22:21 UTC (permalink / raw)
  To: zsh-users


On 2022-10-14 10:15, Dominik Vogt wrote:
>
> Decades ago Paul D. Smith posted the attached script
> "rm-tspaces.el" to the fvwm-workers mailing list:  When you try to
> save a buffer with trailing whitespace, it asks you whether you
> want to remove them before saving.  Very handy.  (Can also be
> configured to do this automatically.)

My editor actually does that as an option which I had set.  But then I 
upgraded my OS and the new, virginal version has it unset and I'd long 
forgotten about it.  And then with the obnoxious 'LF' linefeed indicator 
turned off, I was a sitting duck for the above problem.    A guy can't 
catch a break.




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-14 20:38       ` Lawrence Velázquez
@ 2022-10-14 22:26         ` Ray Andrews
  0 siblings, 0 replies; 22+ messages in thread
From: Ray Andrews @ 2022-10-14 22:26 UTC (permalink / raw)
  To: zsh-users


On 2022-10-14 13:38, Lawrence Velázquez wrote:
>
> Don't fixate on filenames ending in spaces.  The standard behavior
> of backslash is to escape the following character, whatever it is,
> with the exception of LF.  Having \ SP behave differently depending
> on whether it is at the end of a line or not would be ridiculous.

I understand, best to keep it simple and consistent even if there is 
'invisible' trouble on occasion.  Once one is fully aware of the issue 
the problem is easily detected.  A special case exception here might be 
doable but it isn't necessary.  Come to think about it, I've run into 
this issue before, I'd just forgotten because as I said I had my editor 
set to remove trailing spaces automatically.




>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-13 18:25 line continuation with sed Ray Andrews
                   ` (2 preceding siblings ...)
  2022-10-14 11:19 ` Peter Stephenson
@ 2022-10-15  2:34 ` Aaron Schrab
  2022-10-15  2:57   ` Ray Andrews
  3 siblings, 1 reply; 22+ messages in thread
From: Aaron Schrab @ 2022-10-15  2:34 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

At 11:25 -0700 13 Oct 2022, Ray Andrews <rayandrews@eastlink.ca> wrote:
>I'm wondering if this is a zsh issue or entirely sed's fault but:
>
>$ var=$( print -l $var | sed \
>-re 's/.../' \                                 # this is fine
>-re 's/.../'\                                  # this  throws an error 
>which I'd expect
>-re 's/.../' \                                  # this throws an error ...
>-re 's/.../' )

There have already been a number of replies explaining this, and hints 
on how to detect this, so I won't address that.

Instead I'll give a method to help avoid the problem. For awhile now, 
anytime I'm using calling a command with enough options to warrant line 
continuation I build them up in an array instead. This allows splitting 
across lines without using a backslash at the end, and *actually* allows 
comments.

This also allows the arguments to be build up gradually with some being 
added conditionally.

The below actually works as written including the comments:

     args=(
       -re 's/abc/xyx/' # End of the alphabet is better
       -re 's/123/456/' # Bigger numbers are better
       # -re 's/foo/bar/' # Disable for now
     )

     if [ -r /some/file ]
     then
       args+=(-re 's/new/old/')
     fi

     echo abc123 | sed "${args[@]}"

For zsh you can just use $args to reference it, the way I wrote it above 
will work in bash as well.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-15  2:34 ` Aaron Schrab
@ 2022-10-15  2:57   ` Ray Andrews
  2022-10-15  5:08     ` Bart Schaefer
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2022-10-15  2:57 UTC (permalink / raw)
  To: zsh-users


On 2022-10-14 19:34, Aaron Schrab wrote:
> Instead I'll give a method to help avoid the problem. For awhile now, 
> anytime I'm using calling a command with enough options to warrant 
> line continuation I build them up in an array instead. This allows 
> splitting across lines without using a backslash at the end, and 
> *actually* allows comments.
>
> This also allows the arguments to be build up gradually with some 
> being added conditionally.
>
> The below actually works as written including the comments:
>
>     args=(
>       -re 's/abc/xyx/' # End of the alphabet is better
>       -re 's/123/456/' # Bigger numbers are better
>       # -re 's/foo/bar/' # Disable for now
>     )
>
>     if [ -r /some/file ]
>     then
>       args+=(-re 's/new/old/')
>     fi
>
>     echo abc123 | sed "${args[@]}"
>
> For zsh you can just use $args to reference it, the way I wrote it 
> above will work in bash as well.
>
That is most clever!  As it is, when I have a long set of seds, I copy 
the whole thing, comment it, and then add comments (within the comments) 
so as to inform myself what the seds are doing since I tend to forget 
all the syntactic details. You method permits the comments where they 
naturally belong.  Mind, it seems to me that comments after a line wrap 
would be easy to implement but that's not what we have.  Thanks again.




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-15  2:57   ` Ray Andrews
@ 2022-10-15  5:08     ` Bart Schaefer
  2022-10-15 16:53       ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2022-10-15  5:08 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Fri, Oct 14, 2022 at 7:58 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> You method permits the comments where they
> naturally belong.  Mind, it seems to me that comments after a line wrap
> would be easy to implement but that's not what we have.

We went through this a while ago.  A comment can't end with a line
continuation because then it's not possible to distinguish where the
comment itself ends (is the following line part of the comment?).  A
comment can't follow a line continuation for the same reason a space
can't.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-15  5:08     ` Bart Schaefer
@ 2022-10-15 16:53       ` Ray Andrews
  2022-10-17  1:07         ` Bart Schaefer
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2022-10-15 16:53 UTC (permalink / raw)
  To: zsh-users


On 2022-10-14 22:08, Bart Schaefer wrote:
> We went through this a while ago. A comment can't end with a line
> continuation because then it's not possible to distinguish where the
> comment itself ends (is the following line part of the comment?).  A
> comment can't follow a line continuation for the same reason a space
> can't.

I remember.  But it took a while for the memory to resurface, sorry for 
flogging a dead horse.  (But I do think the horse could be flogged a bit 
more ;-)




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-15 16:53       ` Ray Andrews
@ 2022-10-17  1:07         ` Bart Schaefer
  2022-10-17  3:40           ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2022-10-17  1:07 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

You might find something like this interesting:

show-trailing-space() {
  zle .$WIDGET &&
  if [[ $BUFFER = *(' '|$' \n'*)
        || $PREBUFFER = *$' \n'* ]]
  then POSTDISPLAY=$'\u21a9'
  else unset POSTDISPLAY
  fi
}
zle -N magic-space show-trailing-space
zle -N self-insert show-trailing-space
zle -N kill-whole-line show-trailing-space
zle -N kill-line show-trailing-space
zle -N kill-word show-trailing-space
zle -N backward-kill-word show-trailing-space
zle -N backward-delete-char show-trailing-space

Integrating this with other plugins etc. that may have rebound those
widgets or appropriated POSTDISPLAY is left as an exercise.  Other
improvements (bind to history motions etc.) are possible.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-17  1:07         ` Bart Schaefer
@ 2022-10-17  3:40           ` Ray Andrews
  2022-10-17  4:20             ` Bart Schaefer
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2022-10-17  3:40 UTC (permalink / raw)
  To: zsh-users


On 2022-10-16 18:07, Bart Schaefer wrote:
> You might find something like this interesting:
>
> show-trailing-space() {
>    zle .$WIDGET &&
>    if [[ $BUFFER = *(' '|$' \n'*)
>          || $PREBUFFER = *$' \n'* ]]
>    then POSTDISPLAY=$'\u21a9'
>    else unset POSTDISPLAY
>    fi
> }
> zle -N magic-space show-trailing-space
> zle -N self-insert show-trailing-space
> zle -N kill-whole-line show-trailing-space
> zle -N kill-line show-trailing-space
> zle -N kill-word show-trailing-space
> zle -N backward-kill-word show-trailing-space
> zle -N backward-delete-char show-trailing-space
>
> Integrating this with other plugins etc. that may have rebound those
> widgets or appropriated POSTDISPLAY is left as an exercise.  Other
> improvements (bind to history motions etc.) are possible.
>
That is really elegant.  Too bad I can't have that in my editor, that 
little 'return' graphic is exactly what I'd like


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-17  3:40           ` Ray Andrews
@ 2022-10-17  4:20             ` Bart Schaefer
  2022-10-17  9:19               ` Pier Paolo Grassi
  0 siblings, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2022-10-17  4:20 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

On Sun, Oct 16, 2022 at 8:40 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-10-16 18:07, Bart Schaefer wrote:
> > You might find something like this interesting:
> That is really elegant.

Actually that implementation is kind of ugly.  I completely forgot
about this much prettier way:

show-trailing-space() {
  if [[ $BUFFER = *(' '|$' \n'*)
        || $PREBUFFER = *$' \n'* ]]
  then POSTDISPLAY=$'\u21a9'
  else unset POSTDISPLAY
  fi
}
zle -N show-trailing-space
add-zle-hook-widget line-pre-redraw show-trailing-space
add-zle-hook-widget history-line-set show-trailing-space


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-17  4:20             ` Bart Schaefer
@ 2022-10-17  9:19               ` Pier Paolo Grassi
  2022-10-17  9:24                 ` Pier Paolo Grassi
  0 siblings, 1 reply; 22+ messages in thread
From: Pier Paolo Grassi @ 2022-10-17  9:19 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

add-zle-hook-widget
zsh: command not found: add-zle-hook-widget

locate add-zle-hook-widget
/usr/local/share/zsh/5.8/functions/_add-zle-hook-widget
/usr/local/share/zsh/5.8/functions/_add-zle-hook-widget.zwc
/usr/local/share/zsh/5.8/functions/add-zle-hook-widget
/usr/local/share/zsh/5.8/functions/add-zle-hook-widget.zwc

echo $fpath
/root/scripts//zsh/functions/zle/  /usr/local/share/zsh/5.8/functions/

why the command is not found? Should I do something to load the functions
from fpath?
thanks

Pier Paolo Grassi


Il giorno lun 17 ott 2022 alle ore 06:22 Bart Schaefer <
schaefer@brasslantern.com> ha scritto:

> On Sun, Oct 16, 2022 at 8:40 PM Ray Andrews <rayandrews@eastlink.ca>
> wrote:
> >
> > On 2022-10-16 18:07, Bart Schaefer wrote:
> > > You might find something like this interesting:
> > That is really elegant.
>
> Actually that implementation is kind of ugly.  I completely forgot
> about this much prettier way:
>
> show-trailing-space() {
>   if [[ $BUFFER = *(' '|$' \n'*)
>         || $PREBUFFER = *$' \n'* ]]
>   then POSTDISPLAY=$'\u21a9'
>   else unset POSTDISPLAY
>   fi
> }
> zle -N show-trailing-space
> add-zle-hook-widget line-pre-redraw show-trailing-space
> add-zle-hook-widget history-line-set show-trailing-space
>
>

[-- Attachment #2: Type: text/html, Size: 2105 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-17  9:19               ` Pier Paolo Grassi
@ 2022-10-17  9:24                 ` Pier Paolo Grassi
  2022-10-17  9:31                   ` Pier Paolo Grassi
  0 siblings, 1 reply; 22+ messages in thread
From: Pier Paolo Grassi @ 2022-10-17  9:24 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

I answered myself with

autoload -U add-zle-hook-widget

Pier Paolo Grassi


Il giorno lun 17 ott 2022 alle ore 11:19 Pier Paolo Grassi <
pierpaolog@gmail.com> ha scritto:

> add-zle-hook-widget
> zsh: command not found: add-zle-hook-widget
>
> locate add-zle-hook-widget
> /usr/local/share/zsh/5.8/functions/_add-zle-hook-widget
> /usr/local/share/zsh/5.8/functions/_add-zle-hook-widget.zwc
> /usr/local/share/zsh/5.8/functions/add-zle-hook-widget
> /usr/local/share/zsh/5.8/functions/add-zle-hook-widget.zwc
>
> echo $fpath
> /root/scripts//zsh/functions/zle/  /usr/local/share/zsh/5.8/functions/
>
> why the command is not found? Should I do something to load the functions
> from fpath?
> thanks
>
> Pier Paolo Grassi
>
>
> Il giorno lun 17 ott 2022 alle ore 06:22 Bart Schaefer <
> schaefer@brasslantern.com> ha scritto:
>
>> On Sun, Oct 16, 2022 at 8:40 PM Ray Andrews <rayandrews@eastlink.ca>
>> wrote:
>> >
>> > On 2022-10-16 18:07, Bart Schaefer wrote:
>> > > You might find something like this interesting:
>> > That is really elegant.
>>
>> Actually that implementation is kind of ugly.  I completely forgot
>> about this much prettier way:
>>
>> show-trailing-space() {
>>   if [[ $BUFFER = *(' '|$' \n'*)
>>         || $PREBUFFER = *$' \n'* ]]
>>   then POSTDISPLAY=$'\u21a9'
>>   else unset POSTDISPLAY
>>   fi
>> }
>> zle -N show-trailing-space
>> add-zle-hook-widget line-pre-redraw show-trailing-space
>> add-zle-hook-widget history-line-set show-trailing-space
>>
>>

[-- Attachment #2: Type: text/html, Size: 2745 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-17  9:24                 ` Pier Paolo Grassi
@ 2022-10-17  9:31                   ` Pier Paolo Grassi
  2022-10-17 16:11                     ` Bart Schaefer
  0 siblings, 1 reply; 22+ messages in thread
From: Pier Paolo Grassi @ 2022-10-17  9:31 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, zsh-users

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

When the buffer is on multiple lines there is this corner case (zsh 5.8):

E \
cdcd↩

ie the space is on the first line but the eol marker is on the last line of
the buffer, is there a POSTDISPLAY equivalent at row level?

Pier Paolo Grassi


Il giorno lun 17 ott 2022 alle ore 11:24 Pier Paolo Grassi <
pierpaolog@gmail.com> ha scritto:

> I answered myself with
>
> autoload -U add-zle-hook-widget
>
> Pier Paolo Grassi
>
>
> Il giorno lun 17 ott 2022 alle ore 11:19 Pier Paolo Grassi <
> pierpaolog@gmail.com> ha scritto:
>
>> add-zle-hook-widget
>> zsh: command not found: add-zle-hook-widget
>>
>> locate add-zle-hook-widget
>> /usr/local/share/zsh/5.8/functions/_add-zle-hook-widget
>> /usr/local/share/zsh/5.8/functions/_add-zle-hook-widget.zwc
>> /usr/local/share/zsh/5.8/functions/add-zle-hook-widget
>> /usr/local/share/zsh/5.8/functions/add-zle-hook-widget.zwc
>>
>> echo $fpath
>> /root/scripts//zsh/functions/zle/  /usr/local/share/zsh/5.8/functions/
>>
>> why the command is not found? Should I do something to load the functions
>> from fpath?
>> thanks
>>
>> Pier Paolo Grassi
>>
>>
>> Il giorno lun 17 ott 2022 alle ore 06:22 Bart Schaefer <
>> schaefer@brasslantern.com> ha scritto:
>>
>>> On Sun, Oct 16, 2022 at 8:40 PM Ray Andrews <rayandrews@eastlink.ca>
>>> wrote:
>>> >
>>> > On 2022-10-16 18:07, Bart Schaefer wrote:
>>> > > You might find something like this interesting:
>>> > That is really elegant.
>>>
>>> Actually that implementation is kind of ugly.  I completely forgot
>>> about this much prettier way:
>>>
>>> show-trailing-space() {
>>>   if [[ $BUFFER = *(' '|$' \n'*)
>>>         || $PREBUFFER = *$' \n'* ]]
>>>   then POSTDISPLAY=$'\u21a9'
>>>   else unset POSTDISPLAY
>>>   fi
>>> }
>>> zle -N show-trailing-space
>>> add-zle-hook-widget line-pre-redraw show-trailing-space
>>> add-zle-hook-widget history-line-set show-trailing-space
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 3586 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: line continuation with sed
  2022-10-17  9:31                   ` Pier Paolo Grassi
@ 2022-10-17 16:11                     ` Bart Schaefer
  0 siblings, 0 replies; 22+ messages in thread
From: Bart Schaefer @ 2022-10-17 16:11 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Ray Andrews, zsh-users

On Mon, Oct 17, 2022 at 2:32 AM Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
>
> E \
> cdcd↩
>
> ie the space is on the first line but the eol marker is on the last line of the buffer, is there a POSTDISPLAY equivalent at row level?

There's not.  I toyed with the idea of actually inserting the eol
marker into the buffer, and removing it again in zle-line-finish, but
PREBUFFER is read-only so a bunch of ugly special-cases would be
introduced.


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2022-10-17 16:12 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-13 18:25 line continuation with sed Ray Andrews
2022-10-14  6:35 ` Lawrence Velázquez
2022-10-14 11:20   ` Dominik Vogt
2022-10-14 15:44     ` Ray Andrews
2022-10-14 17:10       ` Dominik Vogt
2022-10-14 20:38       ` Lawrence Velázquez
2022-10-14 22:26         ` Ray Andrews
2022-10-14 10:57 ` Marc Chantreux
2022-10-14 11:19 ` Peter Stephenson
2022-10-14 17:15   ` Dominik Vogt
2022-10-14 22:21     ` Ray Andrews
2022-10-15  2:34 ` Aaron Schrab
2022-10-15  2:57   ` Ray Andrews
2022-10-15  5:08     ` Bart Schaefer
2022-10-15 16:53       ` Ray Andrews
2022-10-17  1:07         ` Bart Schaefer
2022-10-17  3:40           ` Ray Andrews
2022-10-17  4:20             ` Bart Schaefer
2022-10-17  9:19               ` Pier Paolo Grassi
2022-10-17  9:24                 ` Pier Paolo Grassi
2022-10-17  9:31                   ` Pier Paolo Grassi
2022-10-17 16:11                     ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).