Re: Some developement questions

[Ergus <spacibba@aol.com>]

On Sun, Aug 26, 2018 at 03:06:35PM +0200, hw wrote:
>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?

Yes, I usually look for it, but online :p  
>
>> 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.

When I started yes, it was difficult. Mainly because the names, the
terms and all the environment were all new and very different of
everything else I used before. Some keybindings in the documentations
didn't work because they were conflicting with the gnome-terminal ones
(as I was using ssh connections with no tramp). There was not redo in
the usual way (still very confusing for me). And many configurations and
help I found in the web was in Lisp which is also very different from
python, C, Ruby, Fortran...


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

Because they look for: "auto completion emacs" and that's the result
they get. So the experience is bad and they move to sublime because
emacs completion was bad.


>
>Gnus is shipped with Emacs.  Have you ever tried to get it to work?
>
I tried but it didn't work for me, and in spite there are alternatives like mu4e the documentation directs you to gnus.

>> 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?
>
>
+1 to this.

And a foro where the users can interact dynamically, and give answers
each other, so all the support does not fall on the emacs developers,
but the users can help each other. I told before: a mailing list is so
1998.

We need some feedback from the users if we want more/newer users.

Vim made like a features claim page where the users report what they
want to see in the next releases, and they vote for them. So the
developers with a simple look knows what is coming next