all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
@ 2019-11-26 18:34 Justin Paston-Cooper
  2019-11-26 19:45 ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Justin Paston-Cooper @ 2019-11-26 18:34 UTC (permalink / raw)
  To: 38392

Hello,

According to the documentation, zap-up-to-char allows one to kill up
to, but not including ARGth occurrence of CHAR. No reference is made
to zap-up-to-char in
https://www.gnu.org/software/emacs/manual/html_node/emacs/Killing.html
or https://www.gnu.org/software/emacs/manual/html_node/emacs/Command-Index.html.

It isn't immediately apparent from the documentation on zap-to-char in
the above sections, and also from the source of zap-to-char, that
there exists a way of zapping up to a char without writing this code
manually. I couldn't find any combination of keys, either, to press
after pressing M-z which would result in the same functionality.

It took me quite a while to come across zap-up-to-char. Could
documentation for this function be added to the Emacs manual?

Kind regards,

Justin





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-26 18:34 bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index" Justin Paston-Cooper
@ 2019-11-26 19:45 ` Eli Zaretskii
  2019-11-26 19:47   ` Justin Paston-Cooper
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2019-11-26 19:45 UTC (permalink / raw)
  To: Justin Paston-Cooper; +Cc: 38392

> From: Justin Paston-Cooper <paston.cooper@gmail.com>
> Date: Tue, 26 Nov 2019 19:34:37 +0100
> 
> According to the documentation, zap-up-to-char allows one to kill up
> to, but not including ARGth occurrence of CHAR. No reference is made
> to zap-up-to-char in
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Killing.html
> or https://www.gnu.org/software/emacs/manual/html_node/emacs/Command-Index.html.

I see it in Command-Index.html and in Other-Kill-Commands.html, which
is a subsection of "Deletion and Killing".  Not sure why you didn't
see it there.

> Could documentation for this function be added to the Emacs manual?

It's already there, AFAICT.

Thanks.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-26 19:45 ` Eli Zaretskii
@ 2019-11-26 19:47   ` Justin Paston-Cooper
  2019-11-26 20:05     ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Justin Paston-Cooper @ 2019-11-26 19:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 38392

I can see zap-to-char mentioned and linked in the above sections, but
not zap-***up***-to-char.

On Tue, 26 Nov 2019 at 20:45, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Justin Paston-Cooper <paston.cooper@gmail.com>
> > Date: Tue, 26 Nov 2019 19:34:37 +0100
> >
> > According to the documentation, zap-up-to-char allows one to kill up
> > to, but not including ARGth occurrence of CHAR. No reference is made
> > to zap-up-to-char in
> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Killing.html
> > or https://www.gnu.org/software/emacs/manual/html_node/emacs/Command-Index.html.
>
> I see it in Command-Index.html and in Other-Kill-Commands.html, which
> is a subsection of "Deletion and Killing".  Not sure why you didn't
> see it there.
>
> > Could documentation for this function be added to the Emacs manual?
>
> It's already there, AFAICT.
>
> Thanks.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-26 19:47   ` Justin Paston-Cooper
@ 2019-11-26 20:05     ` Eli Zaretskii
  2019-11-27 10:11       ` Justin Paston-Cooper
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2019-11-26 20:05 UTC (permalink / raw)
  To: Justin Paston-Cooper; +Cc: 38392

> From: Justin Paston-Cooper <paston.cooper@gmail.com>
> Date: Tue, 26 Nov 2019 20:47:54 +0100
> Cc: 38392@debbugs.gnu.org
> 
> I can see zap-to-char mentioned and linked in the above sections, but
> not zap-***up***-to-char.

Sorry, you are right.

This command isn't even in NEWS, so it's completely undocumented.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-26 20:05     ` Eli Zaretskii
@ 2019-11-27 10:11       ` Justin Paston-Cooper
  2019-11-27 15:40         ` Drew Adams
  2019-11-27 15:54         ` Eli Zaretskii
  0 siblings, 2 replies; 21+ messages in thread
From: Justin Paston-Cooper @ 2019-11-27 10:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 38392

What's the decision on this? If positive, should I email a patch, or
is there someone who deals with documentation?

On Tue, 26 Nov 2019 at 21:05, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Justin Paston-Cooper <paston.cooper@gmail.com>
> > Date: Tue, 26 Nov 2019 20:47:54 +0100
> > Cc: 38392@debbugs.gnu.org
> >
> > I can see zap-to-char mentioned and linked in the above sections, but
> > not zap-***up***-to-char.
>
> Sorry, you are right.
>
> This command isn't even in NEWS, so it's completely undocumented.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 10:11       ` Justin Paston-Cooper
@ 2019-11-27 15:40         ` Drew Adams
  2019-11-27 15:57           ` Justin Paston-Cooper
  2019-11-28  9:20           ` Stefan Kangas
  2019-11-27 15:54         ` Eli Zaretskii
  1 sibling, 2 replies; 21+ messages in thread
