A different way to interactively pass options to commands

A different way to interactively pass options to commands

[Clemens]

Adjusting commands on call is traditionally done via universal prefix
argument. This is mostly nice for numeric repetitions but often it is
also used to change the behavior of a command in other ways and
sometimes even multiple ways depending on the number of times `C-u` is
used.

The recent discussion around changing `interactive' made me think
about ways to improve that. Magit has shown a real nice UI approach to
pass options with its transient menus. Maybe a simpler but similar
mechanism could be added which could also be configured via
`interactive'. Any opinions on this?

Re: A different way to interactively pass options to commands

[Stefan Monnier]

> The recent discussion around changing `interactive' made me think
> about ways to improve that. Magit has shown a real nice UI approach to
> pass options with its transient menus. Maybe a simpler but similar
> mechanism could be added which could also be configured via
> `interactive'. Any opinions on this?

Yes, maybe.

FWIW, there are other prefix commands than C-u.
There's `C-x RET c`.
In the `other-frame-window` GNU ELPA package there are such prefix
commands to force the use of "other frame" or "other window" (arguably
there could/should be one for "same window" as well).

I personally also use the one below.


        Stefan


(defun copy-next-command-output ()
  "Prefix command to add the output of the next command to the `kill-ring`."
  (interactive)
  (let ((md (minibuffer-depth))
        (marker (with-current-buffer "*Messages*"
                  (point-max-marker))))
    (cl-labels ((pre ()
                     (unless (> (minibuffer-depth) md)
                       (add-hook 'post-command-hook #'post)
                       (prepare)))
                (prepare ()
                         (with-current-buffer "*Messages*"
                           (move-marker marker (point-max))))
                (preserve ()
                          (unless (> (minibuffer-depth) md)
                            (remove-hook 'post-command-hook #'post)
                            (add-hook 'pre-command-hook #'pre)))
                (echo ()
                      (unless (> (minibuffer-depth) md)
                        "[copy-output]"))
                (post ()
                      (if (> (minibuffer-depth) md)
                          ;; Prepare, in case there's no pre-command-hook before
                          ;; the next post-command-hook.  E.g. in the case of
                          ;; execute-extended-command.
                          (prepare)
                        (remove-hook 'pre-command-hook #'pre)
                        (remove-hook 'post-command-hook #'post)
                        (remove-hook 'prefix-command-preserve-state-hook
                                     #'preserve)
                        (remove-hook 'prefix-command-echo-keystrokes-functions
                                     #'echo)
                        (prefix-command-update)
                        (with-current-buffer (marker-buffer marker)
                          (when (< marker (point-max))
                            (kill-new (buffer-substring marker (point-max)))))
                          (set-marker marker nil))))
      (add-hook 'prefix-command-preserve-state-hook #'preserve)
      (add-hook 'prefix-command-echo-keystrokes-functions #'echo)
      ;; (message "BEFORE: prefix-arg=%S current-prefix-arg=%S"
      ;;          prefix-arg current-prefix-arg)
      (prefix-command-preserve-state)
      ;; (message "AFTER: prefix-arg=%S current-prefix-arg=%S"
      ;;          prefix-arg current-prefix-arg)
      )))

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Clemens <clemera@posteo.net> writes:

> Adjusting commands on call is traditionally done via universal prefix
> argument. This is mostly nice for numeric repetitions but often it is
> also used to change the behavior of a command in other ways and
> sometimes even multiple ways depending on the number of times `C-u` is
> used.

Yes, `C-u' is the only hammer we have here, unfortunately...  (And
adding commands that are variants of each other.)

> The recent discussion around changing `interactive' made me think
> about ways to improve that. Magit has shown a real nice UI approach to
> pass options with its transient menus. Maybe a simpler but similar
> mechanism could be added which could also be configured via
> `interactive'. Any opinions on this?

What does the Magit UI look like?

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

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, there are other prefix commands than C-u.
> There's `C-x RET c`.

I just recalled that I added something I called "Symbolic Prefixes" to
Gnus in the 90s...  It's bound to `M-i' in Gnus buffers, and you can use
any char as the prefix.  So `M-i r s' will sort in reverse order (in the
group buffer).  Or something like that.

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

Re: A different way to interactively pass options to commands

[Clemens]

> What does the Magit UI look like?

Here is an example

    https://magit.vc/screenshots/popup-diff-arguments.png

taken from

     https://emacsair.me/2017/09/01/magit-walk-through/

Or checkout the beginning of this Video:

     https://www.youtube.com/watch?v=2-0OwGTt0dI

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Clemens <clemera@posteo.net> writes:

>> What does the Magit UI look like?
>
> Here is an example
>
>    https://magit.vc/screenshots/popup-diff-arguments.png
>
> taken from
>
>     https://emacsair.me/2017/09/01/magit-walk-through/
>
> Or checkout the beginning of this Video:
>
>     https://www.youtube.com/watch?v=2-0OwGTt0dI

Thanks.  So it's like a ... mega-popup key menu thing.  It does seem
quite nice -- it makes command discovery very "in your face": You can't
help but know what your options are.

But it's a quite radical departure from other commands in Emacs.

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

Re: A different way to interactively pass options to commands

[Clemens]

> Thanks.  So it's like a ... mega-popup key menu thing.  It does seem
> quite nice -- it makes command discovery very "in your face": You can't
> help but know what your options are.
> 
> But it's a quite radical departure from other commands in Emacs.

You would actively requesting the display with the prefix. Options
could also be displayed in the minibuffer but that room is filled up
quickly.

Re: A different way to interactively pass options to commands

[Clemens]

> Thanks.  So it's like a ... mega-popup key menu thing.  It does seem
> quite nice -- it makes command discovery very "in your face": You can't
> help but know what your options are.
> 
> But it's a quite radical departure from other commands in Emacs.

There could also be a delay so if you know the keys you could skip the
popup display. But more important to me would be the concept itself:
The author of a command can defined keys which adjust the behavior and
callers can call these commands with a prefix and than are queried for
the option key.

Re: A different way to interactively pass options to commands

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Clemens <clemera@posteo.net> writes:
>
>> Adjusting commands on call is traditionally done via universal prefix
>> argument. This is mostly nice for numeric repetitions but often it is
>> also used to change the behavior of a command in other ways and
>> sometimes even multiple ways depending on the number of times `C-u` is
>> used.
>
> Yes, `C-u' is the only hammer we have here, unfortunately...  (And
> adding commands that are variants of each other.)
>
>> The recent discussion around changing `interactive' made me think
>> about ways to improve that. Magit has shown a real nice UI approach to
>> pass options with its transient menus. Maybe a simpler but similar
>> mechanism could be added which could also be configured via
>> `interactive'. Any opinions on this?
>
> What does the Magit UI look like?

Here is what happens when you invoke the `magit-diff' command:

https://magit.vc/screenshots/popup-diff.png

BTW, Org has an interface for some commands that looks like Magit's, but
in essence has some fundamental differences.

When Magit's popup interface was conceived (by yours truly) we were
running out of shortcuts: git has too many features and its interface is
so barroque, that it was not realistic to provide a command-based
interface based on Emacs' command+modifier+prompt interface. Another
problem to overcome was ergonomy and discoverability. The later was
provided by displaying the available options along with a short
description and the former by requiring a minimal and consistent
sequence of keypresses. For instance: showing the log of the current
repository with default options is `ll' (two els); showing the log of
all branches is `la'; showing the log of all branches along with the
corresponding patch for each commit is `l-pa', and so on.

This works very well at wrapping the complexity of git's UI with another
one that is more approachable and agile.

So, could Emacs take advantage of something like this? I think so. Think
of VC, just to mention a package on the same application area
(furthermore, VC has to deal with multiple backends, which makes it
potentially more complex than Magit.) Adding a new switch to some VC
command is a big deal, from the UI perspective and from the integration
with other optiones, and then you end either with a new command or with
a new variable, of which existence the user is not aware until he does
some investigation.

I could implement an analogue, Emacs-oriented Magit popup system, or
just borrow the implementation of it that Magit's current maintainer so
well polished. IIRC Org considered doing that on the past. The second
part is to decide to which part of Emacs to apply it. VC is a good
candidate, although a bit too large since the internal code must be
adapted to groak the information provided by the popup and that may
require too many changes and potential destabilization, as well as being
disruptive from the UI point of view.

IMAO Emacs presents very good oportunities to improve its usability. The
command filtering that we are currently discussing is just a tiny step
(and a sizable basis) on that direction that, along with other much
larger changes, I envisioned on the past.

Re: A different way to interactively pass options to commands

[Stefan Monnier]

>> FWIW, there are other prefix commands than C-u.
>> There's `C-x RET c`.
> I just recalled that I added something I called "Symbolic Prefixes" to
> Gnus in the 90s...  It's bound to `M-i' in Gnus buffers, and you can use
> any char as the prefix.  So `M-i r s' will sort in reverse order (in the
> group buffer).  Or something like that.

Nice.  It'd be great to make it use the `prefix-command-*` thingies so
they appear in the echo-keystrokes and can be combined with other
prefixes like C-u.


        Stefan


PS: I'm not completely satisfied with those `prefix-command-*` thingies,
BTW, so if someone wants to improve them, that'd also be welcome.

Re: A different way to interactively pass options to commands

[Stefan Monnier]

>> Thanks.  So it's like a ... mega-popup key menu thing.  It does seem
>> quite nice -- it makes command discovery very "in your face": You can't
>> help but know what your options are.
>> But it's a quite radical departure from other commands in Emacs.
>
> There could also be a delay so if you know the keys you could skip the
> popup display. But more important to me would be the concept itself:
> The author of a command can defined keys which adjust the behavior and
> callers can call these commands with a prefix and than are queried for
> the option key.

Indeed, these are more like Gnus's `M-i` (as well as a few other such
cases, PCL-CVS also had such prefix commands) in that they are somewhat
specific to a (set of) commands, whereas the other examples I mentioned
tend to be usable with "any" other command (tho they may end up doing
nothing in many cases).


        Stefan

Re: A different way to interactively pass options to commands

[Stefan Monnier]

> So, could Emacs take advantage of something like this? I think so.

IIUC Magit uses the `transient` package for that functionality, right?

I do think it gives a very nice user experience for some things.

The most obvious case that comes to my mind is those of major modes that
have several of `C-c C-<foo> C-<bar>` bindings (e.g. to insert code
templates or other such things) which I never even try to use because
I find those key bindings just much too long to remember.

So, yes, I do hope that this gets adopted more widely.


        Stefan

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> For instance: showing the log of the current
> repository with default options is `ll' (two els); showing the log of
> all branches is `la'; showing the log of all branches along with the
> corresponding patch for each commit is `l-pa', and so on.

I see; interesting.

> So, could Emacs take advantage of something like this? I think so.

Yes, it does sound quite attractive.  For instance, in Gnus, when
responding to a message, there's...  I don't know how many commands.
Let's see:

S F		gnus-summary-followup-with-original
S L		gnus-summary-reply-to-list-with-original
S N		gnus-summary-followup-to-mail-with-original
S R		gnus-summary-reply-with-original
S V		gnus-summary-very-wide-reply-with-original
S W		gnus-summary-wide-reply-with-original
S f		gnus-summary-followup
S n		gnus-summary-followup-to-mail
S r		gnus-summary-reply
S v		gnus-summary-very-wide-reply
S w		gnus-summary-wide-reply
S B R		gnus-summary-reply-broken-reply-to-with-original
S B r		gnus-summary-reply-broken-reply-to

13!  Geez.  Anyway, the interface you describe would fit this use case
well, it seems to me: The choices are whether to include the original or
not, and what subset of the To/Cc's to include in the set...  Currently,
users are probably tapping `S C-h' and then learn what the binding is,
and then using that.  And then forgetting until the next time.

A Magit-like popup menu would probably be a much superior interface
here, I think?

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

Re: A different way to interactively pass options to commands

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So, could Emacs take advantage of something like this? I think so.
>
> IIUC Magit uses the `transient` package for that functionality, right?

The popup functionality was segregated to its own package, yes.

> I do think it gives a very nice user experience for some things.

Yes, for some. For other things it is not the right thing.

It shines for configuring actions. If you have one action that works
depending on multiple options, this UI is great. But if you have many
actions, it is of no use. The later conforms more to Emacs' M-x, menu
and shortcut-based UI.

> The most obvious case that comes to my mind is those of major modes that
> have several of `C-c C-<foo> C-<bar>` bindings (e.g. to insert code
> templates or other such things) which I never even try to use because
> I find those key bindings just much too long to remember.

Org suffers from that kind of key binding proliferation, but IIRC most
of them are different actions, although conceptually related (commands
that operate on tags, for instance.) For now I solve those cases with
M-x, ido and the flx algorithm.

Re: A different way to interactively pass options to commands

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, it does sound quite attractive.  For instance, in Gnus, when
> responding to a message, there's...  I don't know how many commands.
> Let's see:
>
> S F		gnus-summary-followup-with-original
> S L		gnus-summary-reply-to-list-with-original
> S N		gnus-summary-followup-to-mail-with-original
> S R		gnus-summary-reply-with-original
> S V		gnus-summary-very-wide-reply-with-original
> S W		gnus-summary-wide-reply-with-original
> S f		gnus-summary-followup
> S n		gnus-summary-followup-to-mail
> S r		gnus-summary-reply
> S v		gnus-summary-very-wide-reply
> S w		gnus-summary-wide-reply
> S B R		gnus-summary-reply-broken-reply-to-with-original
> S B r		gnus-summary-reply-broken-reply-to
>
> 13!  Geez.

I know that pain well enough ;-)

> Anyway, the interface you describe would fit this use case
> well, it seems to me: The choices are whether to include the original or
> not, and what subset of the To/Cc's to include in the set...  Currently,
> users are probably tapping `S C-h' and then learn what the binding is,
> and then using that.  And then forgetting until the next time.
>
> A Magit-like popup menu would probably be a much superior interface
> here, I think?

That case is a piece of cake for the Magit popup approach, it is almost
too simple. What you have there is just the beginnings of a little
combinatorial explosion.

But then come the long-term advantages: by using the popup approach, if
you wish to add a new parameter you don't need to define 13 new
commands, you just register the parameter with the popup (along with its
corresponding short description) and your UI problem is solved, but much
better: you have discoverability, the user is not overwhelmed by a long
list of commands (he just combines parameters and then starts actions),
you don't have to worry about menus that grow too long, exhausting keys,
etc. and the whole process is almost as fast as using the S** shortcuts
you have now (one key to start the popup, one key for activating each
parameter and one key for launching the action), but with an explicit
interface that shows what you are about to do.

Re: A different way to interactively pass options to commands

[Clemens]

> Org suffers from that kind of key binding proliferation, but IIRC most
> of them are different actions, although conceptually related (commands
> that operate on tags, for instance.) For now I solve those cases with
> M-x, ido and the flx algorithm.

There is also the nice orderless package:

https://github.com/oantolin/orderless

It provides a completion-style which is very flexible and also
features initialism matching like flx. Internally it uses
completion-regexp-list + all-completions so it is very fast. You can
even customize individual components by defining dispatchers for
example I can append an equal sign to some input ("input=") to match 
that input literally or for fuzzy matching I use "match~" it is very nice.

Re: A different way to interactively pass options to commands

[Doug Davis]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, it does sound quite attractive.  For instance, in Gnus, when
> responding to a message, there's...  I don't know how many commands.
> Let's see:
>
> S F		gnus-summary-followup-with-original
> S L		gnus-summary-reply-to-list-with-original
> S N		gnus-summary-followup-to-mail-with-original
> S R		gnus-summary-reply-with-original
> S V		gnus-summary-very-wide-reply-with-original
> S W		gnus-summary-wide-reply-with-original
> S f		gnus-summary-followup
> S n		gnus-summary-followup-to-mail
> S r		gnus-summary-reply
> S v		gnus-summary-very-wide-reply
> S w		gnus-summary-wide-reply
> S B R		gnus-summary-reply-broken-reply-to-with-original
> S B r		gnus-summary-reply-broken-reply-to
>
> 13!  Geez.  Anyway, the interface you describe would fit this use case
> well, it seems to me: The choices are whether to include the original or
> not, and what subset of the To/Cc's to include in the set...  Currently,
> users are probably tapping `S C-h' and then learn what the binding is,
> and then using that.  And then forgetting until the next time.
>
> A Magit-like popup menu would probably be a much superior interface
> here, I think?

I think the menu of gnus-summary response functions can definitely
benefit from something like transient. Below is a proof-of-concept I
just used to call `gnus-summary-wide-reply-with-original' after binding
a new pop-up function to "." followed up by invoking the desired gnus
function with "-w", "-o", "r".

The total number of keystrokes is a bit more than "S W" but the
interface is indeed a welcome addition that would help with
discoverability of the (potentially many) actions, as Óscar mentioned,
if/when the actions and arguments grow. The flag arguments also make it
clear that "-w, --wide" and "-o, --original" are add-ons to the core
action.

I'm sure there's room for refinement; my transient use has been limited
to useless tinkering as a curious magit user, this is honestly the first
real use I've gotten out of writing transient-using code myself ;)
thanks for sparking the idea

#+begin_src emacs-lisp

;; package code:

(require 'transient)
(require 'gnus-sum)

(defun gp--reply-action (&optional args)
  (interactive
   (list (transient-args 'gnus-summary-popup)))
  (let ((-v (member "--very" args))
        (-w (member "--wide" args))
        (-o (member "--original" args)))
    (call-interactively
     (cond ((and -v -w -o) 'gnus-summary-very-wide-reply-with-original)
           ((and -v -w)    'gnus-summary-very-wide-reply)
           ((and -w -o)    'gnus-summary-wide-reply-with-original)
           (-w             'gnus-summary-wide-reply)
           (-o             'gnus-summary-reply-with-original)
           (t              'gnus-summary-reply)))))

(define-transient-command gnus-summary-popup ()
  "Gnus reply popup"
  ["Arguments"
   ("-v" "very" "--very")
   ("-w" "wide" "--wide")
   ("-o" "original" "--original")]
  ["Actions"
   ("r" "Reply" gp--reply-action)])

(provide 'gnus-popup)

;; user code:

(require 'gnus-popup)
(define-key gnus-summary-mode-map (kbd ".") 'gnus-summary-popup)

#+end_src

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Doug Davis <ddavis@ddavis.io> writes:

> I think the menu of gnus-summary response functions can definitely
> benefit from something like transient. Below is a proof-of-concept I
> just used to call `gnus-summary-wide-reply-with-original' after binding
> a new pop-up function to "." followed up by invoking the desired gnus
> function with "-w", "-o", "r".

Wow, cool -- that was little code (and quite clear code) to achieve
this, so it looks like transient.el is very well designed.

So what's the copyright assignment status of transient.el?  :-)  If
we're going to use this throughout Emacs, I guess making it a core
package would be the way to go?

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

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> and the whole process is almost as fast as using the S** shortcuts
> you have now (one key to start the popup, one key for activating each
> parameter and one key for launching the action), but with an explicit
> interface that shows what you are about to do.

Yes, I'm sold on the concept.  :-)

I can also imagine using it on the Gnus scoring commands (which
implements a system that's not entirely unlike this (sort of, if you
squint), but not as user-friendly), and as Stefan M mentioned, skeleton
selections could use this, and the `C-x C-m' thing, perhaps.

Of course, we can't change the current interfaces, but this would be an
additional way to navigate particularly complex (combinatorial-ish)
commands.

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

Re: A different way to interactively pass options to commands

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So what's the copyright assignment status of transient.el?  :-)  If
> we're going to use this throughout Emacs, I guess making it a core
> package would be the way to go?

Jonas (CC'd) proposed Transient for inclusion to GNU ELPA 10 months
ago[1]; afair the thread got derailed because of namespacing issues?

[1] <87368npxw4.fsf@bernoul.li>
    https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01829.html

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Jonas (CC'd) proposed Transient for inclusion to GNU ELPA 10 months
> ago[1]; afair the thread got derailed because of namespacing issues?

*sigh*  This mailing list, man...  It's a classic emacs-devel thread with
230 messages, most of them talking about how "assoc" is a bad name for a
function that deals with alists or not, all of which is 100% irrelevant
for transient.el.

Anyway, that's irrelevant.  (Oops.)

I've downloaded transient.el now, and had a skim-through, and it looks
top notch.  So I think putting it on ELPA is a no-brainer.  But I think
it makes sense to make it a core package?  (I.e., put it into
emacs.git.)  Will that be a problem, maintenance wise, for anybody?

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

Re: A different way to interactively pass options to commands

[Dmitry Gutov]

On 18.02.2021 12:52, Lars Ingebrigtsen wrote:
> But I think
> it makes sense to make it a core package?  (I.e., put it into
> emacs.git.)  Will that be a problem, maintenance wise, for anybody?

I hope it's going to be in the core because it's going to be used by 
some code there (even if just as an optional feature).

Re: A different way to interactively pass options to commands

[Stefan Monnier]

> Jonas (CC'd) proposed Transient for inclusion to GNU ELPA 10 months
> ago[1]; afair the thread got derailed because of namespacing issues?

It's in `elpa.git` and you can get a package from it at:

    http://elpa.gnu.org/devel/transient.html

For some reason, Jonas hasn't considered it "ready enough" to make
a *release*, yet.  Maybe Jonas can remind me/us what are the missing elements.


        Stefan

Re: A different way to interactively pass options to commands

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've downloaded transient.el now, and had a skim-through, and it looks
> top notch.  So I think putting it on ELPA is a no-brainer.  But I think
> it makes sense to make it a core package?  (I.e., put it into
> emacs.git.)  Will that be a problem, maintenance wise, for anybody?

It is an obvious candidate to be a core package, but I suspect that the
maintainer intends to keep growing it externally, so probably it needs
to be under a different namespace on core.

Development snapshots on GNU ELPA (was: A different way to interactively pass options to commands)

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It's in `elpa.git` and you can get a package from it at:
>
>     http://elpa.gnu.org/devel/transient.html

Well *huh*.  Thanks for

(1) correcting me

(2) making me realize GNU ELPA has development snapshots now (is it just
    me, or was this somewhat under-advertised?  IIUC this happened
    during the birth of NonGNU ELPA?)

(3) making me realize I owe you for cleaning up my mess in adaptive-wrap

all with one link 👏

Re: A different way to interactively pass options to commands

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.02.2021 12:52, Lars Ingebrigtsen wrote:
>> But I think
>> it makes sense to make it a core package?  (I.e., put it into
>> emacs.git.)  Will that be a problem, maintenance wise, for anybody?
>
> I hope it's going to be in the core because it's going to be used by
> some code there (even if just as an optional feature).

+1

transient.el can and should be used widely.  My vote is strongly for
distributing it with Emacs.

Re: A different way to interactively pass options to commands

[Dmitry Gutov]

On 18.02.2021 19:45, Stefan Kangas wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> On 18.02.2021 12:52, Lars Ingebrigtsen wrote:
>>> But I think
>>> it makes sense to make it a core package?  (I.e., put it into
>>> emacs.git.)  Will that be a problem, maintenance wise, for anybody?
>> I hope it's going to be in the core because it's going to be used by
>> some code there (even if just as an optional feature).
> +1
> 
> transient.el can and should be used widely.  My vote is strongly for
> distributing it with Emacs.

Alternatively, it could stay a "bundled ELPA" package (Stephen L has 
been working on that feature), with the same effect.

That might make maintenance easier for Jonas while 'transient' is still 
developed externally.

Re: A different way to interactively pass options to commands

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> transient.el can and should be used widely.  My vote is strongly for
>> distributing it with Emacs.
>
> Alternatively, it could stay a "bundled ELPA" package (Stephen L has
> been working on that feature), with the same effect.
>
> That might make maintenance easier for Jonas while 'transient' is still
> developed externally.

Sure, it can wait until we have that support fully worked out.  There is
no particular rush.

The important thing to me is that we should eventually be able to use it
in Emacs itself.

(Of course, it would be very nice to have it bundled somehow already in
Emacs 28.)

Re: A different way to interactively pass options to commands

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > (defun copy-next-command-output ()
  >   "Prefix command to add the output of the next command to the `kill-ring`."

It looks useful, but wouldn't copy-previous-command-output be better?
With that, you could make the decision after running the other command
and seeing its output.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A different way to interactively pass options to commands

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The intro to Magit, which I watched via invidious rather than by
accessing youtube itself, displays text so small I have trouble
reading it.  I can't see what the options say.  But I think I
understand the general scheme that is in use.

I see how it makes sense for a special mode, for a buffer in which
letters can be used as commands.  But how can this be applied
to an ordinary buffer in which letters self-insert?


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A different way to interactively pass options to commands

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> I see how it makes sense for a special mode, for a buffer in which
> letters can be used as commands.  But how can this be applied
> to an ordinary buffer in which letters self-insert?

The transient UI is only displayed when running a command.  For example,
I would press `c' in magit to show the popup for the commit action.

In some text mode with self-inserting letters, you would run a command
with a modifier instead, like you would any command.

To hide the popup, you would need to press `C-g' to hide the popup.
That would stop letters from being interpreted as commands (i.e. make
them self-insert again).

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> The important thing to me is that we should eventually be able to use it
> in Emacs itself.
>
> (Of course, it would be very nice to have it bundled somehow already in
> Emacs 28.)

Yup.  But in whatever way is most convenient for Jonas.

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

Re: A different way to interactively pass options to commands

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It's in `elpa.git` and you can get a package from it at:
>
>     http://elpa.gnu.org/devel/transient.html
>
> For some reason, Jonas hasn't considered it "ready enough" to make
> a *release*, yet.  Maybe Jonas can remind me/us what are the missing elements.

Ah -- I only checked with `M-x list-packages', but it won't show up
there until there's a Version header in transient.el (that's bigger than
zero), I guess?

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

Re: A different way to interactively pass options to commands

[Stefan Monnier]

>   > (defun copy-next-command-output ()
>   >   "Prefix command to add the output of the next command to the `kill-ring`."
>
> It looks useful, but wouldn't copy-previous-command-output be better?
> With that, you could make the decision after running the other command
> and seeing its output.

Of course, but while it's easy to predict the future, it can be
hard to find what happened after the fact ;-)


        Stefan

Re: A different way to interactively pass options to commands

[Stefan Monnier]

> Ah -- I only checked with `M-x list-packages', but it won't show up
> there until there's a Version header in transient.el (that's bigger than
> zero), I guess?

Or until you add http://elpa.gnu.org/devel/ to your
`package-archives`, yes.


        Stefan

Re: A different way to interactively pass options to commands

[Jonas Bernoulli]

>> Jonas (CC'd) proposed Transient for inclusion to GNU ELPA 10 months
>> ago[1]; afair the thread got derailed because of namespacing issues?

This time around the timing is very good. This week I have been working
on getting Transient ready for another release and was already planning
to publish that to GNU Elpa today. And then I saw this thread, while
drinking my morning tea. :D

> For some reason, Jonas hasn't considered it "ready enough" to make a
> *release*, yet.  Maybe Jonas can remind me/us what are the missing
> elements.

I probably was worried about the heisenbug, that I have not been able
to track down until earlier this week.

Also I didn't want to publish until I was able to building the package
locally before publishing it on GNU Elpa.  Now that you have rewritten
the GNU Elpa tooling that works well (thanks again), so that no longer
is a blocker.  (We still have to look into making org-contrib and my
ox-texinfo+ available while building packages, but that can wait.)

So if everything goes according to plan, I will release later today,
or maybe on the weekend.

     Jonas

Re: A different way to interactively pass options to commands

[Clemens]

> So if everything goes according to plan, I will release later today,
> or maybe on the weekend.

What are your thoughts about the discussion of including it in Emacs? I 
think having it built-in would be a huge benefit.

Re: A different way to interactively pass options to commands

[Phil Sainty]

On 18/02/21 9:09 am, Lars Ingebrigtsen wrote:
> Yes, `C-u' is the only hammer we have here, unfortunately...
> (And adding commands that are variants of each other.)
> [...]
> What does the Magit UI look like?

If it helps, this pair of messages provides another description:

* https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg02036.html
* https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00000.html

The second message is more descriptive, but the first one contains
the link for the referenced video.

GNU-devel and NonGNU-devel (was: A different way to interactively pass options to commands)

[Basil L. Contovounesios]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Ah -- I only checked with `M-x list-packages', but it won't show up
>> there until there's a Version header in transient.el (that's bigger than
>> zero), I guess?
>
> Or until you add http://elpa.gnu.org/devel/ to your
> `package-archives`, yes.

Out of curiosity (apologies if these are already answered somewhere):

What are the exact differences in theory and practice between
elpa.gnu.org/devel and elpa.gnu.org/packages, and
elpa.nongnu.org/nongnu-devel and elpa.nongnu.org/nongnu?

Are the devel archives intended as (possibly WIP) counterparts to MELPA?

Based on which criteria are new versions of devel packages released, and
are they subject to :auto-sync in the same way as non-devel packages?

Can the two devel archives be used as drop-in replacements for the
default package-archives?

What are the pros/cons of doing so from a user's perspective?

Thanks,

-- 
Basil

Re: GNU-devel and NonGNU-devel

[Stefan Monnier]

> What are the exact differences in theory and practice between
> elpa.gnu.org/devel and elpa.gnu.org/packages, and
> elpa.nongnu.org/nongnu-devel and elpa.nongnu.org/nongnu?

The devel archives contain tarballs which reflect the current tip of the
Git branch (the one stored in `elpa.git` or `nongnu.git`, not
necessarily the same as the one upstream).

In contrast the non-devel archives only contain tarballs for those
commits where the `Version:` was changed.

> Are the devel archives intended as (possibly WIP) counterparts to MELPA?

It can be thought of as following the model of the non-stable part of
MELPA, but that doesn't make it MELPA to me at all since MELPA is
defined rather by the breadth of its coverage.

> Based on which criteria are new versions of devel packages released, and
> are they subject to :auto-sync in the same way as non-devel packages?

Sync'ing the elpa.git/nongnu.git branches with their upstream is
somewhat orthogonal to the devel-vs-release archives: the sync'ing is
always done between the upstream and the corresponding
elpa.git/nongnu.git branch.  This sync'ing is done for all package in
nongnu.git and only for those tagged with :auto-sync in elpa.git.
Once a sync brings changes to a branch, that will always result in a new
tarball in the devel archive, but it will only result in a new package
in the release archive is the `Version:` changed.

> Can the two devel archives be used as drop-in replacements for the
> default package-archives?

If you're willing to use bleeding edge code, yes.

> What are the pros/cons of doing so from a user's perspective?

The risk of breakage?


        Stefan

Re: A different way to interactively pass options to commands

[Jonas Bernoulli]

>> So if everything goes according to plan, I will release later today,
>> or maybe on the weekend.

I made it, but just barely: https://emacsair.me/2021/02/21/transient-0.3/.

> What are your thoughts about the discussion of including it in Emacs?
> I think having it built-in would be a huge benefit.

I am excited at the prospect of having some core packages use Transient.
But also a bit scared.  In the short run we should keep it in elpa.git.

Some bad interaction with the minibuffer have to be fixed (currently
they are just disallowed, to prevent disaster) before adding to Emacs.
I would prefer the "bundled elpa package" approach over adding the
package to emacs.git itself, but don't know if that feature is already
usable.

Re: A different way to interactively pass options to commands

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 359 bytes --]

1+.

The other  slight concern I have re transient being in core Emacs is
that if the one outside the core moves faster, then as a user of Magit
I'd have to have both versions around ---

That said, I think transient would be wonderful to have a part of emacs
so more packages can use it

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Questions about transient (was: Re: A different way to interactively pass options to commands)

[Joost Kremers]

On Mon, Feb 22 2021, Jonas Bernoulli wrote:
> I am excited at the prospect of having some core packages use Transient.

If transient is included in Emacs core, that would be a good reason for me to
consider moving one of my packages, for which I'm currently using hydras, over
to it.

But I have a few questions about transient, that don't seem to be covered by the
manual. What would be the best place to ask them? This list? The Discussion page
on Github? (They're not really suitable for Github issues.)

TIA

-- 
Joost Kremers
Life has its moments

Re: Questions about transient (was: Re: A different way to interactively pass options to commands)

[Jonas Bernoulli]

Joost Kremers <joostkremers@fastmail.fm> writes:

> But I have a few questions about transient, that don't seem to be covered by the
> manual. What would be the best place to ask them? This list? The Discussion page
> on Github? (They're not really suitable for Github issues.)

Well if they are of interest to other people here then...
here probably.  ;-)

(But search the issue tracker first; other might have had
the same questions before.)

RE: [External] : Questions about transient (was: Re: A different way to interactively pass options to commands)

[Drew Adams]

> If transient is included in Emacs core, that would be a good reason for
> me to consider moving one of my packages

This.  A 3rd-party library is (much) more likely to make use of something that's part of Emacs than it is to provide code that hard-code depends on an external library.

Re: Questions about transient (was: Re: A different way to interactively pass options to commands)

[Joost Kremers]

On Mon, Feb 22 2021, Jonas Bernoulli wrote:
> Joost Kremers <joostkremers@fastmail.fm> writes:
>
>> But I have a few questions about transient, that don't seem to be covered by the
>> manual. What would be the best place to ask them? This list? The Discussion page
>> on Github? (They're not really suitable for Github issues.)
>
> Well if they are of interest to other people here then...
> here probably.  ;-)

I'm not sure they would be of interest to others here, so it might be better to
take them to Github.

Anyway, I'll need to find some time, so expect them some time this week but not
today. :-)



-- 
Joost Kremers
Life has its moments

Re: A different way to interactively pass options to commands

[Stephen Leake]

Jonas Bernoulli <jonas@bernoul.li> writes:

>> What are your thoughts about the discussion of including it in Emacs?
>> I think having it built-in would be a huge benefit.
>
> I would prefer the "bundled elpa package" approach over adding the
> package to emacs.git itself, but don't know if that feature is already
> usable.

Since transient is a single elisp file, the simplest approach is to put
it in emacs.git under lisp, and enter it in elpa as a :core package.
Then emacs.git is the upstream development repo.

The proposed policy for bundled elpa packages is that core emacs code
may not depend on them; on the other hand, core emacs code may depend on
:core elpa packages.

-- 
-- Stephe

Re: A different way to interactively pass options to commands

[Jonas Bernoulli]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>>> What are your thoughts about the discussion of including it in Emacs?
>>> I think having it built-in would be a huge benefit.
>>
>> I would prefer the "bundled elpa package" approach over adding the
>> package to emacs.git itself, but don't know if that feature is already
>> usable.
>
> Since transient is a single elisp file, the simplest approach is to put
> it in emacs.git under lisp, and enter it in elpa as a :core package.
> Then emacs.git is the upstream development repo.

Plus transient.texi.
Does that change anything?

> The proposed policy for bundled elpa packages is that core emacs code
> may not depend on them; on the other hand, core emacs code may depend on
> :core elpa packages.

Well that decides it then; core it is.

Re: GNU-devel and NonGNU-devel

[Basil L. Contovounesios]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What are the exact differences in theory and practice between
>> elpa.gnu.org/devel and elpa.gnu.org/packages, and
>> elpa.nongnu.org/nongnu-devel and elpa.nongnu.org/nongnu?
>
> The devel archives contain tarballs which reflect the current tip of the
> Git branch (the one stored in `elpa.git` or `nongnu.git`, not
> necessarily the same as the one upstream).
>
> In contrast the non-devel archives only contain tarballs for those
> commits where the `Version:` was changed.
>
>> Are the devel archives intended as (possibly WIP) counterparts to MELPA?
>
> It can be thought of as following the model of the non-stable part of
> MELPA, but that doesn't make it MELPA to me at all since MELPA is
> defined rather by the breadth of its coverage.

Right, I was referring specifically to its default bleeding edge update
model.

>> Based on which criteria are new versions of devel packages released, and
>> are they subject to :auto-sync in the same way as non-devel packages?
>
> Sync'ing the elpa.git/nongnu.git branches with their upstream is
> somewhat orthogonal to the devel-vs-release archives: the sync'ing is
> always done between the upstream and the corresponding
> elpa.git/nongnu.git branch.  This sync'ing is done for all package in
> nongnu.git and only for those tagged with :auto-sync in elpa.git.
> Once a sync brings changes to a branch, that will always result in a new
> tarball in the devel archive, but it will only result in a new package
> in the release archive is the `Version:` changed.
>
>> Can the two devel archives be used as drop-in replacements for the
>> default package-archives?
>
> If you're willing to use bleeding edge code, yes.
>
>> What are the pros/cons of doing so from a user's perspective?
>
> The risk of breakage?

Makes sense.  Thanks for the info and for working on these,

-- 
Basil