delete-word does not delete the entire word...

delete-word does not delete the entire word...

[DervishD]

    Hi all :)

    When I issue delete-word in a line like this:

    asridfds jf'_'invnck fhdsfjh shdfasdf

    where '_' is the cursor position, the entire word jfinvnck is not
deleted, just the portion between the cursor and the end of the word.
That's not what I expect, and the manual is pretty terse: delete-word
delete the current word.

    I'm using 4.0.7, with the default WORDCHARS contents, and I've
noticed that this seems to be the standard behaviour of this kind of
widget: kill-word does the same, backward-delete-word too, etc...

    This is not exactly a problem for me, but before creating a new
widget that deletes from the start of the word using the existing
ones I would like to know if the problem is... me. If I'm doing
something wrong I would like to know O:)

    Thanks a lot in advance :))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: delete-word does not delete the entire word...

[Bart Schaefer]

On Oct 11,  2:10pm, DervishD wrote:
} 
}     When I issue delete-word in a line like this:
} 
}     asridfds jf'_'invnck fhdsfjh shdfasdf
} 
}     where '_' is the cursor position, the entire word jfinvnck is not
} deleted, just the portion between the cursor and the end of the word.
} That's not what I expect

Out of curiosity, WHY is that not what you expect?

It's pretty standard behavior of unix-derived text editors to treat the
cursor position as dividing the buffer into two parts, and then acting
on only one of those parts at a time.

Re: delete-word does not delete the entire word...

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> }     where '_' is the cursor position, the entire word jfinvnck is not
> } deleted, just the portion between the cursor and the end of the word.
> } That's not what I expect
> Out of curiosity, WHY is that not what you expect?

    Because when I want to delete a word, I mean the entire word, not
just a portion from the cursor O:) Back when I used bash, I didn't
mess with words, really. In fact I wasn't doing with zsh, neither,
but recently I bind delete-word and delete-backward-word for speed. I
don't know what happens in other shells :??? Anyway, with zsh I can
modify this behaviour :)

> It's pretty standard behavior of unix-derived text editors to treat
> the cursor position as dividing the buffer into two parts, and then
> acting on only one of those parts at a time.

    Maybe, I don't really know. I don't feel like telling what I
think about vi or emacs, but when documentation say 'word' I assume
'entire word', not 'from cursor position to...' ;)) You're right: my
usual editor, joe, does just the same, and I suppose all editors do
the same (believe it or not, I don't use delete word commands in joe
at all...). That's why I was asking. Obviously, it's my fault O:)
I'll write a wrapper around word deletion commands so they act on the
entire word ;)

    Thanks for pointing that, I thought that 'joe' was acting on
complete words, but it is not true! 

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: delete-word does not delete the entire word...

[Bart Schaefer]

On Oct 11,  9:51pm, DervishD wrote:
}
}     Maybe, I don't really know. I don't feel like telling what I
} think about vi or emacs, but when documentation say 'word' I assume
} 'entire word', not 'from cursor position to...' ;))

What you're missing is that the documentation nearly always is expressed
in terms of character positions, not semantic buffer contents.  Thus
the suffix -word in a command name means the prefix (delete, forward,
upcase, etc.) is applied across the range of characters from the cursor
position to the next character that represents a word boundary; not to
the semantic entity that you think of as "a word".

Re: delete-word does not delete the entire word...

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> }     Maybe, I don't really know. I don't feel like telling what I
> } think about vi or emacs, but when documentation say 'word' I assume
> } 'entire word', not 'from cursor position to...' ;))
> What you're missing is that the documentation nearly always is expressed
> in terms of character positions, not semantic buffer contents.

    That's the problem, maybe: I haven't understood that from the
documentation. I mean, the docs talks about LBUFFER, RBUFFER, cursor
positions, etc... when talking about zle widgets, for example, but
doesn't say explicitly (I think, I haven't read the entire
documentation) that a word is not a semantic entity but just the
buffer contents from the cursor position to the next word boundary.
That's why I asked.

    I must confess that before asking I did a search on the mailing
list archives, and didn't found anyone asking anything similar. That
should be a clue for me that the problem was entirely mine. Maybe if
I had used more word-commands in my favourite editor or in my
ocassional uses of vi, I would have been less surprised with the way
of working of zle. Better luck next time :)

    Thanks for your help.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: delete-word does not delete the entire word...

