It's ok, at least I found the cause of my problem.
You can close the bug report.

Thanks

On Fri, Sep 30, 2022 at 6:22 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Fri, 30 Sep 2022 18:05:02 +0530
> > Cc: 58184@debbugs.gnu.org
> >
> > I think I may have found the problem here, JetBrains Mono does not have
> the glyphs for these
> > "faulty" characters that is why Emacs chooses a different font for them,
> but the thing is these characters
> > can still be displayed in the correct font i.e. JetBrains Mono by
> combining the glyphs which made up the
> > unsupported glyph, this is why hb-view was able to display them I guess.
> > For example entering ṃ (#x1e43 Latin small letter m with a dot below)
> will result in it being displayed in a
> > different font,
> > but entering ṃ (m + #x323 Combining dot below) will result in it being
> displayed with JetBrains Mono.
> >
> > So now the question is should these characters be decomposed to better
> fit with other characters when the
> > font does not support them?
>
> We cannot do that in the buffer text, because that would mean
> modifying the text behind user's back.  And doing this in display code
> woul mean activating character composition where none should happen.
>
> I think fonts that don't have glyphs for precomposed characters
> shouldn't be used in Emacs for text that could have the codepoints of
> those characters.  Emacs doesn't pass every character to the shaping
> engine, and so the tricks of decomposing characters to get them
> displayed are something we cannot be expected to do.  Sorry.
>