all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Zap-to-char behaviour
@ 2003-05-20 20:40 Jérôme Marant
  2003-05-20 20:59 ` John Paul Wallington
  2003-05-21 15:31 ` Richard Stallman
  0 siblings, 2 replies; 18+ messages in thread
From: Jérôme Marant @ 2003-05-20 20:40 UTC (permalink / raw)



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

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

* Re: Zap-to-char behaviour
  2003-05-20 20:40 Jérôme Marant
@ 2003-05-20 20:59 ` John Paul Wallington
  2003-05-20 21:08   ` Jérôme Marant
  2003-05-21 15:31 ` Richard Stallman
  1 sibling, 1 reply; 18+ messages in thread
From: John Paul Wallington @ 2003-05-20 20:59 UTC (permalink / raw)
  Cc: emacs-devel

>   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 ?

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

* Re: Zap-to-char behaviour
  2003-05-20 20:59 ` John Paul Wallington
@ 2003-05-20 21:08   ` Jérôme Marant
  0 siblings, 0 replies; 18+ messages in thread
From: Jérôme Marant @ 2003-05-20 21:08 UTC (permalink / raw)


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

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

* Re: Zap-to-char behaviour
  2003-05-20 20:40 Jérôme Marant
  2003-05-20 20:59 ` John Paul Wallington
@ 2003-05-21 15:31 ` Richard Stallman
  2003-05-21 15:59   ` David Kastrup
  1 sibling, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2003-05-21 15:31 UTC (permalink / raw)
  Cc: emacs-devel

      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.

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

* Re: Zap-to-char behaviour
  2003-05-21 15:31 ` Richard Stallman
@ 2003-05-21 15:59   ` David Kastrup
  0 siblings, 0 replies; 18+ messages in thread
From: David Kastrup @ 2003-05-21 15:59 UTC (permalink / raw)
  Cc: emacs-devel

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

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

* Re: Zap-to-char behaviour
@ 2003-05-21 16:30 jmarant
  2003-05-21 17:37 ` Luc Teirlinck
  2003-05-23 12:04 ` Richard Stallman
  0 siblings, 2 replies; 18+ messages in thread
From: jmarant @ 2003-05-21 16:30 UTC (permalink / raw)


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/

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

* Re: Zap-to-char behaviour
  2003-05-21 16:30 Zap-to-char behaviour jmarant
@ 2003-05-21 17:37 ` Luc Teirlinck
  2003-05-21 19:03   ` Luc Teirlinck
  2003-05-21 20:31   ` Ehud Karni
  2003-05-23 12:04 ` Richard Stallman
  1 sibling, 2 replies; 18+ messages in thread
From: Luc Teirlinck @ 2003-05-21 17:37 UTC (permalink / raw)
  Cc: emacs-devel

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.

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

* Re: Zap-to-char behaviour
  2003-05-21 17:37 ` Luc Teirlinck
@ 2003-05-21 19:03   ` Luc Teirlinck
  2003-05-21 20:02     ` Jérôme Marant
  2003-05-21 20:31   ` Ehud Karni
  1 sibling, 1 reply; 18+ messages in thread
From: Luc Teirlinck @ 2003-05-21 19:03 UTC (permalink / raw)
  Cc: emacs-devel

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.

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

* Re: Zap-to-char behaviour
  2003-05-21 19:03   ` Luc Teirlinck
@ 2003-05-21 20:02     ` Jérôme Marant
  0 siblings, 0 replies; 18+ messages in thread
From: Jérôme Marant @ 2003-05-21 20:02 UTC (permalink / raw)


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

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

* Re: Zap-to-char behaviour
  2003-05-21 17:37 ` Luc Teirlinck
  2003-05-21 19:03   ` Luc Teirlinck
@ 2003-05-21 20:31   ` Ehud Karni
  2003-05-21 20:50     ` Jérôme Marant
                       ` (2 more replies)
  1 sibling, 3 replies; 18+ messages in thread
From: Ehud Karni @ 2003-05-21 20:31 UTC (permalink / raw)
  Cc: emacs-devel

-----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-----

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

* Re: Zap-to-char behaviour
  2003-05-21 20:31   ` Ehud Karni
