unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: 64185@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
	me@eshelyaron.com, zkanfer@gmail.com
Subject: bug#64185: proposal for new function: copy-line
Date: Sun, 25 Jun 2023 20:24:10 +0300	[thread overview]
Message-ID: <86a5wnmu3x.fsf@mail.linkov.net> (raw)
In-Reply-To: <8494C1C8-435A-4817-9FA0-7D0A5F8DEC96@gmail.com> ("Mattias Engdegård"'s message of "Sat, 24 Jun 2023 13:29:36 +0200")

>> It would be a major undertaking to design
>> a similar option for `duplicate-dwim` for consistency with `duplicate-line`
>> because of more decisions necessary to make: whether to move point
>> to the beginning or the end of the copied regions, whether to select
>> all the copied regions or only one of them, etc.
>
> Actually we are helped by some constraints: duplicate-dwim must keep
> the region active afterwards, so that the user can run the same
> command immediately and get another copy.  This is important for
> usability.

I don't see from where we can get such assumption - e.g. extending the region
to the copied text also makes sense.

> It seems reasonable to assume that a user wants the same behaviour in
> `duplicate-dwim` whether it is lines or columns being duplicated, and
> have a single variable controlling both.  This assumption may be
> wrong: perhaps a user prefers to stay when copying a line, but move
> when copying columns?

When the users will request a setting for columns, then we could
add a new option e.g. `duplicate-dwim-final-column`.

> If we use separate settings they should naturally work the same way,
> or users will wonder who is running the asylum.

It would be crazy to mix apples and oranges.  `duplicate-line-final-line`
should be applied only to `duplicate-line`.  And if the users need to
do the same with regions, then a separate option could be added
e.g. `duplicate-dwim-final-region`.

> A perhaps more intuitive way of describing the behaviour is not where
> to put point afterwards, but whether copies are inserted before or
> after the original.  That will generalise to duplication of regions,
> rectangular or contiguous, a little better.
>
> It's also easy to describe:
>
> (defcustom duplicate-direction 'after
>   "Where to insert the copies made by `duplicate-line' and `duplicate-dwim'.
> Valid values are `after' and `before' (the original text).
>   :group 'editing
>   :type '(choice (const :tag "After original" after)
>                  (const :tag "Before original" before)))
>
> What do you think?  Should we have a single setting for lines and
> regions, or individual settings for lines and regions, or for lines,
> rectangles and contiguous regions?

My first implementation of `duplicate-line` prepended the copied line
before the original line, and that implementation was flawed: it had
no visual feedback when copying the first line at the top of the window.

>> to my surprise the shortdoc of `substring` has no examples
>> of a negative argument.  I don't know whether this omission
>> is intentional to make the string section shorter.
>
> Thank you for noticing this. I doubt it was intentional.
> The examples have now been extended a bit.
> I'm sure we could do better with examples in general if we were to make an effort.

Thanks.

(Not sure why now one example uses boring "abcde"
instead of the overall style with "foo", "bar", "zot").





  reply	other threads:[~2023-06-25 17:24 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20  5:07 bug#64185: proposal for new function: copy-line Zachary Kanfer
2023-06-20  6:15 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-20 11:44   ` Eli Zaretskii
2023-06-22  3:33     ` Zachary Kanfer
2023-06-22  5:08       ` Eli Zaretskii
2023-06-22  6:57         ` Juri Linkov
2023-06-22 16:25           ` Eli Zaretskii
2023-06-22 17:27             ` Juri Linkov
2023-06-22 17:45               ` Eli Zaretskii
2023-06-22 18:13                 ` Drew Adams
2023-06-22 18:29                   ` Juri Linkov
2023-06-22 18:42                     ` Drew Adams
2023-06-22 18:52                       ` Juri Linkov
2023-06-22 19:05                         ` Drew Adams
2023-06-22 18:17                 ` Juri Linkov
2023-06-22 18:30                   ` Eli Zaretskii
2023-06-23  5:46                     ` Zachary Kanfer
2023-06-23  5:56                       ` Eli Zaretskii
2023-06-23  7:08                   ` Robert Pluim
2023-06-23  7:19                     ` Eli Zaretskii
2023-06-23  9:01                       ` Robert Pluim
2023-06-23 16:46                       ` Juri Linkov
2023-06-23  9:07 ` Mattias Engdegård
2023-06-23 10:28   ` Eli Zaretskii
2023-06-23 10:50     ` Mattias Engdegård
2023-06-23 11:07       ` Eli Zaretskii
2023-06-23 16:45   ` Juri Linkov
2023-06-24 11:29     ` Mattias Engdegård
2023-06-25 17:24       ` Juri Linkov [this message]
2023-06-25 19:46         ` Mattias Engdegård
2023-06-26 17:37           ` Juri Linkov
2023-06-26 17:56             ` Drew Adams
2023-06-26 18:35             ` Eli Zaretskii
2023-06-27 15:35             ` Mattias Engdegård
2023-06-27 18:28               ` Juri Linkov
2023-06-28 13:17                 ` Mattias Engdegård
2023-06-28 17:42                   ` Juri Linkov
2023-06-28 18:37                     ` Eli Zaretskii
2023-06-29  7:13                       ` Juri Linkov
2023-06-30 17:13                         ` Mattias Engdegård
2023-06-30 19:03                           ` Eli Zaretskii
2023-07-01  8:45                             ` Mattias Engdegård
2023-07-01  9:53                               ` Eli Zaretskii
2023-07-01 10:07                                 ` Mattias Engdegård
2023-07-01 10:22                                   ` Eli Zaretskii
2023-07-01 10:33                                     ` Mattias Engdegård
2023-06-25  3:45   ` Zachary Kanfer
2023-06-25 17:19     ` Juri Linkov
     [not found]       ` <CAFXT+RPRwpZgfPKsyz22+-v6vy7RJwyuwaOEkmunc2MAMSoqZA@mail.gmail.com>
     [not found]         ` <86h6qut970.fsf@mail.linkov.net>
2023-06-26 19:18           ` Zachary Kanfer
2023-06-27  2:25             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86a5wnmu3x.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=64185@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mattias.engdegard@gmail.com \
    --cc=me@eshelyaron.com \
    --cc=zkanfer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

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 read-only IMAP folder(s) and NNTP newsgroup(s).