From: Drew Adams @ 2019-11-27 15:40 UTC (permalink / raw)
  To: Justin Paston-Cooper, Eli Zaretskii; +Cc: 38392

> not zap-***up***-to-char.

In Isearch we now have `isearch-yank-until-char'.

So we now have two different ways to name something
that deals with text from point forward to, but not
including, the position of some char: "up to" vs
"until".

It would be better to have a single way to name this.

---

Considering that the names `zap-to-char' and
`zap-up-to-char' are so close, and they can be
confused (witness Eli's missing the difference
here, at first), "until" seems a bit better.

On the other hand, "until" has a strong connotation
of time, and a weak one of space/distance.  And "up
to" is pretty clear, if taken apart from "to".

Really, `zap-to-char' should probably be called
`zap-through-char'.  I'd suggest using the terms
"until" (for "up to") and "through" (for zap "to").

In the improvements I suggested for Isearch (bug
#37417, emacs-devel thread "PATCH:
isearch-yank-until-match" and part of thread
"PATCH: isearch-yank-until-char"), I used
"through" for commands that act from point through
some position: `isearch-yank-through-new-match',
`isearch-yank-through-key-move', and
`isearch-yank-through-rec-edit-move'.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 10:11       ` Justin Paston-Cooper
  2019-11-27 15:40         ` Drew Adams
@ 2019-11-27 15:54         ` Eli Zaretskii
  1 sibling, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2019-11-27 15:54 UTC (permalink / raw)
  To: Justin Paston-Cooper; +Cc: 38392

> From: Justin Paston-Cooper <paston.cooper@gmail.com>
> Date: Wed, 27 Nov 2019 11:11:24 +0100
> Cc: 38392@debbugs.gnu.org
> 
> What's the decision on this? If positive, should I email a patch, or
> is there someone who deals with documentation?

I'm not sure we should have it in the manual.  The fact that you
wanted it doesn't yet mean it's useful enough to have in the manual.

Does anyone else have an opinion?





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 15:40         ` Drew Adams
@ 2019-11-27 15:57           ` Justin Paston-Cooper
  2019-11-27 16:04             ` Drew Adams
  2019-11-28  9:20           ` Stefan Kangas
  1 sibling, 1 reply; 21+ messages in thread
From: Justin Paston-Cooper @ 2019-11-27 15:57 UTC (permalink / raw)
  To: Drew Adams; +Cc: 38392

What about having a class of inclusivity modifiers of the form `C-I
element` (I is isomorphic to set of inclusivities {before, through,
after}), element is either RET for defining inclusivity alone, or a
`regexp RET` for including a certain pattern, similar to C-u, which
would pass an argument to things like C-f, C-b, C-s and do the
appropriate?