[Bart Schaefer]

On Oct 12, 10:57am, DervishD wrote:
}
}  * Bart Schaefer <schaefer@brasslantern.com> dixit:
} > What you're missing is that the documentation nearly always is
} > expressed in terms of character positions, not semantic buffer
} > contents.
} 
} [Zsh doc] doesn't say explicitly (I think, I haven't read the entire
} documentation) that a word is not a semantic entity but just the
} buffer contents from the cursor position to the next word boundary.

You're right, it doesn't. Most of the functions emulate behavior of
emacs or vi, so the doc assumes the reader is familiar with one of
those.  It also doesn't clearly explain what it means to "kill" vs.
"delete" a part of the buffer.  That was OK when those parts of the
docs were written several years ago, but is not the best thing now.

Incidentally, a wrapper function to delete the word under the cursor
is a little tricky to write.  You can't just do

	zle backward-word
	zle delete-word

because if the cursor is on the very first letter this is equivalent
to backward-delete-word.  You either need to examine $LBUFFER[-1] to
determine if it is [not] a word boundary, or do something like

	local cursor=$CURSOR
	zle backward-word
	zle forward-word
	if ((cursor >= CURSOR))
	then
	    zle delete-word
	else
	    zle backward-delete-word
	fi

Re: delete-word does not delete the entire word...

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> } > What you're missing is that the documentation nearly always is
> } > expressed in terms of character positions, not semantic buffer
> } > contents.
> } [Zsh doc] doesn't say explicitly (I think, I haven't read the entire
> } documentation) that a word is not a semantic entity but just the
> } buffer contents from the cursor position to the next word boundary.
> You're right, it doesn't. Most of the functions emulate behavior of
> emacs or vi, so the doc assumes the reader is familiar with one of
> those.

    I assume that, at the moment of writing, 99% of UNIX users used
vi or emacs (or both...), so this behaviour was the expected
behaviour. In fact, since I haven't used word commands, this
behaviour is good for me, I can live with it, without writing
wrappers, and I should live with it, since my editor does exactly the
same, and it's very comfortable to have the same keybindings in the
shell and the editor (at least for me, I spend most of my time coding
or doing things in the shell). The problem, IMHO, is not the
behaviour, is the documentation, that should be more precise.

> That was OK when those parts of the docs were written several years
> ago, but is not the best thing now.

    And updating the documentation is several times harder than
updating the code, I have that problem when coding ;)) Anyway, zsh
docs are pretty good on the average. I like them ;)

> Incidentally, a wrapper function to delete the word under the cursor
> is a little tricky to write.

    Writing zle widgets is tricky. I've written a couple of them
lately, just for learning, and it has been a bit tricky. I've written
wrappers for up-line-or-search and down-line-or-search which searchs
$LBUFFER, not the first word. Like up/down-line-or-beginning-search,
that comes with zsh 4.1.x, but without bells and whistles: no NUMERIC
support, no zstyles, and an easy handling of PREBUFFER.

    I have a problem with it, not easy to solve since it has to do
with carrying information from the current execution of the widget to
the next execution of the widget, etc...

> You either need to examine $LBUFFER[-1] to
> determine if it is [not] a word boundary

    But that means dealing with WORDCHARS. I prefer your suggestion
of doing a double movement and testing where the cursor is
afterwards. BTW, thanks ;)))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: delete-word does not delete the entire word...

[Peter Stephenson]

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

DervishD wrote:
> > Incidentally, a wrapper function to delete the word under the cursor
> > is a little tricky to write.
> 
>     Writing zle widgets is tricky.

