Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

I am trying to compile Emacs on a new computer with freshly installed Windows 11
and mingw and having some troubles.

ld is complaining about missing snprintf. Seems like I can't get past that
one. I am using mingw ucrt toolchain/runtime since m4 failed for "ordinary"
mingw-w64 toolchain which I used on Windows 10 (m4 failed creating configure
script). Any idea why and what to do? It is defined in stdio.h so I would expect
it to be included in basic libc. Do I need to pass some extra flag
compiler/linker flag?

Since I removed msys mingw-w64 from my PATH to be sure mingw-w64-ucrt runtime
don't mix with other mingw runtime(s), Git also got removed from the path (I am
using mingw-64 one), and than my running Emacs couldn't open a file from a Git
repo.

The backtrace shows find-file is calling vc-refresh which realized I am in a Git
repo and is trying to call Git. If I start emacs -q afresh without Git in the
path, it works fine, so I assume Emacs registers Git program at some point and
does not check for it on every call, perhaps I am wrong about that one?

If that would be the case, I think it is a bug to assume that environment can't
change under running Emacs.

Also, calling vc-refresh obviously results in a quite expensive call to git
process everytime I open a file from git repo. Is it really a good default
option? At least I interpret it so since emacs -q has vc-refresh in
find-file-hook. Why do we even need vc-refresh by default in find-file-hook?