On Wed, 27 Nov 2019 at 16:42, Drew Adams <drew.adams@oracle.com> wrote:
>
> > not zap-***up***-to-char.
>
> In Isearch we now have `isearch-yank-until-char'.
>
> So we now have two different ways to name something
> that deals with text from point forward to, but not
> including, the position of some char: "up to" vs
> "until".
>
> It would be better to have a single way to name this.
>
> ---
>
> Considering that the names `zap-to-char' and
> `zap-up-to-char' are so close, and they can be
> confused (witness Eli's missing the difference
> here, at first), "until" seems a bit better.
>
> On the other hand, "until" has a strong connotation
> of time, and a weak one of space/distance.  And "up
> to" is pretty clear, if taken apart from "to".
>
> Really, `zap-to-char' should probably be called
> `zap-through-char'.  I'd suggest using the terms
> "until" (for "up to") and "through" (for zap "to").
>
> In the improvements I suggested for Isearch (bug
> #37417, emacs-devel thread "PATCH:
> isearch-yank-until-match" and part of thread
> "PATCH: isearch-yank-until-char"), I used
> "through" for commands that act from point through
> some position: `isearch-yank-through-new-match',
> `isearch-yank-through-key-move', and
> `isearch-yank-through-rec-edit-move'.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 15:57           ` Justin Paston-Cooper
@ 2019-11-27 16:04             ` Drew Adams
  2019-11-27 16:05               ` Justin Paston-Cooper
  0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2019-11-27 16:04 UTC (permalink / raw)
  To: Justin Paston-Cooper; +Cc: 38392

> What about having a class of inclusivity modifiers of the form `C-I
> element` (I is isomorphic to set of inclusivities {before, through,
                                                     ^^^^^^
> after}),
  ^^^^^
> element is either RET for defining inclusivity alone, or a
> `regexp RET` for including a certain pattern, similar to C-u, which
> would pass an argument to things like C-f, C-b, C-s and do the
> appropriate?

Just a comment about "before" and "after":

Those terms should be used only if the functionality
really does proceed in a particular buffer direction.

For example, the proposed Isearch commands I
mentioned, which have names with "through", can
work in either forward or backward direction, so
in their case "after" or "before" would be wrong,
for the command name.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 16:04             ` Drew Adams
@ 2019-11-27 16:05               ` Justin Paston-Cooper
  2019-11-27 16:44                 ` Drew Adams
  0 siblings, 1 reply; 21+ messages in thread
From: Justin Paston-Cooper @ 2019-11-27 16:05 UTC (permalink / raw)
  To: Drew Adams; +Cc: 38392

What about near, through and far?

On Wed, 27 Nov 2019 at 17:04, Drew Adams <drew.adams@oracle.com> wrote:
>
> > What about having a class of inclusivity modifiers of the form `C-I
> > element` (I is isomorphic to set of inclusivities {before, through,
>                                                      ^^^^^^
> > after}),
>   ^^^^^
> > element is either RET for defining inclusivity alone, or a
> > `regexp RET` for including a certain pattern, similar to C-u, which
> > would pass an argument to things like C-f, C-b, C-s and do the
> > appropriate?
>
> Just a comment about "before" and "after":
>
> Those terms should be used only if the functionality
> really does proceed in a particular buffer direction.
>
> For example, the proposed Isearch commands I
> mentioned, which have names with "through", can
> work in either forward or backward direction, so
> in their case "after" or "before" would be wrong,
> for the command name.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 16:05               ` Justin Paston-Cooper
@ 2019-11-27 16:44                 ` Drew Adams
  2019-11-27 19:35                   ` Justin Paston-Cooper
  0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2019-11-27 16:44 UTC (permalink / raw)
  To: Justin Paston-Cooper; +Cc: 38392

> What about near, through and far?

What about them?

I've already spoken to "through".  How do you
see "near" and "far" fitting into this?





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 16:44                 ` Drew Adams
@ 2019-11-27 19:35                   ` Justin Paston-Cooper
  2019-11-27 21:46                     ` Drew Adams
  0 siblings, 1 reply; 21+ messages in thread
From: Justin Paston-Cooper @ 2019-11-27 19:35 UTC (permalink / raw)
  To: Drew Adams; +Cc: 38392

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

Sorry for my terrible reading comprehension.

I suppose you’re saying that exactly two ‘inclusivities’ suffice: ‘up
to/until’ and 'through' in your case, which makes complete sense.

I have found that both 'up to' and 'until' are still ambiguous, for
instance when trying to agree on a date with someone. This ambiguity might
carry over to the Emacs world, where a user might not know that there is
another distinct inclusivity called 'through'. 'up to' and 'until' can mean
either 'inclusive' or 'exclusive', this seemingly depending on the phase of
the Moon. I still use the words 'inclusive' and 'exclusive' to confirm. I
hope that at least programmers don't find that silly. Of course, there is
an existing precedent of 'up to', 'until', 'through' and 'to'.

Regardless of the naming, wouldn’t an inclusivity modifier over the set of
two inclusivities be a nice thing to have?

On Wed, 27 Nov 2019 at 17:45, Drew Adams <drew.adams@oracle.com> wrote:

> > What about near, through and far?
>
> What about them?
>
> I've already spoken to "through".  How do you
> see "near" and "far" fitting into this?
>

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

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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 19:35                   ` Justin Paston-Cooper
@ 2019-11-27 21:46                     ` Drew Adams
  2019-11-27 22:10                       ` Justin Paston-Cooper
  0 siblings, 1 reply; 21+ messages in thread
