On the adoption of transient.el

On the adoption of transient.el

[Gabriel]

Hi,

With the inclusion of the wonderful transient.el library into Emacs
(commit afcdd4cab3 Apr 20 2021), I wonder what are the plans to leverage
it inside Emacs (gnus, help, project etc) out-of-the-box. I see many
opportunities in this regard although I didn't find any discussion in
#emacs-devel. The technical aspects seems to be straightforward to
implement, but perhaps it's a big topic to decide 'if' or 'how' Emacs
will leverage transient.el and the possible impacts on users. I would
love to hear more about it.

Regards,
Gabriel

Re: On the adoption of transient.el

[Philip Kaludercic]

Gabriel <gabriel376@hotmail.com> writes:

> Hi,
>
> With the inclusion of the wonderful transient.el library into Emacs
> (commit afcdd4cab3 Apr 20 2021), I wonder what are the plans to leverage
> it inside Emacs (gnus, help, project etc) out-of-the-box. I see many
> opportunities in this regard although I didn't find any discussion in
> #emacs-devel. The technical aspects seems to be straightforward to
> implement, but perhaps it's a big topic to decide 'if' or 'how' Emacs
> will leverage transient.el and the possible impacts on users. I would
> love to hear more about it.

Do you have any concrete examples where it could be used?

> Regards,
> Gabriel

-- 
	Philip K.

Re: On the adoption of transient.el

[Gabriel]

Philip Kaludercic <philipk@posteo.net> writes:
> 
> Do you have any concrete examples where it could be used?
>

Well, there are many examples, the possibilities are endless, although I
don't think it's a silver bullet that should be used everywhere.

A concrete example is isearch, where a transient menu could be used to
toggle case fold, toggle regexp, toggle lax whitespace, run
query-replace etc.

Emacs has the wonderful vc.el that could leverage transient.el too.

A transient menu could be also used as an alternative to list the
bindings of a keymap, similar to the package 'which-key'. So instead of
typing '<prefix> C-h' when the user don't know a specific binding in
some keymap, a transient menu could present the bindings and dispatch
the request command.

If 'help-for-help' was not too large, perhaps it could also use a
transient menu. Or could split each section using transient prefixes.

In project.el, 'project-switch-project' could also use a transient menu
for its options rather than the current implementation with
'project-switch-commands'. When using 'C-u C-x p g', the user is asked
three questions, which could be replaced with a nice transient menu.

This is definitely not an exhaustive list. Some other area of Emacs that
may leverage transient.el are: Gnus, Dired, Ispell, GDB, Registers, Tab
Bar, Ediff.

Regards,
Gabriel

Re: On the adoption of transient.el

[Yuri Khan]

On Mon, 5 Jul 2021 at 21:25, Philip Kaludercic <philipk@posteo.net> wrote:

> Do you have any concrete examples where it could be used?

Every time I do an ‘M-x rgrep’, I am asked three to infinity
questions, in a sequence:

* A regexp to grep for.
* A wildcard for the set of files I want searched. (The default value
is inferred from the extension of the file name of the current buffer,
so if I’m in a Dired buffer visiting “2. Name of the second book in a
series”, I have to change that.)
* A starting directory. (The default is the current buffer’s default directory.)
* Whether I want to save some buffers.

I could probably avoid most of these if rgrep displayed them all in a
single transient prompt and maybe had single-key options to search
(a)ll files, files matching the e(x)tension of the current buffer, or
a custom (f)ile name wildcard.

Re: On the adoption of transient.el

[Stefan Monnier]

Gabriel [2021-07-05 13:09:22] wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>> Do you have any concrete examples where it could be used?
> Well, there are many examples, the possibilities are endless, although I
> don't think it's a silver bullet that should be used everywhere.

The main reason why we don't have those transients is that nobody has
put the work into making them (which requires thinking what the UI
should look like, what key bindings to use, etc....).

So patches would go a much longer way than suggestions of places where
to use them.


        Stefan

Re: On the adoption of transient.el

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Mon, 5 Jul 2021 23:50:53 +0700
> Cc: Gabriel <gabriel376@hotmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On Mon, 5 Jul 2021 at 21:25, Philip Kaludercic <philipk@posteo.net> wrote:
> 
> > Do you have any concrete examples where it could be used?
> 
> Every time I do an ‘M-x rgrep’, I am asked three to infinity
> questions, in a sequence:

If you are annoyed by rgrep, then why do you use it?  It doesn't do
anything that "M-x grep" cannot.  That command exists for people who
don't have a good command of the Grep/Find command lines.  So yes, it
asks a lot of questions because that's what its audience needs.

Re: On the adoption of transient.el

[Yuri Khan]

On Tue, 6 Jul 2021 at 00:06, Eli Zaretskii <eliz@gnu.org> wrote:
> > > Do you have any concrete examples where it could be used?
> >
> > Every time I do an ‘M-x rgrep’, I am asked three to infinity
> > questions, in a sequence:
>
> If you are annoyed by rgrep, then why do you use it?  It doesn't do
> anything that "M-x grep" cannot.  That command exists for people who
> don't have a good command of the Grep/Find command lines.

I think this describes me pretty accurately.

> So yes, it
> asks a lot of questions because that's what its audience needs.

My point is that asking a lot of questions all at once in a transient
screen is better than asking the same lot of questions sequentially.
One of the reasons being, if you realize you have answered one of the
previous questions wrongly, you can just revisit that question rather
than canceling and restarting the whole sequence.

I should probably just make a wrapper for rgrep (or find/grep
directly) for myself.

Re: On the adoption of transient.el

[Stefan Monnier]

> I should probably just make a wrapper for rgrep (or find/grep
> directly) for myself.

No, I think you should make a nice Transient UI for rgrep for everyone,
not just for yourself.

Maybe some people will still prefer the sequential UI of `rgrep` and
we'll end up with an additional UI rather than a replacement of the old
one, but it's still an improvement.


        Stefan

Re: On the adoption of transient.el

[Philip Kaludercic]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Mon, 5 Jul 2021 at 21:25, Philip Kaludercic <philipk@posteo.net> wrote:
>
>> Do you have any concrete examples where it could be used?
>
> Every time I do an ‘M-x rgrep’, I am asked three to infinity
> questions, in a sequence:

This is interesting, from my understanding transient makes for a good
interface for calling commands with a lot of flags (git, ffmpeg, pandoc,
...). On the other hand something has always felt off about transient,
in the sense that it is breaking some expected behaviour or couldn't
pin-point yet, but just unconsciously stumble over.

I think that the best path of action is to make concrete suggestions,
to discuss and improve.

-- 
	Philip Kaludercic

Re: On the adoption of transient.el

[Lars Ingebrigtsen]

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

> So patches would go a much longer way than suggestions of places where
> to use them.

Yes, indeed.

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

Re: On the adoption of transient.el

[Jim Porter]

On 7/5/2021 9:50 AM, Yuri Khan wrote:
> On Mon, 5 Jul 2021 at 21:25, Philip Kaludercic <philipk@posteo.net> wrote:
> 
>> Do you have any concrete examples where it could be used?
> 
> Every time I do an ‘M-x rgrep’, I am asked three to infinity
> questions, in a sequence:

Coincidentally, I've been working on an alternative/enhancement to rgrep 
that works with (almost) any grep-like program[1], and I've been looking 
into using transient.el to replace my current implementation of setting 
search options (I just use `read-from-minibuffer' with a custom keymap 
that resembles how isearch works).

I'd definitely be interested in seeing some examples of how I might use 
transient.el to accomplish this. I looked over the documentation for 
transient.el, and while it seems very thorough, I had a hard time 
understanding how to do something isearch-like with it. Given sufficient 
time, I could probably figure it out, but having a smallish example to 
imitate would be a big help for getting started.

In particular, I want to be able to invoke the `urgrep' command, type a 
search string, and hit RET to search[2], but also be able to type some 
key combinations to tweak options (both toggling boolean flags and 
setting values, e.g. number of lines of context to show).

(Also note: if you're interested in using urgrep, feel free, but there's 
a reason it hasn't been added to a package archive yet. I'm still 
changing lots of things around, so I make no promises about backwards 
compatibility for the time being.)

- Jim

[1] https://github.com/jimporter/urgrep
[2] 90% of the time, I just want to search for a string, so I'm 
optimizing for that case.

Re: On the adoption of transient.el

[Rudolf Adamkovič]

Philip Kaludercic <philipk@posteo.net> writes:

> On the other hand something has always felt off about transient, 
> in the sense that it is breaking some expected behaviour or 
> couldn't pin-point yet, but just unconsciously stumble over. 

This is exactly how I feel about the "modern" interfaces in Emacs. 
I reported a bug in Embark recently, and because I could not 
select and copy the text, I ended up re-typing the text that was 
right in front of me in Emacs. Say what? For me, Emacs is a 
program where I expect to never waste time re-typing anything. 
Magit has a similar feel to it, and I can never be sure if the 
program will allow me to select text in the diverse parts of its 
user interface. In my opinion, such uncertainty is bad for power 
users. I would expect this from Apple or Microsoft software, 
because their latest “UX designers” surely know better than 
anyone, but in Emacs?

R+

-- 
Programming reliably --- must be an activity of an undeniably 
mathematical nature [...] You see, mathematics is about thinking, 
and doing mathematics is always trying to think as well as 
possible. -- Edsger W. Dijkstra (1981)  Rudolf Adamkovič 
<salutis@me.com> Studenohorská 25 84103 Bratislava Slovakia 
[he/him]

Re: On the adoption of transient.el

[T.V Raman]

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

Rudolf Adamkovi00 <salutis@me.com> writes:

I think some of this stems from the fact that transient displays the
choices in a window that is actually not the "current window/buffer" in
the common Emacs sense  --- it does take some getting used to --- at
least in the beginning.

I've gotten used to it over time, but only after writing some of my own
Emacspeak wrappers --- on the positive side, the   transient author has
been very helpful in that process.

So on the plus-side, magit/transient does go somewhat outside the
"vanilla emacs box", but it's also a good opportunity to experiment with
new/newer interaction paradigms. I dont think this will cause Emacs to
go the Apple/Microsoft way since as a community, Emacs will never lock
itself down to one single  frozen way of doing UI.

(Or at least I hope so):-)
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> On the other hand something has always felt off about transient, in
>> the sense that it is breaking some expected behaviour or couldn't
>> pin-point yet, but just unconsciously stumble over. 
>
> This is exactly how I feel about the "modern" interfaces in Emacs. I
> reported a bug in Embark recently, and because I could not select and
> copy the text, I ended up re-typing the text that was right in front
> of me in Emacs. Say what? For me, Emacs is a program where I expect to
> never waste time re-typing anything. Magit has a similar feel to it,
> and I can never be sure if the program will allow me to select text in
> the diverse parts of its user interface. In my opinion, such
> uncertainty is bad for power users. I would expect this from Apple or
> Microsoft software, because their latest ¡°UX designers¡± surely know
> better than anyone, but in Emacs?
>
> R+

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: On the adoption of transient.el

[Arthur Miller]

Rudolf Adamkovič <salutis@me.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> On the other hand something has always felt off about transient, in the sense
>> that it is breaking some expected behaviour or couldn't pin-point yet, but
>> just unconsciously stumble over. 
>
> This is exactly how I feel about the "modern" interfaces in Emacs. I reported a
> bug in Embark recently, and because I could not select and copy the text, I
> ended up re-typing the text that was right in front of me in Emacs. Say what?
> For me, Emacs is a program where I expect to never waste time re-typing
> anything. Magit has a similar feel to it, and I can never be sure if the program
> will allow me to select text in the diverse parts of its user interface. In my
> opinion, such uncertainty is bad for power users. I would expect this from Apple
> or Microsoft software, because their latest “UX designers” surely know better
> than anyone, but in Emacs?

I personally feel that Magit has some really useful things to add to the
Emacs, and for some people it is even it's user interface. I would say
Transient is one of those things that are not for me, but that ceratinly
have their place.

To clarify, Transient interface feels like old dos reimplementation:
pick a choice from a list. Seems like a trend nowadays. During last
months I have seen some libraries anounced in c and c++ Reddit for
similar kind of interfaces. People call this "non-curses" TUIs. Sine GUI
entrance, this choices have migrated into pull-down or context sensitive
menus, and ocassional more explorative list like checkbox or radio box
panel or similar. I never had problem with TUIs and nowdays with
millenials grown up on computers, it seems like we don't need
educational and explorative GUIs, and are inclined to trade speed for
the looks. But I regress here. I personally don't need this explorative
part that a Transient menu offers to me, because it is a hickup

I recently wanted a Helm interface to switch between git branches. I
would like to be able to hit a key and have all local branches poped in
a Helm and just type a letter or two and hit enter to switch to a
branch. Thierry, Helm maintainer pointed to me that Magit offers an
inteface for this: I have to run Magit than bb and than Magit will offer
a completing read which will pop the asked Helm interface. To me this is
not a straightforward enough so I have actually coded my branch switcher
as a Helm addon.

