emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Imports / inclusion of s.el into Emacs


From: Richard Stallman
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Mon, 04 May 2020 22:50:43 -0400

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

  > Cruically, I
  > would go further and say that Emacs will be poorer over-all if it insists
  > on supporting only one part of this spectrum.  I think that it's fair to
  > say that it currently leans away from the method that a large number of new
  > coders are demonstrating that they prefer.

If that refers implicitly to API-based help screens, I don't think
anyone is against better support for those.  There is no need to argue
for the general idea of better API-based help screens.

                                               The question is if and how far
  > emacs is willing to change to adapt.

No, that is NOT the question.

People have not asked for "better API-based help screens".  What they
have asked for is specific ways of implementing such API-based help
screens.  Ways that, for the most part, would have other painful
consequences.  People are arguing that we should suffer those painful
consequences.

However, discussion has revealed that one of the things some of those
people really want is better API-based help screens.  We can implement
that without any downside.  I've presented a few ways.  There are
surely others.

Some of these API-based help screens would require attaching data to
some function names -- for instance, to say that 'concat' is a
function for operating on strings.  But that is not hard.  When we see
what data is useful, we can install it.  So don't worry about
installing it -- figure out what data is useful for this.

Fitting these better API-based help screens into the contexts where
they would be most useful would require changes in various places,
including apropos.c.  But those changes are not hard.  When code for
those screens is implemented and ready to install, we will put in the
changes to invoke the code from the best places.

Would people like to write code to display these help screens as they
would like them to appear, based on the data that is available or that
we could add?


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]