best gnu/linux distro for emacs

best gnu/linux distro for emacs

[Alan E. Davis]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Many distros do not provide emacs out of the box.  Something of a slap in
the face, and unexpected.  And annoying.  Various distros handle emacs
differently.

I like the way Gentoo handles emacs, and I may reinstall gentoo in the
future.  Arch worked farily well.  I would prefer to just leave it alone,
pretty much, and tolerate compiling it oneself.

For now, what is the "best" distribution of GNU/Linux for running emacs?

Alan D

[-- Attachment #2: Type: text/html, Size: 494 bytes --]

Re: best gnu/linux distro for emacs

[Xue Fuqiao]

On Sat, 23 Mar 2013 03:09:47 -0700
"Alan E. Davis" <lngndvs@gmail.com> wrote:

> Many distros do not provide emacs out of the box.  Something of a slap in
> the face, and unexpected.  And annoying.  Various distros handle emacs
> differently.

> I like the way Gentoo handles emacs, and I may reinstall gentoo in the
> future.  Arch worked farily well.  I would prefer to just leave it alone,
> pretty much, and tolerate compiling it oneself.

> For now, what is the "best" distribution of GNU/Linux for running emacs?

It depends.  There are different views on the word "best".

According to Saint IGNUcius[1], wholly free GNU/Linux distributions[2]
are recommended.

Although Gentoo and Arch Gentoo do not have a policy of only including
free software, they are good distros technically.  Other distros like
Debian, Fedora, Slackware and openSUSE all have their own advantages.

Debian is known for relatively strict adherence to the philosophies of
free software.  But in Debian, Emacs documentation is in package
`emacs24-common-non-dfsg`, since the Debian community and the FSF have
some disagreement.  There are many packages about Emacs in Debian, like
`emacs-goodies-el', `emacs-snapshot' and `debian-el'.  And there are
also many Debian related Emacs libraries, like devscripts-el[3],
apt-mode[4], apt-sources[5] and so on.

Fedora leads the advancement of free software; Slackware aims to be the
most "Unix-like" distro; and YaST in openSUSE is very elegant.  All of
them are good distros; which is best is depending on your taste.

In Emacs-dev, according to some details, I guess that (just a guess,
there's not much basis):
Richard Stallman uses gNewSense
Stafan Monnier uses Debian
Paul Eggert uses Fedora (or Ubuntu?)
Dmitry Antipov uses Ubuntu
Tom Tromey uses Fedora
Eric S. Raymond uses Ubuntu

And there are some other people who use MS-Windows/OSX/... , like Eli
and Leo.

[1] http://stallman.org/saint.html
[2] http://www.gnu.org/distros/free-distros.html
[3] http://www.netfort.gr.jp/~dancer/software/devscripts-el.html.en
[4] http://www.netfort.gr.jp/~dancer/software/apt-mode.html
[5] http://www.emacswiki.org/emacs/AptSources

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Re: best gnu/linux distro for emacs

[Jude DaShiell]

Probably slackware since you can choose to install it in the install 
process and since Slackware was the first commercial linux distro, the 
slackware team probably has more experience  with emacs than other newer 
linux distros have managed to get over the years.

On Sat, 23 Mar 2013, Alan E. Davis wrote:

> Many distros do not provide emacs out of the box.  Something of a slap in
> the face, and unexpected.  And annoying.  Various distros handle emacs
> differently.
> 
> I like the way Gentoo handles emacs, and I may reinstall gentoo in the
> future.  Arch worked farily well.  I would prefer to just leave it alone,
> pretty much, and tolerate compiling it oneself.
> 
> For now, what is the "best" distribution of GNU/Linux for running emacs?
> 
> Alan D
> 

---------------------------------------------------------------------------
jude <jdashiel@shellworld.net>
Microsoft, windows is accessible. why do blind people need screen readers?

Re: best gnu/linux distro for emacs

[Jay Belanger]

>> For now, what is the "best" distribution of GNU/Linux for running emacs?

...

> Debian is known for relatively strict adherence to the philosophies of
> free software.  But in Debian, Emacs documentation is in package
> `emacs24-common-non-dfsg`, since the Debian community and the FSF have
> some disagreement.  There are many packages about Emacs in Debian, like
> `emacs-goodies-el', `emacs-snapshot' and `debian-el'.  And there are
> also many Debian related Emacs libraries, like devscripts-el[3],
> apt-mode[4], apt-sources[5] and so on.

I recall there were some complaints that Debian had some odd Emacs
setup; I don't recall the details, but I seem to recall David Kastrup
pointing them out.  Does anybody remember? 

Re: best gnu/linux distro for emacs

[Alan Mackenzie]

Jay Belanger <jay.p.belanger@gmail.com> wrote:

>>> For now, what is the "best" distribution of GNU/Linux for running emacs?

> ...

>> Debian is known for relatively strict adherence to the philosophies of
>> free software.  But in Debian, Emacs documentation is in package
>> `emacs24-common-non-dfsg`, since the Debian community and the FSF have
>> some disagreement.  There are many packages about Emacs in Debian, like
>> `emacs-goodies-el', `emacs-snapshot' and `debian-el'.  And there are
>> also many Debian related Emacs libraries, like devscripts-el[3],
>> apt-mode[4], apt-sources[5] and so on.

> I recall there were some complaints that Debian had some odd Emacs
> setup; I don't recall the details, but I seem to recall David Kastrup
> pointing them out.  Does anybody remember?

They put a dummy site-start.el under /etc somewhere.  This can catch you
out if you have your real site-start.el in a normal Emacs place such as
/usr/local/share/emacs/site-lisp/site-start.el since the dummy one gets
loaded instead of the real one.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: best gnu/linux distro for emacs

[Peter Münster]

On Sat, Mar 23 2013, Alan E. Davis wrote:

> For now, what is the "best" distribution of GNU/Linux for running emacs?

openSUSE is the best distribution of all that I know.

-- 
           Peter

Re: best gnu/linux distro for emacs

[Bob Proulx]

Alan Mackenzie wrote:
> Jay Belanger wrote:
> > I recall there were some complaints that Debian had some odd Emacs
> > setup; I don't recall the details, but I seem to recall David Kastrup
> > pointing them out.  Does anybody remember?
> 
> They put a dummy site-start.el under /etc somewhere.  This can catch you
> out if you have your real site-start.el in a normal Emacs place such as
> /usr/local/share/emacs/site-lisp/site-start.el since the dummy one gets
> loaded instead of the real one.

The empty template file is:

  /etc/emacs/site-start.el

What makes /usr/local/share/emacs/site-lisp/site-start.el the normal
path and /etc/emacs/site-start.el something not normal?

In any case...  One could always put the customizations in that file.
That is rather what is expected.  Or one could add a load statement
there to load /usr/local/share/emacs/site-lisp/site-start.el if you
want to keep the customizations there.  It is six of one or a half
dozen of the other.

Bob

Re: best gnu/linux distro for emacs

[Alan Mackenzie]

Bob Proulx <bob@proulx.com> wrote:
> Alan Mackenzie wrote:
>> Jay Belanger wrote:
>> > I recall there were some complaints that Debian had some odd Emacs
>> > setup; I don't recall the details, but I seem to recall David Kastrup
>> > pointing them out.  Does anybody remember?
 
>> They put a dummy site-start.el under /etc somewhere.  This can catch you
>> out if you have your real site-start.el in a normal Emacs place such as
>> /usr/local/share/emacs/site-lisp/site-start.el since the dummy one gets
>> loaded instead of the real one.

> The empty template file is:

>  /etc/emacs/site-start.el

> What makes /usr/local/share/emacs/site-lisp/site-start.el the normal
> path and /etc/emacs/site-start.el something not normal?

A very good question!  I've had a quick search of the Emacs manual and not
found anything specifying the contents of load-path.  The next best thing
was:

"Many sites put these files in a subdirectory named `site-lisp' in the
Emacs installation directory, such as `/usr/local/share/emacs/site-lisp'."

, from the chapter "The Emacs Initialization File".  I'm confident that
/etc/emacs exists nowhere in the manual.

When I start emacs -Q, load-path contains the directories under
/usr/local/share/emacs/24.3/lisp together with
/usr/local/share/emacs/site-lisp.  So it would seem, for a standard build,
that .../site-lisp is the only safe place for site-start.el.

Presumably, there's a way of setting load-path as part of the build
process, and the Debian Emacs team uses it.

> In any case...  One could always put the customizations in that file.
> That is rather what is expected.  Or one could add a load statement
> there to load /usr/local/share/emacs/site-lisp/site-start.el if you
> want to keep the customizations there.  It is six of one or a half
> dozen of the other.

GRRR!!!  Yes, one can do any of these things, but only after having
discovered there's a problem which needs fixing, and diagnosing that
problem.  This cost me, perhaps, an hour or two back in 2005 when I
first installed Debian on a new PC, and my site-start.el wasn't loading.

> Bob

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: best gnu/linux distro for emacs

[W. Greenhouse]

"Alan E. Davis" <lngndvs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Many distros do not provide emacs out of the box.  Something of a
> slap in the face, and unexpected.  And annoying.  Various distros
> handle emacs differently. 
>
> I like the way Gentoo handles emacs, and I may reinstall gentoo in
> the future.  Arch worked farily well.  I would prefer to just leave
> it alone, pretty much, and tolerate compiling it oneself.
>
> For now, what is the "best" distribution of GNU/Linux for running
> emacs?
>
> Alan D

The vital thing is less a question of distros and more a question of
window manager/desktop environment, I think: avoid those which clobber
important Emacs keybindings (e.g. M-TAB) and make it hard to
reconfigure.

Best,
Will

-- 
BOFH excuse #135:

You put the disk in upside down.

Re: best gnu/linux distro for emacs

[Bob Proulx]

Alan Mackenzie wrote:
> Bob Proulx wrote:
> > What makes /usr/local/share/emacs/site-lisp/site-start.el the normal
> > path and /etc/emacs/site-start.el something not normal?
> 
> A very good question!  I've had a quick search of the Emacs manual and not
> found anything specifying the contents of load-path.  The next best thing
> was:
> 
> "Many sites put these files in a subdirectory named `site-lisp' in the
> Emacs installation directory, such as `/usr/local/share/emacs/site-lisp'."
> 
> , from the chapter "The Emacs Initialization File".  I'm confident that
> /etc/emacs exists nowhere in the manual.

I am a big believer in doing things the way it is documented.  But in
this case I am going to argue that the documentation was insufficient
to the task.  Because I think this is simply a case of the
documentation not sufficiently describing how emacs might be compiled
and installed.  Basically all of the stuff that we normally see in the
'configure' script set of options.  Things get messy where theory
meets practice and I can see the documentation trying to avoid getting
into that mess.  But here it has caused a problem.

> When I start emacs -Q, load-path contains the directories under
> /usr/local/share/emacs/24.3/lisp together with
> /usr/local/share/emacs/site-lisp.  So it would seem, for a standard build,
> that .../site-lisp is the only safe place for site-start.el.

You say "for a standard build" and I think that needs more
clarification.  What is a standard build?  Let me jump ahead and
assume this was your own compilation and that you did not supply any
configure options at all.  (Since I think that is likely the case
here.)  Then for you the "standard build" really meant a local
compilation and installation using all of the default configure
options.  Is that correct?

> > In any case...  One could always put the customizations in that file.
> > That is rather what is expected.  Or one could add a load statement
> > there to load /usr/local/share/emacs/site-lisp/site-start.el if you
> > want to keep the customizations there.  It is six of one or a half
> > dozen of the other.
> 
> GRRR!!!  Yes, one can do any of these things, but only after having
> discovered there's a problem which needs fixing, and diagnosing that
> problem.  This cost me, perhaps, an hour or two back in 2005 when I
> first installed Debian on a new PC, and my site-start.el wasn't loading.

This is really uncovering a deeper layer of philosophical question.
The question is how do you package software for distribution to a wide
audience of people?  Where do you put it?  How do you do this while
allowing people to compile and install their own software?  This is
the question that must be answered in order to address your issue.

A local compilation using the standard autotools and no configure
options will root all of the paths in the /usr/local tree.  Programs
will go in /usr/local/bin and so forth.  If that is the standard build
then should a software distribution (pick any) compile their software
using the same configure without any options and install in /usr/local
and so be a "standard build"?  [No.  Please no.]

Instead we have a separation with system packaged paths in / and local
user compiled paths in /usr/local.  We hold /usr/local inviolate
against system intrusion.  And the reverse is almost the same.  We
don't expect that if we compile and install to /usr/local that it will
smash over system package managed files in /.

Knowing this then if I am using a locally compiled program installed
in /usr/local/bin and want to modify its configuration then I expect
it to be configured in /usr/local somewhere usually /usr/local/etc but
sometimes elsewhere.  If I am using a system package installed program
in /bin (or /usr/bin) then I expect it to be configured somewhere in /
usually /etc but sometimes elsewhere too but definitely not /usr/local.

Bob

Re: best gnu/linux distro for emacs

[Xue Fuqiao]

On Sun, 24 Mar 2013 15:51:59 +0000
wgreenhouse@riseup.net (W. Greenhouse) wrote:

> "Alan E. Davis" <lngndvs@gmail.com> writes:

> > For now, what is the "best" distribution of GNU/Linux for running
> > emacs?

> The vital thing is less a question of distros and more a question of
> window manager/desktop environment, I think: avoid those which clobber
> important Emacs keybindings (e.g. M-TAB) and make it hard to
> reconfigure.

Right, many WM/DE block some keyboard inputs like `M-<TAB>', `M-<SPC>',
`C-M-d' and `C-M-l'.  And I think a lightweight WM/DE is preferred.
Because Emacs can do everything, it can take the place of most features
in a DE.

It's also a question of web browser.  For this question, I prefer
Conkeror, because it is mainly patterned after Emacs.

It's also a question of X toolkit.  For this question, I prefer
Gtk+, because it is the best toolkit supported by Emacs.

Maybe it's also a question of secure communications library, but I'm no
expert on GnuTLS and its integration.

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Re: best gnu/linux distro for emacs

[W. Greenhouse]

Xue Fuqiao <xfq.free-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> On Sun, 24 Mar 2013 15:51:59 +0000
> wgreenhouse-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org (W. Greenhouse) wrote:
>
>> "Alan E. Davis" <lngndvs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> > For now, what is the "best" distribution of GNU/Linux for running
>> > emacs?
>
>> The vital thing is less a question of distros and more a question of
>> window manager/desktop environment, I think: avoid those which clobber
>> important Emacs keybindings (e.g. M-TAB) and make it hard to
>> reconfigure.
>
> Right, many WM/DE block some keyboard inputs like `M-<TAB>', `M-<SPC>',
> `C-M-d' and `C-M-l'.  And I think a lightweight WM/DE is preferred.
> Because Emacs can do everything, it can take the place of most features
> in a DE.
>
> It's also a question of web browser.  For this question, I prefer
> Conkeror, because it is mainly patterned after Emacs.
>
> It's also a question of X toolkit.  For this question, I prefer
> Gtk+, because it is the best toolkit supported by Emacs.
>
> Maybe it's also a question of secure communications library, but I'm no
> expert on GnuTLS and its integration.

Big +1 to Conkeror.  However, I am not a big fan of the Gtk+ build of
Emacs, because this choice of X toolkit for building Emacs introduces a
big problem with respect to Emacs daemon reliability (loss of connection
to the X server will now crash the daemon).  See the long-standing bug
against Gtk+, https://bugs.launchpad.net/gtk/+bug/543611/comments/22.

If you like the Emacs GUI under X and you like using emacsclient/emacs
--daemon, I recommend ./configure --with-x-toolkit=lucid or ./configure
--with-x-toolkit=no as alternatives to using a Gtk+ build of Emacs.  X
integration, including graphics and the ability to use Xft fonts, will
not be affected; only the UI "widgets" such as scroll bars and toolbar
buttons will change.  But you will be free from the threat of your
daemon going down if there is some problem with X.

-- 
BOFH excuse #27:

radiosity depletion

Re: best gnu/linux distro for emacs

[Bastian Ballmann]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

Hi,

I prefer Arch Linux, because you always get the newest stuff only hours 
after it
was released and they dont patch the sources so you really get the real 
thing.

just my 2 cent ;)

Basti


Am 23.03.2013 11:09, schrieb Alan E. Davis:
> Many distros do not provide emacs out of the box. Something of a slap 
> in the face, and unexpected.  And annoying. Various distros handle 
> emacs differently.
>
> I like the way Gentoo handles emacs, and I may reinstall gentoo in the 
> future.  Arch worked farily well.  I would prefer to just leave it 
> alone, pretty much, and tolerate compiling it oneself.
>
> For now, what is the "best" distribution of GNU/Linux for running emacs?
>
> Alan D


-- 
ETH Zürich, Bastian Ballmann, IT Service Group
CAB E 44.1, Universitätsstrasse 6, CH-8092 Zürich
Tel +41 44 632 72 04


[-- Attachment #2: Type: text/html, Size: 1631 bytes --]

Re: best gnu/linux distro for emacs

[Alan Mackenzie]

Hi, Bob.

Bob Proulx <bob@proulx.com> wrote:
> Alan Mackenzie wrote:
>> Bob Proulx wrote:
>> > What makes /usr/local/share/emacs/site-lisp/site-start.el the normal
>> > path and /etc/emacs/site-start.el something not normal?
 
>> A very good question!  I've had a quick search of the Emacs manual and not
>> found anything specifying the contents of load-path.  The next best thing
>> was:
 
>> "Many sites put these files in a subdirectory named `site-lisp' in the
>> Emacs installation directory, such as `/usr/local/share/emacs/site-lisp'."
 
>> , from the chapter "The Emacs Initialization File".  I'm confident that
>> /etc/emacs exists nowhere in the manual.

> I am a big believer in doing things the way it is documented.  But in
> this case I am going to argue that the documentation was insufficient
> to the task.  Because I think this is simply a case of the
> documentation not sufficiently describing how emacs might be compiled
> and installed.  Basically all of the stuff that we normally see in the
> 'configure' script set of options.  Things get messy where theory
> meets practice and I can see the documentation trying to avoid getting
> into that mess.  But here it has caused a problem.

I've had a look at ./configure --help, and I don't think it documents
settings for `load-path'.  These paths are in src/epaths.h, which is
generated from src/epaths.in by (I think) ./configure.  I haven't yet
managed to find the precise mechanism which does this generation.

>> When I start emacs -Q, load-path contains the directories under
>> /usr/local/share/emacs/24.3/lisp together with
>> /usr/local/share/emacs/site-lisp.  So it would seem, for a standard build,
>> that .../site-lisp is the only safe place for site-start.el.

/usr/local/share/emacs is hard coded into src/epaths.in.

> You say "for a standard build" and I think that needs more
> clarification.  What is a standard build?  Let me jump ahead and
> assume this was your own compilation and that you did not supply any
> configure options at all.  (Since I think that is likely the case
> here.)  Then for you the "standard build" really meant a local
> compilation and installation using all of the default configure
> options.  Is that correct?

Yes.  But my personal build excludes some of the graphics libraries and
includes --with-gpm.

>> > In any case...  One could always put the customizations in that file.
>> > That is rather what is expected.  Or one could add a load statement
>> > there to load /usr/local/share/emacs/site-lisp/site-start.el if you
>> > want to keep the customizations there.  It is six of one or a half
>> > dozen of the other.
 
>> GRRR!!!  Yes, one can do any of these things, but only after having
>> discovered there's a problem which needs fixing, and diagnosing that
>> problem.  This cost me, perhaps, an hour or two back in 2005 when I
>> first installed Debian on a new PC, and my site-start.el wasn't loading.

> This is really uncovering a deeper layer of philosophical question.
> The question is how do you package software for distribution to a wide
> audience of people?  Where do you put it?  How do you do this while
> allowing people to compile and install their own software?  This is
> the question that must be answered in order to address your issue.

> A local compilation using the standard autotools and no configure
> options will root all of the paths in the /usr/local tree.  Programs
> will go in /usr/local/bin and so forth.  If that is the standard build
> then should a software distribution (pick any) compile their software
> using the same configure without any options and install in /usr/local
> and so be a "standard build"?  [No.  Please no.]

OK, point taken!  A distribution cannot build a "standard build" in that
sense, so I admit it's not all that appropriate a term.  Perhaps "vanilla
build" would be better.

> Instead we have a separation with system packaged paths in / and local
> user compiled paths in /usr/local.  We hold /usr/local inviolate
> against system intrusion.  And the reverse is almost the same.  We
> don't expect that if we compile and install to /usr/local that it will
> smash over system package managed files in /.

We've been talking here all the time about binaries, not configuration
files.

> Knowing this then if I am using a locally compiled program installed
> in /usr/local/bin and want to modify its configuration then I expect
> it to be configured in /usr/local somewhere usually /usr/local/etc but
> sometimes elsewhere.  If I am using a system package installed program
> in /bin (or /usr/bin) then I expect it to be configured somewhere in /
> usually /etc but sometimes elsewhere too but definitely not /usr/local.

You have a point here.  :-)  Where I take issue with the Debian maintainer
(of 2005) is in creating a content-free file /etc/emacs/site-start.el.
That couldn't help but cause problems with a common pre-existing seup.

> Bob

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: best gnu/linux distro for emacs

[Xue Fuqiao]

On Mon, 25 Mar 2013 01:00:42 +0000
wgreenhouse@riseup.net (W. Greenhouse) wrote:

> Xue Fuqiao <xfq.free@gmail.com> writes:
> >> > For now, what is the "best" distribution of GNU/Linux for running
> >> > emacs?

> >> The vital thing is less a question of distros and more a question of
> >> window manager/desktop environment, I think: avoid those which clobber
> >> important Emacs keybindings (e.g. M-TAB) and make it hard to
> >> reconfigure.

> > Right, many WM/DE block some keyboard inputs like `M-<TAB>', `M-<SPC>',
> > `C-M-d' and `C-M-l'.  And I think a lightweight WM/DE is preferred.
> > Because Emacs can do everything, it can take the place of most features
> > in a DE.

As for X window managers, I prefer Sawfish and StumpWM, since they are
highly extensible and customizable.

> > It's also a question of web browser.  For this question, I prefer
> > Conkeror, because it is mainly patterned after Emacs.

> > It's also a question of X toolkit.  For this question, I prefer
> > Gtk+, because it is the best toolkit supported by Emacs.

> Big +1 to Conkeror.

However, there are many problems in Conkeror.  No special facility for
configuring a proxy, cannot run many extensions (fully) and so on.  And
I often encounter segmentation faults when using Conkeror.

> However, I am not a big fan of the Gtk+ build of Emacs, because this
> choice of X toolkit for building Emacs introduces a big problem with
> respect to Emacs daemon reliability (loss of connection to the X
> server will now crash the daemon).  See the long-standing bug against
> Gtk+, https://bugs.launchpad.net/gtk/+bug/543611/comments/22.

I knew it.  I saw an message every time when I use `emacsclient -c -a ""' to invoke Emacs.

> If you like the Emacs GUI under X and you like using emacsclient/emacs
> --daemon, I recommend ./configure --with-x-toolkit=lucid or ./configure
> --with-x-toolkit=no as alternatives to using a Gtk+ build of Emacs.  X
> integration, including graphics and the ability to use Xft fonts, will
> not be affected; only the UI "widgets" such as scroll bars and toolbar
> buttons will change.  But you will be free from the threat of your
> daemon going down if there is some problem with X.

I don't use toolkits like Lucid and LessTif much, sorry.  There are many
features that Gtk+ has but these toolkits don't.

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Re: best gnu/linux distro for emacs

[Óscar Fuentes]

Xue Fuqiao <xfq.free@gmail.com> writes:

> I don't use toolkits like Lucid and LessTif much, sorry.  There are many
> features that Gtk+ has but these toolkits don't.

such as? ...

I'm using Lucid because the daemon problem with Gtk, but AFAIR, apart
from some eye-candy, Emacs+Lucid is not missing any feature (modern open
file dialog, maybe? but who needs that?)

Oh, and the Lucid scrollbars are an accurate indicator of the position
and extension of the current view over its respective buffer.

Re: best gnu/linux distro for emacs

[Peter Dyballa]

Am 25.03.2013 um 19:14 schrieb Óscar Fuentes:

> (modern open file dialog, maybe? but who needs that?)

And who needs the font chooser dialog? It takes eons to find what one is looking for…

--
Greetings

  Pete

No matter which way you ride, it's uphill and against the wind. 
				– First Law of Bicycling

Re: best gnu/linux distro for emacs

[W. Greenhouse]

Alan Mackenzie <acm-h9bWGtP8wOw@public.gmane.org> writes:

>> Knowing this then if I am using a locally compiled program installed
>> in /usr/local/bin and want to modify its configuration then I expect
>> it to be configured in /usr/local somewhere usually /usr/local/etc but
>> sometimes elsewhere.  If I am using a system package installed program
>> in /bin (or /usr/bin) then I expect it to be configured somewhere in /
>> usually /etc but sometimes elsewhere too but definitely not /usr/local.
>
> You have a point here.  :-)  Where I take issue with the Debian maintainer
> (of 2005) is in creating a content-free file /etc/emacs/site-start.el.
> That couldn't help but cause problems with a common pre-existing seup.

The situation re: config file locations for Emacs in Debian hasn't
changed.

FWIW--and this is not to contradict or doubt that you found it
frustrating the first time you were setting up Emacs in Debian, just a
point of info for anyone in similar difficulties--most of the
Debian-specific init for Emacs and Debian elisp packages is actually in
/etc/emacs/site-start.d/ not /etc/emacs/site-start.el.  The .el[c] files
there (non-recursive) are automatically run by the Debian-specific
function `debian-run-directories'.  The distro is guaranteed not to
overwrite any changes you make to the /etc/emacs/site-start.el; that's
free for you to use.

Best,
Will

-- 
BOFH excuse #149:

Dew on the telephone lines.

Re: best gnu/linux distro for emacs

[Xue Fuqiao]

On Mon, 25 Mar 2013 19:14:03 +0100
Óscar Fuentes <ofv@wanadoo.es> wrote:

> Xue Fuqiao <xfq.free@gmail.com> writes:
> > I don't use toolkits like Lucid and LessTif much, sorry.  There are many
> > features that Gtk+ has but these toolkits don't.

> such as? ...

Such as GTK theme, GTK font patterns, "file chooser" dialog and `:rtl'
property in tool-bar.  See also the variable `tool-bar-style' and the
frame parameter `tool-bar-position'.

Nevertheless, GTK builds also miss some features, such as the `tooltip'
face, the `-bd' command line option and `PORTION' in click events when
clicking on a scroll bar.

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Re: best gnu/linux distro for emacs

[Oleksandr Gavenko]

On 2013-03-25, W. Greenhouse wrote:

> Alan Mackenzie <acm@muc.de> writes:
>
>>> Knowing this then if I am using a locally compiled program installed
>>> in /usr/local/bin and want to modify its configuration then I expect
>>> it to be configured in /usr/local somewhere usually /usr/local/etc but
>>> sometimes elsewhere.  If I am using a system package installed program
>>> in /bin (or /usr/bin) then I expect it to be configured somewhere in /
>>> usually /etc but sometimes elsewhere too but definitely not /usr/local.
>>
>> You have a point here.  :-)  Where I take issue with the Debian maintainer
>> (of 2005) is in creating a content-free file /etc/emacs/site-start.el.
>> That couldn't help but cause problems with a common pre-existing seup.
>
> The situation re: config file locations for Emacs in Debian hasn't
> changed.
>
> FWIW--and this is not to contradict or doubt that you found it
> frustrating the first time you were setting up Emacs in Debian, just a
> point of info for anyone in similar difficulties--most of the
> Debian-specific init for Emacs and Debian elisp packages is actually in
> /etc/emacs/site-start.d/ not /etc/emacs/site-start.el.  The .el[c] files
> there (non-recursive) are automatically run by the Debian-specific
> function `debian-run-directories'.  The distro is guaranteed not to
> overwrite any changes you make to the /etc/emacs/site-start.el; that's
> free for you to use.
>
From /usr/share/doc/emacsen-common/debian-emacs-policy.gz (from
`emacsen-common` package):

  debian-startup, among other things, calls debian-run-directories.
  debian-run-directories collects the union of all the file base names
  (i.e. without any .el or .elc extension, and without the directory
  component: i.e. /etc/xemacs/site-start.d/50foo.elc => 50foo), then
  temporarily augments the emacs load path to include
  /etc/<flavor>/site-start.d and /etc/emacs/site-start.d in that
  order, and then calls (load base-name) in alphabetical order.

-- 
Best regards!

Re: best gnu/linux distro for emacs

[Bob Proulx]

Hi Alan,

Alan Mackenzie wrote:
> I've had a look at ./configure --help, and I don't think it documents
> settings for `load-path'.  These paths are in src/epaths.h, which is
> generated from src/epaths.in by (I think) ./configure.  I haven't yet
> managed to find the precise mechanism which does this generation.