But anyway, to Tarsius, and anyone else, I don't mean Magit is bad;
Magit has it's strenghts; in my opinion it is a sort-of pull-down
menu for TUIs, and it certainly has it's audience.

Re: On the adoption of transient.el

[Arthur Miller]

Rudolf Adamkovič <salutis@me.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> On the other hand something has always felt off about transient, in the sense
>> that it is breaking some expected behaviour or couldn't pin-point yet, but
>> just unconsciously stumble over. 
>
> This is exactly how I feel about the "modern" interfaces in Emacs. I reported a
> bug in Embark recently, and because I could not select and copy the text, I
> ended up re-typing the text that was right in front of me in Emacs. Say what?
> For me, Emacs is a program where I expect to never waste time re-typing
> anything. Magit has a similar feel to it, and I can never be sure if the program
> will allow me to select text in the diverse parts of its user interface. In my
> opinion, such uncertainty is bad for power users. I would expect this from Apple
> or Microsoft software, because their latest “UX designers” surely know better
> than anyone, but in Emacs?
>
> R+


Sh*t, pressed wrong button and mail went before I finneshed it ... :-(

Re: On the adoption of transient.el

[Jonas Bernoulli]

> I have to run Magit than bb and than Magit will offer a completing
> read which will pop the asked Helm interface. To me this is not a
> straightforward enough

  (global-set-key [f1] 'magit-checkout)

Also you generally don't have to "run Magit" and can just use "C-x M-g"
and in file-visiting buffers also "C-c M-g".

You will probably also like:
  
  (setq transient-show-popup nil)
  (setq transient-show-popup 0)

Re: On the adoption of transient.el

[Arthur Miller]

Jonas Bernoulli <jonas@bernoul.li> writes:

>> I have to run Magit than bb and than Magit will offer a completing
>> read which will pop the asked Helm interface. To me this is not a
>> straightforward enough
>
>   (global-set-key [f1] 'magit-checkout)
>
> Also you generally don't have to "run Magit" and can just use "C-x M-g"
> and in file-visiting buffers also "C-c M-g".
>
> You will probably also like:
>   
>   (setq transient-show-popup nil)
>   (setq transient-show-popup 0)

Aha. Thanks. I didn't know. I am not so frequent user, so I am not well
used to do things in Magit. I always thought I have to open magit-status
and work from there.

I'll test. Thanks.

Re: On the adoption of transient.el

[Philip Kaludercic]

Rudolf Adamkovič <salutis@me.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> On the other hand something has always felt off about transient, in
>> the sense that it is breaking some expected behaviour or couldn't
>> pin-point yet, but just unconsciously stumble over. 
>
> This is exactly how I feel about the "modern" interfaces in Emacs. I
> reported a bug in Embark recently, and because I could not select and
> copy the text, I ended up re-typing the text that was right in front
> of me in Emacs. Say what? For me, Emacs is a program where I expect to
> never waste time re-typing anything. Magit has a similar feel to it,
> and I can never be sure if the program will allow me to select text in
> the diverse parts of its user interface. In my opinion, such
> uncertainty is bad for power users. I would expect this from Apple or
> Microsoft software, because their latest “UX designers” surely know
> better than anyone, but in Emacs?

I am not sure if this is something specific to modern interfaces, or
rather an overreaching when it comes to binding. After a while I managed
to "pin-point" what was irritating me, and it was the missing ability to
search (something that I seem to do so passively that i didn't even
notice it). Having C-s work is especially useful when there are a lot of
transient options. This cannot be solved by binding C-s manually,
as just because that might work for me, there is some other behaviour
someone else is expecting (eg. your example of selecting and copying
text).

What I understand transient and certain other packages do is basically
override most keys, even those it doesn't use. This is more invasive
than special-mode, that just doesn't bind self-insert-command to most
keys. What I wonder is why this is done/why it might be necessary.

> R+

-- 
	Philip Kaludercic

Re: On the adoption of transient.el

[Óscar Fuentes]

Philip Kaludercic <philipk@posteo.net> writes:

> Rudolf Adamkovič <salutis@me.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> On the other hand something has always felt off about transient, in
>>> the sense that it is breaking some expected behaviour or couldn't
>>> pin-point yet, but just unconsciously stumble over. 
>>
>> This is exactly how I feel about the "modern" interfaces in Emacs. I
>> reported a bug in Embark recently, and because I could not select and
>> copy the text, I ended up re-typing the text that was right in front
>> of me in Emacs. Say what? For me, Emacs is a program where I expect to
>> never waste time re-typing anything. Magit has a similar feel to it,
>> and I can never be sure if the program will allow me to select text in
>> the diverse parts of its user interface. In my opinion, such
>> uncertainty is bad for power users. I would expect this from Apple or
>> Microsoft software, because their latest “UX designers” surely know
>> better than anyone, but in Emacs?
>
> I am not sure if this is something specific to modern interfaces, or
> rather an overreaching when it comes to binding. After a while I managed
> to "pin-point" what was irritating me, and it was the missing ability to
> search (something that I seem to do so passively that i didn't even
> notice it). Having C-s work is especially useful when there are a lot of
> transient options. This cannot be solved by binding C-s manually,
> as just because that might work for me, there is some other behaviour
> someone else is expecting (eg. your example of selecting and copying
> text).
>
> What I understand transient and certain other packages do is basically
> override most keys, even those it doesn't use. This is more invasive
> than special-mode, that just doesn't bind self-insert-command to most
> keys. What I wonder is why this is done/why it might be necessary.

Certain actions do not play well with the possibility of doing arbitrary
things once they are triggered. All-or-nothing sequences sometimes make
sense, and then a good UI will enforce some invariants, usually by
restricting what the user can do.

For instance, allowing the user to do arbitrary things while on the
process of dealing with Magit's transient menu can cause mistakes and
confusion for little or no benefit. If you enter the transient menu and
then feel like doing something else, C-g. No big deal.

Re: On the adoption of transient.el

[T.V Raman]

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

Philip Kaludercic <philipk@posteo.net> writes:


I recently discovered thanks to the transient/magit author that once you
 enable navigation via arrows in transient popups, it also gives you
 isearch of the transient. We then discovered a bug where using isearch
 to find a transient option and pressing enter wasn't working, but
 Jonas has since fixed that and it works.
 transient-enable-popup-navigation is a variable defined in ¡®transient.el¡¯.

Its value is t
Original value was nil

  You can customize this variable.
  This variable was introduced, or its default value was changed, in
  version 0.2.0 of the transient package.

Whether navigation commands are enabled in the transient popup.

While a transient is active the transient popup buffer is not the
current buffer, making it necessary to use dedicated commands to
act on that buffer itself.  If this non-nil, then the following
features are available:

- "<up>" moves the cursor to the previous suffix.
  "<down>" moves the cursor to the next suffix.
  "RET" invokes the suffix the cursor is on.
- "<mouse-1>" invokes the clicked on suffix.
- "C-s" and "C-r" start isearch in the popup buffer.


> Rudolf Adamkovi00 <salutis@me.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> On the other hand something has always felt off about transient, in
>>> the sense that it is breaking some expected behaviour or couldn't
>>> pin-point yet, but just unconsciously stumble over. 
>>
>> This is exactly how I feel about the "modern" interfaces in Emacs. I
>> reported a bug in Embark recently, and because I could not select and
>> copy the text, I ended up re-typing the text that was right in front
>> of me in Emacs. Say what? For me, Emacs is a program where I expect to
>> never waste time re-typing anything. Magit has a similar feel to it,
>> and I can never be sure if the program will allow me to select text in
>> the diverse parts of its user interface. In my opinion, such
>> uncertainty is bad for power users. I would expect this from Apple or
>> Microsoft software, because their latest ¡°UX designers¡± surely know
>> better than anyone, but in Emacs?
>
> I am not sure if this is something specific to modern interfaces, or
> rather an overreaching when it comes to binding. After a while I managed
> to "pin-point" what was irritating me, and it was the missing ability to
> search (something that I seem to do so passively that i didn't even
> notice it). Having C-s work is especially useful when there are a lot of
> transient options. This cannot be solved by binding C-s manually,
> as just because that might work for me, there is some other behaviour
> someone else is expecting (eg. your example of selecting and copying
> text).
>
> What I understand transient and certain other packages do is basically
> override most keys, even those it doesn't use. This is more invasive
> than special-mode, that just doesn't bind self-insert-command to most
> keys. What I wonder is why this is done/why it might be necessary.
>
>> R+

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: On the adoption of transient.el

[Jesse Millwood]

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

Oh wow, not being able to search that buffer has been my main pain point 
of transient. Thank you so much!

On 2021-08-04 2:56 p.m., T.V Raman wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>
> I recently discovered thanks to the transient/magit author that once you
>   enable navigation via arrows in transient popups, it also gives you
>   isearch of the transient. We then discovered a bug where using isearch
>   to find a transient option and pressing enter wasn't working, but
>   Jonas has since fixed that and it works.
>   transient-enable-popup-navigation is a variable defined in ¡®transient.el¡¯.
>
> Its value is t
> Original value was nil
>
>    You can customize this variable.
>    This variable was introduced, or its default value was changed, in
>    version 0.2.0 of the transient package.
>
> Whether navigation commands are enabled in the transient popup.
>
> While a transient is active the transient popup buffer is not the
> current buffer, making it necessary to use dedicated commands to
> act on that buffer itself.  If this non-nil, then the following
> features are available:
>
> - "<up>" moves the cursor to the previous suffix.
>    "<down>" moves the cursor to the next suffix.
>    "RET" invokes the suffix the cursor is on.
> - "<mouse-1>" invokes the clicked on suffix.
> - "C-s" and "C-r" start isearch in the popup buffer.
>
>
>> Rudolf Adamkovi00 <salutis@me.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> On the other hand something has always felt off about transient, in
>>>> the sense that it is breaking some expected behaviour or couldn't
>>>> pin-point yet, but just unconsciously stumble over.
>>> This is exactly how I feel about the "modern" interfaces in Emacs. I
>>> reported a bug in Embark recently, and because I could not select and
>>> copy the text, I ended up re-typing the text that was right in front
>>> of me in Emacs. Say what? For me, Emacs is a program where I expect to
>>> never waste time re-typing anything. Magit has a similar feel to it,
>>> and I can never be sure if the program will allow me to select text in
>>> the diverse parts of its user interface. In my opinion, such
>>> uncertainty is bad for power users. I would expect this from Apple or
>>> Microsoft software, because their latest ¡°UX designers¡± surely know
>>> better than anyone, but in Emacs?
>> I am not sure if this is something specific to modern interfaces, or
>> rather an overreaching when it comes to binding. After a while I managed
>> to "pin-point" what was irritating me, and it was the missing ability to
>> search (something that I seem to do so passively that i didn't even
>> notice it). Having C-s work is especially useful when there are a lot of
>> transient options. This cannot be solved by binding C-s manually,
>> as just because that might work for me, there is some other behaviour
>> someone else is expecting (eg. your example of selecting and copying
>> text).
>>
>> What I understand transient and certain other packages do is basically
>> override most keys, even those it doesn't use. This is more invasive
>> than special-mode, that just doesn't bind self-insert-command to most
>> keys. What I wonder is why this is done/why it might be necessary.
>>
>>> R+

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

Re: On the adoption of transient.el

[T.V Raman]

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

Jesse Millwood <jesse_m@fastmail.com> writes:


I was more motivated to get it solved because where for you it was a
pain-point, for me it was a show-stopper:-)

Jonas' help got me over the hump.

Stepping back, yes, transient, especially when encountered first via
magit looks complex. But that complexity comes from how much more
complex git is --- what transient does well is to make the large
bucket-loads of git commandline options more tractable.

It's also a very good attempt at bringing features of "direct
manipulation interfaces" to the emacs world  --- I use the term "direct
manipulation" intentionally, that is actually what people mean when they
jump to a GUI. But transient shows that it is possible to implement such
interfaces within the Emacs paradigm by stretching the boundaries a
little, and where we do feel discomfort with respect to over-stretching
those boundaries (losing isearch is an example), we can  claw it back.

Note that  things like dired in emacs are also direct-manipulation
interfaces --- they just preserve *all* of the goodness of Emacs.

The other package that is similar to transient with many advantages  is
hydra --- though I  haven't seen any hydras as complex as the transients
that Git forces magit to require.


> Oh wow, not being able to search that buffer has been my main pain
> point of transient. Thank you so much! 
>
> On 2021-08-04 2:56 p.m., T.V Raman wrote:
>
>     Philip Kaludercic <philipk@posteo.net> writes:
>
>
> I recently discovered thanks to the transient/magit author that once you
>  enable navigation via arrows in transient popups, it also gives you
>  isearch of the transient. We then discovered a bug where using isearch
>  to find a transient option and pressing enter wasn't working, but
>  Jonas has since fixed that and it works.
>  transient-enable-popup-navigation is a variable defined in ¡®transient.el¡¯.
>
> Its value is t
> Original value was nil
>
>   You can customize this variable.
>   This variable was introduced, or its default value was changed, in
>   version 0.2.0 of the transient package.
>
> Whether navigation commands are enabled in the transient popup.
>
> While a transient is active the transient popup buffer is not the
> current buffer, making it necessary to use dedicated commands to
> act on that buffer itself.  If this non-nil, then the following
> features are available:
>
> - "<up>" moves the cursor to the previous suffix.
>   "<down>" moves the cursor to the next suffix.
>   "RET" invokes the suffix the cursor is on.
> - "<mouse-1>" invokes the clicked on suffix.
> - "C-s" and "C-r" start isearch in the popup buffer.
>
>
>         Rudolf Adamkovi00 <salutis@me.com> writes:
>
>             Philip Kaludercic <philipk@posteo.net> writes:
>
>                 On the other hand something has always felt off about
>                 transient, in
> the sense that it is breaking some expected behaviour or couldn't
> pin-point yet, but just unconsciously stumble over. 
>
>
> This is exactly how I feel about the "modern" interfaces in Emacs. I
> reported a bug in Embark recently, and because I could not select and
> copy the text, I ended up re-typing the text that was right in front
> of me in Emacs. Say what? For me, Emacs is a program where I expect to
> never waste time re-typing anything. Magit has a similar feel to it,
> and I can never be sure if the program will allow me to select text in
> the diverse parts of its user interface. In my opinion, such
> uncertainty is bad for power users. I would expect this from Apple or
> Microsoft software, because their latest ¡°UX designers¡± surely know
> better than anyone, but in Emacs?
>
>
> I am not sure if this is something specific to modern interfaces, or
> rather an overreaching when it comes to binding. After a while I managed
> to "pin-point" what was irritating me, and it was the missing ability to
> search (something that I seem to do so passively that i didn't even
> notice it). Having C-s work is especially useful when there are a lot of
> transient options. This cannot be solved by binding C-s manually,
> as just because that might work for me, there is some other behaviour
> someone else is expecting (eg. your example of selecting and copying
> text).
>
> What I understand transient and certain other packages do is basically
> override most keys, even those it doesn't use. This is more invasive
> than special-mode, that just doesn't bind self-insert-command to most
> keys. What I wonder is why this is done/why it might be necessary.
>
>             R+
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: On the adoption of transient.el

[Arthur Miller]

"T.V Raman" <raman@google.com> writes:

> Jesse Millwood <jesse_m@fastmail.com> writes:
>
>
> I was more motivated to get it solved because where for you it was a
> pain-point, for me it was a show-stopper:-)
>
> Jonas' help got me over the hump.
>
> Stepping back, yes, transient, especially when encountered first via
> magit looks complex. But that complexity comes from how much more
> complex git is --- what transient does well is to make the large
> bucket-loads of git commandline options more tractable.
>
> It's also a very good attempt at bringing features of "direct
> manipulation interfaces" to the emacs world  --- I use the term "direct
> manipulation" intentionally, that is actually what people mean when they
> jump to a GUI. But transient shows that it is possible to implement such
> interfaces within the Emacs paradigm by stretching the boundaries a
> little, and where we do feel discomfort with respect to over-stretching
> those boundaries (losing isearch is an example), we can  claw it back.
>
> Note that  things like dired in emacs are also direct-manipulation
> interfaces --- they just preserve *all* of the goodness of Emacs.
>
> The other package that is similar to transient with many advantages  is
> hydra --- though I  haven't seen any hydras as complex as the transients
> that Git forces magit to require.

Are you sure it is Git that forces magit to be complex?

I think it is rather the design choice. Magit exposes 1-1 git commands as a
pick-from-the-list interface. I am not saying anything against, but the
interface to Git commands coould have been abstracted into something
that more resembles Dired or some other ux model. Observe, I have
nothing against Magit, I am just saying that nothing is forced. It is
all choice of how one prefer to use things.

There are other guis to Git, by accident I discovered one two days ago
(tips from a Linux magazine):

https://github.com/francescmm/GitQlient

No idea how good that thing is or other tools, I don't use any of those,
but it is fully possible to create ux that does not expose git commands
directly. Observe that I don't say it should be done, I am not against
magit or for some Qt gui, I am just saying, the ux and level of
abstraction is a design choice :).