From: Drew Adams @ 2019-11-27 21:46 UTC (permalink / raw)
  To: Justin Paston-Cooper; +Cc: 38392

> I suppose you’re saying that exactly two ‘inclusivities’ suffice: ‘up to/until’ and 'through' in your case, which makes complete sense.

I wasn't speaking to what might suffice.  I was just
pointing out that we use `up-to' for zapping and `until' for searching - and we mean the same thing by them.  And I mentioned `through' as a possible name for including the final char. 

> I have found that both 'up to' and 'until' are still ambiguous, for instance when trying to agree on a date with someone. This ambiguity might carry over to the Emacs world, where a user might not know that there is another distinct inclusivity called 'through'. 'up to' and 'until' can mean either 'inclusive' or 'exclusive', this seemingly depending on the phase of the Moon. I still use the words 'inclusive' and 'exclusive' to confirm. I hope that at least programmers don't find that silly. Of course, there is an existing precedent of 'up to', 'until', 'through' and 'to'.

Yes, the terms are ambiguous.  If we use consistent
names and the doc is clear then I don't think there's
a problem in practice.  But yes, in conversation,
and particularly with dates/times, people can need
to discuss a bit to be sure to be on the same page.

> Regardless of the naming, wouldn’t an inclusivity modifier over the set of two inclusivities be a nice thing to have?

