Tapatalk

UltraEdit as GIT_EDITOR?

UltraEdit as GIT_EDITOR?

71
NewbieNewbie
71

PostApr 20, 2020#1

I have UltraEdit (x64  26.20.0.68) set up as my EDITOR, and have been having some trouble with git commits.  If GIT_EDITOR (or various other configurations) are not set, git will use the EDITOR environment variable as its editor.  When I "git commit" it opens UE to allow me to specify a check-in message.  While git normally waits until the editor is closed before proceeding, with UE as the editor it attempts to proceed immediately, sees that the check-in message is blank, and fails.

Does anyone know whether there is a command line I could put in the GIT_EDITOR environment variable to get git to work correctly with UE?

6,823625
Grand MasterGrand Master
6,823625

PostApr 20, 2020#2

GIT proceeds immediately because of the started instance of UltraEdit exits immediately. There are several options to avoid that.

The first one is running UltraEdit executable with option /fni (force new instance) as first parameter. Then the started UltraEdit instance does not search for an already running instance to pass the arguments (file name(s)) to the already running instance and exit. I don't know if this is possible via the environment variable GIT_EDITOR.

The second one is opening in UltraEdit Advanced - Settings or Configuration - Application layout - Miscellaneous and check the setting Maintain separate process for each file opened from external application. See help for details about this option. The instance of UltraEdit started by Git is in this case running in background without showing a window while the file name passed as argument to started UE instance is passed to already running instance for viewing and editing by the user. When the user closes the file in the instance with visible window, the foreground UE instance informs the background UE instance that it can exit now as the file is closed in foreground instance.

The third one is opening in UltraEdit Advanced - Settings or Configuration - Application layout - Miscellaneous and check the setting Allow multiple instances to use by default multiple instances of UltraEdit instead of just one.

Note: UltraEdit must be exited after changing a configuration setting to be active for new instances. The configuration settings are stored into INI file or Windows registry on exit of UltraEdit while being immediately applied on already running instance on which the modification on configuration was made by the user.

71
NewbieNewbie
71

PostApr 20, 2020#3

It turns out that in a clean command line, I didn't have the EDITOR environment variable set, and I couldn't figure out how git decided to use it in the first place.   I was able to make it work correctly by editing C:\Users\<name>\.gitconfig like so:

Code: Select all

[core]
    editor = 'C:/Program Files/IDM Computer Solutions/UltraEdit/uedit64.exe' /fni
(Note the forward slashes in place of the normal Windows backslashes.)
Thanks for the help!

5

PostMar 22, 2025#4

Hm. Running UE64 2024.3.0.8 and Git 2.47.1. Win 64.

The /fni portion does no good. UltraEdit reports "Access to C:\Program Files\Git\fni was denied.'
Replacing /fni with //fni gets rid of the error message but only launches a new instance of UE64 (no open COMMIT_EDITMSG file/edit window).

No //fni or /fni at all opens UE64. 
Only if UE64 is already running, an edit window for COMMIT_EDITMSG is opened. Otherwise UE64 will not automatically open the COMMIT_EDITMSG file.

Notepad and EditPad Pro both auto-open COMMIT_EDITMSG even when no previous instances are running.

Examples from my .gitconfig :

Code: Select all

[core]
    editor = 'C:/Program Files/UltraEdit/uedit64.exe'

# ...or...

[core]
    editor = 'C:/Program Files/EditPad Pro 8/EditPadPro8.exe'

Now, how can I get the same behavior from UE64? That is, if no previous instance of UE64 is already running - launching UE64, auto-opening COMMIT_EDITMSG when performing git commit ?
error.png (21.55KiB)

PostMar 22, 2025#5

Yes, I'm aware that there was a typo in the .gitconfig file when I re-created the error message from UE64 ("fin", not "fni"). But the result remains the same with a properly spelled /fni .
error.png (19.08KiB)

PostMar 23, 2025#6

It seems that the problem is related to 64-bit UltraEdit being a bit picky when it comes to forward slashes in the file path:

UEDIT64 \TEMP\COMMIT_EDITMSG works just fine.
UEDIT64 /TEMP/COMMIT_EDITMSG does not work. 

The other editors I've tested are less picky.

6,823625
Grand MasterGrand Master
6,823625

PostMar 23, 2025#7