Re: On the adoption of transient.el

[Eric S Fraga]

On Thursday,  5 Aug 2021 at 09:01, Arthur Miller wrote:
> I am not saying anything against, but the interface to Git commands
> coould have been abstracted into something that more resembles Dired
> or some other ux model. 

as in vc-dir?  I generally prefer using the vc- commands for git but
fall back on magit when I need to do things that are not possible in
vc.  Ideally, vc would support everything (or most everything) that
magit does as I prefer the vc interface (less friction for me).

But to be clear: magit is brilliant at providing an interface to the
mystery that is the full git ecosystem!

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4.6 on Debian 11.0

Re: On the adoption of transient.el

[Tim Cross]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> But to be clear: magit is brilliant at providing an interface to the
> mystery that is the full git ecosystem!

+1. I'm not sure I know of another command with as many options and
sub-commands as git. Prior to magit, I spent a lot of time skimming
through the git help or man git-*. The challenge with git is that 99% of
the time, you just have a very few set of commands to remember, but when
you need something from that other 1%, you can never remember the
details. With magit, i get sufficient summary/prompts to make this
realtively easy.

I'm not sure how easily you could do a git interface based around
dired-style UI design which provides much more than the vc-* interface
already provides. 

Re: On the adoption of transient.el

[Arthur Miller]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Thursday,  5 Aug 2021 at 09:01, Arthur Miller wrote:
>> I am not saying anything against, but the interface to Git commands
>> coould have been abstracted into something that more resembles Dired
>> or some other ux model. 
>
> as in vc-dir?  I generally prefer using the vc- commands for git but
> fall back on magit when I need to do things that are not possible in
> vc.  Ideally, vc would support everything (or most everything) that
> magit does as I prefer the vc interface (less friction for me).
>
> But to be clear: magit is brilliant at providing an interface to the
> mystery that is the full git ecosystem!

I am not super-duper familiar with any of those, my git needs are so
humble, I can do most of stuff from command line, but you are probably
correct!

Re: On the adoption of transient.el

[Jean-Christophe Helary]

> On Aug 5, 2021, at 18:38, Arthur Miller <arthur.miller@live.com> wrote:
> 
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:

>> But to be clear: magit is brilliant at providing an interface to the
>> mystery that is the full git ecosystem!
> 
> I am not super-duper familiar with any of those, my git needs are so
> humble, I can do most of stuff from command line, but you are probably
> correct!

No need to even consider the most obscure git commands to appreciate Magit, just having the ability to select subparts of a diff to stage or unstage. I have no idea how a similarly simple action can be implemented in CL git commands.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: On the adoption of transient.el

[Eric S Fraga]

On Thursday,  5 Aug 2021 at 19:23, Tim Cross wrote:
> I'm not sure how easily you could do a git interface based around
> dired-style UI design which provides much more than the vc-* interface
> already provides. 

Yes, that's probably the case.  I use vc for most of the simple
activities (diffs, simple commits, viewing the log, pushing/fetching)
but fall back to magit for selective commits and branching.

I do use other version control systems (especially SRC for single file
"projects") and so having the same key bindings regardless of VCS is
ideal for reducing friction.  This is where vc wins.

I'm happy with the vc & magit combination as, when using magit, I expect
to be taking my time thinking carefully about what I am doing so the
friction is not an issue.
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4.6 on Debian 11.0

Re: On the adoption of transient.el

[Eli Zaretskii]

> From: Eric S Fraga <e.fraga@ucl.ac.uk>
> Date: Thu, 05 Aug 2021 11:37:03 +0100
> 
> On Thursday,  5 Aug 2021 at 19:23, Tim Cross wrote:
> > I'm not sure how easily you could do a git interface based around
> > dired-style UI design which provides much more than the vc-* interface
> > already provides. 
> 
> Yes, that's probably the case.  I use vc for most of the simple
> activities (diffs, simple commits, viewing the log, pushing/fetching)
> but fall back to magit for selective commits and branching.

I'm not sure we've used up the potential of "C-x v v" for Git.  It
currently doesn't even fully support the simplest workflow with Git,
only going as far as making a local commit.  (I tried to suggest a
better "next action" heuristics some moons ago, but couldn't get the
involved parties to agree.)  If and when we have the basic Git
workflow covered, we could perhaps try implementing some less frequent
variants using some combination of heuristics and prompting the user.

FWIW, when I need to do something with Git that I do rarely and
therefore don't really remember how it's done, I just search the
Internet.  There's so much stuff there about every single Git command
and Git-related issue that I usually find the answer in a few seconds.
IME, the Git man pages are worthless unless you know exactly which
command you want to use, so I almost never use the docs which come
with Git.

I'd be interested to see a demonstration of how Magit makes doing some
fancy Git job without searching the Internet for solutions.  But
please take some really exotic job, not something semi-trivial.

> I do use other version control systems (especially SRC for single file
> "projects") and so having the same key bindings regardless of VCS is
> ideal for reducing friction.  This is where vc wins.

Yes, and I think it could win more than it does now.  In general, the
adaptation of VC to modern VCSes is IMO incomplete, and we could do
much better.

Re: On the adoption of transient.el

[T.V Raman]

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

Eric S Fraga <e.fraga@ucl.ac.uk> writes:


If vc let you do all  that magit does with git, then vc would become VC
and be renamed "VeryComplex":-)

> On Thursday,  5 Aug 2021 at 09:01, Arthur Miller wrote:
>> I am not saying anything against, but the interface to Git commands
>> coould have been abstracted into something that more resembles Dired
>> or some other ux model. 
>
> as in vc-dir?  I generally prefer using the vc- commands for git but
> fall back on magit when I need to do things that are not possible in
> vc.  Ideally, vc would support everything (or most everything) that
> magit does as I prefer the vc interface (less friction for me).
>
> But to be clear: magit is brilliant at providing an interface to the
> mystery that is the full git ecosystem!

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: On the adoption of transient.el

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure we've used up the potential of "C-x v v" for Git.

The "C-x v v" workflow works for Git as far as you use Git as you use
CVS.

> I'd be interested to see a demonstration of how Magit makes doing some
> fancy Git job without searching the Internet for solutions.  But
> please take some really exotic job, not something semi-trivial.

AFAIK Magit is not advertised as a tool for doing exotic jobs without
prior knowledge. Magit is great at discoverability, ergonomics, and
user-friendliness. This means that the capabilities of the tool are
explicit, you operate the tool with a simple interface and the state you
are operating on is obvious. Compare this with writing commands on the
console (that you previously need to memorize) on a cycle of "see what I
got -> do some change -> see what I got". However, you still need to
know the basic concepts of Git to use Magit.

