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?
> 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)
)))
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
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
> 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
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
> 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.
> 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.
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.
>> 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.
>> 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
> 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
Ó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
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.
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.
> 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.
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
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
Ó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
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
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
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).
> 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
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.
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 👏
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.
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.
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.)
[[[ 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)
[[[ 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)
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).
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
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
> > (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
> 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
>> 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
> 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.
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.
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
> 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
>> 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.
[-- 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
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
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.)
> 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.
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
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
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.
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