Zap-to-char behaviour

Zap-to-char behaviour

[Jérôme Marant]

Hi,

  Currently, zap-to-char deletes every character up to
  a given character and including the said character.
  Does this behaviour satisfy most people?

  I personaly have rarely seen the need for removing
  this last character: usually, I want to remove
  characters up to a closing parenthesis or a semicolon
  for instance.

  Cheers, 

-- 
Jérôme Marant

Re: Zap-to-char behaviour

[John Paul Wallington]

>   Currently, zap-to-char deletes every character up to
>   a given character and including the said character.
>   Does this behaviour satisfy most people?
> 
>   I personaly have rarely seen the need for removing
>   this last character: usually, I want to remove
>   characters up to a closing parenthesis or a semicolon
>   for instance.

I don`t personally use `zap-to-char', so I don't know whether
killing up to and including char is a better default.

In the sources the code to avoid zapping said char is commented out.
How about having a seperate `zap-up-to-char' command ?

Re: Zap-to-char behaviour

[Jérôme Marant]

John Paul Wallington <jpw@gnu.org> writes:

> I don`t personally use `zap-to-char', so I don't know whether
> killing up to and including char is a better default.
>
> In the sources the code to avoid zapping said char is commented out.
> How about having a seperate `zap-up-to-char' command ?

  Why not, yes. One can always remap it afterwards.

  Thanks.

-- 
Jérôme Marant

http://marant.org

Re: Zap-to-char behaviour

[Richard Stallman]

      Currently, zap-to-char deletes every character up to
      a given character and including the said character.
      Does this behaviour satisfy most people?

It seems useful to me.  It means you can repeat the
command and it isn't a no-op.

When I don't really want to delete that character, I just type it
again.

Re: Zap-to-char behaviour

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       Currently, zap-to-char deletes every character up to
>       a given character and including the said character.
>       Does this behaviour satisfy most people?
> 
> It seems useful to me.  It means you can repeat the
> command and it isn't a no-op.

Well, if that was the main rationale, it would be easy enough just to
make sure that one deletes at least one character: namely ignore the
immediately following character when finding the next one to zap to.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Zap-to-char behaviour

[jmarant]

Richard Stallman <rms@gnu.org> a écrit :

> Currently, zap-to-char deletes every character up to
>       a given character and including the said character.
>       Does this behaviour satisfy most people?
> 
> It seems useful to me.  It means you can repeat the
> command and it isn't a no-op.
> 
> When I don't really want to delete that character, I just type it
> again.

Sure, that's what I have to do currently.

Anyway, would it be of any annoyance to add a
'zap-up-to-char' function which does the same as zap-to-char
except from removing the character? (I'm currently
not fluent at Elisp).

Thanks.

--
Jérôme Marant


___________________________________
Webmail Nerim, http://www.nerim.net/

Re: Zap-to-char behaviour

[Luc Teirlinck]

J. Marant wrote:

   Anyway, would it be of any annoyance to add a
   'zap-up-to-char' function which does the same as zap-to-char
   except from removing the character? (I'm currently
   not fluent at Elisp).

No, as John Paul Wallington already pointed out, all you need to do is
uncomment a comment in the function definition.  If you are planning
on using both functions, I would also suggest differentiating between
the two echo area messages.  Result:

(defun zap-up-to-char (arg char)
  "Kill up to, but not including ARG'th occurrence of CHAR.
Case is ignored if `case-fold-search' is non-nil in the current buffer.
Goes backward if ARG is negative; error if CHAR not found."
  (interactive "p\ncZap up to char: ")
  (kill-region (point) (progn
			 (search-forward (char-to-string char) nil nil arg)
			 (goto-char (if (> arg 0) (1- (point)) (1+ (point))))
			 (point))))

The problem now is that if you want to keep the regular M-z binding to
zap-to-char, then you probably will need to bind the new command to a
longer key sequence and it takes only one keystroke to retype the
character anyway.

Sincerely,

Luc.

Re: Zap-to-char behaviour

[Luc Teirlinck]

The function zap-up-to-char I sent you behaves strangely (like C-d) if
called with a zero argument.  Of course, it is not meant to be called
with zero argument.  If it were actually meant for inclusion in emacs,
we might want to do something else for a zero argument: no-op like M-z
or error message.

Sincerely,

Luc.

Re: Zap-to-char behaviour

[Jérôme Marant]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> The function zap-up-to-char I sent you behaves strangely (like C-d) if
> called with a zero argument.  Of course, it is not meant to be called
> with zero argument.  If it were actually meant for inclusion in emacs,
> we might want to do something else for a zero argument: no-op like M-z
> or error message.

Well, it's up to you to decide whether you want to include this function
in emacs. I personaly think it would be useful for some people like
me, and wouldn't cost much space.

If no, I'll put the function in my .emacs. Thanks for it anyway.

Cheers,

-- 
Jérôme Marant

http://marant.org

Re: Zap-to-char behaviour

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 21 May 2003 12:37:14 -0500 (CDT), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> 
> No, as John Paul Wallington already pointed out, all you need to do is
> uncomment a comment in the function definition.  If you are planning
> on using both functions, I would also suggest differentiating between
> the two echo area messages.  Result:
> 
> (defun zap-up-to-char (arg char)
>   "Kill up to, but not including ARG'th occurrence of CHAR.
> Case is ignored if `case-fold-search' is non-nil in the current buffer.
> Goes backward if ARG is negative; error if CHAR not found."
>   (interactive "p\ncZap up to char: ")
>   (kill-region (point) (progn
>                        (search-forward (char-to-string char) nil nil arg)
>                        (goto-char (if (> arg 0) (1- (point)) (1+ (point))))
>                        (point))))
> 
> The problem now is that if you want to keep the regular M-z binding to
> zap-to-char, then you probably will need to bind the new command to a
> longer key sequence and it takes only one keystroke to retype the
> character anyway.