But I'll try answering your request with two examples. First one: as you
work on some feature you find and fix some typos here and there, or do
some other quick change not directly related to your initial task. You
end with those quick changes mixed with your main task. With Magit, it
is trivial to separately commit the changes: on the Magit status buffer
navigate to the fixed typos, select them as you select a region on
Emacs, press `s' and the selected change goes to the staging area. Do
the same for the rest and commit.

For the second example let's suppose that you implemented a complex
feature as a series of commits on a branch. Those commits reveal all the
gore details of your work: mistakes, backtracks, half-done subtasks,
etc. Things that the rest of the world care nothing about. With Magit
you can easily reorder, split, mix, rewrite, whatever, your commits.
Thanks to this you can end with a tidy series of commits, which are much
more adequate for the public consumption (suppossing that the public is
more interested on how the feature is implemented that on your personal
method of writing code.)

>> I do use other version control systems (especially SRC for single file
>> "projects") and so having the same key bindings regardless of VCS is
>> ideal for reducing friction.  This is where vc wins.
>
> Yes, and I think it could win more than it does now.  In general, the
> adaptation of VC to modern VCSes is IMO incomplete, and we could do
> much better.

I'm skeptical about this. VC works on some concepts that are hard to
reconciliate with modern VCSes (as long as you want to take advantage of
what those VCSes offer.) Also, please note that "modern VCSes" are not
an homogenous bunch, there are big differences among them, and those
differences will increase with the new wave of VCSes (see Pijul, for
instance.)

Re: On the adoption of transient.el

[Eric S Fraga]

On Thursday,  5 Aug 2021 at 07:33, T.V Raman wrote:
> If vc let you do all  that magit does with git, then vc would become VC
> and be renamed "VeryComplex":-)

Valid point.  Maybe I should have said "more" and not everything... ;-)

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4.6 on Debian 11.0

Re: On the adoption of transient.el

[Arthur Miller]

"T.V Raman" <raman@google.com> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>
> If vc let you do all  that magit does with git, then vc would become VC
> and be renamed "VeryComplex":-)
:-)

Re: On the adoption of transient.el

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 05 Aug 2021 16:45:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure we've used up the potential of "C-x v v" for Git.
> 
> The "C-x v v" workflow works for Git as far as you use Git as you use
> CVS.

Which is too little.  For example, the pull and push commands are part
of every simple Git workflow, but "C-x v v" doesn't support them,
AFAIK.  If you are going to claim that push and pull are not part of
"using Git as you use CVS", then I will claim that your notion of
using Git as CVS is pretty useless in practice.

> > I'd be interested to see a demonstration of how Magit makes doing some
> > fancy Git job without searching the Internet for solutions.  But
> > please take some really exotic job, not something semi-trivial.
> 
> AFAIK Magit is not advertised as a tool for doing exotic jobs without
> prior knowledge.

But if that is indeed so, and I still need to search the net for how
to do some non-trivial job with Git/Magit, then Magit will be less
helpful, because what I will find in my search will mostly be Git
commands from the shell prompt, and not their Magit equivalents.

> Magit is great at discoverability, ergonomics, and
> user-friendliness. This means that the capabilities of the tool are
> explicit, you operate the tool with a simple interface and the state you
> are operating on is obvious. Compare this with writing commands on the
> console (that you previously need to memorize) on a cycle of "see what I
> got -> do some change -> see what I got".

I'm afraid I'm not following.  If I find by searching the net the
sequence of Git commands to do some job, I just copy/paste them into
the shell window, and that's it.  And no need to memorize those
commands: the next time I need to do the same job, I do the net search
again.  Since the search hits the right answers very quickly, this is
very adequate for jobs I need to do rarely (which is why I don't
remember the commands in the first place).

What am I missing?

> But I'll try answering your request with two examples. First one: as you
> work on some feature you find and fix some typos here and there, or do
> some other quick change not directly related to your initial task. You
> end with those quick changes mixed with your main task. With Magit, it
> is trivial to separately commit the changes: on the Magit status buffer
> navigate to the fixed typos, select them as you select a region on
> Emacs, press `s' and the selected change goes to the staging area. Do
> the same for the rest and commit.

You mean, instead of selective "git add" (with or without -i) and/or
"git stash"?  I'm probably missing something, because I don't see how
that's significantly different.

> For the second example let's suppose that you implemented a complex
> feature as a series of commits on a branch. Those commits reveal all the
> gore details of your work: mistakes, backtracks, half-done subtasks,
> etc. Things that the rest of the world care nothing about. With Magit
> you can easily reorder, split, mix, rewrite, whatever, your commits.

I never do that.  I commit stuff and merge it exactly as I did
originally, and don't care what "the world" thinks about my mistakes
and back-tracking.  I _want_ to have the original history in the final
push.  That's why I always almost never use rebase.

> >> I do use other version control systems (especially SRC for single file
> >> "projects") and so having the same key bindings regardless of VCS is
> >> ideal for reducing friction.  This is where vc wins.
> >
> > Yes, and I think it could win more than it does now.  In general, the
> > adaptation of VC to modern VCSes is IMO incomplete, and we could do
> > much better.
> 
> I'm skeptical about this. VC works on some concepts that are hard to
> reconciliate with modern VCSes (as long as you want to take advantage of
> what those VCSes offer.)

The popular workflows are a few, and they cover 85% of typical usage.
It is true that at some points of the workflow there could be
ambiguity as to what should be the "next action", but that ambiguity
could be resolved either by some defcustom or by prompting the users,
asking them what would they want to do next from a short list of
possibilities.

So I think your skepticism is unjustified.

How about if we describe one of the simple Git workflows, and see how
hard would it be to come up with "C-x v v" support for it in its
entirety?

> Also, please note that "modern VCSes" are not an homogenous bunch,
> there are big differences among them

I'd be curious to see those big differences, specifically between Git,
Mercurial, and Bazaar.

> and those differences will increase with the new wave of VCSes (see
> Pijul, for instance.)

Let's bother about that when Emacs actually supports those.

Re: On the adoption of transient.el

[Juri Linkov]

>> > I'm not sure we've used up the potential of "C-x v v" for Git.
>>
>> The "C-x v v" workflow works for Git as far as you use Git as you use
>> CVS.
>
> Which is too little.  For example, the pull and push commands are part
> of every simple Git workflow, but "C-x v v" doesn't support them,
> AFAIK.  If you are going to claim that push and pull are not part of
> "using Git as you use CVS", then I will claim that your notion of
> using Git as CVS is pretty useless in practice.

This is already possible with something like this (untested!)

(advice-add 'vc-git-checkin
            :after (lambda (&rest _args)
                     (vc-git-push "Do you want to push it? ")))

Re: On the adoption of transient.el

[Juri Linkov]

> AFAIK Magit is not advertised as a tool for doing exotic jobs without
> prior knowledge. Magit is great at discoverability, ergonomics, and
> user-friendliness. This means that the capabilities of the tool are
> explicit, you operate the tool with a simple interface and the state you
> are operating on is obvious. Compare this with writing commands on the
> console (that you previously need to memorize)

While I think Magit is a great package for discoverability etc.
I found that it's completely sufficient to use just the shell-command.
With the persistent history of the previously constructed git commands
using a flex-style completion on previous commands will even reduce
the need in some vc commands, e.g.

'M-! chm TAB' runs `git checkout master` (instead of C-x v r)
'M-! pur TAB' runs `git pull --rebase`   (instead of C-x v P)
...

> But I'll try answering your request with two examples. First one: as you
> work on some feature you find and fix some typos here and there, or do
> some other quick change not directly related to your initial task. You
> end with those quick changes mixed with your main task. With Magit, it
> is trivial to separately commit the changes: on the Magit status buffer
> navigate to the fixed typos, select them as you select a region on
> Emacs, press `s' and the selected change goes to the staging area. Do
> the same for the rest and commit.

Currently I'm finishing implementation of a new vc command that
will allow committing from a diff buffer.  So for example, after
displaying all changes with e.g. 'C-x v D' you can remove
some unneeded hunks (with e.g. 'M-k' 'diff-hunk-kill'),
then on the remaining hunks type 'C-c C-c' in the diff buffer.
It will create a usual *vc-log* buffer where typing 'C-c C-c'
will commit only changes from the diff buffer.  Internally
it works by running three git commands:

`git stash push -m stash_name -- list_of_file_names_from_diff`
`cat diff_buffer.patch | git am` # should also handle return code
`git stash pop -q`

Re: On the adoption of transient.el

[Phil Sainty]

On 2021-08-06 04:17, Eli Zaretskii wrote:
> I'm afraid I'm not following.  If I find by searching the net the
> sequence of Git commands to do some job, I just copy/paste them into
> the shell window, and that's it.  And no need to memorize those
> commands: the next time I need to do the same job, I do the net search
> again.  Since the search hits the right answers very quickly, this is
> very adequate for jobs I need to do rarely (which is why I don't
> remember the commands in the first place).
> 
> What am I missing?

Maybe nothing?  It's hard to say.  On occasion I'll revert to the same
search-online process (an example I can think of being finding the
reference for a deleted-but-not-yet-garbage-collected commit; that's
not something I'd look to Magit to resolve).

Here's a description of Magit that I once wrote.  It wasn't aimed at
Emacs users, so some of the benefits apply equally to vc, and your
definition of "complex" might not align with mine.  The most complex
things I do on a regular basis are probably all related to rebasing,
and you've said you rarely do any of that, whereas I do it a great
deal, partly because Magit makes it so easy.  E.g. If I realise there
is a bug in a commit somewhere in my unmerged work-in-progress branch,
then I will squash the fix into the original commit 99% of the time,
because doing so takes me about 5 seconds.

FWIW...



Magit provides highly interactive views of your repository, with
simple and efficient key bindings to perform actions (which are often
contextual), such that even complex tasks become remarkably quick and
easy to do. A help buffer displays the available keys at any given
time, so it's always easy to see what the options are.

The main status buffer has collapsible sections for the repo as a
whole, so you not only see which files are staged and unstaged (or
untracked, stashed, unpushed, etc), but you can interactively expand
and collapse the entries to see some/all the diffs; stage or unstage
things with at a keystroke (where "things" can be all changes, or a
single file, or a single hunk of the diff for that file, or a
user-selected region!). Grooming your commits is ludicrously easy and
intuitive when you can just eye-ball the current state and then point
at things to add to (or remove from) that state.

Naturally committing and writing (or amending) commit messages inside
the editor is very streamlined.

Logs are interactive, as each line of the log buffer represents a
commit, so any command which accepts a reference (commit hash, branch
name, tag, etc) can be performed by typing the keys for that action
with the cursor on the log entry for that reference, and Magit will
contextually use that reference (or offer it as a default) for the
command (e.g. viewing, branching, merging, rebasing, etc...)

Diffs are interactive, so you can jump to the relevant file in the
editor (in either its 'before' or 'after' state for that diff), or
apply (or revert) the changes for a file/hunk/region of the diff at a
keystroke. e.g. You could display the diff for a stash (or for a
commit from another branch) and then interactively apply only part of
it.

History rewriting becomes trivial when you can stage some changes and
then point at any commit and say "amend this commit", and it just
happens. Or reword an earlier commit message at any time in the same
manner. Or rebase a range of commits onto a different base by visually
choosing the relevant log entries. Or make a series of fixup commits
(again simply choosing the target log entry each time without needing
to care what the hashes are), and then autosquash them all in a couple
of keystrokes.

Magit interacts with existing conflict resolution tools in Emacs, so
you can smoothly deal with conflicts without leaving the editor.

There's plenty more, but hopefully that gives an idea of what Magit is
about.

It doesn't try to provide any unfamiliar abstractions -- it just makes
things fast and easy. Complex things become simple, and simple things
become trivial. There are very few times that I ever find myself
needing a command line to do something with git, as everything which
Magit supports (which more than covers my day-to-day needs) is just
nicer to do inside Magit, without ever leaving the editor.

Re: On the adoption of transient.el

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Fri, 06 Aug 2021 02:17:07 +0300
> 
> >> The "C-x v v" workflow works for Git as far as you use Git as you use
> >> CVS.
> >
> > Which is too little.  For example, the pull and push commands are part
> > of every simple Git workflow, but "C-x v v" doesn't support them,
> > AFAIK.  If you are going to claim that push and pull are not part of
> > "using Git as you use CVS", then I will claim that your notion of
> > using Git as CVS is pretty useless in practice.
> 
> This is already possible with something like this (untested!)
> 
> (advice-add 'vc-git-checkin
>             :after (lambda (&rest _args)
>                      (vc-git-push "Do you want to push it? ")))

If we are looking for workarounds, instead of actually solving the
problem, then it is much easier and cleaner to say "git push" from the
shell prompt.

And btw, I'm not sure the very next step after commit is an immediate
push.  At least that's not what I do in my workflow.  We need to
seriously discuss the workflows before we decide how to extend
vc-next-action to support modern dVCSes.

Re: On the adoption of transient.el

[John Yates]

On Thu, Aug 5, 2021 at 7:41 PM Juri Linkov <juri@linkov.net> wrote:
> Currently I'm finishing implementation of a new vc command ...
[..SNIP..]
> it works by running three git commands:
>
> `git stash push -m stash_name -- list_of_file_names_from_diff`
> `cat diff_buffer.patch | git am` # should also handle return code
> `git stash pop -q`

Will this new command work with all vc supported [D]VCSs?

On the subject of new vc commands, I would love a vc equivalent
of git-timemachine.

Re: On the adoption of transient.el

[Stefan Monnier]

John Yates [2021-08-06 08:39:51] wrote:
> On Thu, Aug 5, 2021 at 7:41 PM Juri Linkov <juri@linkov.net> wrote:
>> Currently I'm finishing implementation of a new vc command ...
> [..SNIP..]
>> it works by running three git commands:
>>
>> `git stash push -m stash_name -- list_of_file_names_from_diff`
>> `cat diff_buffer.patch | git am` # should also handle return code
>> `git stash pop -q`
>
> Will this new command work with all vc supported [D]VCSs?

I don't know the practical answer, but I do know in theory it could:
we just need to add generic support for "stash".


        Stefan

Re: On the adoption of transient.el

[Omar Polo]

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

> John Yates [2021-08-06 08:39:51] wrote:
>> On Thu, Aug 5, 2021 at 7:41 PM Juri Linkov <juri@linkov.net> wrote:
>>> Currently I'm finishing implementation of a new vc command ...
>> [..SNIP..]
>>> it works by running three git commands:
>>>
>>> `git stash push -m stash_name -- list_of_file_names_from_diff`
>>> `cat diff_buffer.patch | git am` # should also handle return code
>>> `git stash pop -q`
>>
>> Will this new command work with all vc supported [D]VCSs?
>
> I don't know the practical answer, but I do know in theory it could:
> we just need to add generic support for "stash".
>
>
>         Stefan

Sorry for hijacking the thread, but given that the we ended up talking
about stash support for vc, I thought to share this.

I'm working (very very slowly) on vc-got[0], a vc backend for the GoT[1]
vcs.  One of the things I did was to add a shash command, and while very
primitive, it seems to work decently.  It adds an additional column in
vc-dir to show the stage status of the file (there are a couple of
screenshot in the readme).  The implementation is quite messy because
vc-dir-move-to-goal-column hardcodes the value of 25 and I wanted to add
an additional column with the stage status *before* the file status.  I
also had to add an additional command, vc-got-stage-commit, because
vc-next-action (and the rest of vc) assumes that we're working with file
sets.  The process of (un)staging hunks is still pretty tedious since
it's basically a wrapper around `got stage -p' (the equivalent of `git
add -p') using y-or-n-p...