If you have 4.1, much of the work is done for you; see the description
of match-words-by-style in the zshcontrib manual.  Here's a function
using it (which consequently won't work in 4.0) which can go into the
distribution when the glitches have been ironed out.

A side effect is that you can decide using styles what constitutes a
word, as described in the same section of the manual.


[-- Attachment #2: delete-whole-word --]
[-- Type: text/plain, Size: 938 bytes --]

emulate -L zsh
setopt extendedglob

local curcontext=:zle:delete-whole-word
local -a matched_words
# Start and end of range of characters to remove.
integer pos1 pos2

match-words-by-style

if [[ -n "${matched_words[3]}" ]]; then
    # There's whitespace before the cursor, so the word we are deleting
    # starts at the cursor position.
    pos1=$CURSOR
else
    # No whitespace before us, so delete any wordcharacters there.
    pos1="${#matched_words[1]}"
fi

if [[ -n "${matched_words[4]}" ]]; then
    # There's whitespace at the cursor position, so only delete
    # up to the cursor position.
    pos2=$CURSOR
else
    # No whitespace at the cursor position, so delete the
    # current character and any following wordcharacters.
    (( pos2 = CURSOR + ${#matched_words[5]} + 1 ))
fi

# Move the cursor and delete the block in one go for the
# purpose of yanking.
(( CURSOR = pos1 ))
BUFFER="${BUFFER[1,pos1]}${BUFFER[pos2,-1]}"

[-- Attachment #3: Type: text/plain, Size: 111 bytes --]

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: delete-word does not delete the entire word...

[Bart Schaefer]

On Oct 12,  7:31pm, Peter Stephenson wrote:
} 
} If you have 4.1, much of the work is done for you; see the description
} of match-words-by-style in the zshcontrib manual.
[...]
} A side effect is that you can decide using styles what constitutes a
} word, as described in the same section of the manual.

I almost mentioned the -match functions, but decided not to because the
manual section for them has no examples of the corresponding styles.

} [ delete-whole-word ] :
}
} emulate -L zsh
} setopt extendedglob

Why does this need extendedglob?

} # Move the cursor and delete the block in one go for the
} # purpose of yanking.
} (( CURSOR = pos1 ))
} BUFFER="${BUFFER[1,pos1]}${BUFFER[pos2,-1]}"

I'm a little puzzled by that comment.  This is delete-whole-word, not
kill-whole-word, so there shouldn't be any expectation of yanking ...
and in fact when I try it I can't yank the word that was deleted.

It's clear from kill-word-match that BUFFER edits are not automatically
propagated to CUTBUFFER.  Which makes sense ...

Re: delete-word does not delete the entire word...

[DervishD]

    Hi Peter :)

 * Peter Stephenson <pws@pwstephenson.fsnet.co.uk> dixit:
> >     Writing zle widgets is tricky.
> If you have 4.1, much of the work is done for you; see the description
> of match-words-by-style in the zshcontrib manual.

    I don't have 4.1.x, not for everyday use (I have 4.0.7 for that),
but I have a local installation of 4.1 for testing things like those.

    Anyway I like to write my own widgets when necessary, in order to
learn more of zsh. Nice example, by the way :))) Thanks a lot

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: delete-word does not delete the entire word...

[Peter Stephenson]

Bart Schaefer wrote:
> I almost mentioned the -match functions, but decided not to because the
> manual section for them has no examples of the corresponding styles.

Look in select-word-style, which is the simple interface, not requiring
explicit styles set by the user.  If you'd like the styles there shown
in the manual, too, fine.

> } [ delete-whole-word ] :
> }
> } emulate -L zsh
> } setopt extendedglob
> 
> Why does this need extendedglob?

It probably doesn't, but I turn that on as a matter of course, since
otherwise it's not there when I need it, or I've made it difficult to
turn it on later, etc.  In any case, whenever I use patterns I assume
extended globbing is present even if I don't use it.

> } # Move the cursor and delete the block in one go for the
> } # purpose of yanking.
> } (( CURSOR = pos1 ))
> } BUFFER="${BUFFER[1,pos1]}${BUFFER[pos2,-1]}"
> 
> I'm a little puzzled by that comment.  This is delete-whole-word, not
> kill-whole-word, so there shouldn't be any expectation of yanking ...
> and in fact when I try it I can't yank the word that was deleted.

Yes, I meant `undo' rather than yank.  You should find it undoes in one
go.

> It's clear from kill-word-match that BUFFER edits are not automatically
> propagated to CUTBUFFER.  Which makes sense ...

Indeed, there's a complete separate interface as used in the other
-match functions.  (I should have called this one
delete-whole-word-match for consistency.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************