git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes”

From
Pratyush Yadav <me@yadavpratyush.com>
Date
Sep 16, 2019, 17:49 UTC
Message-ID
<20190916174950.so6ku57hyr35ivy4@yadavpratyush.com>
In-Reply-To
<CAMPXz=oC29Wr16KPp_jJ5gFi7N2AN3tqnHX38FkszR32PH5M+Q@mail.gmail.com>
On 15/09/19 01:41PM, David wrote:
Show 40 quoted lines
> On Sun, 15 Sep 2019 at 05:08, Pratyush Yadav <me@yadavpratyush.com> wrote:
> > On 15/09/19 02:07AM, David wrote:
> > > On Sat, 14 Sep 2019 at 06:51, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> 
> > > > I consider adding a second way as not not acceptable. I also consider
> > > > double-click on a file in a GUI an "open" action.
> > >
> > > Yes!
> > >
> > > In fact, I've often fantasized how useful it would be that if I double
> > > clicked on that file name in the unstaged pane or the staged pane,
> > > then that would open the file for editing in my preferred/configured editor.
> > >
> > > Now for me *that* would be a very frequently used improvement!
> > >
> > > I wonder what other readers think about this idea?
> >
> > Sounds reasonable. I've wanted something similar, but for commit
> > messages.
> >
> > But one major reason I didn't come up with a patch for editing commit
> > messages in the editor of your choice is terminal based editors.
> 
> Hi again Pratyush Yadav, and other readers!
> 
> I hope I don't sound like I am arguing or enthusiastically promoting change
> in this subthread. I'm not, my attitude is rather just to explore an idea to see
> what others think of it. Some days I have good ideas, other days my ideas
> have flaws that I missed, so I like to discuss first.
> 
> More important, I want to say that I am very happy to see that there are
> folks interested to discuss the Tcl/Tk git GUI tools. In fact I have local Tcl
> patches myself, bugfixes and enhancements for git-gui and gitk, which I
> would be happy to share except that I do not know how to do that effectively.
> 
> I don't enjoy Tcl and because of that I have avoided it and don't consider
> my skill level to be very high. I find it rather obtuse, especially the way
> it does namespacing, and "upvar" in particular. I struggle to read it without
> comments. But I learned enough of Tcl specifically to improve aspects
> of git-gui and gitk that were bothering me in the past.

I have quite the opposite experience with Tcl. I've been a C person for a long time, and was never a big fan of scripting languages. But I have been enjoying hacking in Tcl. But I do agree that some parts of Tcl are rather strange, and not easy for readability.

I'd be happy to look at your enhancements, and try to fine tune the 
code, but I would point out that some things might just be too specific 
to your workflow, and won't work for the rest of the people using 
git-gui. So do take that into account if you do decide to send some 
improvements in.
 
Show 5 quoted lines
> As well as bug fixes, I have enhancements to both that greatly assist
> my workflow. For example, in git-gui, I have a hotkey that pastes the
> currently highlighted pathname into the commit message. In gitk,
> I have added "find all files in commit" to the file list pane, and fixed
> the flawed regex matching and associated controls.
FYI, I'm not the maintainer of gitk. So patches for it should be sent to 
Paul Mackerras <paulus@ozlabs.org>.
 
Show 28 quoted lines
> My workflow involves a lot of large rebases, and merge conflicts can occur
> in the middle of them that affect dozens of files, that need editing
> to resolve. That's where easily being able to start an editor from git-gui
> in that situation would benefit my workflow. But, it's not a big deal.
> 
> Now, to specific comments you made:
> 
> > I don't
> > think there is any way of finding out the default terminal emulator in
> > Linux, and I don't think there is a standard way of making terminal
> > emulator launch programs you want.
> 
> I agree where you say there is no "standard way", because the
> various GUI environments are not consistent (Gnome, LXDE, etc) and
> neither are the command line arguments of various terminal emulators,
> and sometimes those don't work as expected.
> 
> > So your suggestion works only for GUI based editors. We would have to
> > mention that only GUI based editors can open files.
> 
> Here, I disagree. My suggestion was to provide a double-click facility
> that would trigger a command that can be *configured by the user*.
> 
> And it is wrong to say that only GUI editors can open files.
> For example, my OS is Debian, my GUI is LXDE, and my terminal
> emulator is lxterminal. (I don't recommend it, but that's another story).
> If I have a terminal window open, I can type the command:
>   $ lxterminal -e vi foo

Ah! I have used this many times (for gnome-terminal), but for some reason it didn't occur to me to have a customizable editor command. FWIW, I am in favor of something like this being used in git-gui.

Show 34 quoted lines
> and a new independent terminal window opens with the editor 'vi'
> editing the file foo. Similar functionality can be achieved from a
> .desktop file, or from a shell script.
> 
> Here is a demo Tcl script (working here) that confirms one way
> of spawning an editor from Tcl in a terminal window under LXDE:
> 
> ##### begin script #####
> #!/usr/bin/tclsh
> 
> package require Tk
> 
> # name of this script
> set scriptname [info script]
> 
> # demo user command
> set command "lxterminal -e vi -R $scriptname"
> 
> # create text widget
> pack [text .t]
> 
> # add text to show that we are running
> .t insert end "$scriptname: Running: $command\n"
> 
> # run the demo command
> set chan [open "| $command"]
> 
> # (at this point, a new terminal window appears
> # containing vi displaying this script file)
> 
> # add text to show that we did not block on command
> .t insert end "$scriptname: Reached end\n"
> 
> ##### end script #####

If you would volunteer to send patches implementing something like that, I would be happy to review. As for me doing it myself, I can't really say if or when I can get to it. I have limited time available, and there are some other things I'd rather do first.

-- 
Regards,
Pratyush Yadav
Previous: DavidNext: Marc Branchaud
Message 8 of 13 in “Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes””
  1. Allan FordSep 13, 2019
  2. Pratyush YadavSep 13, 2019
  3. Bert WesargSep 13, 2019
  4. Pratyush YadavSep 13, 2019
  5. DavidSep 14, 2019
  6. Pratyush YadavSep 14, 2019
  7. DavidSep 15, 2019
  8. Pratyush YadavSep 16, 2019
  9. Marc BranchaudSep 13, 2019
  10. DavidSep 14, 2019
  11. Pratyush YadavSep 14, 2019
  12. DavidSep 15, 2019
  13. Johannes SixtSep 14, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.