Mostly I expect that configure without options will root in /usr/local
but that software distributions will add --prefix=/usr and root it
there in the system directories instead.  The actual list of configure
options that are needed are pretty long.  I count 28 used in the
Debian version.  Mostly needed for setting up cross-compilation for
the various architectures.  But a few like --preix and --libdir so as
to locate the files in the desired place not in /usr/local.  Without
looking I would assume that many of those paths will work into the
load-path.  But some are apparently hard coded as you found.  I don't
know.  I just know what I would expect.

> >> When I start emacs -Q, load-path contains the directories under
> >> /usr/local/share/emacs/24.3/lisp together with
> >> /usr/local/share/emacs/site-lisp.  So it would seem, for a standard build,
> >> that .../site-lisp is the only safe place for site-start.el.
> 
> /usr/local/share/emacs is hard coded into src/epaths.in.

Interesting.  I am not sure that shouldn't be --prefix based.  If that
is hard coded then it won't relocate easily.

> > A local compilation using the standard autotools and no configure
> > options will root all of the paths in the /usr/local tree.  Programs
> > will go in /usr/local/bin and so forth.  If that is the standard build
> > then should a software distribution (pick any) compile their software
> > using the same configure without any options and install in /usr/local
> > and so be a "standard build"?  [No.  Please no.]
> 
> OK, point taken!  A distribution cannot build a "standard build" in that
> sense, so I admit it's not all that appropriate a term.  Perhaps "vanilla
> build" would be better.