No, that is not enough, because, as RMS pointed out, running this a
second time (when arg = 1, the default) will do nothing. This will
make it inconsistent (2 times M-3 `zap-up-to-char' will be different
from 3 * M-2 `zap-up-to-char'). If you want a consistent function I
propose the following:


(defun zap-up-to-char (arg char)
  "Kill up to, but not including ARG'th occurrence of CHAR.
Case is ignored if `case-fold-search' is non-nil in the current buffer.
Goes backward if ARG is negative; error if CHAR not found.
If ARG is 0, do nothing. If character at (point) is CHAR skip it."
  (interactive "p\ncZap up to char: ")
  (or (zerop arg)
      (let ((direction (if (> arg 0) 1 -1)))
           (kill-region (point)
                        (progn
                           (forward-char direction)
                           (search-forward (char-to-string char) nil nil arg)
                           (- (point) direction)))
           (backward-char direction))))

This was was tested lightly and it seems consistent. The kill ring
is also seems OK when repeating the operation several times.

My personal opinion is that `zap-to-char' is good enough for me and
I don't need this one, but if you want it, it better be good.

Ehud.


- -- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE+y+IuLFvTvpjqOY0RAmAiAJ0YLJxEe8cZhuZLKBIbNxRWMcJk5gCfY9Kj
QpPJf2tv/z+aHmQWFRwRz/w=
=CsQ7
-----END PGP SIGNATURE-----

Re: Zap-to-char behaviour

[Jérôme Marant]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> This was was tested lightly and it seems consistent. The kill ring
> is also seems OK when repeating the operation several times.
>
> My personal opinion is that `zap-to-char' is good enough for me and
> I don't need this one, but if you want it, it better be good.

I tried it and it works fine. Whether you include it or not, I'm
going to use it right now :-)

Thanks a lot.

Cheers,

-- 
Jérôme Marant

http://marant.org

Re: Zap-to-char behaviour

[Luc Teirlinck]

Ehud Karni wrote:

   If you want a consistent function I propose the following:

Your function seems indeed to be an improvement.

   My personal opinion is that `zap-to-char' is good enough for me and
   I don't need this one,

I do not personally see the need for zap-up-to-char either, because it
is so easy to retype the character that M-z already prompted for.
However, if your usage is such that you know that you *never* will
want to erase the character, then rebinding M-z to zap-up-to-char
might be useful.

Sincerely,

Luc.

Re: Zap-to-char behaviour

[Luc Teirlinck]

Ehud Karni wrote:

   The kill ring also seems OK

Actually, not putting the unwanted character in the kill ring might be
an extra argument for providing `zap-up-to-char', but I personally do
not use zap-to-char sufficiently often to have strong opinions on the
issue.

Sincerely,

Luc.

Re: Zap-to-char behaviour

[Jérôme Marant]

Luc Teirlinck <teirllm@dms.auburn.edu> a écrit :

> Actually, not putting the unwanted character in the kill ring might be
> an extra argument for providing `zap-up-to-char', but I personally do
> not use zap-to-char sufficiently often to have strong opinions on the
> issue.

Why would we want to put the unwanted character in
the kill ring?

--
Jérôme Marant

___________________________________
Webmail Nerim, http://www.nerim.net/

Re: Zap-to-char behaviour

[Luc Teirlinck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

J. Marant wrote:

   Luc Teirlinck <teirllm@dms.auburn.edu> a écrit :

   > Actually, not putting the unwanted character in the kill ring might be
   > an extra argument for providing `zap-up-to-char', but I personally do
   > not use zap-to-char sufficiently often to have strong opinions on the
   > issue.

   Why would we want to put the unwanted character in
   the kill ring?

I meant that I have no strong opinions on whether zap-up-to-char
should be provided.  If it is provided then the non-killed character
should obviously not be put in the kill ring.

Sincerely,

Luc.

Re: Zap-to-char behaviour

[Jérôme Marant]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I meant that I have no strong opinions on whether zap-up-to-char
> should be provided.  If it is provided then the non-killed character
> should obviously not be put in the kill ring.

OK. I see.

Cheers,

-- 
Jérôme Marant

http://marant.org

Re: Zap-to-char behaviour

[Richard Stallman]

    Anyway, would it be of any annoyance to add a
    'zap-up-to-char' function which does the same as zap-to-char
    except from removing the character?

I see no point in it, but I won't object if someone else adds it.
It could go in misc.el.

Re: Zap-to-char behaviour

[Jérôme Marant]

Richard Stallman <rms@gnu.org> writes:

>     Anyway, would it be of any annoyance to add a
>     'zap-up-to-char' function which does the same as zap-to-char
>     except from removing the character?
>
> I see no point in it, but I won't object if someone else adds it.
> It could go in misc.el.

It would be nice to add it, if you please.

Cheers,

-- 
Jérôme Marant

http://marant.org