Re: Some developement questions

[hw]

Eli Zaretskii <address@hidden> writes:

>> From: hw <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Fri, 24 Aug 2018 03:00:32 +0200
>> 
>> How do we make such proposals?  Should we post some or all of our
>> settings here, including self-written functions we call with non-default
>> key bindings?  What are the users we should have in mind?
>
> My idea is to start with identifying particular classes of users, in
> terms of stuff they mostly do in Emacs, perhaps with a second
> gradation into 2 or 3 proficiency levels.  Then making a list of
> settings each class/level generally wants to change from the built-in
> defaults.  When we have that, we could step back and see what to do
> with the data we collected.  For some, we might decide we want to
> change the defaults, end of story.  For others, we should discuss in
> what form(s) to expose the relevant options to each such group of
> users.
>
> That is just one idea, of course; other ideas for making progress are
> welcome.

It´s a good idea, though I think it shouldn't be limited to settings.

>> (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
>
> This is already in the defaults.

I probably read it on the emacs wiki, 15 years ago maybe.

Maybe Emacs should give us warnings when it discovers outdated,
deprecated or useless settings in ~/.emacs.

>> (setq scroll-margin 0)
>
> This is the default.

I´ve had it at 2 for many years and only tried 0 the other day.  If I
remove it, I won't remember how it's called, so I'd have to comment it
out.

>> (setq Man-width 75)
>
> Emacs nowadays calculates the width dynamically, depending on the
> dimensions of the window.

Why not make Emacs dynamically size it's windows to the width of the
display first? ;~O

<Rant>

Yes, Emacs can do that since a while, and has made it an extremely
annoying default.  Who wants to read manual pages or other text when it
has been formatted to be about 140--300 characters per line wide (and
way more than that if my eyes were what they used to be)?

Lines that wide are great for programming and suck for manuals.  Even
the about 140 characters per line I have with defaulting to two windows
side by side are a bit much for programming, and fortunately most lines
are a lot shorter.  If they are too long, I reformat them to a
reasonable length.  About 140 is a good compromise, yet still too wide
for manuals. (For more than two windows side by side, I'd need a larger
display (or glasses maybe).)

And who wants to need to somehow re-format manual pages to a reasonable
width when they make the window smaller?  Re-formatting them isn't even
possible --- at least it wasn't when I made this setting.  If it now is,
are the manual pages reformatted automatically when you change the size
of the window?  If they are, who would want to change the size of a
window to be able to read a manual page?

This is a good example for a default that really should be changed.
Text is easiest to read at about 70--80 characters per line.  Not having
this setting at a reasonable default allows Emacs to show off with being
able to reformat manual pages to ridiculous line lengths, thus making
them unreadable, which is not useful for the users.

How about changing the effect of Man-width, or an additional setting:
Emacs could usefully format manual pages to fit the window when the
window is narrower than the default width of manual pages (unless the
window is ridiculously narrow, in which case it could fall back to the
default width for manual pages) and format them no wider than the
default width of manual pages for windows that are wider.  It could
also, depending on a(nother) setting(s), dynamically re-format the
manual pages to

min(
    (width_of_window <= ridiculously_narrow) ?
    max_width_of_manual_pages : width_of_window,
    max_width_of_manual_pages
   )

when the window is resized and had been less wide than the maximal width
for manual pages before.

I'd consider that as much more useful than ending up with ridiculously
wide manual pages that are unreadable when they are as wide as the
window and even more unreadable when you make the window less wide in an
attempt to get the pages more readable: awww, too late ....

This would be the solution for this particular setting: a good default.

</Rant>

>
>> (load "~/emacs/my-mark-line")
>
> This is not really a setting ;-)

That's why I think packaging configurations targeted at qualified
classes of users shouldn't be limited to settings like Man-width.

Think of what Ergus pointed out in his last post[1] about the
difficulties users and Emacs are experiencing:


+ find out about Emacs
+ install Emacs
+ find out about package manager of Emacs
+ configure package manager, add repos
+ somehow get an idea of what packages to install
+ get into dependency hell and alternatives hell
+ get into documentation hell because it's hard to tell which
  documentation is up to date
+ get nothing to work


<Ergus>
> So even if the new user had time, patience and abilities to configure
> and open the package manager, add melpa, install jedi, but not
> configure it or use autocomplete, nothing will work for him. This is
> very error prone.
</Ergus>

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.  I don't know about melpa and jedi, and I remember
that there was something that required something that had to do with
either auto-complete or snippets (I had yasnippets also working but then
couldn't be bothered to create all the snippets I would have needed for
it to make sense, but it's cool), and that there were several things
that would either provide automatic completion or snippets, and it was
not too clear which one I should use. My clone of the auto-complete repo
is from 2014, so I don´t remember everything exactly.  It wasn't too
difficult, though, but I didn't do it for python.

So I agree with Ergus here.  This is why I was asking about the package
manager handling dependencies (and alternatives).  Users kinda need to
be able to create a package from their running and working (and perhaps
even non-working) configuration, including /everything/ that is needed
for this configuration.  Other users need to be able to back up their
configuration --- hence be able to create configuration packages --- and
to conveniently install packages created by other users, or by
themselves.  They do not need to have to try to figure out dependencies
or alternatives when installing packages.  Otherwise they would have
some sort of Gentoo experience which can get so horrible it could make
them switch to Windows, or even to a Mac.[2]

Now when Ergus gets everything which is great for programming in python
to work, he would create a configuration package, send it to me, and I
could install it and start learning python.  Emacs kinda needs to be
able to be boring for users to become excited about it and wanting to
learn.  And that includes displaying manual pages by default in a
boringly wonderful readable way.  Often times, the greatest power arises
from simplicity --- perhaps all the more so, the more complicated
everything becomes.


[1]: Message-ID: <address@hidden>

[2]: For those who haven't tried: Gentoo is virtually great, i. e. great
     until the at-least-weekly update fails and forces you yet again to
     make wild guesses about how you could fix the dependencies because
     the package management doesn't do that because you're the one who
     is supposed to do it.  If you can't fix them in time, or if you try
     to avoid the dreadful updates, or if you don't have several hours
     per machine each week for updates, the machine may quickly become
     impossible to update at all.  Not only that, the machine may be
     useless because it can not provide the services it is supposed to
     provide before you fixed the dependencies, which may not be
     possible until some packages have been updated by the package
     managers.  I can understand how I unexpectedly become the one to
     fix the dependencies, and I can not afford to depend on package
     managers who mess things up so badly that updates become
     impossible.  This is one of the many paths leading to the
     appreciation of Centos and the realisation that sometimes there is
     nothing better than boring.