Re: emacs rendering comparisson between emacs23 and emacs26.3

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

To tell the people with the strongest commitment to freedom to use an
old version of Emacs is to choose failure.  We need to re-optimize the
Emacs master so it gives good performance on those machines.

Suggesting that we disable certain features is ok.  Perhaps there
could be a command to select several of these modes together.

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

That is ok as part of the solution.

Regarding C++ indentation, I have two suggestions.

* We could support a faster indentation mode for C code
and for C++ files that use a limited repertoire of C++ constructs.

* Maybe we can come up with additional tricks comparable to
{-in-column-0 to optimize parsing.  Emacs users would put these things
into source files so as to get better peformance.

  > 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

What were the results of the comparisons you did with this setting?
(I wasn't following this topic until yesterday.)

  > 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.

Would you please try that?  But don't limit yourself to existing
configuration options -- try changing it at the C level if you can.
If you find that this makes a big difference (a "bi di" ?), we can
arrange to turn it on and off at run time.

  > With the help of Michael Albinus I have update the emacs23 builtin tramp
  > version to the latest one that supports GNU/Emacs23

The slash is not called for here.  In "GNU Emacs", "GNU" acts as an adjectival
modifying "Emacs", so it is correct to separate them with just a space.

At least that is one problem that is easy to fix.

                                                        (wellcome multihops and
  > adb).

Has Tramp become a lot slower?  Or is it only that the current Tramp doesn't
work on Emacs 23?

          I think perhaps in the future I could upgrade org-mode to the last
  > version that supports GNU Emacs 23 (¿?). And I am going to stay with that 
setup on
  > low power machines.

Has Org mode become a lot slower?  Or is it only that the current Org
mode doesn't work on Emacs 23?


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)