Re: Some developement questions

[hw <hw@adminart.net>]

Alexis <flexibeast@gmail.com> writes:

> hw <hw@adminart.net> 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.

Right, the check is more something that to enabled every know and then
rather something that would need to be done on each start.

How does 0.5--1 second more or less time needed for booting make a
difference?

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

Yes :)  And I learned from this thread that I need to pay more attention
to the documentation.  There is lots I haven't looked at yet, and it
continues to evolve.  I guess it just doesn't come to mind because I'm
so much used to search the internet to find something.

> As someone who has been using Emacs for around 20 years,
> i very much appreciate the comprehensive NEWS file with each release,

There is a NEWS file?

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

It was Ergus who finds this difficult.

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

Well, yes, it is what I find when I search, and it doesn't matter if
something is official or not when I need to solve a particular problem
because when the solution is good, what difference does it make?

Documentation that can be found can always be old when the software it
refers to is old.  You always have to wonder if there is something more
recent that makes the old documentation outdated or irrelevant.

Emacs stands out in this because it has not only been around for a long
time but continues to evolve at a relatively fast pace compared to other
software that has also been around for ages.  While old documentation
for other software may still be relevant, old documentation for Emacs
might not be because Emacs has moved on while the other software has
not.

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

Perhaps that's because it is so much easier and so much more a habit to
enter some search term into a search engine and to browse the findings
than it is to go through the documentation that comes with Emacs.

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

I continue to be amazed and delighted with how exceptionally responsive
and interested the developers of Emacs are and how much help you can get
when you only ask.  This is just wonderful :)

Making bug reports is worthwhile with Emacs because the developers take
care of them and bugs do get fixed.  All this is something other
projects could learn a lot from.

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


cat ~/emacs/auto-complete/.git/config 
[...]
[remote "origin"]
        url = https://github.com/auto-complete/auto-complete.git
[...]


It looks like the last commit was two years ago.  I guess it was still
maintained when I tried it four years ago :)

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

Auto completion is worse than a phone ringing, a notification popping up
on the screen, someone asking you a question and/or wanting you to do
something or people talking in front of your office while you are trying
to program.  Auto completion is worse because these things are temporary
and cause you to loose only anything between 10 minutes and 2 hours
while auto completion interrupts you constantly and thus prevents you
from getting anything programmed at all.

So why would anyone want to torture themselves with auto completion?


Gnus is shipped with Emacs.  Have you ever tried to get it to work?

> i think this is indeed a problem, but unfortunately, i don't have any
> suggestions as to how it might be addressed. :-(

I think if we could make configuration packages that handle all the
dependencies and perhaps deal with alternatives, such packages could be
made for particular use cases.

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

I never looked at either ...

"Section 4 of the manual describes special files (devices)."

You must have different manpages.

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

Is there another one?  Maybe it also needs to point to the documentation
that comes with Emacs and tell people to always lock there to verify the
information in the wiki.  But then, do I need to learn elisp before I
could have a function like (goto-matching-fence) because I'm supposed to
verify that it is not out of date?

Perhaps nowadays, a wiki is the way to go because it suits the way how
people find information.  Long ago, we were reading the documentation
that came packaged with the software because we didn't have the kind of
internet access we now have.  Nowadays, we wish that documentation came
with the software like it used to.

Would it be possible to convert the documentation that comes with Emacs
into a wiki?