[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some developement questions
From: |
Ergus |
Subject: |
Re: Some developement questions |
Date: |
Sat, 25 Aug 2018 12:34:13 +0200 |
User-agent: |
NeoMutt/20180716 |
On Sat, Aug 25, 2018 at 05:35:33PM +1000, Alexis wrote:
hw <address@hidden> writes:
Maybe Emacs should give us warnings when it discovers outdated,
deprecated or useless settings in ~/.emacs.
i imagine many people might want this; but many people might /not/
want this if it has a noticeable impact on startup times. Startup
times don't usually have an impact on me personally, since i run an
Emacs server at machine startup and connect clients to that. From what
i've read, however, a number of people find even an extra 0.5s-1.0s in
startup to be significant when jumping in and out of a non-client
Emacs instance. So if this feature did have an impact on startup
times, people would want to be able to enable and disable it at will.
If the messages are just printed in the message buffer it shouldn't impact too much the startup time I think.
get into documentation hell because it's hard to tell which
documentation is up to date
One of the pleasures i find in using Emacs is its extensive
accompanying documentation, documentation which (in my experience) is
typically far better maintained than that of many other projects[1].
As someone who has been using Emacs for around 20 years, i very much
appreciate the comprehensive NEWS file with each release, which allows
me to quite quickly ascertain what changes have been made that might
affect my configuration and workflow (e.g. changed default values).
i say this because i'm wondering which area(s) of documentation you're
having these difficulties with? If you're talking about the Emacs Wiki
at emacswiki.org, well, as far as i'm aware, that's not an official
wiki, is it[2]? Nor is wikemacs.org. i personally much prefer the
latter to the former. But i strongly feel that people's first
destinations when searching for documentation should be the Emacs
Manual and the Emacs Lisp Reference Manual - only after not being able
to locate the information in those manuals, making sure to make use
their excellent indexes, should one consider trying to find
information on the two wikis. i regularly find myself responding to
"How do I do X in Emacs?" questions with "Here's the relevant section
of the relevant manual." At any rate, one should certainly consider
submitting a bug report about inadequate or inaccurate documentation
for functionality shipped with Emacs. Even if no volunteer can
immediately address it, at least it's recorded as something for
potential volunteers to work on.
You are right, emacs documentation is awesome... once you understand how
to get there and how it is organized, the name of the package or the
functionality you want to configure and how to use the indices.
Newer users will go straight to google/duckduckgo to make the
questions. Not only because they don't know exactly the name of what
they are looking for, but also because that's the stackoverflow's
culture. In the beginning they just want some code to copy and paste
in the config.
There are not emacs foros either, the closes we had were some reddit
posts from more than 2 years ago. And the mailing list really feels so
1995. So when a user configures or find a solution, there is not a
central place to share his tweaks/work/corrections/worksaround, and
where the developers could get opinions about what to improve, or what
"defaults" are changing most of the users.
So basically the information is not flowing as it should in all the
directions (developer/mainteiner - experiences user - new user - potential
user).
Another consequence of this is that newer users will report miss configured
features or solved problems as bugs that are never solved, or they feel
intimidated/disapointed to do it. Maybe it is already corrected,
fixed or a work around exists, or another user knows how to fix quickly
but the issues list grows infinitely and all the work goes to the developers.
I had auto-complete working (until I disabled it because it got into
my way by trying to automatically complete everything when I used
Emacs for something I didn't install auto-complete for), installed
from a git repo somewhere on github.
Do you literally mean the `auto-complete.el' package and its
associated `ac-*' packages? Is that still maintained? i'm using
`company` as my autocompletion framework, myself. But neither is
shipped with Emacs, and there's no index entry for `auto-complete' or
`autocomplete' in the Emacs Manual, which probably comes as a surprise
to the many people who have come to expect autocompletion as basic
functionality in a programming environment .... i think this is indeed
a problem, but unfortunately, i don't have any suggestions as to how
it might be addressed. :-(
This is one of the reasons I made my first questions. Because I don't
know what package to use in the list of options when multiple packages
offer the same functionality. I just mention some of them in a previous
message. But from the project point of view, sadly there are not as many
developers as they used to be, so maintaining two or three similar
packages for exactly the same is a waste of man power and a source of
incompatibilities and conflicts with other packages (and so on
recursively because fixing it requires then more man power).
Example: When I started using emacs most of the recommendation were to
use flycheck instead of flymake because it was supposed to be a
replacement for the last one. 5 years later, in the latest release they
have touched flymake and now I don't know if I should migrate back or
not, or why there are people putting effort in flymake instead of
flycheck. But the worst is that some plugins are available only in one
of them (same in auto-complete vs company) since ever.
This is the kind of problems that stagnates big projects and disappoint
developers and users.
Alexis.
--
[1] OpenBSD is probably the other project i think of when thinking of
excellence in documentation. Comparing `man 4 intro' for the Linux
kernel vs. `man 4 intro' for the OpenBSD kernel is eye-opening.
[2] i have the impression that many people assume it /is/ an official
Emacs wiki, so if its not, this fact might need to be somehow
emphasised or made more clear.
- Re: Some developement questions, (continued)
- Re: Some developement questions, Ergus, 2018/08/23
- Re: Some developement questions, Eli Zaretskii, 2018/08/23
- Re: Some developement questions, Pierre Neidhardt, 2018/08/23
- Re: Some developement questions, Eli Zaretskii, 2018/08/23
- Re: Some developement questions, hw, 2018/08/23
- Re: Some developement questions, Eli Zaretskii, 2018/08/24
- Re: Some developement questions, Ergus, 2018/08/24
- Re: Some developement questions, hw, 2018/08/26
- Re: Some developement questions, hw, 2018/08/24
- Re: Some developement questions, Alexis, 2018/08/25
- Re: Some developement questions,
Ergus <=
- Re: Some developement questions, Radon Rosborough, 2018/08/25
- Re: Some developement questions, Eli Zaretskii, 2018/08/25
- Re: Some developement questions, Ergus, 2018/08/25
- Re: Some developement questions, Eli Zaretskii, 2018/08/25
- Re: Some developement questions, Radon Rosborough, 2018/08/25
- Re: Some developement questions, Ergus, 2018/08/25
- Re: Some developement questions, hw, 2018/08/26
- Re: Some developement questions, Eli Zaretskii, 2018/08/26
- Re: Some developement questions, hw, 2018/08/26
- Re: Some developement questions, Eli Zaretskii, 2018/08/27