All good.  I was hoping we would be in agreement that a distribution
must add at least --prefix to configure and other options too so that
the result can be distributed and doesn't interfere with a local
compilation to /usr/local.  The two compilation configurations must be
different for at least some level or they will interfere.  The problem
lies in the right balance of everything.

For the most part I am pretty happy with Debian's packaging of emacs.
The unstable track stays pretty up to date with new versions as they
are released.  The stable track gets support as needed through the
lifecycle.  There is a rich variety of additions that I can simply
install and everything works.  Upgrades work simply and easily.

For the particular case of site-start.el I don't know.  By having the
packaged version in /etc/emacs it means that it keeps the system
version separate from a locally compiled version.  The two won't cross
unless a specific change is made to remove the /etc file.  They won't
use the same file unless something is done to make them use the same
file.  If that is done then the system emacs and a /usr/local locally
compiled version would share the same site-start.el file.  But if not
then they won't.

I don't know if that is the plan or just an accident.  But it seems
desirable to me.  I often turn people loose in /usr/local and say go
have fun and do whatever.  By design anything they do there won't
break something in /usr.  By default anyway.

Not everything on the system is that way.  For example Perl may have
additional modules installed in /usr/local and they will be pulled in
by default and may override the system ones.  Which is terribly
convenient!  But which plan is best?  I don't know.  There isn't one
canonical right for everything.

