Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> branch: emacs-29
> commit b8d2ec920f37f5d77d32440eefc97dd5e8c2c7dc
> Author: Gregory Heytings <gregory@heytings.org>
> Commit: Gregory Heytings <gregory@heytings.org>
>
>     Revert "Improve last change to xfaces.c" (05ece1eb8b)
>     
>     * src/xfaces.c: Revert 05ece1eb8b.
>     
>     See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.

Don't do that!  You did not answer ANY part of what I said.

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> branch: emacs-29
>> commit b8d2ec920f37f5d77d32440eefc97dd5e8c2c7dc
>> Author: Gregory Heytings <gregory@heytings.org>
>> Commit: Gregory Heytings <gregory@heytings.org>
>>
>>     Revert "Improve last change to xfaces.c" (05ece1eb8b)
>>     
>>     * src/xfaces.c: Revert 05ece1eb8b.
>>     
>>     See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.
>
> Don't do that!  You did not answer ANY part of what I said.

Btw, for posterity's sake, I undid this revert for two reasons:

  - unsetting the "extra" attribute is not safe on the Haiku port.
  - the bitmask variable is a real nusiance for anyone trying to
    debug Emacs or change the layout of the font attribute index
    enumerator.

Just because a bug has been closed does NOT mean the change in it is no
longer subject to scrutiny.  I don't follow bug reports that aren't
related to X, which means I (and possibly many others) only see changes
as they arrive on emacs-diffs.  Which means that by the time the bug is
closed, no, the discussion is not ``over'', and other people still have
a chance to make changes to problems they see as they see them (a
bitmask depending on the internal layout of an enum exposed to Lisp is
definitely one such problem, so is unsetting `:extra'.)

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Gregory Heytings]

>> Don't do that!  You did not answer ANY part of what I said.

Of course I did.  That you did not read it is another thing.

>
> Btw, for posterity's sake, I undid this revert for two reasons:
>

What kind of development practice is this?  You "improve" code in a 
complex area of the Emacs code base that was agreed upon after a long 
discussion only a couple of hours after it was pushed, without asking 
anyone whether what you want to do is okay?  And you revert without even 
reading or replying to the detailed explanation why that "improvement" was 
wrong.

>
> - unsetting the "extra" attribute is not safe on the Haiku port.
>

That's wrong.  And you would have understood this if you had read the 
detailed explanation why your "improvement" is wrong.

>
> - the bitmask variable is a real nusiance for anyone trying to debug 
> Emacs or change the layout of the font attribute index enumerator.
>

It isn't, and it is not supposed to be modified on a daily basis.

>
> Just because a bug has been closed does NOT mean the change in it is no 
> longer subject to scrutiny. I don't follow bug reports that aren't 
> related to X, which means I (and possibly many others) only see changes 
> as they arrive on emacs-diffs.  Which means that by the time the bug is 
> closed, no, the discussion is not ``over'', and other people still have 
> a chance to make changes to problems they see as they see them (a 
> bitmask depending on the internal layout of an enum exposed to Lisp is 
> definitely one such problem, so is unsetting `:extra'.)
>

Nobody said the discussion was over (although I was hoping it was).

But what you did is not a "discussion", it is the exact opposite of a 
"discussion": these are misguided changes introduced in the release branch 
_without any discussion_.

Issue building master

[Ergus]

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

 Hi:
I sent this to emacs help with no reply, so maybe here I'll get more luck:

I just built the master branch and I am getting this error with -nw:

```
Symbol's function definition is void: internal-echo-keystrokes-prefix
```

and this in gui:

```
Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes /home/ergo/.local/share/emacs/30.0.50/lisp/language /home/ergo/.local/share/emacs/30.0.50/lisp/international /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function definition is void: file-name-sans-extension
``
I tried the usual: make extraclean, make bootstrap and the issue persists... Any other advise??

Thanks in advance, Ergus


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

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Of course I did.  That you did not read it is another thing.

You did not.  The only real technical argument you put forth was some
nonsense about FOR_EACH_TAIL being slow.

> What kind of development practice is this?  You "improve" code in a
> complex area of the Emacs code base that was agreed upon after a long
> discussion only a couple of hours after it was pushed, without asking
> anyone whether what you want to do is okay?

My change did not change any behavior, which is why I saw no purpose
discussing it at all.

All it did was rename and redocument a Lisp variable to remove
technicalities that are not of interest to our users.

How many people will remember to redocument the variable the next time
enum font_property_index is changed? Or when realize_gui_face is
renamed?

> And you revert without even reading or replying to the detailed
> explanation why that "improvement" was wrong.

I replied.

> That's wrong.  And you would have understood this if you had read the
> detailed explanation why your "improvement" is wrong.

Really? What if a font entity is there, not a font spec? Or a font spec
from the Haiku font dialog?

> It isn't, and it is not supposed to be modified on a daily basis.

A bitmask is always a nuisance, both for users and developers.
Not all Emacs users write programs in languages that make heavy use
of bitmasks such as C.

> Nobody said the discussion was over (although I was hoping it was).
>
> But what you did is not a "discussion", it is the exact opposite of a
> "discussion": these are misguided changes introduced in the release
> branch _without any discussion_.

Why do I have to discuss so-called ``misguided'' changes to obvious
problems, such as having a bitmask exposed to Lisp?

Once again, here are the problems with having bitmasks exposed to users
(not necessarily just through Lisp, this applies to other extension
languages as well along with some graphics drivers) that have been found
in real life:

  1. Nobody will ever remember to update the variable after the enum is
     changed.

  2. Someone will fill the bitmask with random bogus that happens to do
     nothing now, but will start to do something unexpected ``some time
     later''.

  3. The maximum value of enum font_property_index will exceed what can
     fit in 29 bits at some point in the future.

The doc string and variable was renamed because they make references to
the inner workings of the font machinery.  Again, who will remember to
change the doc string once the C code is rewritten or changed, possibly
after you and I are both gone, or, god forbid, even dead?  (The latter
is a real possibility with the vast timescales in this project.)

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[xenodasein--- via Emacs development discussions.]

Dec 12, 2022, 02:41 by luangruo@yahoo.com:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> branch: emacs-29
>> commit b8d2ec920f37f5d77d32440eefc97dd5e8c2c7dc
>> Author: Gregory Heytings <gregory@heytings.org>
>> Commit: Gregory Heytings <gregory@heytings.org>
>>
>>  Revert "Improve last change to xfaces.c" (05ece1eb8b)
>>  
>>  * src/xfaces.c: Revert 05ece1eb8b.
>>  
>>  See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.
>>
>
> Don't do that!  You did not answer ANY part of what I said.
>

https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01179.html

Your definition of improvement seems to be based on whoever you are
trying to irritate at the moment.  From this penchant for a little bit
of trolling I was suspecting that you are brat, now I am certain.

Cool down, please [was: emacs-29 b8d2ec920f: Revert ...]

[tomas]

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

On Mon, Dec 12, 2022 at 11:18:01AM +0100, xenodasein--- via Emacs development discussions. wrote:

[...]

> trying to irritate at the moment.  From this penchant for a little bit
> of trolling I was suspecting that you are brat, now I am certain.

Folks, keep it civil, please.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Po Lu]

xenodasein@tutanota.de writes:

> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01179.html
>
> Your definition of improvement seems to be based on whoever you are
> trying to irritate at the moment.  From this penchant for a little bit
> of trolling I was suspecting that you are brat, now I am certain.

You seem to not understand the difference between Emacs Lisp and C.  And
the difference between the Motif drag and drop wire protocol, which
Emacs specifically decodes into something Lisp can understand, and a
variable users are supposed to set.

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Gregory Heytings]

>> Of course I did.  That you did not read it is another thing.
>
> You did not.  The only real technical argument you put forth was some 
> nonsense about FOR_EACH_TAIL being slow.
>

"Nonsense", again?  Thank you!

>
> My change did not change any behavior, which is why I saw no purpose 
> discussing it at all.
>

It is telling that you "see no purpose" in discussing a change to code 
that was agreed upon after 300 posts in a bug report.

>
> All it did was rename and redocument a Lisp variable to remove 
> technicalities that are not of interest to our users.
>

That variable is of no interest whatsoever to our users.  It is there only 
for debugging purposes, and is once again only meant to be used by the few 
users who understand subtle technicalities in the face realization code.

>> And you revert without even reading or replying to the detailed 
>> explanation why that "improvement" was wrong.
>
> I replied.
>

Aha.  That's your understanding of a "discussion", then: you say 
something, and act immediately, without waiting for a potential answer. 
And then claim that there was a "discussion" because you said something. 
Oh, in fact no, that's not even what happened: you reverted before saying 
anything.

>> That's wrong.  And you would have understood this if you had read the 
>> detailed explanation why your "improvement" is wrong.
>
> Really? What if a font entity is there, not a font spec? Or a font spec 
> from the Haiku font dialog?
>

You would not ask that question if you had read the explanation in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.  And the fact you 
ask that question shows that you did not read it.

>
> 1. Nobody will ever remember to update the variable after the enum is 
> changed.
>

The relevant parts of that enum have not changed at all since they were 
introduced fifteen years ago.

>
> 2. Someone will fill the bitmask with random bogus that happens to do 
> nothing now, but will start to do something unexpected ``some time 
> later''.
>

Nobody should do that.  The docstring clearly said: "There is no reason to 
change that value except for debugging purposes."

>
> 3. The maximum value of enum font_property_index will exceed what can 
> fit in 29 bits at some point in the future.
>

Oh yes, I see.  FONT_SPEC_MAX is (and has always been) 15, but clearly, 
for a reason that hasn't happened in the past fifteen years, "at some 
point in the future", it will become 30, and that will be problematic on 
32-bit computers.  And you tell me that what I write is "nonsense".

Anyway, I don't want to deal with this anymore.  I probably spent about 50 
hours on that bug, that's more than enough.

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[xenodasein--- via Emacs development discussions.]

Dec 12, 2022, 10:36 by luangruo@yahoo.com:

> xenodasein@tutanota.de writes:
>
>> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01179.html
>>
>> Your definition of improvement seems to be based on whoever you are
>> trying to irritate at the moment.  From this penchant for a little bit
>> of trolling I was suspecting that you are brat, now I am certain.
>>
>
> You seem to not understand the difference between Emacs Lisp and C.  And
> the difference between the Motif drag and drop wire protocol, which
> Emacs specifically decodes into something Lisp can understand, and a
> variable users are supposed to set.
>

Attempting to boss others around over things you yourself do not
understand is precisely what you're all about.  Well, you'll grow up
eventually.

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> It is telling that you "see no purpose" in discussing a change to code
> that was agreed upon after 300 posts in a bug report.

Sorry, but I don't see where in the discussion the use of a bitmask as a
variable was actually discussed.  My change does not touch any of the
code which was discussed.

> That variable is of no interest whatsoever to our users.  It is there
> only for debugging purposes, and is once again only meant to be used
> by the few users who understand subtle technicalities in the face
> realization code.

Then the best course of action is to just remove the variable.

> Aha.  That's your understanding of a "discussion", then: you say
> something, and act immediately, without waiting for a potential
> answer. And then claim that there was a "discussion" because you said
> something. Oh, in fact no, that's not even what happened: you reverted
> before saying anything.

Only because you reverted first.

> You would not ask that question if you had read the explanation in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.  And the fact
> you ask that question shows that you did not read it.

Anyway, AFAIK :font can be a font-entity and not a font-spec, in which
case it is definitely not okay to touch :extra under the Haiku font
backend: it contains two indices into the system-wide font and family
arrays which should not be changed.

> The relevant parts of that enum have not changed at all since they
> were introduced fifteen years ago.

And will you guarantee that will always be the case?

> Nobody should do that.  The docstring clearly said: "There is no
> reason to change that value except for debugging purposes."

Alas, what ``should'' be is very different from reality.  Someone will
set the unused bits to random garbage, and someone elses nice plan for
adding extra fields to a font object will be broken by that change.

> Oh yes, I see.  FONT_SPEC_MAX is (and has always been) 15, but
> clearly, for a reason that hasn't happened in the past fifteen years,
> "at some point in the future", it will become 30, and that will be
> problematic on 32-bit computers.  And you tell me that what I write is
> "nonsense".

It could change, and once it does I can almost guarantee that nobody
will think to update the ``obscure'' bitmask exposed to Lisp that users
``are not supposed'' to set.

> Anyway, I don't want to deal with this anymore.  I probably spent
> about 50 hours on that bug, that's more than enough.

Fair enough.

Re: Issue building master

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 09:37:05 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> 
> I just built the master branch and I am getting this error with -nw:
> 
> ```
> Symbol's function definition is void: internal-echo-keystrokes-prefix
> ```

Is this when building or when starting after the build completes?  (I
see no problem in either case.)

> and this in gui:
> 
> ```
> Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp
> /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp
> /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes /home/ergo/.local/share/emacs/30.0.50/lisp/language
> /home/ergo/.local/share/emacs/30.0.50/lisp/international
> /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes
> /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function definition
> is void: file-name-sans-extension
> ``

If this is during startup after the build, then your pdmp file either
doesn't exist or is faulty.

If this is during a build, then why does it say "Dump mode: nil"?

What happens if you clone the repository anew, and then do a fresh
build?

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 11:18:01 +0100 (CET)
> Cc: emacs-devel@gnu.org, Gregory Heytings <gregory@heytings.org>
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> Your definition of improvement seems to be based on whoever you are
> trying to irritate at the moment.  From this penchant for a little bit
> of trolling I was suspecting that you are brat, now I am certain.

This is a warning: please stop these ad-hominem attacks, or your posts
here will be moderated.

There will be no further warnings.

Re: Issue building master

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 13:56:58 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> 
> Is this when building or when starting after the build completes?  (I
> see no problem in either case.)
> 
> When starting after the build completes.
> 
> > and this in gui:
> > 
> > ```
> > Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes
> /home/ergo/.local/share/emacs/30.0.50/lisp/language
> > /home/ergo/.local/share/emacs/30.0.50/lisp/international
> > /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes
> > /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function
> definition
> > is void: file-name-sans-extension
> > ``
> 
> If this is during startup after the build, then your pdmp file either
> doesn't exist or is faulty.
> 
> This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> this?

Do you install Emacs (as in "make install"), or do you run it from the
source tree?

P.S. And please don't remove the list from the CC.

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[xenodasein--- via Emacs development discussions.]

Dec 12, 2022, 13:44 by eliz@gnu.org:

>> Date: Mon, 12 Dec 2022 11:18:01 +0100 (CET)
>> Cc: emacs-devel@gnu.org, Gregory Heytings <gregory@heytings.org>
>> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
>>
>> Your definition of improvement seems to be based on whoever you are
>> trying to irritate at the moment.  From this penchant for a little bit
>> of trolling I was suspecting that you are brat, now I am certain.
>>
>
> This is a warning: please stop these ad-hominem attacks, or your posts
> here will be moderated.
>
> There will be no further warnings.
>

Ah, I forgot how only your protégé has the right to these "ad-hominem
attacks."  Well go ahead, it's probably better for me anyway.  Not
so sure about maintainers or Emacs though, with this head in the sand
approach.  Giving authority to brats like PL is yet another great
decision for driving Emacs into further obscurity, congratulations if
that is the intent.  Bye.

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[tomas]

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

On Mon, Dec 12, 2022 at 04:03:59PM +0100, xenodasein--- via Emacs development discussions. wrote:
> Dec 12, 2022, 13:44 by eliz@gnu.org:
> 
> >> Date: Mon, 12 Dec 2022 11:18:01 +0100 (CET)
> >> Cc: emacs-devel@gnu.org, Gregory Heytings <gregory@heytings.org>
> >> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> >>
> >> Your definition of improvement seems to be based on whoever you are
> >> trying to irritate at the moment.  From this penchant for a little bit
> >> of trolling I was suspecting that you are brat, now I am certain.
> >>
> >
> > This is a warning: please stop these ad-hominem attacks, or your posts
> > here will be moderated.
> >
> > There will be no further warnings.
> >
> 
> Ah, I forgot how only your protégé has the right to these "ad-hominem
> attacks." [...]

The only ad hominem I've seen came from you. Po Lu's and Gregory's tone
was heated, I'd say unpleasantly so, but not ad hominem.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Issue building master

[Ergus]

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

 

    On Monday, December 12, 2022 at 03:15:46 PM GMT+1, Eli Zaretskii <eliz@gnu.org> wrote:  
 
 > Date: Mon, 12 Dec 2022 13:56:58 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> 
> Is this when building or when starting after the build completes?  (I
> see no problem in either case.)
> 
> When starting after the build completes.
> 
> > and this in gui:
> > 
> > ```
> > Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes
> /home/ergo/.local/share/emacs/30.0.50/lisp/language
> > /home/ergo/.local/share/emacs/30.0.50/lisp/international
> > /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes
> > /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function
> definition
> > is void: file-name-sans-extension
> > ``
> 
> If this is during startup after the build, then your pdmp file either
> doesn't exist or is faulty.
> 
> This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> this?

Do you install Emacs (as in "make install"), or do you run it from the
source tree?

From source tree. I checkout to other branches, old commits, recompiled, emacs -Q... just same error again and again. 



P.S. And please don't remove the list from the CC.
Sorry I am using a weird web client (as emacs is broken) I am not sure how does it work

  

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

Re: Issue building master

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 15:49:29 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > If this is during startup after the build, then your pdmp file either
> > doesn't exist or is faulty.
> > 
> > This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> > this?
> 
> Do you install Emacs (as in "make install"), or do you run it from the
> source tree?
> 
> From source tree. I checkout to other branches, old commits, recompiled, emacs -Q... just same
> error again and again. 

The emacs-29 branch also?  And a clean new clone also?  Then it's
almost certainly something specific to your system.  Did you update
some libraries or tools or some other software lately?

What if you try configuring Emacs with

  ./configure ... --enable-checking='yes,glyphs' CFLAGS='-O0 -g3'

(where "..." stands for the other options you use when you configure
Emacs) -- do you see something different?

If you download the Emacs 28.2 tarball, can you build and run it?

Re: Issue building master

[Ergus]

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

 Hi:
    On Monday, December 12, 2022 at 05:05:12 PM GMT+1, Eli Zaretskii <eliz@gnu.org> wrote:  
 
 > Date: Mon, 12 Dec 2022 15:49:29 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > If this is during startup after the build, then your pdmp file either
> > doesn't exist or is faulty.
> > 
> > This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> > this?
> 
> Do you install Emacs (as in "make install"), or do you run it from the
> source tree?
> 
> From source tree. I checkout to other branches, old commits, recompiled, emacs -Q... just same
> error again and again. 

The emacs-29 branch also? Yes.
And a clean new clone also?  Then it's almost certainly something specific to your system.  Did you updatesome libraries or tools or some other software lately?actually I use Arch, so yes because it is a rolling release. But I don't have any other problem with anything else, just emacs.. so... not sure it is my system...
What if you try configuring Emacs with

  ./configure ... --enable-checking='yes,glyphs' CFLAGS='-O0 -g3'

(where "..." stands for the other options you use when you configure
Emacs) -- do you see something different?
Same behavior
If you download the Emacs 28.2 tarball, can you build and run it?
I will try this one in a while then...

Sorry for too much bother, but this is making me crazy since yesterday...
  

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