No idea.  Modifier where?  Here we're talking about
function names.  I don't think we need to or should
add such a thing to the names.





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 21:46                     ` Drew Adams
@ 2019-11-27 22:10                       ` Justin Paston-Cooper
  2019-11-28  0:45                         ` Phil Sainty
  0 siblings, 1 reply; 21+ messages in thread
From: Justin Paston-Cooper @ 2019-11-27 22:10 UTC (permalink / raw)
  To: Drew Adams; +Cc: 38392

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

On Wed, 27 Nov 2019 at 22:46, Drew Adams <drew.adams@oracle.com> wrote:

> > I suppose you’re saying that exactly two ‘inclusivities’ suffice: ‘up
> to/until’ and 'through' in your case, which makes complete sense.
>
> I wasn't speaking to what might suffice.  I was just
> pointing out that we use `up-to' for zapping and `until' for searching -
> and we mean the same thing by them.  And I mentioned `through' as a
> possible name for including the final char.


>
> > I have found that both 'up to' and 'until' are still ambiguous, for
> instance when trying to agree on a date with someone. This ambiguity might
> carry over to the Emacs world, where a user might not know that there is
> another distinct inclusivity called 'through'. 'up to' and 'until' can mean
> either 'inclusive' or 'exclusive', this seemingly depending on the phase of
> the Moon. I still use the words 'inclusive' and 'exclusive' to confirm. I
> hope that at least programmers don't find that silly. Of course, there is
> an existing precedent of 'up to', 'until', 'through' and 'to'.
>
> Yes, the terms are ambiguous.  If we use consistent
> names and the doc is clear then I don't think there's
> a problem in practice.  But yes, in conversation,
> and particularly with dates/times, people can need
> to discuss a bit to be sure to be on the same page.


Fair enough.


>
> > Regardless of the naming, wouldn’t an inclusivity modifier over the set
> of two inclusivities be a nice thing to have?
>
> No idea.  Modifier where?  Here we're talking about
> function names.  I don't think we need to or should
> add such a thing to the names.


> The idea was that there could be a key combination entered before commands
related to movement, killing, searching and so on which would pass an
argument to those commands determining their inclusivity. Similar to the
idea behind T and t in viper-mode. Not sure how it would tie in with the
numerical argument, though.

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

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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 22:10                       ` Justin Paston-Cooper
@ 2019-11-28  0:45                         ` Phil Sainty
  2019-11-28 12:48                           ` Lars Ingebrigtsen
  2019-11-29 10:19                           ` Eli Zaretskii
  0 siblings, 2 replies; 21+ messages in thread
From: Phil Sainty @ 2019-11-28  0:45 UTC (permalink / raw)
  To: 38392

Eli wrote:
> I'm not sure we should have it in the manual.  The fact that you
> wanted it doesn't yet mean it's useful enough to have in the manual.
> 
> Does anyone else have an opinion?

Mentioning only one of the two commands just seems arbitrary,
so I think it should be either "both" or "neither" for the sake
of consistency.

I think the manual should mention both of them, and that their
docstrings should probably mention one another as well, so that
users can learn about these alternatives more easily.


-Phil






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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-27 15:40         ` Drew Adams
  2019-11-27 15:57           ` Justin Paston-Cooper
@ 2019-11-28  9:20           ` Stefan Kangas
  2019-11-28 16:42             ` Drew Adams
  1 sibling, 1 reply; 21+ messages in thread
From: Stefan Kangas @ 2019-11-28  9:20 UTC (permalink / raw)
  To: Drew Adams; +Cc: Justin Paston-Cooper, 38392

Drew Adams <drew.adams@oracle.com> writes:

> In Isearch we now have `isearch-yank-until-char'.
>
> So we now have two different ways to name something
> that deals with text from point forward to, but not
> including, the position of some char: "up to" vs
> "until".
>
> It would be better to have a single way to name this.
>
> ---
>
> Considering that the names `zap-to-char' and
> `zap-up-to-char' are so close, and they can be
> confused (witness Eli's missing the difference
> here, at first), "until" seems a bit better.
>
> On the other hand, "until" has a strong connotation
> of time, and a weak one of space/distance.  And "up
> to" is pretty clear, if taken apart from "to".
>
> Really, `zap-to-char' should probably be called
> `zap-through-char'.  I'd suggest using the terms
> "until" (for "up to") and "through" (for zap "to").

FWIW, I think `zap-until-char' and `zap-through-char' would be less
clear than the current names.

I agree with the point about consistency.  It would be better then to
rename `isearch-yank-until-char' to `isearch-yank-up-to-char' instead
of renaming the old commands, I think.

Best regards,
Stefan Kangas





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-28  0:45                         ` Phil Sainty
@ 2019-11-28 12:48                           ` Lars Ingebrigtsen
  2019-11-29 12:15                             ` Stefan Kangas
  2019-11-29 10:19                           ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-28 12:48 UTC (permalink / raw)
  To: Phil Sainty; +Cc: 38392

Phil Sainty <psainty@orcon.net.nz> writes:

> I think the manual should mention both of them, and that their
> docstrings should probably mention one another as well, so that
> users can learn about these alternatives more easily.

Yup.  Both variants seem equally useful (that is, not really  :-)).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-28  9:20           ` Stefan Kangas
@ 2019-11-28 16:42             ` Drew Adams
  0 siblings, 0 replies; 21+ messages in thread
From: Drew Adams @ 2019-11-28 16:42 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Justin Paston-Cooper, 38392

> > In Isearch we now have `isearch-yank-until-char'.
> >
> > So we now have two different ways to name something
> > that deals with text from point forward to, but not
> > including, the position of some char: "up to" vs
> > "until".
> >
> > It would be better to have a single way to name this.
> >
> > ---
> >
> > Considering that the names `zap-to-char' and
> > `zap-up-to-char' are so close, and they can be
> > confused (witness Eli's missing the difference
> > here, at first), "until" seems a bit better.
> >
> > On the other hand, "until" has a strong connotation
> > of time, and a weak one of space/distance.  And "up
> > to" is pretty clear, if taken apart from "to".
> >
> > Really, `zap-to-char' should probably be called
> > `zap-through-char'.  I'd suggest using the terms
> > "until" (for "up to") and "through" (for zap "to").
> 
> FWIW, I think `zap-until-char' and `zap-through-char' would be less
> clear than the current names.
> 
> I agree with the point about consistency.  It would be better then to
> rename `isearch-yank-until-char' to `isearch-yank-up-to-char' instead
> of renaming the old commands, I think.