@ 2003-05-21 20:50     ` Jérôme Marant
  2003-05-21 21:58     ` Luc Teirlinck
  2003-05-21 22:35     ` Luc Teirlinck
  2 siblings, 0 replies; 18+ messages in thread
From: Jérôme Marant @ 2003-05-21 20:50 UTC (permalink / raw)
  Cc: emacs-devel

"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

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

* Re: Zap-to-char behaviour
  2003-05-21 20:31   ` Ehud Karni
  2003-05-21 20:50     ` Jérôme Marant
@ 2003-05-21 21:58     ` Luc Teirlinck
  2003-05-21 22:35     ` Luc Teirlinck
  2 siblings, 0 replies; 18+ messages in thread
From: Luc Teirlinck @ 2003-05-21 21:58 UTC (permalink / raw)
  Cc: emacs-devel

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.

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

* Re: Zap-to-char behaviour
  2003-05-21 20:31   ` Ehud Karni
  2003-05-21 20:50     ` Jérôme Marant
  2003-05-21 21:58     ` Luc Teirlinck
@ 2003-05-21 22:35     ` Luc Teirlinck
  2 siblings, 0 replies; 18+ messages in thread
From: Luc Teirlinck @ 2003-05-21 22:35 UTC (permalink / raw)
  Cc: emacs-devel

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.

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

* Re: Zap-to-char behaviour
@ 2003-05-22  7:23 Jérôme Marant
  2003-05-22 15:56 ` Luc Teirlinck
  0 siblings, 1 reply; 18+ messages in thread
From: Jérôme Marant @ 2003-05-22  7:23 UTC (permalink / raw)


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/

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

* Re: Zap-to-char behaviour
  2003-05-22  7:23 Jérôme Marant
@ 2003-05-22 15:56 ` Luc Teirlinck
  2003-05-22 21:04   ` Jérôme Marant
  0 siblings, 1 reply; 18+ messages in thread
From: Luc Teirlinck @ 2003-05-22 15:56 UTC (permalink / raw)
  Cc: emacs-devel

[-- 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.

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

* Re: Zap-to-char behaviour
  2003-05-22 15:56 ` Luc Teirlinck
@ 2003-05-22 21:04   ` Jérôme Marant
  0 siblings, 0 replies; 18+ messages in thread
From: Jérôme Marant @ 2003-05-22 21:04 UTC (permalink / raw)
  Cc: emacs-devel

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

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

* Re: Zap-to-char behaviour
  2003-05-21 16:30 Zap-to-char behaviour jmarant
  2003-05-21 17:37 ` Luc Teirlinck
@ 2003-05-23 12:04 ` Richard Stallman
  2003-05-23 18:27   ` Jérôme Marant
  1 sibling, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2003-05-23 12:04 UTC (permalink / raw)
  Cc: emacs-devel

    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.

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

* Re: Zap-to-char behaviour
  2003-05-23 12:04 ` Richard Stallman
@ 2003-05-23 18:27   ` Jérôme Marant
  0 siblings, 0 replies; 18+ messages in thread
From: Jérôme Marant @ 2003-05-23 18:27 UTC (permalink / raw)
  Cc: emacs-devel

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

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

end of thread, other threads:[~2003-05-23 18:27 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-21 16:30 Zap-to-char behaviour jmarant
2003-05-21 17:37 ` Luc Teirlinck
2003-05-21 19:03   ` Luc Teirlinck
2003-05-21 20:02     ` Jérôme Marant
2003-05-21 20:31   ` Ehud Karni
2003-05-21 20:50     ` Jérôme Marant
2003-05-21 21:58     ` Luc Teirlinck
2003-05-21 22:35     ` Luc Teirlinck
2003-05-23 12:04 ` Richard Stallman
2003-05-23 18:27   ` Jérôme Marant
  -- strict thread matches above, loose matches on Subject: below --
2003-05-22  7:23 Jérôme Marant
2003-05-22 15:56 ` Luc Teirlinck
2003-05-22 21:04   ` Jérôme Marant
2003-05-20 20:40 Jérôme Marant
2003-05-20 20:59 ` John Paul Wallington
2003-05-20 21:08   ` Jérôme Marant
2003-05-21 15:31 ` Richard Stallman
2003-05-21 15:59   ` David Kastrup

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.