> > Instead we have a separation with system packaged paths in / and local
> > user compiled paths in /usr/local.  We hold /usr/local inviolate
> > against system intrusion.  And the reverse is almost the same.  We
> > don't expect that if we compile and install to /usr/local that it will
> > smash over system package managed files in /.
> 
> We've been talking here all the time about binaries, not configuration
> files.

Wait.  We started out talking about the site-start.el file.  That is a
configuration file.  Or at least a local file for whatever elisp you
put there.  But it is definitely not a binary.

> > Knowing this then if I am using a locally compiled program installed
> > in /usr/local/bin and want to modify its configuration then I expect
> > it to be configured in /usr/local somewhere usually /usr/local/etc but
> > sometimes elsewhere.  If I am using a system package installed program
> > in /bin (or /usr/bin) then I expect it to be configured somewhere in /
> > usually /etc but sometimes elsewhere too but definitely not /usr/local.
> 
> You have a point here.  :-)  Where I take issue with the Debian maintainer
> (of 2005) is in creating a content-free file /etc/emacs/site-start.el.
> That couldn't help but cause problems with a common pre-existing seup.

I don't know what the right answer is there.  But I would like to say
a few words about the problem in general for other packages.

Personally I agree with you that having a file with nothing but
comments is useless and undesirable.  I hate it.  If I never make a
change to it then all is okay.  I can upgrade the package and
(usually) that file will upgrade with the package.  But if I have made
local changes to the configuration file then upon upgrade I am
prompted to either select the package version or my version or to
merge the changes.  This is the Debian dpkg conffile system where
conffile changes are always preserved.  I know that rpm does things
differently.  (And I think less desirably.)

