git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: David <bouncingcats@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: Re: Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes”
Date: Sun, 15 Sep 2019 13:41:12 +1000	[thread overview]
Message-ID: <CAMPXz=oC29Wr16KPp_jJ5gFi7N2AN3tqnHX38FkszR32PH5M+Q@mail.gmail.com> (raw)
In-Reply-To: <20190914190656.r2aogh4dcobay5vn@yadavpratyush.com>

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.

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.

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
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 #####

  reply	other threads:[~2019-09-15  3:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13  2:54 Git Gui - enhancement suggestion - Can a double click on the file name in the “unstaged” area move the item to “staged changes” Allan Ford
2019-09-13 14:32 ` Pratyush Yadav
2019-09-13 20:27   ` Bert Wesarg
2019-09-13 21:06     ` Pratyush Yadav
2019-09-14 16:07     ` David
2019-09-14 19:08       ` Pratyush Yadav
2019-09-15  3:41         ` David [this message]
2019-09-16 17:49           ` Pratyush Yadav
2019-09-13 21:53   ` Marc Branchaud
2019-09-14 15:57     ` David
2019-09-14 21:23       ` Pratyush Yadav
2019-09-15  3:42         ` David
2019-09-14  7:24   ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMPXz=oC29Wr16KPp_jJ5gFi7N2AN3tqnHX38FkszR32PH5M+Q@mail.gmail.com' \
    --to=bouncingcats@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).