So, all of this to say that I'd really like if someone would try to add
something to vc-mode to stage (and un-stage!) individual hunks, and I'd
like to help in that case.  I'm not stepping up myself because I don't
feel qualified enough (^_^);

Cheers,


[0]: https://git.omarpolo.com/vc-got or https://github.com/omar-polo/vc-got/
[1]: https://gameoftrees.org/

Re: On the adoption of transient.el

[Rudolf Adamkovič]

This is useful, thank you! C-n/C-p and C-s/C-r solved. Selection 
with C-SPC still does not work, e.g. one still cannot copy some 
text for a bug report or personal notes. Further, and I forgot to 
mention this in my original message, the new transient UI renders 
the help system, such as the glorious C-h k, useless. Not being 
able to copy text or describe all keys is not what I expect to see 
in the official parts of vanilla Emacs.

R+

"T.V Raman" <raman@google.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes: 
>  
> I recently discovered thanks to the transient/magit author that 
> once you 
>  enable navigation via arrows in transient popups, it also gives 
>  you isearch of the transient. We then discovered a bug where 
>  using isearch to find a transient option and pressing enter 
>  wasn't working, but Jonas has since fixed that and it works. 
>  transient-enable-popup-navigation is a variable defined in 
>  ‘transient.el’. 
> 
> Its value is t Original value was nil 
> 
>   You can customize this variable.  This variable was 
>   introduced, or its default value was changed, in version 0.2.0 
>   of the transient package. 
> 
> Whether navigation commands are enabled in the transient popup. 
> 
> While a transient is active the transient popup buffer is not 
> the current buffer, making it necessary to use dedicated 
> commands to act on that buffer itself.  If this non-nil, then 
> the following features are available: 
> 
> - "<up>" moves the cursor to the previous suffix. 
>   "<down>" moves the cursor to the next suffix.  "RET" invokes 
>   the suffix the cursor is on. 
> - "<mouse-1>" invokes the clicked on suffix.  - "C-s" and "C-r" 
> start isearch in the popup buffer. 
>  
>> Rudolf Adamkovič <salutis@me.com> writes: 
>> 
>>> Philip Kaludercic <philipk@posteo.net> writes: 
>>> 
>>>> On the other hand something has always felt off about 
>>>> transient, in the sense that it is breaking some expected 
>>>> behaviour or couldn't pin-point yet, but just unconsciously 
>>>> stumble over.  
>>> 
>>> This is exactly how I feel about the "modern" interfaces in 
>>> Emacs. I reported a bug in Embark recently, and because I 
>>> could not select and copy the text, I ended up re-typing the 
>>> text that was right in front of me in Emacs. Say what? For me, 
>>> Emacs is a program where I expect to never waste time 
>>> re-typing anything. Magit has a similar feel to it, and I can 
>>> never be sure if the program will allow me to select text in 
>>> the diverse parts of its user interface. In my opinion, such 
>>> uncertainty is bad for power users. I would expect this from 
>>> Apple or Microsoft software, because their latest “UX 
>>> designers” surely know better than anyone, but in Emacs? 
>> 
>> I am not sure if this is something specific to modern 
>> interfaces, or rather an overreaching when it comes to binding. 
>> After a while I managed to "pin-point" what was irritating me, 
>> and it was the missing ability to search (something that I seem 
>> to do so passively that i didn't even notice it). Having C-s 
>> work is especially useful when there are a lot of transient 
>> options. This cannot be solved by binding C-s manually, as just 
>> because that might work for me, there is some other behaviour 
>> someone else is expecting (eg. your example of selecting and 
>> copying text). 
>> 
>> What I understand transient and certain other packages do is 
>> basically override most keys, even those it doesn't use. This 
>> is more invasive than special-mode, that just doesn't bind 
>> self-insert-command to most keys. What I wonder is why this is 
>> done/why it might be necessary. 
>> 
>>> R+ 
> 
> --  
> 
> Thanks, 
> 
> --Raman(I Search, I Find, I Misplace, I Research) ♈ Id: 
> kg:/m/0285kf1  🦮 

-- 
"Contrariwise," continued Tweedledee, "if it was so, it might be; 
and if it were so, it would be; but as it isn't, it ain't. That's 
logic." -- Lewis Carroll, Through the Looking Glass  Rudolf 
Adamkovič <salutis@me.com> Studenohorská 25 84103 Bratislava 
Slovakia  [he/him]

Re: On the adoption of transient.el

[T.V Raman]

yes, the transient window is special in that it is "never current" but
visible --- I too dont like that behavior but live with it because it
supposedly enhances the visible interface (what do I know, I dont look
at the screen:-))
Rudolf Adamkovič writes:
 > This is useful, thank you! C-n/C-p and C-s/C-r solved. Selection 
 > with C-SPC still does not work, e.g. one still cannot copy some 
 > text for a bug report or personal notes. Further, and I forgot to 
 > mention this in my original message, the new transient UI renders 
 > the help system, such as the glorious C-h k, useless. Not being 
 > able to copy text or describe all keys is not what I expect to see 
 > in the official parts of vanilla Emacs.
 > 
 > R+
 > 
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > Philip Kaludercic <philipk@posteo.net> writes: 
 > >  
 > > I recently discovered thanks to the transient/magit author that 
 > > once you 
 > >  enable navigation via arrows in transient popups, it also gives 
 > >  you isearch of the transient. We then discovered a bug where 
 > >  using isearch to find a transient option and pressing enter 
 > >  wasn't working, but Jonas has since fixed that and it works. 
 > >  transient-enable-popup-navigation is a variable defined in 
 > >  ‘transient.el’. 
 > > 
 > > Its value is t Original value was nil 
 > > 
 > >   You can customize this variable.  This variable was 
 > >   introduced, or its default value was changed, in version 0.2.0 
 > >   of the transient package. 
 > > 
 > > Whether navigation commands are enabled in the transient popup. 
 > > 
 > > While a transient is active the transient popup buffer is not 
 > > the current buffer, making it necessary to use dedicated 
 > > commands to act on that buffer itself.  If this non-nil, then 
 > > the following features are available: 
 > > 
 > > - "<up>" moves the cursor to the previous suffix. 
 > >   "<down>" moves the cursor to the next suffix.  "RET" invokes 
 > >   the suffix the cursor is on. 
 > > - "<mouse-1>" invokes the clicked on suffix.  - "C-s" and "C-r" 
 > > start isearch in the popup buffer. 
 > >  
 > >> Rudolf Adamkovič <salutis@me.com> writes: 
 > >> 
 > >>> Philip Kaludercic <philipk@posteo.net> writes: 
 > >>> 
 > >>>> On the other hand something has always felt off about 
 > >>>> transient, in the sense that it is breaking some expected 
 > >>>> behaviour or couldn't pin-point yet, but just unconsciously 
 > >>>> stumble over.  
 > >>> 
 > >>> This is exactly how I feel about the "modern" interfaces in 
 > >>> Emacs. I reported a bug in Embark recently, and because I 
 > >>> could not select and copy the text, I ended up re-typing the 
 > >>> text that was right in front of me in Emacs. Say what? For me, 
 > >>> Emacs is a program where I expect to never waste time 
 > >>> re-typing anything. Magit has a similar feel to it, and I can 
 > >>> never be sure if the program will allow me to select text in 
 > >>> the diverse parts of its user interface. In my opinion, such 
 > >>> uncertainty is bad for power users. I would expect this from 
 > >>> Apple or Microsoft software, because their latest “UX 
 > >>> designers” surely know better than anyone, but in Emacs? 
 > >> 
 > >> I am not sure if this is something specific to modern 
 > >> interfaces, or rather an overreaching when it comes to binding. 
 > >> After a while I managed to "pin-point" what was irritating me, 
 > >> and it was the missing ability to search (something that I seem 
 > >> to do so passively that i didn't even notice it). Having C-s 
 > >> work is especially useful when there are a lot of transient 
 > >> options. This cannot be solved by binding C-s manually, as just 
 > >> because that might work for me, there is some other behaviour 
 > >> someone else is expecting (eg. your example of selecting and 
 > >> copying text). 
 > >> 
 > >> What I understand transient and certain other packages do is 
 > >> basically override most keys, even those it doesn't use. This 
 > >> is more invasive than special-mode, that just doesn't bind 
 > >> self-insert-command to most keys. What I wonder is why this is 
 > >> done/why it might be necessary. 
 > >> 
 > >>> R+ 
 > > 
 > > --  
 > > 
 > > Thanks, 
 > > 
 > > --Raman(I Search, I Find, I Misplace, I Research) ♈ Id: 
 > > kg:/m/0285kf1  🦮 
 > 
 > -- 
 > "Contrariwise," continued Tweedledee, "if it was so, it might be; 
 > and if it were so, it would be; but as it isn't, it ain't. That's 
 > logic." -- Lewis Carroll, Through the Looking Glass  Rudolf 
 > Adamkovič <salutis@me.com> Studenohorská 25 84103 Bratislava 
 > Slovakia  [he/him]

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: On the adoption of transient.el

[Phil Sainty]

On 2021-08-07 11:02, Rudolf Adamkovič wrote:
> This is useful, thank you! C-n/C-p and C-s/C-r solved. Selection with
> C-SPC still does not work, e.g. one still cannot copy some text for a
> bug report or personal notes.

You actually can, but it seems unintentional.

It looks like the search functionality works by creating a new buffer
with the same contents, and if you exit the search in an unexpected
way it doesn't switch back to the actual transient buffer.  This then
leaves you in a regular buffer in which you can copy text etc, but
you then have to kill that buffer in order to return to the original
transient buffer (which looks identical).

E.g. in Magit

c         ;; 'commit' transent
C-s       ;; isearch
C-x h     ;; exit isearch and mark whole buffer
M-w       ;; copy
C-x k RET ;; kill searchable buffer
C-g       ;; exit transient buffer

This is confusing until you figure out what's going on, but I also
hope it can be retained as a feature in some fashion, because I agree
that it's nice to have an editable version of these buffers.


> Further, and I forgot to mention this in my original message, the new
> transient UI renders the help system, such as the glorious C-h k, 
> useless.

You get key help with '?'

E.g. in Magit

c    ;; 'commit' transient
?    ;; help for key
a    ;; shows *Help* for `magit-commit-amend'


-Phil

Re: On the adoption of transient.el

[Jonas Bernoulli]

Rudolf Adamkovič <salutis@me.com> writes:

> the new transient UI renders 
> the help system, such as the glorious C-h k, useless.

This is https://github.com/magit/transient/issues/113.  Basically,
    "I know and intend to do something about it. Help welcome."

> Not being able to copy text or describe all keys is not what I expect
> to see in the official parts of vanilla Emacs.

    "We cannot allow such heresy in the inner sanctum."

So far I have brought back all the "lost features" or communicated my
plans to do so.

Occasionally I left out a feature, thinking it was not necessary.  Oh,
the hubris!  For example I thought it would be acceptable to loose the
ability to copy some text that is part of the UI (after all there is
precedence in Emacs itself like the margin, header-line, mode-line,
menu, and echo area (including partial key sequences)), but I was wrong,
it means I have strayed from The Way of Emacs.

I probably can bring back this feature as well.
Just opened https://github.com/magit/transient/issues/126 for that.

>>> What I understand transient and certain other packages do is 
>>> basically override most keys, even those it doesn't use. This 
>>> is more invasive than special-mode, that just doesn't bind 
>>> self-insert-command to most keys. What I wonder is why this is 
>>> done/why it might be necessary.

You are of course not the only person who has reservations and who
has expressed their discomfort.  At various occasions this gave me
the opportunity to explain the reasoning behind some of the design
decisions.

I just went through past issues to compile a list of things I have
to cover in the FAQ (both "why?" and "how to restore?" questions).

[Just opened https://github.com/magit/transient/issues/127 for that.]

It will take time to finish that work, but meanwhile you could read
some of the things I have written already.

From https://github.com/magit/transient/issues/38#issuecomment-489069727:

    "In summary. Transient popups are like incomplete key sequences.
[Even when using plain old regular prefix keys] You can only invoke
commands that are available given the current incomplete key sequence
or abort. One could call that a modal interface. Transient differs from
regular prefix keys in that it shows you the available suffixes in a
buffer. That causes it to be perceived as more modal, but really it is
exactly the same as for regular incomplete key sequences except for the
visual feedback."

Lengthier musings [keep in mind that some of it is outdated]:

- https://github.com/magit/transient/issues/17#issuecomment-464243333
- https://github.com/magit/transient/issues/17#issuecomment-482815245

Also note that so far I have not pushed for Transient to actually be
used in Emacs.  That's because I want to address such concerns first.
There are issue in the issue tracker about those.  In addition to the
once mentioned above, you are probably most interested in #114 and #127.

     Jonas

Re: On the adoption of transient.el

[T.V Raman]

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

Rudolf Adamkovi00 <salutis@me.com> writes:


For my own use case with Emacspeak, it was imperative that I be able to
move around  and read the transient buffer, see how I solved it in
emacspeak here:
https://github.com/tvraman/emacspeak/blob/master/lisp/emacspeak-transient.el#L183

Basically I advice transient--show-buffer to snapshot the updated
transient buffer contents, and then display that when the transient is
suspended. Note: I'm not advocating this as  a mainstream solution, but
more as an example of prototyping behavior that may be needed for more
than just the emacspeak user.


> This is useful, thank you! C-n/C-p and C-s/C-r solved. Selection with
> C-SPC still does not work, e.g. one still cannot copy some text for a
> bug report or personal notes. Further, and I forgot to mention this in
> my original message, the new transient UI renders the help system,
> such as the glorious C-h k, useless. Not being able to copy text or
> describe all keys is not what I expect to see in the official parts of
> vanilla Emacs.
>
> R+
>
> "T.V Raman" <raman@google.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:  I recently
>> discovered thanks to the transient/magit author that once you
>> enable navigation via arrows in transient popups, it also gives  you
>> isearch of the transient. We then discovered a bug where  using
>> isearch to find a transient option and pressing enter  wasn't
>> working, but Jonas has since fixed that and it works.
>> transient-enable-popup-navigation is a variable defined in
>> ¡®transient.el¡¯. Its value is t Original value was nil   You can
>> customize this variable.  This variable was   introduced, or its
>> default value was changed, in version 0.2.0   of the transient
>> package. Whether navigation commands are enabled in the transient
>> popup. While a transient is active the transient popup buffer is not
>> the current buffer, making it necessary to use dedicated commands to
>> act on that buffer itself.  If this non-nil, then the following
>> features are available: - "<up>" moves the cursor to the previous
>> suffix.   "<down>" moves the cursor to the next suffix.  "RET"
>> invokes   the suffix the cursor is on. - "<mouse-1>" invokes the
>> clicked on suffix.  - "C-s" and "C-r" start isearch in the popup
>> buffer.  
>>> Rudolf Adamkovi00 <salutis@me.com> writes: 
>>>> Philip Kaludercic <philipk@posteo.net> writes: 
>>>>> On the other hand something has always felt off about transient,
>>>>> in the sense that it is breaking some expected behaviour or
>>>>> couldn't pin-point yet, but just unconsciously stumble over.  
>>>> This is exactly how I feel about the "modern" interfaces in
>>>> Emacs. I reported a bug in Embark recently, and because I could
>>>> not select and copy the text, I ended up re-typing the text that
>>>> was right in front of me in Emacs. Say what? For me, Emacs is a
>>>> program where I expect to never waste time re-typing
>>>> anything. Magit has a similar feel to it, and I can never be sure
>>>> if the program will allow me to select text in the diverse parts
>>>> of its user interface. In my opinion, such uncertainty is bad for
>>>> power users. I would expect this from Apple or Microsoft software,
>>>> because their latest ¡°UX designers¡± surely know better than
>>>> anyone, but in Emacs? 
>>> I am not sure if this is something specific to modern interfaces,
>>> or rather an overreaching when it comes to binding. After a while I
>>> managed to "pin-point" what was irritating me, and it was the
>>> missing ability to search (something that I seem to do so passively
>>> that i didn't even notice it). Having C-s work is especially useful
>>> when there are a lot of transient options. This cannot be solved by
>>> binding C-s manually, as just because that might work for me, there
>>> is some other behaviour someone else is expecting (eg. your example
>>> of selecting and copying text). What I understand transient and
>>> certain other packages do is basically override most keys, even
>>> those it doesn't use. This is more invasive than special-mode, that
>>> just doesn't bind self-insert-command to most keys. What I wonder
>>> is why this is done/why it might be necessary. 
>>>> R+ 
>> --  Thanks, --Raman(I Search, I Find, I Misplace, I Research) 7©3 Id:
>> kg:/m/0285kf1  •0Ü8 

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: On the adoption of transient.el

[Dmitry Gutov]

Hi Juri,

On 06.08.2021 02:20, Juri Linkov wrote:

> While I think Magit is a great package for discoverability etc.
> I found that it's completely sufficient to use just the shell-command.
> With the persistent history of the previously constructed git commands
> using a flex-style completion on previous commands will even reduce
> the need in some vc commands, e.g.
> 
> 'M-! chm TAB' runs `git checkout master` (instead of C-x v r)
> 'M-! pur TAB' runs `git pull --rebase`   (instead of C-x v P)
> ...

Same here (except for the flex completion).

> Currently I'm finishing implementation of a new vc command that
> will allow committing from a diff buffer.  So for example, after
> displaying all changes with e.g. 'C-x v D' you can remove
> some unneeded hunks (with e.g. 'M-k' 'diff-hunk-kill'),
> then on the remaining hunks type 'C-c C-c' in the diff buffer.
> It will create a usual *vc-log* buffer where typing 'C-c C-c'
> will commit only changes from the diff buffer.

This is a very welcome development.

> Internally
> it works by running three git commands:
> 
> `git stash push -m stash_name -- list_of_file_names_from_diff`
> `cat diff_buffer.patch | git am` # should also handle return code

Somewhere around here, I suppose you will pop up the usual log-edit buffer?

> `git stash pop -q`

For your consideration, here's a description of the strategy used by the 
venerable commit-patch command/package:

https://github.com/caldwell/commit-patch/blob/master/commit-patch#L212-L214

- Let the user edit a diff in the diff-mode buffer
- Save it to a file
- 'git apply --cached', to put the contents to the staging area
- 'git commit'

It might have some advantages, such as less chance of something going 
awry with the user's stashes due to a coding error (current, or one 
possibly introduced in the future).

On the flip side, I suppose it will be harder to reuse the existing 
'checkin' backend function. Or generalize the exact approach to other 
backends, since only Git has staging area.

Re: On the adoption of transient.el

[Alfred M. Szmidt]

   Currently I'm finishing implementation of a new vc command that
   will allow committing from a diff buffer.  

This sounds similar to my diff-commit-hunk.el hack; but it is entierly
VC agonstic.

   So for example, after
   displaying all changes with e.g. 'C-x v D' you can remove
   some unneeded hunks (with e.g. 'M-k' 'diff-hunk-kill'),
   then on the remaining hunks type 'C-c C-c' in the diff buffer.
   It will create a usual *vc-log* buffer where typing 'C-c C-c'
   will commit only changes from the diff buffer.  Internally
   it works by running three git commands:

   `git stash push -m stash_name -- list_of_file_names_from_diff`
   `cat diff_buffer.patch | git am` # should also handle return code
   `git stash pop -q`

===File ~/diff-commit-hunk.el===============================
;;;; diff-commit-hunk.el --- commit parts of a hunk in `diff-mode'

(require 'diff-mode)

(defun current-buffer-file-name ()
  (buffer-file-name (current-buffer)))

(defun restore-source-file ()
  (with-current-buffer (current-buffer)
    (erase-buffer)
    (insert-buffer "*diff-commit-hunk*")
    (write-file (current-buffer-file-name)))
  (remove-hook 'vc-checkin-hook 'restore-source-file))

(defmacro with-original-file (&rest body)
  "Reverts associated source file temporarily in a `diff-mode'
buffer to the latest found in VCS, executes BODY and commits the
changes back VCS."
  `(progn
     (save-excursion
       (diff-goto-source)
       (let ((buf (current-buffer)))
	 (with-current-buffer (get-buffer-create "*diff-commit-hunk*")
	   (erase-buffer)
	   (insert-buffer buf)))
       (vc-revert-file (current-buffer-file-name)))
     ,@body
     (save-excursion
       (diff-goto-source)
       (write-file (current-buffer-file-name))
       (add-hook 'vc-checkin-hook 'restore-source-file)
       (vc-checkin (list (current-buffer-file-name))
		   (vc-backend (current-buffer-file-name))))))

;;;###autoload
(defun diff-commit-hunk ()
  "Revert associated source file to the latest version from VCS,
and apply (and commit) current hunk."
  (interactive)
  (with-original-file
   (let ((diff-advance-after-apply-hunk nil))
     (diff-apply-hunk))))

;;;###autoload
(defun diff-commit-all ()
  "Like `diff-commit-hunk', but applies all hunks in the current
diff buffer."
  (interactive)
  (with-original-file
   (goto-char (point-min))
   (diff-hunk-next)			;Skip header.
   (while (not (eobp))
     (diff-apply-hunk))))

(define-key diff-mode-map (kbd "s-a") #'diff-commit-hunk)
(define-key diff-mode-map (kbd "H-a") #'diff-commit-all)

;;;; diff-commit-hunk.el ends here.
============================================================

Re: On the adoption of transient.el

[Juri Linkov]

>> `git stash pop -q`
>
> For your consideration, here's a description of the strategy used by the
> venerable commit-patch command/package:
>
> https://github.com/caldwell/commit-patch/blob/master/commit-patch#L212-L214

Thanks for the reference, it's a good example for implementing
a similar command in vc.

> - Let the user edit a diff in the diff-mode buffer
> - Save it to a file
> - 'git apply --cached', to put the contents to the staging area
> - 'git commit'

But these commands don't perform a merge when committing a patch
with changes in the same file.  So afterwards `git diff` will show
the reversed diff for already committed changes.

This means there are no alternatives to using `git stash pop`
that performs the merge.

Re: On the adoption of transient.el

[Juri Linkov]

>    Currently I'm finishing implementation of a new vc command that
>    will allow committing from a diff buffer.
>
> This sounds similar to my diff-commit-hunk.el hack; but it is entierly
> VC agonstic.
>
> (defun restore-source-file ()
>   (with-current-buffer (current-buffer)
>     (erase-buffer)
>     (insert-buffer "*diff-commit-hunk*")
>     (write-file (current-buffer-file-name)))
>   (remove-hook 'vc-checkin-hook 'restore-source-file))

IIUC, it copies the old file back without merging changes in the same file.

OTOH, `commit-patch` uses `interdiff` (for non-git VCSs)
to compute differences between two changesets.  Then vc
could use something like your diff-commit-hunk.el
for non-git VCSs to implement generic support for stash.

Re: On the adoption of transient.el

[Juri Linkov]

> On the subject of new vc commands, I would love a vc equivalent
> of git-timemachine.

I wonder how is this different from vc-print-log and then
using 'f' (log-view-find-revision) on different commits
navigated by 'n' and 'p' in the *vc-change-log* buffer?
Or 'vc-annotate' and then using 'a' (vc-annotate-revision-previous-to-line).

Re: On the adoption of transient.el

[Alfred M. Szmidt]

   >    Currently I'm finishing implementation of a new vc command that
   >    will allow committing from a diff buffer.
   >
   > This sounds similar to my diff-commit-hunk.el hack; but it is entierly
   > VC agonstic.
   >
   > (defun restore-source-file ()
   >   (with-current-buffer (current-buffer)
   >     (erase-buffer)
   >     (insert-buffer "*diff-commit-hunk*")
   >     (write-file (current-buffer-file-name)))
   >   (remove-hook 'vc-checkin-hook 'restore-source-file))

   IIUC, it copies the old file back without merging changes in the same file.

I'm not sure what you mean.  What scenario are you thinking of?  The
"old file" is the one that contains any changes you are working with.

   OTOH, `commit-patch` uses `interdiff` (for non-git VCSs)
   to compute differences between two changesets.  Then vc
   could use something like your diff-commit-hunk.el
   for non-git VCSs to implement generic support for stash.

What are commit-patch and interdiff?  Since diff-commit-hunk.el works
well for git (and really for any VCS), why have a different system
there?

Re: On the adoption of transient.el

[John Yates]

On Tue, Aug 10, 2021 at 3:24 AM Juri Linkov <juri@linkov.net> wrote:
>
> > On the subject of new vc commands, I would love a vc equivalent
> > of git-timemachine.
>
> I wonder how is this different from vc-print-log and then
> using 'f' (log-view-find-revision) on different commits
> navigated by 'n' and 'p' in the *vc-change-log* buffer?
> Or 'vc-annotate' and then using 'a' (vc-annotate-revision-previous-to-line).

Discoverability.  Less indirection.  No need to access a log buffer.

But, most importantly, context.  Time-machine understands that
the revisions being visited are related and attempts to open each
new revision at the same position.  Your suggestions open each
revision positioned at the first line.

Re: On the adoption of transient.el

[Dmitry Gutov]

On 10.08.2021 10:15, Juri Linkov wrote:
>> - Let the user edit a diff in the diff-mode buffer
>> - Save it to a file
>> - 'git apply --cached', to put the contents to the staging area
>> - 'git commit'
> But these commands don't perform a merge when committing a patch
> with changes in the same file.  So afterwards `git diff` will show
> the reversed diff for already committed changes.

Sorry, I don't understand. Could you explain the scenario in more detail?

Re: On the adoption of transient.el

[Juri Linkov]

>    > (defun restore-source-file ()
>    >   (with-current-buffer (current-buffer)
>    >     (erase-buffer)
>    >     (insert-buffer "*diff-commit-hunk*")
>    >     (write-file (current-buffer-file-name)))
>    >   (remove-hook 'vc-checkin-hook 'restore-source-file))
>
>    IIUC, it copies the old file back without merging changes in the same file.
>
> I'm not sure what you mean.  What scenario are you thinking of?  The
> "old file" is the one that contains any changes you are working with.

This is what I meant: when a file already contains some changes that should
not be committed, and some other changes need to be committed from a patch
in the same file (let's name these changesets as "old" and "new"), then
you save the old file contents temporarily, commit a patch with "new"
changes, and restore the old file contents.  As a result, when you do
'C-x v =' (vc-diff) on such file, it will show the diff that includes
the already committed "new" changes, because these changes were never
merged to the old file.

>    OTOH, `commit-patch` uses `interdiff` (for non-git VCSs)
>    to compute differences between two changesets.  Then vc
>    could use something like your diff-commit-hunk.el
>    for non-git VCSs to implement generic support for stash.
>
> What are commit-patch and interdiff?  Since diff-commit-hunk.el works
> well for git (and really for any VCS), why have a different system
> there?

`interdiff` used by https://github.com/caldwell/commit-patch
is a command that shows the differences between two diff files,
that could help to merge changes from the patch to the working copy
of the same file.

Re: On the adoption of transient.el

[Juri Linkov]

>>> - Let the user edit a diff in the diff-mode buffer
>>> - Save it to a file
>>> - 'git apply --cached', to put the contents to the staging area
>>> - 'git commit'
>> But these commands don't perform a merge when committing a patch
>> with changes in the same file.  So afterwards `git diff` will show
>> the reversed diff for already committed changes.
>
> Sorry, I don't understand. Could you explain the scenario in more detail?

This is the shortest test case:

1. make changes in one part of a file
2. create a patch with changes in another part of the same file
3. git apply --cached a.patch
4. git commit -m "Apply a.patch"
5. git commit -a -m "Commit original file changes"

The last commit reverts the changes committed from the patch.

Re: On the adoption of transient.el

[Dmitry Gutov]

On 11.08.2021 09:58, Juri Linkov wrote:
>> Sorry, I don't understand. Could you explain the scenario in more detail?
> This is the shortest test case:
> 
> 1. make changes in one part of a file
> 2. create a patch with changes in another part of the same file
> 3. git apply --cached a.patch
> 4. git commit -m "Apply a.patch"
> 5. git commit -a -m "Commit original file changes"
> 
> The last commit reverts the changes committed from the patch.

I see, thanks.

To respond to that, I think even among those who would use this feature 
(advanced users), most aren't going to edit the diff outputted by 'C-x v 
D' aside from splitting and deleting hunks (available by bindings 'C-c 
C-s' and 'k'). And those kind of changes shouldn't trigger this problem.

Second, if someone does edit the patch further (after switching off the 
read-only-mode in the diff buffer), they might actually expect this 
behavior: like, I edited the changes for commit, but I didn't edit the 
file itself; should the working copy of the file really incorporate 
those changes? And if they're using something like diff-hl-mode, they 
would notice the effect quickly (whether they expected it or not), and 
could undo/apply that missing change easily.

There is a similar solution to stashes using 'git apply', but it seems 
finicky. Assuming a.patch changes file.ext:

6. git add file.ext
7. git apply --3way a.patch

And see the conflict markers (if the changes do indeed conflict, which 
is not necessarily the case).

I'm not sure triggering conflicts on commit is the best idea, but the 
"no conflict" situation seems nice.

Either way, it requires a user with advanced skill. A simpler 
implementation that would require them to do an extra step manually in 
unusual scenarios doesn't seem too bad.

Re: On the adoption of transient.el

[Arthur Miller]

Jonas Bernoulli <jonas@bernoul.li> writes:

>> I have to run Magit than bb and than Magit will offer a completing
>> read which will pop the asked Helm interface. To me this is not a
>> straightforward enough
>
>   (global-set-key [f1] 'magit-checkout)
>
> Also you generally don't have to "run Magit" and can just use "C-x M-g"
> and in file-visiting buffers also "C-c M-g".

Hi Jonas, I have tried your magit-checkout now. It does not really do
what I had in mind. It seems to just be a wrapper around git checkout,
and similar to git checkout gives error if there are unstaged changes.

What I wanted was a fast straightforward branch switcher, no questions
asked.

The strategy is to stash save all buffers belonging to the project,
stash everything, inclusive untracked files, and than checkout to the
other branch. When checked back, the stash is applied back. I don't know
if you have something like that in magit or if it is something generally
desirable, but I always wanted something simple and dirty to be able to
switch fast when I need it.

Re: On the adoption of transient.el

[Óscar Fuentes]

Arthur Miller <arthur.miller@live.com> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>>> I have to run Magit than bb and than Magit will offer a completing
>>> read which will pop the asked Helm interface. To me this is not a
>>> straightforward enough
>>
>>   (global-set-key [f1] 'magit-checkout)
>>
>> Also you generally don't have to "run Magit" and can just use "C-x M-g"
>> and in file-visiting buffers also "C-c M-g".
>
> Hi Jonas, I have tried your magit-checkout now. It does not really do
> what I had in mind. It seems to just be a wrapper around git checkout,
> and similar to git checkout gives error if there are unstaged changes.
>
> What I wanted was a fast straightforward branch switcher, no questions
> asked.
>
> The strategy is to stash save all buffers belonging to the project,
> stash everything, inclusive untracked files, and than checkout to the
> other branch. When checked back, the stash is applied back. I don't know
> if you have something like that in magit or if it is something generally
> desirable, but I always wanted something simple and dirty to be able to
> switch fast when I need it.

How would Magit know that when you "return back" to a branch it must
apply a certain stash? It seems to me that you are asking for some
Work-In-Progress management system, which use branches instead of
stashes. IIRC there are some Magit extensions for this and even creating
your own doesn't seem difficult, but IMHO your use case, in the way you
describe it, has dubious applications in general.

For starters, the part about automatically stashing untracked files, I
have seem cases where it would stash gigabytes of build products.

Re: On the adoption of transient.el

[Arthur Miller]

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

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>
>>>> I have to run Magit than bb and than Magit will offer a completing
>>>> read which will pop the asked Helm interface. To me this is not a
>>>> straightforward enough
>>>
>>>   (global-set-key [f1] 'magit-checkout)
>>>
>>> Also you generally don't have to "run Magit" and can just use "C-x M-g"
>>> and in file-visiting buffers also "C-c M-g".
>>
>> Hi Jonas, I have tried your magit-checkout now. It does not really do
>> what I had in mind. It seems to just be a wrapper around git checkout,
>> and similar to git checkout gives error if there are unstaged changes.
>>
>> What I wanted was a fast straightforward branch switcher, no questions
>> asked.
>>
>> The strategy is to stash save all buffers belonging to the project,
>> stash everything, inclusive untracked files, and than checkout to the
>> other branch. When checked back, the stash is applied back. I don't know
>> if you have something like that in magit or if it is something generally
>> desirable, but I always wanted something simple and dirty to be able to
>> switch fast when I need it.
>
> How would Magit know that when you "return back" to a branch it must
> apply a certain stash?

Stash can take a name.

> Work-In-Progress management system, which use branches instead of
> apply a certain stash?

No, Stashes are exactly for that (stash create a branch under the hood I
think, but it is not important).

>                        It seems to me that you are asking for some
> Work-In-Progress management system, which use branches instead of
> stashes. IIRC there are some Magit extensions for this and even creating

I don't ask for anything. I was in a discussion and wanted a fast
switcher, was told to use Magit and didn't found it fitting my
needs. Jonas said I should try magit-checkout, and I just explained why
it does not fit my particular need. Just as act of politness to Jonas
kind advice on magit, nothing more.

> your own doesn't seem difficult, but IMHO your use case, in the way you
> describe it, has dubious applications in general.

It is not a "general" solution. I want it to quickly switch branches and
be able to quickly come back. If you work on something bigger, and than
need to checkout another branch for a small fix or lookup and switching
back, I want to save myself of manual work. That is the use
case. Dubious or not :).

> For starters, the part about automatically stashing untracked files, I
> have seem cases where it would stash gigabytes of build products.

Well, if you have case where you have gigabytes of files in git repo,
than you don't want to use this one?

Re: On the adoption of transient.el

[John Yates]

On Sat, Aug 14, 2021 at 8:55 AM Óscar Fuentes <ofv@wanadoo.es> wrote:
> Arthur Miller <arthur.miller@live.com> writes:
> > The strategy is to stash save all buffers belonging to the project,
> > stash everything, inclusive untracked files, and than checkout to the
> > other branch. When checked back, the stash is applied back. I don't know
> > if you have something like that in magit or if it is something generally
> > desirable, but I always wanted something simple and dirty to be able to
> > switch fast when I need it.
>
> How would Magit know that when you "return back" to a branch it must
> apply a certain stash?

Rather than use a stash I would have a script that does two things:
* Creates an undo script for the next step
* Saves everything important as a new commit on the current branch.
  This would include, among other things, all untracked files and the
  undo script mentioned in the first step.

Now with the workspace in a clean state you can switch away to some
other branch.  When you return to the original branch you run the undo
script.  It backs out the last commit.  This would included performing

    git rm --cached <all originally untracked files>

Re: On the adoption of transient.el

[Arthur Miller]

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

John Yates <john@yates-sheets.org> writes:

> On Sat, Aug 14, 2021 at 8:55 AM Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Arthur Miller <arthur.miller@live.com> writes:
>> > The strategy is to stash save all buffers belonging to the project,
>> > stash everything, inclusive untracked files, and than checkout to the
>> > other branch. When checked back, the stash is applied back. I don't know
>> > if you have something like that in magit or if it is something generally
>> > desirable, but I always wanted something simple and dirty to be able to
>> > switch fast when I need it.
>>
>> How would Magit know that when you "return back" to a branch it must
>> apply a certain stash?
>
> Rather than use a stash I would have a script that does two things:
> * Creates an undo script for the next step
> * Saves everything important as a new commit on the current branch.
>   This would include, among other things, all untracked files and the
>   undo script mentioned in the first step.

I had thoughts of implementing commit strategy too :-). I even have
prepared a variable that I have planned to use for this. My motivation
was mostly to see if it is somewhat faster than stashing and reaplying
changes, but I haven't really got to that yet.

After more thoughts I am also not sure if that would be any better than
stash to be honest. Stashes are meant for something like this, and it is
a normal strategy people use. Can you give me some reason why would it
be better to commit changes instead of stashing away them?

When it comes to tracked/untracked files, I do have from the beginning a
variable to switch what is stashed away. I agree with what you wrote in
your last replay, that it is not always desirable to stash untracked
files. I was just not in the mood for explaining in details what I am
doing, so I wrote just very short notice to not use this strategy :).

> Now with the workspace in a clean state you can switch away to some

Isn't that what stashing away also does?

> other branch.  When you return to the original branch you run the undo
> script.  It backs out the last commit.  This would included performing
>
>     git rm --cached <all originally untracked files>

I do delete the stash after applying it. Pop can't be reliably used in
an automated script like this, so I apply the specially named stash and
than throw it away, which si similar to pop.

> * Creates an undo script for the next step

The undo script would be an interesting addition indeed. I am not sure
if we think of same thing, but what I am doing is saving all open and
modified file buffers belonging to git root and subfolders, before I do
stashing. What would be nice, is to undo saved changes in buffers that
were modified, so that they appear as modified after checking out old
branch again. Currently they are just saved, so when they are checked
out again, they don't appear as modified again.

I am not sure where to look to implement something like that, is there
some variable in buffer I can check for modifications sine last save, so
I could use it to save some state somewhere?

Thanks you for the comment, this was constructive.

If you are interested to take a look I have attached the code, and the
poject is here with some additional info in readme:

https://github.com/amno1/helm-git-branch


[-- Attachment #2: helm-git-branch.el --]
[-- Type: text/plain, Size: 8357 bytes --]

;;; helm-git-branch.el --- Switch git branch with Helm interface.  -*- lexical-binding: t; -*-

;; Copyright (C) 2021  Arthur Miller

;; Author: Arthur Miller <arthur.miller@live.com>
;; Keywords:

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;;

;;; Code:

(require 'helm-ls-git)

(defvar helm-source-git-local-branches nil
  "This source will built at runtime.
It can be build explicitly with function
`helm-git-build-local-branches-source'.")

(defface helm-git-branch-current-clean-face
    '((t :foreground "#2aa198"))
  "Files which contain rebase/merge conflicts."
  :group 'helm-ls-git)

(defface helm-git-branch-current-dirty-face
    '((t :foreground "#dc322f"))
  "Files which contain rebase/merge conflicts."
  :group 'helm-ls-git)

;;; Custom
\f
(defgroup helm-git-branch nil
  "Fast git branch switching with Helm."
  :group 'helm)

(defcustom helm-git-branch-changes-action 'stash
  "The default action upon changing a branch with uncommited changes.

If this option is set to 'stash the changes will be automatically stashed.

If this option is set to 'commit the changes will automatically commited."
  :type 'symbol
  :group 'helm)

(defgroup helm-git-branch nil
  "Fast git branch switching with Helm."
  :group 'helm)

(defcustom helm-git-branch-stash-prefix "helm-git-branch--"
  "The prefix to prepend to stash names when autostashing a branch."
  :type 'string
  :group 'helm)

(defcustom helm-git-branch-auto-save-on-change t
  ""
  :type 'boolean
  :group 'helm)

(defcustom helm-git-branch-auto-stash-unstaged t
  ""
  :type 'boolean
  :group 'helm)

(defcustom helm-git-branch-fuzzy-match nil
  "Enable fuzzy matching in `helm-git-*-branch'."
  :group 'helm-branch-git
  :set (lambda (var val)
         (set var val)
         (setq helm-source-git-local-branches nil))
  :type 'boolean)
\f
(defmacro replace-all (from to &optional buffer)
  `(with-current-buffer (or ,buffer (current-buffer))
     (goto-char (point-min))
     (while (search-forward ,from nil t)
       (replace-match ,to))))

(defun git-make-cmd (git-args &rest cmd-args)
  (let ((cmd
         (seq-concatenate
          'list
          '(call-process "git" nil t nil) (split-string git-args) cmd-args)))
    `(lambda () ,cmd)))

(defun git-call (git-args)
  (funcall (git-make-cmd git-args)))

(defmacro with-helm-git (git-cmd &rest body)
  `(nbutlast
     (split-string
      (helm-aif (helm-ls-git-root-dir)
          (with-helm-default-directory it
            (with-output-to-string
              (with-current-buffer standard-output
                (insert (format "%s" (git-call ,git-cmd)))
                ,@body
                (buffer-string))))) "\n" t "[\s\t]*")))

(defvar helm-git-branch-map
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map helm-generic-files-map)
    map))

(defvar helm-git-branch-buffer-map
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map helm-buffer-map)
    map))
\f
;;; Sources
(defun helm-git--local-branches ()
  (with-helm-git "branch"))

(defun helm-git-branch-local-transformer (candidates _source)
  (cl-loop with root = (helm-ls-git-root-dir)
        for i in candidates
        collect
        (cond ((string-match "^\\(*\\)\\(.*\\)" i) ; current branch
               (if (helm-git-branch--dirty-p)
                   (cons (propertize i 'face 'helm-git-branch-current-dirty-face)
                         (expand-file-name (match-string 2 i) root))
                 (cons (propertize i 'face 'helm-git-branch-current-clean-face)
                       (expand-file-name (match-string 2 i) root))))
              (t i))))

(defun helm-git-branch-local-action-transformer (actions _candidate)
  (when (= 1 (length (helm-marked-candidates)))
    (helm-make-actions "Checkout branch"
                       (lambda (_candidate)
                         (let ((marked (helm-marked-candidates)))
                           (dolist (f marked)
                             (vc-git-revert f)
                             (helm-aif (get-file-buffer f)
                                 (with-current-buffer it
                                   (revert-buffer t t)))))))
    actions))
\f
(defclass helm-git-local-source (helm-source-in-buffer)
  ((header-name :initform 'helm-ls-git-header-name)
   (init :initform
         (lambda ()
           (helm-init-candidates-in-buffer 'global
             (helm-git--local-branches))))
   (keymap :initform 'helm-git-branch-map)
   (action :initform (helm-make-actions "Git checkout"
                                        (lambda (_candidate)
                                          (helm-git-branch--checkout _candidate))))
   (filtered-candidate-transformer :initform 'helm-git-branch-local-transformer)
   (action-transformer :initform 'helm-git-branch-local-action-transformer)))

(defun helm-git-build-local-branches-source ()
  ;;(and (memq 'helm-source-ls-git-branches helm-ls-git-default-sources)
  (helm-make-source "Local branches" 'helm-git-local-source
    :fuzzy-match helm-git-branch-fuzzy-match
    :group 'helm
    :keymap helm-git-branch-map))
\f
(defun helm-git-branch--dirty-p ()
  (not (string-blank-p (helm-ls-git-status))))

(defun helm-git-branch--stash ()
  (helm-aif (helm-ls-git-root-dir)
      (with-helm-default-directory it
        (with-output-to-string
          (with-current-buffer standard-output
            (insert
             (call-process "git" nil t nil "stash" "save"
                           (when helm-git-branch-auto-stash-unstaged "-u")
                           (concat helm-git-branch-stash-prefix
                                   (helm-ls-git--branch)))))))))

(defun helm-git-branch--unstash ()
  (helm-aif (helm-ls-git-root-dir)
      (with-helm-default-directory it
        (with-output-to-string
          (with-current-buffer standard-output
            (insert (call-process "git" nil t nil "stash" "list"))
            (goto-char (point-min))
            (when (search-forward (concat helm-git-branch-stash-prefix
                                          (helm-ls-git--branch)) nil t)
              (goto-char (line-beginning-position))
              (search-forward "}" (line-end-position))
              (let ((stash (buffer-substring-no-properties
                            (line-beginning-position) (point))))
                (call-process "git" nil t nil "stash" "apply" stash)
                (call-process "git" nil t nil "stash" "drop" stash))))))))

(defun helm-git-branch--checkout (branch)
  (helm-aif (helm-ls-git-root-dir)
      (with-helm-default-directory it
        (with-output-to-string
          (with-current-buffer standard-output
            (when helm-git-branch-auto-save-on-change
              (save-some-buffers
               t
               (lambda () (file-in-directory-p default-directory (helm-ls-git-root-dir)))))
            (when (helm-git-branch--dirty-p)
              (helm-git-branch--stash))
            (insert (call-process "git" nil t nil "checkout" branch))
            (helm-git-branch--unstash))))))
\f
;;; Commands
;;;###autoload
(defun helm-git-local-branches (&optional arg)
  (interactive "p")
  (let ((helm-ff-default-directory
         (or helm-ff-default-directory
             default-directory)))
    (when (and arg (not (helm-ls-git-root-dir)))
      (error "Not inside a Git repository"))
    (setq helm-source-git-local-branches
          (helm-git-build-local-branches-source))
    (helm-set-local-variable
     'helm-ls-git--current-branch (helm-ls-git--branch))
    (helm :sources helm-source-git-local-branches
          :ff-transformer-show-only-basename nil
          :truncate-lines helm-buffers-truncate-lines
          :buffer "*helm branches*")))

(provide 'helm-git-branch)
;;; helm-git-branch.el ends here

Re: On the adoption of transient.el

[Stefan Monnier]

John Yates [2021-08-15 17:57:27] wrote:
> On Sat, Aug 14, 2021 at 8:55 AM Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Arthur Miller <arthur.miller@live.com> writes:
>> > The strategy is to stash save all buffers belonging to the project,
>> > stash everything, inclusive untracked files, and than checkout to the
>> > other branch. When checked back, the stash is applied back. I don't know
>> > if you have something like that in magit or if it is something generally
>> > desirable, but I always wanted something simple and dirty to be able to
>> > switch fast when I need it.
>>
>> How would Magit know that when you "return back" to a branch it must
>> apply a certain stash?
>
> Rather than use a stash I would have a script that does two things:
> * Creates an undo script for the next step
> * Saves everything important as a new commit on the current branch.
>   This would include, among other things, all untracked files and the
>   undo script mentioned in the first step.

When the users look at this outside of Magit, they'll be very confused,
I think.  So, I think that the kind of functionality you're asking for
would be better implemented in Git than in Magit.


        Stefan

Re: On the adoption of transient.el

[Arthur Miller]

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

>           So, I think that the kind of functionality you're asking for
> would be better implemented in Git than in Magit.

Maybe, but it's not. One can just create an alias in shell for this, or a
shell script. Personanlly I wanted the convenience of Helm completion,
and I also wanted to learn how to write Helm apps, so I did it as a Helm
app. It is really just automation for somethign I do manually.

I wouldn't mind if Magit had an option like 'magit-fast-checkout',
even though I don't use Magit myself usually, I might have used
something like this.

Re: On the adoption of transient.el

[Manuel Uberti]

 > Currently I'm finishing implementation of a new vc command
 > that will allow committing from a diff buffer.  So for
 > example, after displaying all changes with e.g. 'C-x v D'
 > you can remove some unneeded hunks (with e.g. 'M-k' 'diff-
 > hunk-kill'), then on the remaining hunks type 'C-c C-c' in
 > the diff buffer. It will create a usual *vc-log* buffer
 > where typing 'C-c C-c' will commit only changes from the
 > diff buffer.  Internally it works by running three git
 > commands:

 > `git stash push -m stash_name -- list_of_file_names_from_diff`
 > `cat diff_buffer.patch | git am` # should also handle return code
 > `git stash pop -q`

Hi Juri,

do you have any news on this command you were working on?


Thanks

-- 
Manuel Uberti
https://manueluberti.eu

Re: On the adoption of transient.el

[T.V Raman]

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

Manuel Uberti <manuel.uberti@inventati.org> writes:


Also -- with repeat-mode in Emacs 28, many of the simpler transient
use-cases  might be better done with repeat --- and that might also
provide an opportunity / time-window to update transient to be more
consistent with the rest of emacs. Specifically, Transient is still a
bit of an outlier in how it handles point with respect to what the user
interacts with -->> Currently I'm finishing implementation of a new vc command
>> that will allow committing from a diff buffer.  So for
>> example, after displaying all changes with e.g. 'C-x v D'
>> you can remove some unneeded hunks (with e.g. 'M-k' 'diff-
>> hunk-kill'), then on the remaining hunks type 'C-c C-c' in
>> the diff buffer. It will create a usual *vc-log* buffer
>> where typing 'C-c C-c' will commit only changes from the
>> diff buffer.  Internally it works by running three git
>> commands:
>
>> `git stash push -m stash_name -- list_of_file_names_from_diff`
>> `cat diff_buffer.patch | git am` # should also handle return code
>> `git stash pop -q`
>
> Hi Juri,
>
> do you have any news on this command you were working on?
>
>
> Thanks

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: On the adoption of transient.el

[Juri Linkov]

>> Currently I'm finishing implementation of a new vc command
>> that will allow committing from a diff buffer.  So for
>> example, after displaying all changes with e.g. 'C-x v D'
>> you can remove some unneeded hunks (with e.g. 'M-k' 'diff-
>> hunk-kill'), then on the remaining hunks type 'C-c C-c' in
>> the diff buffer. It will create a usual *vc-log* buffer
>> where typing 'C-c C-c' will commit only changes from the
>> diff buffer.  Internally it works by running three git
>> commands:
>
>> `git stash push -m stash_name -- list_of_file_names_from_diff`
>> `cat diff_buffer.patch | git am` # should also handle return code
>> `git stash pop -q`
>
> do you have any news on this command you were working on?

The command is basically ready and I'll give it more testing
and commit it soon in a week after vacation.  But please note
that it will use `git apply --cached && git commit`
instead of `git stash`.

Re: On the adoption of transient.el

[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. ]]]

This seems to be an idea for a command that would let you select hunks
from a diff, and commit those hunks directly into a repo -- but only
if it is a git repo.

VC is supposed to handle various version control systems in a generic
way, and any added faciities should be generic, too.

Also, I have a feeling it is cleaner and safer for the command to make
the selected changes in an Emacs buffer visiting the source file.
Then, after you look at that buffer and make sure it has the contents
you want, you can commit it with C-x v v.

This would make it simpler, and also eliminate the problematical
limitation to git.

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

Re: On the adoption of transient.el

[Juri Linkov]

>> do you have any news on this command you were working on?
>
> The command is basically ready and I'll give it more testing
> and commit it soon in a week after vacation.

There is a feature request in bug#52349 from which the patch will be pushed.