Re: xdisp.c in C++ (Was: Abysmal state of GTK build)

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

On 22-08-25 10:28 , Eli Zaretskii wrote:
> Feel free to describe how rewriting xdisp.c in C++ could make it
> significantly easier to understand and maintain.  We might as well
> consider doing something still in C, if any of the ideas sound
> attractive.
> 
> It is quite obvious that the various methods in
> get_next_display_element and set_iterator_to_next could use
> polymorphism, and the iterator object itself could be rewritten in
> C++.  Likewise the handle_stop handlers.  But will this really make
> the code simpler and easier to understand?
> 
> And what else in xdisp.c will benefit from rewriting it in C++?
> 
> (This is obviously a very academic discussion at this point, so I'll
> understand if you don't want to invest any real time in it.  I asked
> those questions on the chance that you already have most of the
> answers figured out and ready.)

Yup, it's academic.  If I had to bet, I'd say nothing will change :-).
And I don't carry a design in my head.  And I don't know if I would work 
on it anyway because Emacs doesn't play that big a role in my life 
nowadays, and I might as well be dead or hand shaking thin air until 
changing something would pay off.

What I wanted to convey is that I perceive a problem, that I think it 
should be addressed for the long run, and that following the path of GCC 
and GDB would be good.

One can say the problem doesn't exist, or it's not that grave.  Or one 
can say we don't need C++ to solve the problem, which is what Po Lu 
thinks, I believe.  Or no-one will work on this.  And so on, that's all 
fine, I don't want to argue here ad infinitum.

 From my POV, the one thing that's certain is that making things 
impossible ensures they won't happen.

A definite decision would make me happy. If it's the right one, of 
course :-).

That should be it from my side.