bug#12217: [PATCH] Re: 24.2.50; append-to-register: Provide a convenient key binding

[Jambunathan K]

See attached patch.

Once patch goes through, I will submit a second part which updates
regs.texi.

Some context:

I usually to use M-x append-to-register (and with this patch `C-x r +')
to collect sexps. I think it will be convenient to have the collected
snippets separated by a suitable separator. Is it OK if a default "\n"
be used? WDYT. Note that this will be a departure from current
behaviour where the snippets are blindly concatenated.

ps: Patch should apply cleanly to below bzr version.

,----
| kjambunathan@debian-6:~/src/emacs/trunk$ bzr version-info
| revision-id: r...@gnu.org-20120817072823-0zjgqf10g1d0vcf1
| date: 2012-08-17 00:28:23 -0700
| build-date: 2012-08-17 15:17:41 +0530
| revno: 109655
| branch-nick: trunk
`----

[Stefan Monnier]

> Once patch goes through, I will submit a second part which updates
> regs.texi.

I think the change is OK. I would prefer a single `cond' form with the
`error' in the last branch (instead of unless+if) so as to avoid
a redundant `numberp' check (not as a matter of efficiency, of course,
but maintenance).
If you send such an updated patch with the corresponding regs.texi
change, we'll install it.

> I usually to use M-x append-to-register (and with this patch `C-x r +')
> to collect sexps. I think it will be convenient to have the collected
> snippets separated by a suitable separator. Is it OK if a default "\n"
> be used? WDYT.

I think I'd rather not add any separator by default. In many cases
adding such a separator would render the command inconvenient, and in
many others the user can easily make sure the text he appends includes
an appropriate separator.

I can see cases where adding a separator could be handy, but I'm not
sure hardcoding "\n" would solve enough of those cases. Maybe you could
prompt for a separator if the user provided a C-u prefix?


Stefan

[Jambunathan K]

Attaching modified patch. Patch is generated against revno: 109935.

>> Once patch goes through, I will submit a second part which updates
>> regs.texi.
>
> I think the change is OK. I would prefer a single `cond' form with the
> `error' in the last branch (instead of unless+if) so as to avoid
> a redundant `numberp' check (not as a matter of efficiency, of course,
> but maintenance).
> If you send such an updated patch with the corresponding regs.texi
> change, we'll install it.

Done.

>> I usually to use M-x append-to-register (and with this patch `C-x r +')
>> to collect sexps. I think it will be convenient to have the collected
>> snippets separated by a suitable separator. Is it OK if a default "\n"
>> be used? WDYT.
>
> I think I'd rather not add any separator by default.

> In many cases adding such a separator would render the command
> inconvenient, and in many others the user can easily make sure the
> text he appends includes an appropriate separator.

> I can see cases where adding a separator could be handy, but I'm not
> sure hardcoding "\n" would solve enough of those cases.

> Maybe you could prompt for a separator if the user provided a C-u
> prefix?

Prefix is used as a `delete-flag' already ...

I have introduced an extra indirection via a `separator-register' (which
is nil by default) Now what gets used as a separator - a newline, a
double newline, a comma or a tab - is under user control.

There is already one user - that is me - who will find this feature
useful.

[Stefan Monnier]

>> Maybe you could prompt for a separator if the user provided a C-u
>> prefix?
> Prefix is used as a `delete-flag' already ...

The way I read the current binding of C-x r + (increment-register), it
only uses the prefix to specify the number to add to the register, which
in the case of string concatenation is of no use.

So we can use the prefix of C-x + either the way you do in your current
patch (i.e. to specify the delete-flag of append-to-register) or we can
use it to specify the separator.

I understand that deleting the text is a common need, but you can do
that with C-x + C-w instead of C-u C-x +, so maybe it's OK to use C-u
for the separator.

> I have introduced an extra indirection via a `separator-register' (which
> is nil by default) Now what gets used as a separator - a newline, a
> double newline, a comma or a tab - is under user control.

I've renamed it to register-separator, because I'd rather that
register.el move (ever so slowly) to obey the "register-" prefix.


Stefan "Installed, thank you!"

[Andreas Schwab]

Jambunathan K <kjambu...@gmail.com> writes:

> I have introduced an extra indirection via a `separator-register' (which
> is nil by default) Now what gets used as a separator - a newline, a
> double newline, a comma or a tab - is under user control.

Why the extra indirection? Why not just make it a string and use it
directly?

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Jambunathan K]

Andreas Schwab <sch...@linux-m68k.org> writes:

> Jambunathan K <kjambu...@gmail.com> writes:
>
>> I have introduced an extra indirection via a `separator-register'
>> (which is nil by default) Now what gets used as a separator - a
>> newline, a double newline, a comma or a tab - is under user control.
>
> Why the extra indirection? Why not just make it a string and use it
> directly?

In short, Function before form and it is also about some workflows being
less intrusive than others.

Let's look at some use-cases.

Use-case-1 (A concrete one)

I find myself collecting sexps. (This is going to happen more as I
plan to explore more new codebases.)

When I look at existing code - with an intention to prepare some
patch - I find myself collecting recipes from 2 or 3 places. I then
"insert" it in to target location and put them together. Since the
recipes are collected from 2 or 3 places, they need to be visually
separated. Going forward I will store "double newline" (read
paragraph) as separator for these recipe blocks.

Note: Org exporters are moving to new framework. Now when I am
re-implementing some features in my (own) org-e-odt.el, I find
myself collecting recipes from org-export.el, org-e-latex.el and
felt sorry that the sexps are not visually separated.

Use-case-2 (Contrived one)

Now let's say I am a language learner and I am looking at a French
article from within Emacs. As I read through the article, I see
some words that need to be looked up. Instead of immediate lookup,
I may store the word or a phrase in a register and later insert in
to my language notes for further refinement. In this case, I may
want to separate them with a newline or even better something like
an Org-table.

In that case, in my scratch buffer I will type something like this
in scratch buffer, C-x r s + it and then collect away. I can then
paste that in to my Notes buffer and then re-align it using Org.


--8<---------------cut here---------------start------------->8---
|
|
--8<---------------cut here---------------end--------------->8---


This is how the collected table looks like

,----
| Now|
| |looked|
| |immediate|
| |further
`----

A string or a separator register
================================

It is easy for me to do "C-x r s" a separator rather to do a "M: (setq
separator "")". There is lesser context switch. A separator register
"guarantees" that the words are separated. This frees one from
remembering to store the surrounding separator and just focus on
collection process.




> Andreas.

[Jambunathan K]

> I've renamed it to register-separator, because I'd rather that
> register.el move (ever so slowly) to obey the "register-" prefix.

Looks like you failed to mark some files in work-area
before the commmit.

I still see references to separator-register in *.el file, NEWS and
Changelog files.

[Jambunathan K]

Andreas Schwab <sch...@linux-m68k.org> writes:

> Jambunathan K <kjambu...@gmail.com> writes:
>
>> I have introduced an extra indirection via a `separator-register' (which
>> is nil by default) Now what gets used as a separator - a newline, a
>> double newline, a comma or a tab - is under user control.
>
> Why the extra indirection? Why not just make it a string and use it
> directly?

Why registers when there is a kill ring? A text register is but a kill
ring.

Register is a framework and hence abstract.

The original authors needed it badly, took trouble to implement it, but
unfortunately failed to document what new workflows they enable. (I see
some references to number registers being used in conjunction with
macros - just about it.) Now a user is left to his own device to
contrive how a register should be used. It is like an incomplete
sentence begging for ....

Btw, no registers were killed in the preparation of the patch.

> Andreas.