No objection from me.

Consistency can help in general, but it's not an
imperative.  More important than global consistency
is local consistency (e.g. within Isearch, don't use
more than one way to name the same thing).

It's probably too late to change `zap-to-char', but
I think that `through' is clearer than `to', when
the char is included.  `zap-through-char' would be
clearer, and it's confusing to have both `-to-' and
`-up-to-'.

(There currently is no Isearch yank command that has
"through" semantics, but I added a couple in my code
and in the patch I submitted for bug #37417.)





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-28  0:45                         ` Phil Sainty
  2019-11-28 12:48                           ` Lars Ingebrigtsen
@ 2019-11-29 10:19                           ` Eli Zaretskii
  1 sibling, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2019-11-29 10:19 UTC (permalink / raw)
  To: Phil Sainty; +Cc: 38392-done

> Date: Thu, 28 Nov 2019 13:45:20 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> 
> Eli wrote:
> > I'm not sure we should have it in the manual.  The fact that you
> > wanted it doesn't yet mean it's useful enough to have in the manual.
> > 
> > Does anyone else have an opinion?
> 
> Mentioning only one of the two commands just seems arbitrary,
> so I think it should be either "both" or "neither" for the sake
> of consistency.
> 
> I think the manual should mention both of them, and that their
> docstrings should probably mention one another as well, so that
> users can learn about these alternatives more easily.

Thanks, done (I only added the reference to the doc string of
zap-to-char, though).





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-28 12:48                           ` Lars Ingebrigtsen
@ 2019-11-29 12:15                             ` Stefan Kangas
  2019-12-05  9:56                               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 21+ messages in thread
From: Stefan Kangas @ 2019-11-29 12:15 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Phil Sainty, 38392

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yup.  Both variants seem equally useful (that is, not really  :-)).

FWIW, I use zap-up-to-char almost every day.  Try it!  You might like
it, and end up being a weirdo like me.  ;-)

Best regards,
Stefan Kangas





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

* bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index"
  2019-11-29 12:15                             ` Stefan Kangas
@ 2019-12-05  9:56                               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2019-12-05  9:56 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Phil Sainty, 38392

Stefan Kangas <stefan@marxist.se> writes:

> FWIW, I use zap-up-to-char almost every day.  Try it!  You might like
> it, and end up being a weirdo like me.  ;-)

I'm very set in my "move the point around and kill the region" ways.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





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

end of thread, other threads:[~2019-12-05  9:56 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-26 18:34 bug#38392: zap-up-to-char should appear in "Deletion and Killing" Emacs info section and "Command Index" Justin Paston-Cooper
2019-11-26 19:45 ` Eli Zaretskii
2019-11-26 19:47   ` Justin Paston-Cooper
2019-11-26 20:05     ` Eli Zaretskii
2019-11-27 10:11       ` Justin Paston-Cooper
2019-11-27 15:40         ` Drew Adams
2019-11-27 15:57           ` Justin Paston-Cooper
2019-11-27 16:04             ` Drew Adams
2019-11-27 16:05               ` Justin Paston-Cooper
2019-11-27 16:44                 ` Drew Adams
2019-11-27 19:35                   ` Justin Paston-Cooper
2019-11-27 21:46                     ` Drew Adams
2019-11-27 22:10                       ` Justin Paston-Cooper
2019-11-28  0:45                         ` Phil Sainty
2019-11-28 12:48                           ` Lars Ingebrigtsen
2019-11-29 12:15                             ` Stefan Kangas
2019-12-05  9:56                               ` Lars Ingebrigtsen
2019-11-29 10:19                           ` Eli Zaretskii
2019-11-28  9:20           ` Stefan Kangas
2019-11-28 16:42             ` Drew Adams
2019-11-27 15:54         ` Eli Zaretskii

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.