Re: emacs rendering comparisson between emacs23 and emacs26.3

[rrandresf]

Hi Alan. Hi. Richard.

>> contain the "Management Engine" back door and can't start up
>> without it.

Alan> That's a good point.  Presumably processors without these back
Alan> doors are difficult to come by nowadays.

>> Is it possible, to restore most of the lost peformance by
>> deactivating some new features?

Alan> The only way at the moment (for CC Mode) is to change
Alan> font-lock-maximum-decoration from t to 2.

BTW. On my comparissons that variable was set no nil
as Doc says:
--8<---------------cut here---------------start------------->8---
If nil, use the default decoration (typically the minimum available).
--8<---------------cut here---------------end--------------->8---
Also xdisp.c. Just load c-mode not c++-mode

Alan> Most of the increased processing comes from fixing bugs rather
Alan> than adding new features.  Keeping up with, in particular, the
Alan> latest C++ standard (which seems to appear every three years) is
Alan> a challenge, as they steadily make shallow syntactic analysis
Alan> more and more difficult.

I have complete the same test on all Emacsen (Sxemacs-git and Xemacs
21.5). Nothing beats GNU/Emacs23 on rendering.

As Eli pointed out on another email on this same thread. It could be
BIDI. I would need to check on configure If it is possible to deactivate
BIDI support and see what difference it Does.

With the help of Michael Albinus I have update the emacs23 builtin tramp
version to the latest one that supports GNU/Emacs23 (wellcome multihops and
adb). I think perhaps in the future I could upgrade org-mode to the last
version that supports GNU/Emacs23 (¿?). And I am going to stay with that setup 
on
low power machines. BTW. Not having magit on GNU/Emacs23 have made me
discover the niceties about vc-dir (sometimes it hangs on GNU/Emacs23) not
on 26.3.

Also on the same subject. There are several packages that require
GNU/Emacs24 as minimum but they DO work fine with GNU/Emacs23. Yes I Do use
GNU/Emacs23 with package.el. and GNU/Emacs23 coexist with GNU/Emacs26.3

Also GNU/Emacs23. with all the patches from Gentoo (thanks Ulrich
Mueller). compiles fine with latest and greatest tooling {glibc 2.30} on x86 
(32 and 64 bits). But does not compile on
ARM (a low power machine like orange pi). It stays on a loop. I have no have 
the time for attaching gdb to
it. But I plan on  doing it sometime in the future. So for ARM architecture just
CANNOT_DUMP works with a lot of tweaking for compilation (Do not try it).

Best Regards