The package changes are almost always simply changes to the comments,
frequently flowing through from the upstream package.  Since I am
pedantic about such things I always take the fresh new version of the
configuration file and then redo my changes to it so that my copy is
as much in sync with the upstream as possible.  This is a manual
operation which is unneeded when the file is nothing but an empty
template of comments.  A drudgery.  And an unneeded one creating extra
work making it more annoying to me.

Whenever possible if a .d directory of config files is available then
I always make my customizations there in a uniquely named local file
that does not overlap with any packaged configuration file.  That way
the packaged configuration file is never edited.  This means that
upgrades can be fully hands-off.  It will upgrade and I won't ever
need to merge anything.

But since I read many of the bug lists for many of the packages I
frequently see users placing requests for package maintainers to
include an empty template file that has nothing but comments.  The
exchange usually goes like this.  User files a bug requesting a
template with all possible options commented.  Maintainer replies that
a full sample is available in /usr/share/doc/foo/example/foo.conf.
User responds that it is too much trouble for them to look there.
They won't know to look in the doc directory.  At least couldn't there
be a template that points to the full doc?  More discussion.  Back and
forth.  It is hard to argue against documentation.  Eventually the
maintainer relents and adds an empty template with nothing but
comments.

Time progresses and new packages roll through and the comments in the
original file have spelling errors that get fixed or other minor
stuff.  Perhaps new information is added.  Whatever.  The file is
updated.  Now upon upgrade I have to merge my local configuration with
the new version.  This happens with every upgrade.  I file a bug that
requests that the file be removed from the package.  But while it is
easy to add conffiles to a package it is quite a different thing to
remove them from it.  So it never happens.  And so the world becomes a
little bit worse to accommodate the naive user.  Sigh.

I have no idea if that is what has happened here or not.  But I have
seen it happen to other packages.

Bob

Re: best gnu/linux distro for emacs

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

() Alan Mackenzie <acm@muc.de>
() Mon, 25 Mar 2013 12:01:17 +0000 (UTC)

   /usr/local/share/emacs is hard coded into src/epaths.in.

However, there is special provision for src/epaths.h in the top-level
makefile (target ‘epaths-force’) to DTRT for ‘--prefix’ (et al).  See
also the "You might wonder" comment in configure.ac.

So for example, configuring w/ ‘--prefix ~/local’, you will never see
/usr/local dirs in ‘load-path’ unless you add them at runtime.

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]