The backtrace:

  call-process("git" nil (t nil) nil "--no-pager" "ls-files" "-c" "-z" "--" "dired-auto-readme.el")
  process-file("git" nil (t nil) nil "--no-pager" "ls-files" "-c" "-z" "--" "dired-auto-readme.el")
  vc-git--call((t nil) "ls-files" "-c" "-z" "--" "dired-auto-readme.el")
  vc-git--out-ok("ls-files" "-c" "-z" "--" "dired-auto-readme.el")
  vc-git-registered("c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  vc-git-registered("c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  vc-call-backend(Git registered "c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  #f(compiled-function (b) #<bytecode -0xf11085386c2ca6c>)(Git)
  mapc(#f(compiled-function (b) #<bytecode -0xf11085386c2ca6c>) (RCS CVS SVN SCCS SRC Bzr Git Hg))
  vc-registered("c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  vc-backend("c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  vc-refresh-state()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer dired-auto-readme.el> "~/repos/dired-auto-readme/dired-auto-readme.el" nil nil "~/repos/dired-auto-readme/dired-auto-readme.el" (0 3031117341))
  find-file-noselect("c:/Users/arthu/repos/dired-auto-readme/dired-auto-..." nil nil nil)
  find-file("c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  dired--find-file(find-file "c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  dired--find-possibly-alternative-file("c:/Users/arthu/repos/dired-auto-readme/dired-auto-...")
  dired-find-file()
  funcall-interactively(dired-find-file)
  command-execute(dired-find-file)

After removing vc-refresh from find-file-hook, it works fine.

I am using 29.2_1 precompiled binary from the ftp, until I can compile my own.

/arthur

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 12/02/2024 12:06, Arthur Miller wrote:
> Also, calling vc-refresh obviously results in a quite expensive call to git
> process everytime I open a file from git repo. Is it really a good default
> option? At least I interpret it so since emacs -q has vc-refresh in
> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?

To have the mode-line indicator up-to-date, I imagine.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 12/02/2024 12:06, Arthur Miller wrote:
>> Also, calling vc-refresh obviously results in a quite expensive call to git
>> process everytime I open a file from git repo. Is it really a good default
>> option? At least I interpret it so since emacs -q has vc-refresh in
>> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?
>
> To have the mode-line indicator up-to-date, I imagine.

(setq vc-handled-backends nil) solved it. I would prefer such an expensive
feature to be opt-in not opt-out, or at least better advertised so I don't have
to find by a chance what Emacs is doing in the background; thanks.

>                                             I imagine.

I would appreciate if you leave sarcasm out of your answers.

Thank you.
/arthur

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 12/02/2024 15:56, Arthur Miller wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> On 12/02/2024 12:06, Arthur Miller wrote:
>>> Also, calling vc-refresh obviously results in a quite expensive call to git
>>> process everytime I open a file from git repo. Is it really a good default
>>> option? At least I interpret it so since emacs -q has vc-refresh in
>>> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?
>> To have the mode-line indicator up-to-date, I imagine.
> (setq vc-handled-backends nil) solved it. I would prefer such an expensive
> feature to be opt-in not opt-out, or at least better advertised so I don't have
> to find by a chance what Emacs is doing in the background; thanks.

The fact of the matter is, it's relatively expensive only on certain 
platforms, but much less so on the main one that we keep in mind when 
developing Emacs (GNU/Linux).

You might be curious to hear that visiting a file controlled by Git 
under MS Windows was ever slower in the past, and yours truly spent some 
effort reducing the number of process calls we take to compute a file's 
status (about 10 years ago or so).

>>                                              I imagine.
> I would appreciate if you leave sarcasm out of your answers.

No sarcasm here. Your question is valid: why not defer the process calls 
until some operation actually requests the file's status.

The answer stems from the UI considerations. And if we show it in the 
mode-line, we have to update the file's VCS status eagerly.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> Date: Mon, 12 Feb 2024 16:58:52 +0200
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> To have the mode-line indicator up-to-date, I imagine.
> > (setq vc-handled-backends nil) solved it. I would prefer such an expensive
> > feature to be opt-in not opt-out, or at least better advertised so I don't have
> > to find by a chance what Emacs is doing in the background; thanks.
> 
> The fact of the matter is, it's relatively expensive only on certain 
> platforms, but much less so on the main one that we keep in mind when 
> developing Emacs (GNU/Linux).

If by "certain platforms" you mean MS-Windows, then the command shown
in the backtrace posted by Arthur takes between 24 and 30 msec here.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 12/02/2024 18:49, Eli Zaretskii wrote:
>> Date: Mon, 12 Feb 2024 16:58:52 +0200
>> Cc:emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>>>> To have the mode-line indicator up-to-date, I imagine.
>>> (setq vc-handled-backends nil) solved it. I would prefer such an expensive
>>> feature to be opt-in not opt-out, or at least better advertised so I don't have
>>> to find by a chance what Emacs is doing in the background; thanks.
>> The fact of the matter is, it's relatively expensive only on certain
>> platforms, but much less so on the main one that we keep in mind when
>> developing Emacs (GNU/Linux).
> If by "certain platforms" you mean MS-Windows, then the command shown

Yes.

> in the backtrace posted by Arthur takes between 24 and 30 msec here.

If there are several calls required (I don't remember how many we have 
now), 30x4 can turn into a 120ms delay, which would be perceptible 
enough and fairly annoying.

One of the other problems I recall is that the Git distribution at the 
time added a shell script called git.bat (or git.cmd, something like 
that), and that extension took priority over git.exe in the path lookup. 
And launching that was an order of a magnitude slower than using git.exe 
directly.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> Date: Mon, 12 Feb 2024 20:05:36 +0200
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > in the backtrace posted by Arthur takes between 24 and 30 msec here.
> 
> If there are several calls required (I don't remember how many we have 
> now), 30x4 can turn into a 120ms delay, which would be perceptible 
> enough and fairly annoying.

I don't experience any annoyance in my Emacs.

> One of the other problems I recall is that the Git distribution at the 
> time added a shell script called git.bat (or git.cmd, something like 
> that), and that extension took priority over git.exe in the path lookup. 
> And launching that was an order of a magnitude slower than using git.exe 
> directly.

I see only moderate slowdown when invoking Git via a batch file:
something like 50% slower (i.e. by a factor of 1.5).  That is nowhere
near an order of magnitude.

And again, I'm using this every day, and have yet to see any annoying
delays.  At least in the Emacs repositories.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 12/02/2024 21:15, Eli Zaretskii wrote:

>> One of the other problems I recall is that the Git distribution at the
>> time added a shell script called git.bat (or git.cmd, something like
>> that), and that extension took priority over git.exe in the path lookup.
>> And launching that was an order of a magnitude slower than using git.exe
>> directly.
> I see only moderate slowdown when invoking Git via a batch file:
> something like 50% slower (i.e. by a factor of 1.5).  That is nowhere
> near an order of magnitude.
> 
> And again, I'm using this every day, and have yet to see any annoying
> delays.  At least in the Emacs repositories.

Perhaps my recollections also stem from using a computer an order of a 
magnitude slower than what we, on average, have these days.

Either way, perhaps Arthur can support the claim about "a quite 
expensive call" with some numbers from his machine.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> Date: Mon, 12 Feb 2024 21:25:33 +0200
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> Either way, perhaps Arthur can support the claim about "a quite 
> expensive call" with some numbers from his machine.

Yes, some data would be welcome.  Perhaps there are some other factors
at work there.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 12/02/2024 15:56, Arthur Miller wrote:
>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>> 
>>> On 12/02/2024 12:06, Arthur Miller wrote:
>>>> Also, calling vc-refresh obviously results in a quite expensive call to git
>>>> process everytime I open a file from git repo. Is it really a good default
>>>> option? At least I interpret it so since emacs -q has vc-refresh in
>>>> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?
>>> To have the mode-line indicator up-to-date, I imagine.
>> (setq vc-handled-backends nil) solved it. I would prefer such an expensive
>> feature to be opt-in not opt-out, or at least better advertised so I don't have
>> to find by a chance what Emacs is doing in the background; thanks.
>
> The fact of the matter is, it's relatively expensive only on certain platforms,
> but much less so on the main one that we keep in mind when developing Emacs
> (GNU/Linux).

To me, this is expensive regardless of the platform.

It is not so much about the speed of process spawning, more about the fact that
I am spending CPU cycles and battery on something I don't care about.

I wasn't even aware this was going on, untill yesterday. I understand that some
users like to see diverse stuff in their modeline, statusbars, powerlines,
command prompts and other widgets. That is fine; if users want it, give it to
them.

But I am not such a user, and this feels a bit too much to have it auto
on. This can get triggered automatically in save places; for example I have save
place on, so when I open a file, Emacs will display cursor at the same place
where I left. I see that it gets triggred in some places with Helm
completion. Basically everything I have nowdays is in Git, inclusive my entire
emacs.d folder. That means I am constantly starting and killing git processes,
and I don't even care about that info on my modeline. I look barely at modeline;
sometimes I take a look at the clock or line/column number.

As a note, doesn't people normally use gitstatusd for this?

https://github.com/romkatv/gitstatus (GPL3 software)

> You might be curious to hear that visiting a file controlled by Git under MS
> Windows was ever slower in the past, and yours truly spent some effort reducing
> the number of process calls we take to compute a file's status (about 10 years
> ago or so).

I trust you, and I have no doubts that you have done a good job. Ten years ago,
I wasn't even using git myself.

If you consider that people are complaining quite a lot about Emacs been too
slow on Windows, than I would consider if this is something that has to be on by
default.

>>>                                              I imagine.
>> I would appreciate if you leave sarcasm out of your answers.
>
> No sarcasm here.

If you end with "I imagne" than it implies it is self-evident. For me it
obviously wasn't :). I got aware of it from that backtrace.

As a side note: I am really grateful to whomever wrote the debugger and edebug
so I can just click on a function name and jump to the implementation instrument
it with edebug and just step through. It is really handy.

> No sarcasm here. Your question is valid: why not defer the process calls until
> some operation actually requests the file's status.
>
> The answer stems from the UI considerations. And if we show it in the mode-line,
> we have to update the file's VCS status eagerly.

I understand and agree that running a git process in modeline update would be
even worse, we don't want that :-).

Can we have it optional to update modeline, but to have the rest of
vc-mode active?

Seems that setting vc-backend to nil shuts down everything.

If it is used just for the modeline update, than we can safely (and optionally)
remove it from the find-file hook to start with? Something like this:

#+begin_src emacs-lisp
(defcustom vc-display-status t
  "If non-nil, display revision number and lock status in mode line.
If nil, only the backend name is displayed.  When the value
is `no-backend', then no backend name is displayed before the
revision number and lock status."
  :type '(choice (const :tag "Show only revision/status" no-backend)
                 (const :tag "Show backend and revision/status" t)
                 (const :tag "Show only backend name" backend)
                 (const :tag "Don't show any revision info" nil))
  :set
  (lambda (symbol new)
    (set-default symbol new)
    (if (not new)
        (setq find-file-hook (delq 'vc-refresh-state find-file-hook))
      (add-hook 'find-file-hook 'vc-refresh-state)))
  :group 'vc)
#+end_src

When saving files, it is implemented differently, basic-save-buffer triggers
everything by calling vc-backend. Is it some special reason why vc-refresh-state
is called directly and now in after-save-hook for example? I add
vc-refresh-state to after-save-hook and hack the needed places, could that work,
or are the some other considerations? Sorry, I am not familiar with
vc.el/project.el so I don't know how everything hangs together in that regard.

Thanks for the help.
/arthur

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 13 Feb 2024 10:47:33 +0100
> 
> I wasn't even aware this was going on, untill yesterday. I understand that some
> users like to see diverse stuff in their modeline, statusbars, powerlines,
> command prompts and other widgets. That is fine; if users want it, give it to
> them.
> 
> But I am not such a user, and this feels a bit too much to have it auto
> on. This can get triggered automatically in save places; for example I have save
> place on, so when I open a file, Emacs will display cursor at the same place
> where I left. I see that it gets triggred in some places with Helm
> completion. Basically everything I have nowdays is in Git, inclusive my entire
> emacs.d folder. That means I am constantly starting and killing git processes,
> and I don't even care about that info on my modeline. I look barely at modeline;
> sometimes I take a look at the clock or line/column number.

I understand your POV, but this is turned on by default in Emacs long
ago.  So the default cannot be changed just because you personally
dislike it.  Instead, I suggest that you change the default value of
mode-line format locally.  Or remove vc-refresh-state from
find-file-hook.  Or try playing with the value of vc-display-status.
Or some other change that could do what you want; look in vc-hooks.el
for ideas.

> If you consider that people are complaining quite a lot about Emacs been too
> slow on Windows, than I would consider if this is something that has to be on by
> default.

Git is not slow on MS-Windows; I posted the numbers I measured to show
that.  Git is just much faster on GNU/Linux, so people who are
accustomed to its speed on the latter complain when they need to work
on the former.  IOW, it's a "relative complaint", not an "absolute
complaint".

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 13 Feb 2024 10:47:33 +0100
>> 
>> I wasn't even aware this was going on, untill yesterday. I understand that some
>> users like to see diverse stuff in their modeline, statusbars, powerlines,
>> command prompts and other widgets. That is fine; if users want it, give it to
>> them.
>> 
>> But I am not such a user, and this feels a bit too much to have it auto
>> on. This can get triggered automatically in save places; for example I have save
>> place on, so when I open a file, Emacs will display cursor at the same place
>> where I left. I see that it gets triggred in some places with Helm
>> completion. Basically everything I have nowdays is in Git, inclusive my entire
>> emacs.d folder. That means I am constantly starting and killing git processes,
>> and I don't even care about that info on my modeline. I look barely at modeline;
>> sometimes I take a look at the clock or line/column number.
>
> I understand your POV, but this is turned on by default in Emacs long
> ago.  So the default cannot be changed just because you personally
Yes, I have already understood that from the replies ysterday :). I never
realized that was going on under the hood. If you don't want to change the
defualt at least let us have an easy way to disable it. 

> dislike it.  Instead, I suggest that you change the default value of
> mode-line format locally.  Or remove vc-refresh-state from

I don't think it even shows on my modeline; I have no idea even where in the
modline to look for it. My modeline is already very simplified, with most of the
stuff diminished or removed. As said, I noticed first from that backtrace
yesterday.

> find-file-hook.  Or try playing with the value of vc-display-status.
> Or some other change that could do what you want; look in vc-hooks.el
> for ideas.

Yes, I did play with vc-display-status; setting it to nil does not do what you
suggest it will do. It still triggers git process.

I have to manually remove the vc-refresh from the hook for find-file. At least
in 29.2_1 or turn-off everything by setting backends to nil.

I see in the master that code for vc-display-status has changed and there are
some options now, but there is no :set function and option to completely disable
it. I haven't built yet from the master, so I can't tell how well it works to
just choose 'backend as an option in this regards.

There is also the save file stuff which is implemented differently. As I asked
Dmitry, is there any special reason why is it not implemented via
after-save-hook? If it isn't I can hack it and use after-save-hook instead which
than lets me to simply hack defcustom for vd-display-status with :set function
to add/remove vc-refresh to/from relevant hooks.

>> If you consider that people are complaining quite a lot about Emacs been too
>> slow on Windows, than I would consider if this is something that has to be on by
>> default.
>
> Git is not slow on MS-Windows; I posted the numbers I measured to show
> that.  Git is just much faster on GNU/Linux, so people who are
> accustomed to its speed on the latter complain when they need to work
> on the former.  IOW, it's a "relative complaint", not an "absolute
> complaint".

Yesterday, about an hour after I sent email here, someone posted this claiming
that git interactions slow down vc-mode:

https://www.reddit.com/r/emacs/comments/1ahx90f/if_you_would_like_a_new_feature_in_emacs_v30_what/kq2sxml/?context=3

It could be a moot or it could be something in it; I don't know.

I don't know why people experience that Emacs is slow on Windows.I experience it
myself too and I haven't blamed it on anything specific yet. I have thoughts
that it perhaps is mingw/msys runtime; but I don't know. I didn't say Git
specific is slow. Perhaps it is a combination of things that make Emacs slow. I
don't know. You are monitoring Reddit every day more or less, and see yourself
that people are not complaining on anything specifically.

Anyway, regardless of how fast Git or Emacs are, if I do not value to see some
statusline update, I don't think I should spend CPU cycles and battery life on
it, regardless how slow or fast it may be.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 13/02/2024 15:36, Eli Zaretskii wrote:
>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 13 Feb 2024 10:47:33 +0100
>>
>> I wasn't even aware this was going on, untill yesterday. I understand that some
>> users like to see diverse stuff in their modeline, statusbars, powerlines,
>> command prompts and other widgets. That is fine; if users want it, give it to
>> them.
>>
>> But I am not such a user, and this feels a bit too much to have it auto
>> on. This can get triggered automatically in save places; for example I have save
>> place on, so when I open a file, Emacs will display cursor at the same place
>> where I left. I see that it gets triggred in some places with Helm
>> completion. Basically everything I have nowdays is in Git, inclusive my entire
>> emacs.d folder. That means I am constantly starting and killing git processes,
>> and I don't even care about that info on my modeline. I look barely at modeline;
>> sometimes I take a look at the clock or line/column number.
> 
> I understand your POV, but this is turned on by default in Emacs long
> ago.  So the default cannot be changed just because you personally
> dislike it.  Instead, I suggest that you change the default value of
> mode-line format locally.  Or remove vc-refresh-state from
> find-file-hook.  Or try playing with the value of vc-display-status.
> Or some other change that could do what you want; look in vc-hooks.el
> for ideas.

We could try dropping the forced refresh from find-file-hook. Then we'd 
have a function there that should be called differently, which would 
just reset the saved backend/status for the file, and the cached value 
for vc-mode (the mode-line element).

Then, if the user disabled showing the VC state in the mode-line, and 
doesn't have any other packages installed that use the status, Git won't 
be called, at least not right away.

Apparent downsides:

- As you noted in another thread, errors in the mode-line don't trigger 
the debugger. Any problems with fetching the VCS state will become 
somewhat more difficult to debug. Although someone would just have to 
evaluate (vc-state ...) to trigger that outside of mode-line context.

- Prompting the user whether to follow "symbolic link to %s-controlled 
source file" would become a lot more difficult if the code that's 
supposed to do that, again, runs in the context of the mode-line.

The latter seems like more of a problem, but we could fall back to the 
current functionality when the file is a symlink and vc-follow-symlinks 
is non-nil (fetch the backend eagerly).

As a result, we could have Emacs that's a little bit faster for users 
with custom mode-lines. And also for any find-file-noselect calls done 
in the background (we do those, sometimes on a list of files) won't 
fetch the VCS status eagerly. That seems like a win.

So I would welcome such an experiment, especially if one is careful to 
retain support for vc-follow-symlinks.

vc-after-save could similarly avoid doing the full refresh until the 
file's backend/state are requested again.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 13/02/2024 15:36, Eli Zaretskii wrote:
>>> From: Arthur Miller <arthur.miller@live.com>
>>> Cc: emacs-devel@gnu.org
>>> Date: Tue, 13 Feb 2024 10:47:33 +0100
>>>
>>> I wasn't even aware this was going on, untill yesterday. I understand that some
>>> users like to see diverse stuff in their modeline, statusbars, powerlines,
>>> command prompts and other widgets. That is fine; if users want it, give it to
>>> them.
>>>
>>> But I am not such a user, and this feels a bit too much to have it auto
>>> on. This can get triggered automatically in save places; for example I have save
>>> place on, so when I open a file, Emacs will display cursor at the same place
>>> where I left. I see that it gets triggred in some places with Helm
>>> completion. Basically everything I have nowdays is in Git, inclusive my entire
>>> emacs.d folder. That means I am constantly starting and killing git processes,
>>> and I don't even care about that info on my modeline. I look barely at modeline;
>>> sometimes I take a look at the clock or line/column number.
>> I understand your POV, but this is turned on by default in Emacs long
>> ago.  So the default cannot be changed just because you personally
>> dislike it.  Instead, I suggest that you change the default value of
>> mode-line format locally.  Or remove vc-refresh-state from
>> find-file-hook.  Or try playing with the value of vc-display-status.
>> Or some other change that could do what you want; look in vc-hooks.el
>> for ideas.
>
> We could try dropping the forced refresh from find-file-hook. Then we'd have a
> function there that should be called differently, which would just reset the
> saved backend/status for the file, and the cached value for vc-mode (the
> mode-line element).

I didn't suggest to rebuild everything :). Just an option to remove the update
for those who don't want the update (I guess I am the only one). 

> Then, if the user disabled showing the VC state in the mode-line, and doesn't
> have any other packages installed that use the status, Git won't be called, at
> least not right away.

It would be one's own responsibility to keep track if it is needed by other
applicaitons or not. This why I asked, if there is something else than modeline
that needs this.

I see defcustom declaration fo vc-display-status is changed from what it was in
29.2 to what is now in the master. I guess you (or someone) is already planning
something in this direction? Was it meant that vc-refresh (or something in the
chain of call) decide to call git or not based on the value of that variable?
Looks to me like that was the plan, but I don't know the intentions.

> Apparent downsides:
>
> - As you noted in another thread, errors in the mode-line don't trigger the
>   debugger. Any problems with fetching the VCS state will become somewhat more
>   difficult to debug. Although someone would just have to evaluate (vc-state
>  ...) to trigger that outside of mode-line context.
>
> - Prompting the user whether to follow "symbolic link to %s-controlled source
>   file" would become a lot more difficult if the code that's supposed to do
>  that, again, runs in the context of the mode-line.
>
> The latter seems like more of a problem, but we could fall back to the current
> functionality when the file is a symlink and vc-follow-symlinks is non-nil
> (fetch the backend eagerly).

As I though yesterday of it, it is more like: do what you do now, the way you do
now, when you do it, just let me turn it off.

However, while I saw find-file-hook and was thinking in terms of just removing
vc-refresh from the hook, perhaps there is a better way: As you (or whomever)
seem to have prepared vc-display-status with choice of 'backend, 'status or
nothing, so hook can be always called and it can decide if it will call git or
not based the value of that variable?

> As a result, we could have Emacs that's a little bit faster for users with
> custom mode-lines. And also for any find-file-noselect calls done in the
> background (we do those, sometimes on a list of files) won't fetch the VCS
> status eagerly. That seems like a win.

In case when list of files are checked, one can let-binding vc-display-status
to nil in vc-refresh (or the responsible one) so to not trigger git? 

> So I would welcome such an experiment, especially if one is careful to retain
> support for vc-follow-symlinks.
>
> vc-after-save could similarly avoid doing the full refresh until the file's
> backend/state are requested again.

When they request for the backend state; they could do so asyncrhonously to, by
starting a timer? The update will not be immideate; run first when Emas is idle,
if it is just the modeline; but third party apps, if there are such, can be more
picky. 

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 14/02/2024 01:10, Arthur Miller wrote:

>> We could try dropping the forced refresh from find-file-hook. Then we'd have a
>> function there that should be called differently, which would just reset the
>> saved backend/status for the file, and the cached value for vc-mode (the
>> mode-line element).
> 
> I didn't suggest to rebuild everything :). Just an option to remove the update
> for those who don't want the update (I guess I am the only one).

That's wouldn't be a big rewrite, I think. So far it seems the required 
changes would be limited, that's why I outlined the idea.

>> Then, if the user disabled showing the VC state in the mode-line, and doesn't
>> have any other packages installed that use the status, Git won't be called, at
>> least not right away.
> 
> It would be one's own responsibility to keep track if it is needed by other
> applicaitons or not. This why I asked, if there is something else than modeline
> that needs this.
> 
> I see defcustom declaration fo vc-display-status is changed from what it was in
> 29.2 to what is now in the master. I guess you (or someone) is already planning
> something in this direction? Was it meant that vc-refresh (or something in the
> chain of call) decide to call git or not based on the value of that variable?
> Looks to me like that was the plan, but I don't know the intentions.

The idea behind it was something else: to be able to unify mode-line 
elements (from vc and project).

> In case when list of files are checked, one can let-binding vc-display-status
> to nil in vc-refresh (or the responsible one) so to not trigger git?

vc-display-status only affects vc's mode-line element.

>> So I would welcome such an experiment, especially if one is careful to retain
>> support for vc-follow-symlinks.
>>
>> vc-after-save could similarly avoid doing the full refresh until the file's
>> backend/state are requested again.
> 
> When they request for the backend state; they could do so asyncrhonously to, by
> starting a timer? The update will not be immideate; run first when Emas is idle,
> if it is just the modeline; but third party apps, if there are such, can be more
> picky.

That's not simpler.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 14/02/2024 01:10, Arthur Miller wrote:
>
>>> We could try dropping the forced refresh from find-file-hook. Then we'd have a
>>> function there that should be called differently, which would just reset the
>>> saved backend/status for the file, and the cached value for vc-mode (the
>>> mode-line element).
>> I didn't suggest to rebuild everything :). Just an option to remove the update
>> for those who don't want the update (I guess I am the only one).
>
> That's wouldn't be a big rewrite, I think. So far it seems the required changes
> would be limited, that's why I outlined the idea.

Allright; I'll have to learn vc-mode and see how it works in that case; I am not
familiar with that code at all.

>>> Then, if the user disabled showing the VC state in the mode-line, and doesn't
>>> have any other packages installed that use the status, Git won't be called, at
>>> least not right away.
>> It would be one's own responsibility to keep track if it is needed by other
>> applicaitons or not. This why I asked, if there is something else than modeline
>> that needs this.
>> I see defcustom declaration fo vc-display-status is changed from what it was
>> in
>> 29.2 to what is now in the master. I guess you (or someone) is already planning
>> something in this direction? Was it meant that vc-refresh (or something in the
>> chain of call) decide to call git or not based on the value of that variable?
>> Looks to me like that was the plan, but I don't know the intentions.
>
> The idea behind it was something else: to be able to unify mode-line elements
> (from vc and project).

Ok, I see. A question: is it importnat to keep display on modeline or
elsewhere decoupled from the actual repo query?

>> In case when list of files are checked, one can let-binding vc-display-status
>> to nil in vc-refresh (or the responsible one) so to not trigger git?
>
> vc-display-status only affects vc's mode-line element.

Can I use to in the meaning "no status display" = "no git query"? That is why I
ask if it is important to keep display decoupled from the query.

>>> So I would welcome such an experiment, especially if one is careful to retain
>>> support for vc-follow-symlinks.
>>>
>>> vc-after-save could similarly avoid doing the full refresh until the file's
>>> backend/state are requested again.
>> When they request for the backend state; they could do so asyncrhonously to,
>> by
>> starting a timer? The update will not be immideate; run first when Emas is idle,
>> if it is just the modeline; but third party apps, if there are such, can be more
>> picky.
>
> That's not simpler.

After looking more at it; what I find problematic is that it is automatic. Also,
use of hooks find-file/after-save (eventually) means either all or nothing.

I looked a bit in vc-hooks and vc-dir, and come up with this little ugly hack:

(define-minor-mode vc-mode
  "vc-mode test"
  :global nil :lighter " vcm "
  (setq-local vc-handled-backends
        (if vc-mode
            '(RCS CVS SVN SCCS SRC Bzr Git Hg)
          nil)))

Since vc-mode is just a dummy function; I per-used it. Now I can keep in my init
file (setq vc-handled-backends nil) and nothing screems after Git when it is not
in the path; and in projects where I wish to work with vc-mode and run vc-dir, I
can start vc-mode and than vc-dir works as expected. 

I also don't see how Emacs could know when to start vc-mode and when not,
without user taking an action. If complete automatic handling of version control
is desired than something like that is not acceptable.

An alternative could be to have another find-file/save-file functions, say
find/save-vc-file, that does the same, but also runs the vc-refresh-status. Than
those who prefer to always see vc status when in a vc repo could use it as
the default find-file function; and those like me, who would prefer it
on-demand, could call it when they need it. But that is not so pretty and
automatic.

Anyway, I think I can personally live with my hack, unless there is something
really nasty I am forseeing there. That achieves what I asked for, without you
needed to change anything.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 14/02/2024 23:04, Arthur Miller wrote:

>> The idea behind it was something else: to be able to unify mode-line elements
>> (from vc and project).
> 
> Ok, I see. A question: is it importnat to keep display on modeline or
> elsewhere decoupled from the actual repo query?

Probably, yes. If I understood your question right.

>>> In case when list of files are checked, one can let-binding vc-display-status
>>> to nil in vc-refresh (or the responsible one) so to not trigger git?
>>
>> vc-display-status only affects vc's mode-line element.
> 
> Can I use to in the meaning "no status display" = "no git query"? That is why I
> ask if it is important to keep display decoupled from the query.

If we do it this way, it will just be an incremental increase in the 
complexity of the code, and it will support only a part of the 
applicable use cases. I think I've explained that in one of the previous 
emails.

>>>> So I would welcome such an experiment, especially if one is careful to retain
>>>> support for vc-follow-symlinks.
>>>>
>>>> vc-after-save could similarly avoid doing the full refresh until the file's
>>>> backend/state are requested again.
>>> When they request for the backend state; they could do so asyncrhonously to,
>>> by
>>> starting a timer? The update will not be immideate; run first when Emas is idle,
>>> if it is just the modeline; but third party apps, if there are such, can be more
>>> picky.
>>
>> That's not simpler.
> 
> After looking more at it; what I find problematic is that it is automatic. Also,
> use of hooks find-file/after-save (eventually) means either all or nothing.
> 
> I looked a bit in vc-hooks and vc-dir, and come up with this little ugly hack:
> 
> (define-minor-mode vc-mode
>    "vc-mode test"
>    :global nil :lighter " vcm "
>    (setq-local vc-handled-backends
>          (if vc-mode
>              '(RCS CVS SVN SCCS SRC Bzr Git Hg)
>            nil)))
> 
> Since vc-mode is just a dummy function; I per-used it. Now I can keep in my init
> file (setq vc-handled-backends nil) and nothing screems after Git when it is not
> in the path; and in projects where I wish to work with vc-mode and run vc-dir, I
> can start vc-mode and than vc-dir works as expected.

If you're just looking for a hack for personal use, this one's as good 
as any.

> I also don't see how Emacs could know when to start vc-mode and when not,
> without user taking an action. If complete automatic handling of version control
> is desired than something like that is not acceptable.

It would be whenever some actual feature requested the vc state to be 
computed because it's going to use it now.

> Anyway, I think I can personally live with my hack, unless there is something
> really nasty I am forseeing there. That achieves what I asked for, without you
> needed to change anything.

I don't think you're going to have any big problems with the above 
setup, as long as you remember to turn on vc-mode to use any features 
that require VC. Such as diff-hl-mode, for example.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 14/02/2024 23:04, Arthur Miller wrote:
>
>>> The idea behind it was something else: to be able to unify mode-line elements
>>> (from vc and project).
>> Ok, I see. A question: is it importnat to keep display on modeline or
>> elsewhere decoupled from the actual repo query?
>
> Probably, yes. If I understood your question right.
>
>>>> In case when list of files are checked, one can let-binding vc-display-status
>>>> to nil in vc-refresh (or the responsible one) so to not trigger git?
>>>
>>> vc-display-status only affects vc's mode-line element.
>> Can I use to in the meaning "no status display" = "no git query"? That is why
>> I
>> ask if it is important to keep display decoupled from the query.
>
> If we do it this way, it will just be an incremental increase in the complexity
> of the code, and it will support only a part of the applicable use cases. I

Allright, np I understand.

> think I've explained that in one of the previous emails.

You will have to forgive me; I am not familiar with vc-mode and project.el;
perhaps you have explained, but I didn't got it how ti all hangs together and
what are intentions with all this. Better to ask, than to assume wrong.

>>>>> So I would welcome such an experiment, especially if one is careful to retain
>>>>> support for vc-follow-symlinks.
>>>>>
>>>>> vc-after-save could similarly avoid doing the full refresh until the file's
>>>>> backend/state are requested again.
>>>> When they request for the backend state; they could do so asyncrhonously to,
>>>> by
>>>> starting a timer? The update will not be immideate; run first when Emas is idle,
>>>> if it is just the modeline; but third party apps, if there are such, can be more
>>>> picky.
>>>
>>> That's not simpler.
>> After looking more at it; what I find problematic is that it is
>> automatic. Also,
>> use of hooks find-file/after-save (eventually) means either all or nothing.
>> I looked a bit in vc-hooks and vc-dir, and come up with this little ugly hack:
>> (define-minor-mode vc-mode
>>    "vc-mode test"
>>    :global nil :lighter " vcm "
>>    (setq-local vc-handled-backends
>>          (if vc-mode
>>              '(RCS CVS SVN SCCS SRC Bzr Git Hg)
>>            nil)))
>> Since vc-mode is just a dummy function; I per-used it. Now I can keep in my
>> init
>> file (setq vc-handled-backends nil) and nothing screems after Git when it is not
>> in the path; and in projects where I wish to work with vc-mode and run vc-dir, I
>> can start vc-mode and than vc-dir works as expected.
>
> If you're just looking for a hack for personal use, this one's as good as any.
>
>> I also don't see how Emacs could know when to start vc-mode and when not,
>> without user taking an action. If complete automatic handling of version control
>> is desired than something like that is not acceptable.
>
> It would be whenever some actual feature requested the vc state to be computed
> because it's going to use it now.
So basically commands would have to auto-start it.

>> Anyway, I think I can personally live with my hack, unless there is something
>> really nasty I am forseeing there. That achieves what I asked for, without you
>> needed to change anything.
>
> I don't think you're going to have any big problems with the above setup, as
> long as you remember to turn on vc-mode to use any features that require
> VC. Such as diff-hl-mode, for example.
I can just advice or wrap those commands I use, so I guess it is not a problem
for me.

Thanks for the help.
/a

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> Date: Tue, 13 Feb 2024 23:26:42 +0200
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 13/02/2024 15:36, Eli Zaretskii wrote:
> > 
> > I understand your POV, but this is turned on by default in Emacs long
> > ago.  So the default cannot be changed just because you personally
> > dislike it.  Instead, I suggest that you change the default value of
> > mode-line format locally.  Or remove vc-refresh-state from
> > find-file-hook.  Or try playing with the value of vc-display-status.
> > Or some other change that could do what you want; look in vc-hooks.el
> > for ideas.
> 
> We could try dropping the forced refresh from find-file-hook. Then we'd 
> have a function there that should be called differently, which would 
> just reset the saved backend/status for the file, and the cached value 
> for vc-mode (the mode-line element).
> 
> Then, if the user disabled showing the VC state in the mode-line, and 
> doesn't have any other packages installed that use the status, Git won't 
> be called, at least not right away.

What is the purpose of such a change?  Does it target users who don't
want vc-refresh-state in find-file-hook, but still want the VC info
shown on the mode line?  That sounds like a strange preference, since
find-file-hook is called just once per file buffer, whereas showing
the info on the mode line can potentially cause vc-refresh-state (or
something similar) to be called much more frequently, right?

So before we discuss such a move, even as an experiment, I'd like to
understand better what would be the intended effect in user-facing
terms, and make sure we indeed consider such a behavior change
reasonable.  Because this kind of changes is likely to cause
unintended problems, so I'd like to be sure we really want it before
we start investing time and efforts in it.  Likewise, I would like to
avoid the situation where Arthur (or someone else) spends time and
efforts in experimenting with such a setup, only to be told later
that we don't think the results makes sense to us.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 14/02/2024 16:30, Eli Zaretskii wrote:
>> Date: Tue, 13 Feb 2024 23:26:42 +0200
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 13/02/2024 15:36, Eli Zaretskii wrote:
>>>
>>> I understand your POV, but this is turned on by default in Emacs long
>>> ago.  So the default cannot be changed just because you personally
>>> dislike it.  Instead, I suggest that you change the default value of
>>> mode-line format locally.  Or remove vc-refresh-state from
>>> find-file-hook.  Or try playing with the value of vc-display-status.
>>> Or some other change that could do what you want; look in vc-hooks.el
>>> for ideas.
>>
>> We could try dropping the forced refresh from find-file-hook. Then we'd
>> have a function there that should be called differently, which would
>> just reset the saved backend/status for the file, and the cached value
>> for vc-mode (the mode-line element).
>>
>> Then, if the user disabled showing the VC state in the mode-line, and
>> doesn't have any other packages installed that use the status, Git won't
>> be called, at least not right away.
> 
> What is the purpose of such a change?  Does it target users who don't
> want vc-refresh-state in find-file-hook, but still want the VC info
> shown on the mode line?

Those in particular won't see an immediate benefit, but, to reiterate:

   As a result, we could have Emacs that's a little bit faster for users
   with custom mode-lines [that don't show VCS status or backend].

   And also [for all users:] any find-file-noselect calls performed in
   the background (sometimes those are even done on a list of files)
   won't fetch the VCS status eagerly until the buffer is displayed.

 > That sounds like a strange preference, since
 > find-file-hook is called just once per file buffer, whereas showing
 > the info on the mode line can potentially cause vc-refresh-state (or
 > something similar) to be called much more frequently, right?

The backend and the state are cached in vc-file-prop-obarray, so it 
shouldn't result in more process calls, no matter the scenario. It's 
mostly about how early we fetch this information.

> So before we discuss such a move, even as an experiment, I'd like to
> understand better what would be the intended effect in user-facing
> terms, and make sure we indeed consider such a behavior change
> reasonable.  Because this kind of changes is likely to cause
> unintended problems, so I'd like to be sure we really want it before
> we start investing time and efforts in it.  Likewise, I would like to
> avoid the situation where Arthur (or someone else) spends time and
> efforts in experimenting with such a setup, only to be told later
> that we don't think the results makes sense to us.

For me, it really depends on the execution: whether it will actually 
require a moderate amount of changes (as I imagined), and whether the 
perceived improvement in user experience is there. And the appearance of 
"unintended problems", of course.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> Date: Wed, 14 Feb 2024 18:36:47 +0200
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > What is the purpose of such a change?  Does it target users who don't
> > want vc-refresh-state in find-file-hook, but still want the VC info
> > shown on the mode line?
> 
> Those in particular won't see an immediate benefit, but, to reiterate:
> 
>    As a result, we could have Emacs that's a little bit faster for users
>    with custom mode-lines [that don't show VCS status or backend].
> 
>    And also [for all users:] any find-file-noselect calls performed in
>    the background (sometimes those are even done on a list of files)
>    won't fetch the VCS status eagerly until the buffer is displayed.

If that's the purpose, why not simply have a value of
vc-display-status which would cause vc-refresh-state do nothing?
AFAIU, the result will be the same, but with much less code churn and
definitely safer.

>  > That sounds like a strange preference, since
>  > find-file-hook is called just once per file buffer, whereas showing
>  > the info on the mode line can potentially cause vc-refresh-state (or
>  > something similar) to be called much more frequently, right?
> 
> The backend and the state are cached in vc-file-prop-obarray, so it 
> shouldn't result in more process calls, no matter the scenario. It's 
> mostly about how early we fetch this information.

My point is that find-file-hook has an explicit and very specific
trigger for fetching the VC information, whereas doing that from the
mode line doesn't have that advantage, and will probably need to call
VC much more frequently in order not to miss changes.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 14/02/2024 18:51, Eli Zaretskii wrote:
>> Date: Wed, 14 Feb 2024 18:36:47 +0200
>> Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>> What is the purpose of such a change?  Does it target users who don't
>>> want vc-refresh-state in find-file-hook, but still want the VC info
>>> shown on the mode line?
>>
>> Those in particular won't see an immediate benefit, but, to reiterate:
>>
>>     As a result, we could have Emacs that's a little bit faster for users
>>     with custom mode-lines [that don't show VCS status or backend].
>>
>>     And also [for all users:] any find-file-noselect calls performed in
>>     the background (sometimes those are even done on a list of files)
>>     won't fetch the VCS status eagerly until the buffer is displayed.
> 
> If that's the purpose, why not simply have a value of
> vc-display-status which would cause vc-refresh-state do nothing?
> AFAIU, the result will be the same, but with much less code churn and
> definitely safer.

vc-display-status only affects what the default mode-line does, and not 
the myriad of alternative configurations.

It cleaner to let the work happen when it's really required to happen, 
rather than guess in advance based on an imprecise indicator like this.

>>   > That sounds like a strange preference, since
>>   > find-file-hook is called just once per file buffer, whereas showing
>>   > the info on the mode line can potentially cause vc-refresh-state (or
>>   > something similar) to be called much more frequently, right?
>>
>> The backend and the state are cached in vc-file-prop-obarray, so it
>> shouldn't result in more process calls, no matter the scenario. It's
>> mostly about how early we fetch this information.
> 
> My point is that find-file-hook has an explicit and very specific
> trigger for fetching the VC information, whereas doing that from the
> mode line doesn't have that advantage, and will probably need to call
> VC much more frequently in order not to miss changes.

Again: the backend and state are cached. Why would VC be called more?

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> Date: Wed, 14 Feb 2024 19:01:10 +0200
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > My point is that find-file-hook has an explicit and very specific
> > trigger for fetching the VC information, whereas doing that from the
> > mode line doesn't have that advantage, and will probably need to call
> > VC much more frequently in order not to miss changes.
> 
> Again: the backend and state are cached. Why would VC be called more?

How do you know when the cache is stale and needs to be refreshed, if
the only purpose is to show the info on the mode line?

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Dmitry Gutov]

On 14/02/2024 19:29, Eli Zaretskii wrote:
>> Date: Wed, 14 Feb 2024 19:01:10 +0200
>> Cc:arthur.miller@live.com,emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>>> My point is that find-file-hook has an explicit and very specific
>>> trigger for fetching the VC information, whereas doing that from the
>>> mode line doesn't have that advantage, and will probably need to call
>>> VC much more frequently in order not to miss changes.
>> Again: the backend and state are cached. Why would VC be called more?
> How do you know when the cache is stale and needs to be refreshed, if
> the only purpose is to show the info on the mode line?

It's really a question of when to invalidate.

And we can continue to do that when/where we do now (find-file-hook and 
vc-after-save), just without re-fetching the new values.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Mon, 12 Feb 2024 11:06:02 +0100
> 
> I am trying to compile Emacs on a new computer with freshly installed Windows 11
> and mingw and having some troubles.
> 
> ld is complaining about missing snprintf. Seems like I can't get past that
> one. I am using mingw ucrt toolchain/runtime since m4 failed for "ordinary"
> mingw-w64 toolchain which I used on Windows 10 (m4 failed creating configure
> script). Any idea why and what to do? It is defined in stdio.h so I would expect
> it to be included in basic libc. Do I need to pass some extra flag
> compiler/linker flag?

Which problem do you want to solve? the one with creating the
configure script, so you could use the "ordinary" MinGW toolchain, or
the one with snprintf?

I don't really understand why you have a problem creating the
configure script (nor why you think it's m4's fault).  What is
different from what you had on Windows 10?  Are you using the same
development tools copied from the old computer, or did you install
them anew?  If the former, there should be no problems with creating
the configure script.  If all else fails, please show the error
messages you get trying to create the configure script.

One thing to watch out is to make sure your Git installation doesn't
perform any EOL conversions.

For the snprintf problem, my suggestion is to review the patches the
MSYS2 folks use for the UCRT build of Emacs.  No one submitted to us
patches to support UCRT builds, so that build is currently unsupported
by the upstream project, but AFAIU MSYS2 folks do succeed in building
it, so I guess they do have patches for it.  It is better to use those
patches as a starting point.

> Since I removed msys mingw-w64 from my PATH to be sure mingw-w64-ucrt runtime
> don't mix with other mingw runtime(s), Git also got removed from the path (I am
> using mingw-64 one), and than my running Emacs couldn't open a file from a Git
> repo.

The simple fix for that is to have on PATH a git.cmd batch file that
invokes Git after setting PATH locally (with setlocal) to include the
directory where you have Git installed.

> The backtrace shows find-file is calling vc-refresh which realized I am in a Git
> repo and is trying to call Git. If I start emacs -q afresh without Git in the
> path, it works fine, so I assume Emacs registers Git program at some point and
> does not check for it on every call, perhaps I am wrong about that one?

You don't tell enough to figure out what could be the reason for this.
What are your customizations doing that could cause Emacs find Git
even though it is not on PATH?

> If that would be the case, I think it is a bug to assume that environment can't
> change under running Emacs.

Modifying PATH from within a running Emacs session is not recommended,
precisely because it can cause subtle issues.

> Also, calling vc-refresh obviously results in a quite expensive call to git
> process everytime I open a file from git repo. Is it really a good default
> option? At least I interpret it so since emacs -q has vc-refresh in
> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?

We show the VC status on the mode line.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Mon, 12 Feb 2024 11:06:02 +0100
>> 
>> I am trying to compile Emacs on a new computer with freshly installed Windows 11
>> and mingw and having some troubles.
>> 
>> ld is complaining about missing snprintf. Seems like I can't get past that
>> one. I am using mingw ucrt toolchain/runtime since m4 failed for "ordinary"
>> mingw-w64 toolchain which I used on Windows 10 (m4 failed creating configure
>> script). Any idea why and what to do? It is defined in stdio.h so I would expect
>> it to be included in basic libc. Do I need to pass some extra flag
>> compiler/linker flag?
>
> Which problem do you want to solve? the one with creating the
> configure script, so you could use the "ordinary" MinGW toolchain, or
> the one with snprintf?
Seems, like ordinary one works today; but if we can figure out why it does not
link with correct library in ucrt build, it would be nice.

> I don't really understand why you have a problem creating the
> configure script (nor why you think it's m4's fault).  What is
Needer do I; but before I did a git pull today, ./autogen.sh resulted in error
from M4 that some macro was already defined. I don't remember which one. I tried
to trigger it today just to show the error message, but I did a git pull without
thinking before createing a worktree for the build, and autogen suddenly worked.

> different from what you had on Windows 10?  Are you using the same
> development tools copied from the old computer, or did you install
I didn't copy over; that option did cross my mind, but the old one is old since
2016, so I thought it would good to install new stuff a fresh so to say. But
nothing special; just msys2 out of the box, with deps needed to build Emacs.

> them anew?  If the former, there should be no problems with creating
> the configure script.  If all else fails, please show the error
> messages you get trying to create the configure script.
>
> One thing to watch out is to make sure your Git installation doesn't
> perform any EOL conversions.

Yes. I am aware of that one.

> For the snprintf problem, my suggestion is to review the patches the
> MSYS2 folks use for the UCRT build of Emacs.  No one submitted to us
> patches to support UCRT builds, so that build is currently unsupported
> by the upstream project, but AFAIU MSYS2 folks do succeed in building
> it, so I guess they do have patches for it.  It is better to use those
> patches as a starting point.

I didn't know they have one; I'll check it, and come back if I manage to build
it in ucrt runtime.

>> Since I removed msys mingw-w64 from my PATH to be sure mingw-w64-ucrt runtime
>> don't mix with other mingw runtime(s), Git also got removed from the path (I am
>> using mingw-64 one), and than my running Emacs couldn't open a file from a Git
>> repo.
>
> The simple fix for that is to have on PATH a git.cmd batch file that
> invokes Git after setting PATH locally (with setlocal) to include the
> directory where you have Git installed.
>
>> The backtrace shows find-file is calling vc-refresh which realized I am in a Git
>> repo and is trying to call Git. If I start emacs -q afresh without Git in the
>> path, it works fine, so I assume Emacs registers Git program at some point and
>> does not check for it on every call, perhaps I am wrong about that one?
>
> You don't tell enough to figure out what could be the reason for this.
> What are your customizations doing that could cause Emacs find Git
> even though it is not on PATH?

No no; Emacs does not find it when it is not in the PATH. :)

>> If that would be the case, I think it is a bug to assume that environment can't
>> change under running Emacs.
>
> Modifying PATH from within a running Emacs session is not recommended,
> precisely because it can cause subtle issues.

It wasn't modified from within Emacs; but from Windows GUI; but the effect is
the same of course.

>> Also, calling vc-refresh obviously results in a quite expensive call to git
>> process everytime I open a file from git repo. Is it really a good default
>> option? At least I interpret it so since emacs -q has vc-refresh in
>> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?
>
> We show the VC status on the mode line.

If that is *the only* reason, can we make that status refresh optional?

It can trigger checks even in files I am not currently working on. For example I
have .emacs.d as a git repo so I can back it up, and I believe I am not the only
one. Save place and recentf for example, and basically every other configuration
that saves something is saving it in .emacs.d. It can be quite many status
checks if it automatically checks git status for all files. There can be other
reasons why I wouldn't like/need those checks in some repos. You can see the
answer to Dmitry for a suggestion.

Thanks for the help.
/a

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 13 Feb 2024 11:44:43 +0100
> 
> > We show the VC status on the mode line.
> 
> If that is *the only* reason, can we make that status refresh optional?

We decided to make it the default long ago, and never heard any
significant complaints -- until now.  So changing the default after
all those years is not an option.  But you can customize the default
value of mode-line-format to omit the '(vc-mode vc-mode) part from it,
and then I think you will get what you want, locally.

> It can trigger checks even in files I am not currently working on. For example I
> have .emacs.d as a git repo so I can back it up, and I believe I am not the only
> one. Save place and recentf for example, and basically every other configuration
> that saves something is saving it in .emacs.d. It can be quite many status
> checks if it automatically checks git status for all files. There can be other
> reasons why I wouldn't like/need those checks in some repos. You can see the
> answer to Dmitry for a suggestion.

These checks are very fast, so I see no reason to avoid them by
default.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Angelo Graziosi]

> ld is complaining about missing snprintf

BTW, MSYS2 people build Emacs for UCRT64 with a few patches. See:

https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs

I use those patches also for my Emacs master builds.

Ciao,
  Angelo.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> ld is complaining about missing snprintf
>
> BTW, MSYS2 people build Emacs for UCRT64 with a few patches. See:
>
> https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs
>
> I use those patches also for my Emacs master builds.
>
> Ciao,
>  Angelo.

Thank you very much for the pointers Angelo!

I didn't know they build Emacs with ucrt runtime; I should have actually checked
that myself :-).

I'll try to build with those patches.

I'll also make an issue and ask them if they can donate those patches to Emacs;
I guess they are considered as non-trivial so FSF copyright is needed.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

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

Angelo Graziosi <angelo.g0@libero.it> writes:

>> ld is complaining about missing snprintf
>
> BTW, MSYS2 people build Emacs for UCRT64 with a few patches. See:
>
> https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs
>
> I use those patches also for my Emacs master builds.

I was not able to apply their patches to the current master; git apply refused.
Seems like their patch is for Emacs 28.2. Instead I have manually patched-in their
changes to the sources and was able to build it. Typing from it.

More than the patch, I also had to copy over cp.exe from msys/bin to ucrt64/bin,
because the cp.exe included in ucrt runtime failed in autogen or configure; I
don't remember, with message that --force flag is not implemented yet, when some
script was installing git hooks.

Emacs seems to work as usual thus far, but the native compiler complains about
missing function:

Debugger entered--Lisp error: (void-function comp-write-bytecode-file)
  comp-write-bytecode-file("c:/Users/arthu/.emacs.d/eln-cache/30.0.50-ccd5287a/dired-auto-readme-d510bed9-ac3fa899.eln")
  emacs-lisp-native-compile()
  emacs-lisp-native-compile-and-load()
  funcall-interactively(emacs-lisp-native-compile-and-load)
  command-execute(emacs-lisp-native-compile-and-load)


I also did got the message that Emacs is not functional at the end of the build:

  GEN      ../../info/efaq-w32.info
org.texi:15658: warning: @anchor should not appear on @item line
org.texi:15671: warning: @anchor should not appear on @item line
make[2]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64/doc/misc'
make[1]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
make sanity-check make-target=all
make[1]: Entering directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
***
*** "make all" succeeded, but Emacs is not functional.
***
*** You could try to:
*** - run "make bootstrap", which might fix the problem
*** - run "make V=1", which displays the full commands invoked by make,
***   to further investigate the problem
***
make[1]: *** [Makefile:424: sanity-check] Error 1
make[1]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
make: *** [Makefile:375: all] Error 2

arthu@Emmi UCRT64 ~/repos/emsrc/ucrt-w64
$ nt/runemacs.exe &
[1] 11791

However; I am running Emacs, it byte-compiles, loads stuff, runs my setup and
everything seems to work as usual.

I did make V=1, but see nothing failing, in make script.

> Ciao,
>  Angelo.

Thanks for the pointer;

Ciao


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Compile-with-mingw-UCRT-runtime.patch --]
[-- Type: text/x-patch, Size: 1462 bytes --]

From 22ea9383e28fff60c9880d7d8e6c5102bb43a8d7 Mon Sep 17 00:00:00 2001
From: Arthur Miller <arthur.miller@live.com>
Date: Tue, 13 Feb 2024 19:35:20 +0100
Subject: [PATCH] Compile with mingw UCRT runtime.

---
 nt/cmdproxy.c | 4 ++++
 src/sysdep.c  | 6 ++++++
 2 files changed, 10 insertions(+)

diff --git a/nt/cmdproxy.c b/nt/cmdproxy.c
index 0500b653bb2..59ffe2c4db7 100644
--- a/nt/cmdproxy.c
+++ b/nt/cmdproxy.c
@@ -38,6 +38,10 @@ #define DEFER_MS_W32_H
 #include <string.h>  /* strlen */
 #include <ctype.h>   /* isspace, isalpha */
 
+#ifdef _UCRT
+#define _snprintf snprintf
+#endif
+
 /* We don't want to include stdio.h because we are already duplicating
    lots of it here */
 extern int _snprintf (char *buffer, size_t count, const char *format, ...);
diff --git a/src/sysdep.c b/src/sysdep.c
index 3a6829dd27a..9adff04d45f 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -2983,8 +2983,10 @@ close_output_streams (void)
 #else /* !__ANDROID__ */
   if (close_stream (stdout) != 0)
     {
+#ifndef _UCRT
       emacs_perror ("Write error to standard output");
       _exit (EXIT_FAILURE);
+#endif
     }
 
   /* Do not close stderr if addresses are being sanitized, as the
@@ -2993,7 +2995,11 @@ close_output_streams (void)
   if (err | (ADDRESS_SANITIZER
 	     ? fflush (stderr) != 0 || ferror (stderr)
 	     : close_stream (stderr) != 0))
+#ifndef _UCRT
     _exit (EXIT_FAILURE);
+#else
+    ;
+#endif
 #endif /* __ANDROID__ */
 }
 \f
-- 
2.43.1

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org, eliz@gnu.org
> Date: Tue, 13 Feb 2024 20:00:16 +0100
> 
> More than the patch, I also had to copy over cp.exe from msys/bin to ucrt64/bin,
> because the cp.exe included in ucrt runtime failed in autogen or configure; I
> don't remember, with message that --force flag is not implemented yet, when some
> script was installing git hooks.

This seems to indicate that your system is misconfigured: when you run
MSYS Bash to build Emacs, the MSYS's bin directory should be on PATH
_ahead_ of the MinGW bin directory, because Bash wants to run MSYS
ports, not MinGW (a.k.a. "native Windows") ports.

Copying MSYS programs into the MinGW bin directory is a bad idea, and
will at some point bite you, so my recommendation is not to do so.  In
general, my advice is to keep MSYS and MinGW executables separate, and
have separate environments for each one.  In my setup, when I run the
MSYS Bash, the MSYS executables are found first, but when I run the
Windows cmd.exe it's the other way around.

> Emacs seems to work as usual thus far, but the native compiler complains about
> missing function:
> 
> Debugger entered--Lisp error: (void-function comp-write-bytecode-file)
>   comp-write-bytecode-file("c:/Users/arthu/.emacs.d/eln-cache/30.0.50-ccd5287a/dired-auto-readme-d510bed9-ac3fa899.eln")
>   emacs-lisp-native-compile()
>   emacs-lisp-native-compile-and-load()
>   funcall-interactively(emacs-lisp-native-compile-and-load)
>   command-execute(emacs-lisp-native-compile-and-load)

This should be fixed now on the master branch.

> I also did got the message that Emacs is not functional at the end of the build:
> 
>   GEN      ../../info/efaq-w32.info
> org.texi:15658: warning: @anchor should not appear on @item line
> org.texi:15671: warning: @anchor should not appear on @item line

This is a harmless warning, so it shouldn't stop the build.

> make[2]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64/doc/misc'
> make[1]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
> make sanity-check make-target=all
> make[1]: Entering directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
> ***
> *** "make all" succeeded, but Emacs is not functional.

Maybe it's because of the problem with comp-write-bytecode-file.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org, eliz@gnu.org
>> Date: Tue, 13 Feb 2024 20:00:16 +0100
>> 
>> More than the patch, I also had to copy over cp.exe from msys/bin to ucrt64/bin,
>> because the cp.exe included in ucrt runtime failed in autogen or configure; I
>> don't remember, with message that --force flag is not implemented yet, when some
>> script was installing git hooks.
>
> This seems to indicate that your system is misconfigured: when you run

If they say that cp.exe does not support --force flag, it means it is for some
reason incomplete. I actually looked in scripts to see what is using -f flag to
cp to rewrite the script but didn't found it. So I had to use another cp
executable. Option was to download EZports :), but it seemed like overkill in
this case.

> MSYS Bash to build Emacs, the MSYS's bin directory should be on PATH
> _ahead_ of the MinGW bin directory, because Bash wants to run MSYS
> ports, not MinGW (a.k.a. "native Windows") ports.

Isn't that what their "shell launcher" does for me; sets the correct path(s) for
all the forest of stuff they have? This is the path the tool itself sets up;
nothing is modified by me; this is what echo $PATH shows:

/ucrt64/bin:/ucrt64/bin/site_perl/5.32.1:/ucrt64/bin/vendor_perl:/ucrt64/bin/core_perl:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/

This is what OS sees as the path:

C:\Users\arthu>echo %PATH%
C:\Program Files\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\Steel Bank Common Lisp\;C:\Users\arthu\AppData\Local\Microsoft\WindowsApps;C:\Program\emacs-29.2\bin;C:\Program\Java\jdk-21\bin;

I have just added openssh, sbcl and java to the path :).

> Copying MSYS programs into the MinGW bin directory is a bad idea

Yes, I know; I don't do that at all; but I can't imagine that cp.exe is
pulling crap load of libraries behind; it should be quite self-contained, and it
worked.

> will at some point bite you, so my recommendation is not to do so.  In
> general, my advice is to keep MSYS and MinGW executables separate, and
> have separate environments for each one.  In my setup, when I run the
> MSYS Bash, the MSYS executables are found first, but when I run the
> Windows cmd.exe it's the other way around.

I only keep mingw in the system path; no msys at all; but now I removed
everything msys/mingw/ucrt related while I was building Emacs to not pull in
something wrong by a chance. There are three runtime involved, chances some
executable from a wrong runtime gets involved is unfortunately not so small.

>> Emacs seems to work as usual thus far, but the native compiler complains about
>> missing function:
>> 
>> Debugger entered--Lisp error: (void-function comp-write-bytecode-file)
>>   comp-write-bytecode-file("c:/Users/arthu/.emacs.d/eln-cache/30.0.50-ccd5287a/dired-auto-readme-d510bed9-ac3fa899.eln")
>>   emacs-lisp-native-compile()
>>   emacs-lisp-native-compile-and-load()
>>   funcall-interactively(emacs-lisp-native-compile-and-load)
>>   command-execute(emacs-lisp-native-compile-and-load)
>
> This should be fixed now on the master branch.
>
>> I also did got the message that Emacs is not functional at the end of the build:
>> 
>>   GEN      ../../info/efaq-w32.info
>> org.texi:15658: warning: @anchor should not appear on @item line
>> org.texi:15671: warning: @anchor should not appear on @item line
>
> This is a harmless warning, so it shouldn't stop the build.

I though so; but I wasn't sure. I am a bit suspicious about discarding those
close_stream errors ad they do in the patch, but thus far it seems to work.

>> make[2]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64/doc/misc'
>> make[1]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
>> make sanity-check make-target=all
>> make[1]: Entering directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
>> ***
>> *** "make all" succeeded, but Emacs is not functional.
>
> Maybe it's because of the problem with comp-write-bytecode-file.

Could be.

Anyway, that was what I needed to build it on ucrt runtime with GCC. Guys at
msys are pointing out that their repo is bsd3 license and gpl compatible and
thus free for all, so they are not sending in any patches. It is anyway just 3
ifdefs; less than 10 lines of code, so decide yourself if you are going to patch it
in and test further or you prefer to keep Emacs as unsuported under ucrt runtime.

Thanks for looking through this.
/a

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Tue, 13 Feb 2024 23:05:00 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Arthur Miller <arthur.miller@live.com>
> >> Cc: emacs-devel@gnu.org, eliz@gnu.org
> >> Date: Tue, 13 Feb 2024 20:00:16 +0100
> >> 
> >> More than the patch, I also had to copy over cp.exe from msys/bin to ucrt64/bin,
> >> because the cp.exe included in ucrt runtime failed in autogen or configure; I
> >> don't remember, with message that --force flag is not implemented yet, when some
> >> script was installing git hooks.
> >
> > This seems to indicate that your system is misconfigured: when you run
> 
> If they say that cp.exe does not support --force flag, it means it is for some
> reason incomplete.

I think there's a misunderstanding: you are supposed to use the MSYS
cp.exe (and grep.exe and gawk.exe and find.exe and some other
commands) when running the Emacs build process, not the cp.exe
included with the ucrt runtime.  But the way to make sure you run the
MSYS executables is to arrange your Emacs-building sessions in a way
that MSYS programs are on PATH ahead of ucrt and other MinGW programs,
not by copying MSYS executables into directories where you keep native
Windows executables.

> Option was to download EZports :)

There's cp.exe in ezwinports.  When I need a native Windows cp.exe, I
use the one from the old GnuWin32 port.  But when I build Emacs, the
build runs cp.exe from MSYS, not the native executable.

> > MSYS Bash to build Emacs, the MSYS's bin directory should be on PATH
> > _ahead_ of the MinGW bin directory, because Bash wants to run MSYS
> > ports, not MinGW (a.k.a. "native Windows") ports.
> 
> Isn't that what their "shell launcher" does for me; sets the correct path(s) for
> all the forest of stuff they have? This is the path the tool itself sets up;
> nothing is modified by me; this is what echo $PATH shows:
> 
> /ucrt64/bin:/ucrt64/bin/site_perl/5.32.1:/ucrt64/bin/vendor_perl:/ucrt64/bin/core_perl:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/

I wonder what are those ucrt* directories doing there, and what kind
of executables they hold.  If that's the MSYS stuff, then maybe you
should take this up with the MSYS2 developers.

> you prefer to keep Emacs as unsuported under ucrt runtime.

I don't mind supporting UCRT, but only if someone volunteers to be the
POC and RI for solving any related problems (the one with close_stream
sounds like a real bug that the patch just sweeps under the carpet --
not a solution I'd like to have in Emacs).  I myself don't know enough
about UCRT, don't have the toolchain to build a UCRT Emacs, and
therefore cannot do that job (even if I forget my other duties here).

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
>> Date: Tue, 13 Feb 2024 23:05:00 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Arthur Miller <arthur.miller@live.com>
>> >> Cc: emacs-devel@gnu.org, eliz@gnu.org
>> >> Date: Tue, 13 Feb 2024 20:00:16 +0100
>> >> 
>> >> More than the patch, I also had to copy over cp.exe from msys/bin to ucrt64/bin,
>> >> because the cp.exe included in ucrt runtime failed in autogen or configure; I
>> >> don't remember, with message that --force flag is not implemented yet, when some
>> >> script was installing git hooks.
>> >
>> > This seems to indicate that your system is misconfigured: when you run
>> 
>> If they say that cp.exe does not support --force flag, it means it is for some
>> reason incomplete.
>
> I think there's a misunderstanding: you are supposed to use the MSYS
> cp.exe (and grep.exe and gawk.exe and find.exe and some other
> commands) when running the Emacs build process, not the cp.exe
> included with the ucrt runtime.  But the way to make sure you run the
> MSYS executables is to arrange your Emacs-building sessions in a way
> that MSYS programs are on PATH ahead of ucrt and other MinGW programs,
> not by copying MSYS executables into directories where you keep native
> Windows executables.
>
>> Option was to download EZports :)
>
> There's cp.exe in ezwinports.  When I need a native Windows cp.exe, I
> use the one from the old GnuWin32 port.  But when I build Emacs, the
> build runs cp.exe from MSYS, not the native executable.
>
>> > MSYS Bash to build Emacs, the MSYS's bin directory should be on PATH
>> > _ahead_ of the MinGW bin directory, because Bash wants to run MSYS
>> > ports, not MinGW (a.k.a. "native Windows") ports.
>> 
>> Isn't that what their "shell launcher" does for me; sets the correct path(s) for
>> all the forest of stuff they have? This is the path the tool itself sets up;
>> nothing is modified by me; this is what echo $PATH shows:
>> 
>> /ucrt64/bin:/ucrt64/bin/site_perl/5.32.1:/ucrt64/bin/vendor_perl:/ucrt64/bin/core_perl:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/
>
> I wonder what are those ucrt* directories doing there, and what kind
> of executables they hold.  If that's the MSYS stuff, then maybe you
> should take this up with the MSYS2 developers.

Yes, that is the msys stuff, that is how they setup envirnoment from their
shells.  I see GCC & co; the usual stuff (tolchain, base-devel, tex and so
on). Bash is from msys.

https://www.msys2.org/docs/environments/

>> you prefer to keep Emacs as unsuported under ucrt runtime.
>
> I don't mind supporting UCRT, but only if someone volunteers to be the

I would love to help; but I have obviously not enough understanding myself aobut
the problems here, so I can't give adequate help to anyone including myself :);
unfortunately.

> POC and RI for solving any related problems (the one with close_stream
> sounds like a real bug that the patch just sweeps under the carpet --
> not a solution I'd like to have in Emacs).  I myself don't know enough
> about UCRT, don't have the toolchain to build a UCRT Emacs, and
> therefore cannot do that job (even if I forget my other duties here).

The toolchain is just one pacman -S command away, but I understand you about the
time; I would be srpurised if you had :).

I agree that until someone is sure about those close_stream events that crash
the build, it shouldn't be considered as a supported build. I can experiment a
bit more and see if I can find out why they appear; but it can be something in
their environment too.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Angelo Graziosi]

Il 13/02/2024 20:00, Arthur Miller ha scritto:
> I was not able to apply their patches to the current master; git apply refused.

I have MSYS2/UCRT64 installed and build Emacs master with a script.

For the source I use 
https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz

and the script applies patches with

case "${BTYPE}" in
         tty)
             patch -p0 < "${D}/MSYS2-packages/emacs-git/configure.ac.diff" \
                 || error_msg "Failure patching configure.ac"
             patch -p0 < "${D}/MSYS2-packages/emacs-git/Makefile.in.patch" \
                 || error_msg "Failure patching Makefile.in"
             echo
             ;;
         u64)
             patch -Np1 -i "${D}/UCRT64-packages/emacs/001-ucrt.patch" \
                 || error_msg "Failure patching nt/cmdproxy.c"
             patch -Np1 -i 
"${D}/UCRT64-packages/emacs/002-clang-fixes.patch" \
                 || error_msg "Failure patching configure.ac (CLANG build)"
             echo
             ;;
     esac

I did the last build with master dated Feb 03.

I think it is only a setup environment issue..

Ciao,
   Angelo.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Angelo Graziosi <angelo.g0@libero.it> writes:

> Il 13/02/2024 20:00, Arthur Miller ha scritto:
>> I was not able to apply their patches to the current master; git apply refused.
>
> I have MSYS2/UCRT64 installed and build Emacs master with a script.
>
> For the source I use
> https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz
>
> and the script applies patches with
>
> case "${BTYPE}" in
>         tty)
>             patch -p0 < "${D}/MSYS2-packages/emacs-git/configure.ac.diff" \
>                 || error_msg "Failure patching configure.ac"
>             patch -p0 < "${D}/MSYS2-packages/emacs-git/Makefile.in.patch" \
>                 || error_msg "Failure patching Makefile.in"
>             echo
>             ;;
>         u64)
>             patch -Np1 -i "${D}/UCRT64-packages/emacs/001-ucrt.patch" \
>                 || error_msg "Failure patching nt/cmdproxy.c"
>             patch -Np1 -i "${D}/UCRT64-packages/emacs/002-clang-fixes.patch" \
>                 || error_msg "Failure patching configure.ac (CLANG build)"
>             echo
>             ;;
>     esac
>
> I did the last build with master dated Feb 03.
>
> I think it is only a setup environment issue..
>
> Ciao,
>   Angelo.

I was lazy; I just tried git apply ucrt.patch, and it refused; nad I was like 3
if-defs; I can just put it in, 30 seconds :). I just build with gcc, so I wasn't
interestedin clang patch.

By the way, is there any reason to build with clang instead of gcc? Faster,
smaller, better? I never tried to be honest.

Thank you for the script too; looks useful!
Ciaos

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Angelo Graziosi]

Il 13/02/2024 23:09, Arthur Miller ha scritto:
> 
> I was lazy; I just tried git apply ucrt.patch, and it refused; nad I was like 3
> if-defs; I can just put it in, 30 seconds :). I just build with gcc, so I wasn't
> interestedin clang patch.

I don't remember well now.. but without the clang patch the build 
finishes with a "...not functional Emacs" message.. maybe the clang 
patch is not only for CLANG... MSYS2 people should explain this..

> 
> By the way, is there any reason to build with clang instead of gcc? Faster,
> smaller, better? I never tried to be honest.

they build for different "architecture/systems": ucrt64, clang64, 
mingw64, clangarm64.. They are starting to drop some 32-bit packages. 
Ask them for other details...

Ciao,
   Angelo.

Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller]

Angelo Graziosi <angelo.g0@libero.it> writes:

> Il 13/02/2024 23:09, Arthur Miller ha scritto:
>> I was lazy; I just tried git apply ucrt.patch, and it refused; nad I was like
>> 3
>> if-defs; I can just put it in, 30 seconds :). I just build with gcc, so I wasn't
>> interestedin clang patch.
>
> I don't remember well now.. but without the clang patch the build finishes with
> a "...not functional Emacs" message.. maybe the clang patch is not only for
> CLANG... MSYS2 people should explain this..

Ah, there is the answer :). Yes it does; it ended so for me, but everything
seems to work fine.

>> By the way, is there any reason to build with clang instead of gcc? Faster,
>> smaller, better? I never tried to be honest.
>
> they build for different "architecture/systems": ucrt64, clang64, mingw64,
> clangarm64.. They are starting to drop some 32-bit packages. Ask them for other
> details...

Yes, I know they do; I thought you were also. Just wonder if there is any
difference; I am too lazy to build and try myself. Yeah, you are right I should
ask them, but I think I am not that curious :).

> Ciao,
>   Angelo.

Thanks; ciaos.