The Microsoft documentation about Naming Files, Paths, and Namespaces describes clearly that the directory separator is \ on Windows and not / as on Linux/Mac. The documentation page describes also how the Windows file I/O automatically corrects file/folder strings with / to strings with \ before passing the file/folder strings to the file system (usually NTFS or FAT32).

Applications written natively for Windows like the Windows commands interpret an argument beginning with / as an option. UltraEdit does that also because of supporting multiple options whereby most begin with / as that character is not allowed in a file/folder name on Windows which is the reason for the automatic correction by Windows file I/O.

Many applications are nowadays ported from Linux to Windows and use on Windows also the Linux standard for options. Command line options on Linux/Mac begin with - which is usually not used as first character of a file/folder name. Such applications do not have a problem with an argument string beginning with / because of not interpreting such an argument string as a command line option. The argument string is interpreted as file/folder name and is passed later to the Windows file I/O which automatically corrects the wrong directory separator.

It is nevertheless not advisable to use / in file/folder strings on Windows as that can result in an unexpected behavior on execution despite the automatic correction by Windows file I/O depending on the application. The Windows Command Processor cmd is such an application.

Example of wrong execution behavior caused by using / instead of \ in a command prompt window.

Code: Select all

for %I in (%SystemRoot%/*.exe) do @if exist "%I" (echo Existing file: "%I") else echo Missing file: "%I"
This command line executed in a command prompt window with current working directory being not the Windows directory outputs that every executable file found in the Windows directory by the Windows file I/O does not exist for the Windows Command Processor.

Code: Select all

for %I in (%SystemRoot%\*.exe) do @if exist "%I" (echo Existing file: "%I") else echo Missing file: "%I"
This command line always works and outputs all found executables in the Windows directory as existing file. The difference between the two command lines is just the usage of wrong / instead of correct \ in the wildcard pattern with full path causing cmd interpreting the found file name wrong as it can be seen on the output file names.

Another example is the command CD. There is the directory Downloads in root directory of the current drive. The execution of cd /Downloads fails with an error message because of  CD interprets /D as option and the remaining string ownloads as name of the subdirectory to change to in the current working directory. The execution of cd \Downloads works and changes the current directory on same drive to the subdirectory Downloads of the root directory of current drive.

A file/folder string beginning with / references on Linux/Mac a file/folder with its absolute name. / at the beginning means root of the file system on Linux/Mac. A file/folder string beginning with \ references on Windows the root directory of the current drive and is therefore a relative path specification as described by Microsoft on the first linked documentation page. Users of Git on Windows should know all those differences in syntax between Windows and Linux/Mac.

5

PostMar 23, 2025#8

Something (git, UE64) has obviously changed since 2020, as it appears that it was working back then. I can live with using a different editor for the commit message, even a workaround involving sed, though I had expected this to be an easy match for UE.

6,823625
Grand MasterGrand Master
6,823625

PostMar 24, 2025#9

UEStudio has built-in support for Git in comparison to UltraEdit which has no built-in support for Git.

I have not installed Git, but I faked a Git installation by copying another executable and naming the copy git.exe and creating %USERPROFILE%\.gitconfig from a template found in world wide web. Then I started UEStudio and enabled the Git integration with enabling also the configuration option Set UEStudio as default editor for all repositories. UEStudio added to the file %USERPROFILE%\.gitconfig in section [core] the line:

Code: Select all

editor="'C:/Program Files/IDM Computer Solutions/UEStudio/UEStudio.exe'"
UEStudio configured itself just with its fully qualified file name with Linux/Mac directory separator / and with single quotes and enclosing all in double quotes. That is most likely done for Git Bash on Windows.

I cannot try if that configuration really works also for writing commit messages independent on what is configured in UEStudio at Advanced - Settings or Configuration - Application layout - Miscellaneous regarding to start of UEStudio on an instance already running.

Please contact UltraEdit support by email if that information from a user of UC/UE/UES with no usage of Git is of no help. I am sure that the UltraEdit support can help on how to configure UltraEdit at least as text editor for Git although not having a built-in Git integration like UEStudio.

5

PostMar 25, 2025#10

That's some dedication, thank you for the effort.
Even with the double-then-single quote approach, the result remains less than perfect. If UE is already running, the COMMIT_EDITMSG file is opened for editing. If UE is not already running, an instance is launched but COMMIT_EDITMSG is not opened for editing.

I'll check with UE support. My only aim is to use UE as a text editor for the COMMIT_EDITMSG file, all the other git stuff is handled reasonably well by the RAD environment.