23.0.60; Feature request: Menu item "load init files" after -q/-Q

23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Reiner Steib]

Hi,

when XEmacs is started with `--vanilla' or `-q', it displays an item
"Load init files" in the menu bar.  The name of the command in XEmacs
is `load-user-init-file'.

Maybe Emacs should do have something similar.  I'm not sure about
where to add it. Maybe a menu entry in the Options menu and a tool bar
button?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

RE: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Drew Adams]

> when XEmacs is started with `--vanilla' or `-q', it displays an item
> "Load init files" in the menu bar.  The name of the command in 
> XEmacs is `load-user-init-file'.
> 
> Maybe Emacs should do have something similar.  I'm not sure about
> where to add it. Maybe a menu entry in the Options menu and a tool 
> bar button?

How about the File menu? That's the first menu I'd look in for something like
this. The Options menu should be mainly about setting options.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Dan Nicolaescu]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

  > Hi,
  > 
  > when XEmacs is started with `--vanilla' or `-q', it displays an item
  > "Load init files" in the menu bar.  The name of the command in XEmacs
  > is `load-user-init-file'.
  > 
  > Maybe Emacs should do have something similar.  I'm not sure about
  > where to add it. Maybe a menu entry in the Options menu and a tool bar
  > button?

Why is this good?
IMHO it's just bloat: if someone uses "emacs -q", it's
quite intentional and probably knows enough about emacs to do 
M-x load-file ~/.emacs RET.
emacs -q is not something done very often, wanting to load .emacs when
using emacs -q is even less frequent.  So why bother providing a special
purpose facility for it?

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Date: Fri, 04 Apr 2008 16:00:29 +0200
> Cc: 
> 
> when XEmacs is started with `--vanilla' or `-q', it displays an item
> "Load init files" in the menu bar.  The name of the command in XEmacs
> is `load-user-init-file'.
> 
> Maybe Emacs should do have something similar.

If a non-trivial .emacs is loaded after Emacs starts, the effect might
be different from the same .emacs loaded at startup, due to the stage
of the startup sequence where .emacs is normally loaded.  This could
surprise users, unless we write a special load function that takes
care of these subtleties.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> From: Reiner Steib <reinersteib+gmane@imap.cc>
>> Date: Fri, 04 Apr 2008 16:00:29 +0200
>> Cc: 
>>
>> when XEmacs is started with `--vanilla' or `-q', it displays an item
>> "Load init files" in the menu bar.  The name of the command in XEmacs
>> is `load-user-init-file'.
>>
>> Maybe Emacs should do have something similar.
> 
> If a non-trivial .emacs is loaded after Emacs starts, the effect might
> be different from the same .emacs loaded at startup, due to the stage
> of the startup sequence where .emacs is normally loaded.  This could
> surprise users, unless we write a special load function that takes
> care of these subtleties.

But is not that an argument in favor of the menu item then?

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Eli Zaretskii]

> Date: Fri, 04 Apr 2008 20:03:59 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: Reiner Steib <Reiner.Steib@gmx.de>, emacs-pretest-bug@gnu.org
> 
> > If a non-trivial .emacs is loaded after Emacs starts, the effect might
> > be different from the same .emacs loaded at startup, due to the stage
> > of the startup sequence where .emacs is normally loaded.  This could
> > surprise users, unless we write a special load function that takes
> > care of these subtleties.
> 
> But is not that an argument in favor of the menu item then?

I don't see how what I wrote could be in favor or against the menu
item.

What I tried to say was that a simple (load "~/.emacs") is not what
this feature should do, whether from the menu bar or from some other
place.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Fri, 04 Apr 2008 20:03:59 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: Reiner Steib <Reiner.Steib@gmx.de>, emacs-pretest-bug@gnu.org
>>
>>> If a non-trivial .emacs is loaded after Emacs starts, the effect might
>>> be different from the same .emacs loaded at startup, due to the stage
>>> of the startup sequence where .emacs is normally loaded.  This could
>>> surprise users, unless we write a special load function that takes
>>> care of these subtleties.
>> But is not that an argument in favor of the menu item then?
> 
> I don't see how what I wrote could be in favor or against the menu
> item.
> 
> What I tried to say was that a simple (load "~/.emacs") is not what
> this feature should do, whether from the menu bar or from some other
> place.

Yes, that is what I meant. Maybe there should be a function doing what 
is required then. And placing that on the menu is rather natural then IMO.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stefan Monnier]

I just fail to see what problem this feature suggestion is trying
to solve.


        Stefan

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Davis Herring]

>> What I tried to say was that a simple (load "~/.emacs") is not what
>> this feature should do, whether from the menu bar or from some other
>> place.
>
> Yes, that is what I meant. Maybe there should be a function doing what
> is required then. And placing that on the menu is rather natural then IMO.

I take this "necessity" as an argument against the feature: making such a
delayed load have the same effects as the normal load would be
non-trivial, and any bugs in the emulation would lead to confusion.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > when XEmacs is started with `--vanilla' or `-q', it displays an item
 > > "Load init files" in the menu bar.  The name of the command in XEmacs
 > > is `load-user-init-file'.
 > > 
 > > Maybe Emacs should do have something similar.

The common use case for this feature is a user reports a bug, we ask
them to replicate with "xemacs -vanilla", and now they have error
messages and stuff in buffers.  So they hit the "Send Mail" menu item
and get the horrible default MUA when they were expecting Gnus or VM.

An "in-your-face" button makes it easy to get these users to a
semblance of sanity, where they can comfortably compose mail, copy
buffers, make attachments, etc, in the comfort of their home
customizations.

 > If a non-trivial .emacs is loaded after Emacs starts, the effect might
 > be different from the same .emacs loaded at startup, due to the stage
 > of the startup sequence where .emacs is normally loaded. This could
 > surprise users,

You're right about the logic, but I've never heard of such a problem in
10 years of reading XEmacs lists daily.

 > unless we write a special load function that takes care of these
 > subtleties.

In XEmacs, basically the only things that happen after loading the
init files are (1) defvar'ing the user's mail address to a computed
default, (2) putting text into the scratch buffer, and (3) running
after-init-hook (these are not necessarily in order, but they're
almost certainly independent).  (Note that "load-user-init-file" is a
misnomer in that default.el gets loaded too, unless the user
suppresses it.)

If the init files tromp on the mail address when loaded out of order,
that's almost surely a good thing.  Text in the scratch buffer is not
of interest here.  So to protect the user, all you really need to do
is warn them if after-init-hook is non-nil.

YMMV; Mike Sperber has done a full-body-replacement on our startup.el,
so I suspect the resemblence to any Emacs version is now nil.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Reiner Steib <Reiner.Steib@gmx.de>,
>     emacs-pretest-bug@gnu.org
> Date: Sun, 06 Apr 2008 03:46:17 +0900
> 
>  > If a non-trivial .emacs is loaded after Emacs starts, the effect might
>  > be different from the same .emacs loaded at startup, due to the stage
>  > of the startup sequence where .emacs is normally loaded. This could
>  > surprise users,
> 
> You're right about the logic, but I've never heard of such a problem in
> 10 years of reading XEmacs lists daily.
> 
>  > unless we write a special load function that takes care of these
>  > subtleties.
> 
> In XEmacs, basically the only things that happen after loading the
> init files are (1) defvar'ing the user's mail address to a computed
> default, (2) putting text into the scratch buffer, and (3) running
> after-init-hook (these are not necessarily in order, but they're
> almost certainly independent).  (Note that "load-user-init-file" is a
> misnomer in that default.el gets loaded too, unless the user
> suppresses it.)

I was more thinking about setting the various frame parameters
(including for the initial frame) and the various hooks the user could
set from .emacs, such as window-setup-hook, emacs-startup-hook, etc.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I was more thinking about setting the various frame parameters
 > (including for the initial frame) and the various hooks the user could
 > set from .emacs, such as window-setup-hook, emacs-startup-hook, etc.

Frame and window parameters aren't a problem, I think; the user is
going to know that the environment for those things is messed up.
Those other hooks I don't know about; the only one in XEmacs to my
knowledge is after-init-hook.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stefan Monnier]

>> > when XEmacs is started with `--vanilla' or `-q', it displays an item
>> > "Load init files" in the menu bar.  The name of the command in XEmacs
>> > is `load-user-init-file'.
>> > 
>> > Maybe Emacs should do have something similar.

> The common use case for this feature is a user reports a bug, we ask
> them to replicate with "xemacs -vanilla", and now they have error
> messages and stuff in buffers.  So they hit the "Send Mail" menu item
> and get the horrible default MUA when they were expecting Gnus or VM.

That's a good point.  We need to work harder to make sure that
`emacs -Q' either refuses to try and send mail (with an error that
explains that mail is not configured) or that does something
sufficiently safe that we're pretty sure it'll work.  It used to be that
running `sendmail' was good enough, but nowadays that sadly doesn't cut
it any more.

As for the default MUA itself, I think it's OK as long as it works.


        Stefan

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Stefan Monnier writes:

 > That's a good point.  We need to work harder to make sure that
 > `emacs -Q' either refuses to try and send mail (with an error that
 > explains that mail is not configured) or that does something

In XEmacs, `sendmail' is always configured.

 > sufficiently safe that we're pretty sure it'll work.  It used to be that
 > running `sendmail' was good enough, but nowadays that sadly doesn't cut
 > it any more.
 > 
 > As for the default MUA itself, I think it's OK as long as it works.

In XEmacs the default MUA is RMail[1] + sendmail.  IMHO in the modern
environment that is far from working for the kind of user this feature
is aimed at.


Footnotes: 
[1]  Note that I don't know what features recent RMail might have in
it, but lack of multipart/mixed and MIME attachment support is a
killer IMO, and it would seem from recent traffic that even recent
Emacs versions don't have those without add-ons like tm or SEMI.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stefan Monnier]

>> That's a good point.  We need to work harder to make sure that
>> `emacs -Q' either refuses to try and send mail (with an error that
>> explains that mail is not configured) or that does something

> In XEmacs, `sendmail' is always configured.

I'm not sure we're talking about the same thing.  The question is mostly
whether or not the message will reach its destination.  MUA frills like
support for MIME are quite secondary in comparison.


        Stefan

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> That's a good point.  We need to work harder to make sure that
 > >> `emacs -Q' either refuses to try and send mail (with an error that
 > >> explains that mail is not configured) or that does something
 > 
 > > In XEmacs, `sendmail' is always configured.
 > 
 > I'm not sure we're talking about the same thing.  The question is mostly
 > whether or not the message will reach its destination.  MUA frills like
 > support for MIME are quite secondary in comparison.

Oh, OK.  But either that's just as much a problem in plain `emacs' as
in `emacs -Q', or it will normally be fixed by loading the init files.
That's what confused me.

I think it may be good enough to condition-case the sending function,
and if it fails inform the user that the buffer may be saved with C-x
C-w and then sent in any way the user normally uses to send files by
mail.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stefan Monnier]

>> >> That's a good point.  We need to work harder to make sure that
>> >> `emacs -Q' either refuses to try and send mail (with an error that
>> >> explains that mail is not configured) or that does something
>> 
>> > In XEmacs, `sendmail' is always configured.
>> 
>> I'm not sure we're talking about the same thing.  The question is mostly
>> whether or not the message will reach its destination.  MUA frills like
>> support for MIME are quite secondary in comparison.

> Oh, OK.  But either that's just as much a problem in plain `emacs' as
> in `emacs -Q', or it will normally be fixed by loading the init files.
> That's what confused me.

But that's the issue: if sending mail works "reliably" from "emacs -Q"
there's no need for "load .emacs".

> I think it may be good enough to condition-case the sending function,
> and if it fails inform the user that the buffer may be saved with C-x
> C-w and then sent in any way the user normally uses to send files by
> mail.

The case when there's an error is the easy one.  The problem is when
sendmail accepts the mail and then silently drops it, sends it to
someone who'll drop it as "spam", or sends it to a black hole that
nobody will ever look at (e.g. a local mailbox).


        Stefan

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Stefan Monnier writes:

 > But that's the issue: if sending mail works "reliably" from "emacs -Q"
 > there's no need for "load .emacs".

That's your issue, which I agree is an issue, though I don't see how
you propose to address it via "load .emacs".  My issue is that I
wouldn't wish sendmail.el on my worst enemy, let alone an innocent
newbie, and most especially not on an innocent newbie who's gotten
used to message-mode.

 > The case when there's an error is the easy one.  The problem is when
 > sendmail accepts the mail and then silently drops it,

I don't see how we can detect that from Emacs, let alone prevent it.

 > sends it to someone who'll drop it as "spam",

PEBKAC, not solvable at our end AFAICS.

 > sends it to a black hole that nobody will ever look at (e.g. a
 > local mailbox).

PEBKAC, not solvable at our end AFAICS.

In both cases I claim are PEBKAC, the user should be using
report-emacs-bug (or whatever it may be called nowadays), which should
set up the To header correctly.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stefan Monnier]

>> But that's the issue: if sending mail works "reliably" from "emacs -Q"
>> there's no need for "load .emacs".

> That's your issue, which I agree is an issue, though I don't see how
> you propose to address it via "load .emacs".

You said: "it will normally be fixed by loading the init files".

>> The case when there's an error is the easy one.  The problem is when
>> sendmail accepts the mail and then silently drops it,
> I don't see how we can detect that from Emacs, let alone prevent it.

That's the problem.

>> sends it to someone who'll drop it as "spam",
> PEBKAC, not solvable at our end AFAICS.

Not PEBCAK at all.  Most machines nowadays which have /usr/sbin/sendmail
have it misconfigured in such a way that it may very well send it to the
right place, but the right place will drop it as "spam".
In case you wonder: yes I hate blacklists.

>> sends it to a black hole that nobody will ever look at (e.g. a
>> local mailbox).

> In both cases I claim are PEBKAC, the user should be using
> report-emacs-bug (or whatever it may be called nowadays), which should
> set up the To header correctly.

The problem is not the "To:" header.  It's the necessity to setup your
MTA so that it sends email through your ISP's SMTP server.  And you may
not even know your ISP and his SMTP server (e.g. in most hotpspots).
In many cases, the only reliable way for the user to send an email is
via a webmail application.


        Stefan

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> But that's the issue: if sending mail works "reliably" from "emacs -Q"
 > >> there's no need for "load .emacs".
 > 
 > > That's your issue, which I agree is an issue, though I don't see how
 > > you propose to address it via "load .emacs".
 > 
 > You said: "it will normally be fixed by loading the init files".

Please, don't be argumentative.  I'm just trying to explain why
communication broke down.  Obviously, when I write "it", "it" refers
to my issue, not yours.  The ambiguity is inherent, but I was unable
to see what you were talking about because I don't consider it an
Emacs issue to be solved in Emacs.

 > >> sends it to someone who'll drop it as "spam",
 > > PEBKAC, not solvable at our end AFAICS.
 > 
 > Not PEBCAK at all.  Most machines nowadays which have /usr/sbin/sendmail
 > have it misconfigured

OK, so it's a PEBMAKAC: Problem Existing Between Mail Admin's Keyboard
And Chair.  Still not something we can do anything about.

 > And you may not even know your ISP and his SMTP server (e.g. in
 > most hotpspots).

Speak for yourself; my SMTP server speaks TLS on a port not blocked by
my ISP's firewall. :-)  But of course that's unusual as yet.

 > In many cases, the only reliable way for the user
 > to send an email is via a webmail application.

In that case, what you really want is to simply disable bug reporting
by mail, and rewrite the whole system to directly inject the report
into debbugs via port 80.  (Note that this essentially takes us back
to the days of UUCP, but I guess we don't have much choice.)
Alternatively allow sufficiently smart users to register and use TLS.

However, I don't see what this has to do with the current situation
where we are discussing why it is useful to have a "Load init file"
button for "emacs -q" in an environment where newbies will be asked to
run that to debug, taking them out of their familar environment (which
may be massively customized in defaults.el, for all we know).

If you think that the only interesting customization is
`mail-user-agent' and you think that mail is essentially useless
nowadays, then just stamp this whole discussion "wontfix".  I consider
that a competitive advantage for XEmacs[1], and won't complain at all if
you do! ;-)

Footnotes: 
[1]  No trade secrets, I've already told you why.  Let he who channels
the users best win!

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stefan Monnier]

>> >> But that's the issue: if sending mail works "reliably" from "emacs -Q"
>> >> there's no need for "load .emacs".
>> 
>> > That's your issue, which I agree is an issue, though I don't see how
>> > you propose to address it via "load .emacs".
>> 
>> You said: "it will normally be fixed by loading the init files".

> Please, don't be argumentative.  I'm just trying to explain why
> communication broke down.  Obviously, when I write "it", "it" refers
> to my issue, not yours.  The ambiguity is inherent, but I was unable
> to see what you were talking about because I don't consider it an
> Emacs issue to be solved in Emacs.

Sorry, I did not intend to be argumentative.  The thread is just a bit
long and with many unrelated aspects mixed together.  As far as I can
tell the only interesting aspect of a "load .emacs" button is to setup
the mail system so that M-x report-emacs-bug works.  So it's the only
part of the thread that I'm focusing on.

>> >> sends it to someone who'll drop it as "spam",
>> > PEBKAC, not solvable at our end AFAICS.
>> Not PEBCAK at all.  Most machines nowadays which have /usr/sbin/sendmail
>> have it misconfigured
> OK, so it's a PEBMAKAC: Problem Existing Between Mail Admin's Keyboard
> And Chair.  Still not something we can do anything about.

Those broken machines have no such thing as a "Mail Admin".

>> In many cases, the only reliable way for the user
>> to send an email is via a webmail application.

> In that case, what you really want is to simply disable bug reporting
> by mail, and rewrite the whole system to directly inject the report
> into debbugs via port 80.

Yes, that's actually an attractive option (except that I don't think you
can report bugs to Debbugs via port 80, but we could let
emacsbugs.donarmstrong.com accept SMTP connections on a port that's open
on pretty much all firewalls).

> (Note that this essentially takes us back
> to the days of UUCP, but I guess we don't have much choice.)

Yes, it's a very sad affair.  SMTP is dying.


        Stefan

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> Sorry, I did not intend to be argumentative.  The thread is just a bit
> long and with many unrelated aspects mixed together.  As far as I can
> tell the only interesting aspect of a "load .emacs" button is to setup
> the mail system so that M-x report-emacs-bug works.  So it's the only
> part of the thread that I'm focusing on.


Just a question since I do not understand:

I told earlier that on w32 this works because the bug reporter falls 
back to using the system mail program (as an example this in my case 
Thunderbird). Why can't this be done on other systems as well today?

Default of send-mail-function (was: 23.0.60; Feature request: Menu item "load init files" after -q/-Q)

[Reiner Steib]

[ Shifting this to emacs-devel ]

On Mon, Apr 07 2008, Lennart Borgman (gmail) wrote:

> Just a question since I do not understand:
>
> I told earlier that on w32 this works because the bug reporter falls
> back to using the system mail program (as an example this in my case
> Thunderbird). Why can't this be done on other systems as well today?

On GNU/Linux, send-mail-function typically defaults to
send-mail-function. [1] I.e. the mail is feed to /usr/sbin/sendmail.
/usr/sbin/sendmail typically exist on every GNU/Linux systems, however
on today's end-user desktops, it's quite likely that it has not have
been configured correctly.

On system-type darwin and windows-nt, send-mail-function defaults to
mailclient-send-it which passes the mail to "the system's mail client"
via a mailto-URL.  If we would use this on gnu/linux as well, it would
pass the mail to browse-url-browser-function, which is the first one
installed on the system out of: gnome-moz-remote, mozilla (this should
be moved down the list and be replace by seamonkey, IMHO), firefox,
galeon (is galeon still alive?), kfmclient (KDE), etc.  Now it depends
on whether this *browser* handles mailto-URLs in a sensible way.
[I hope I understood the code correctly. If not, please correct me.]

One might argue that this is better then relying on
/usr/sbin/sendmail.  I'd tend to agree.

Bye, Reiner.

[1] Gnus' message.el tries a bit harder to ensure /usr/sbin/sendmail
    exist.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Default of send-mail-function

[Lennart Borgman (gmail)]

Reiner Steib wrote:
> [ Shifting this to emacs-devel ]
> 
> On Mon, Apr 07 2008, Lennart Borgman (gmail) wrote:
> 
>> Just a question since I do not understand:
>>
>> I told earlier that on w32 this works because the bug reporter falls
>> back to using the system mail program (as an example this in my case
>> Thunderbird). Why can't this be done on other systems as well today?
> 
> On GNU/Linux, send-mail-function typically defaults to
> send-mail-function. [1] I.e. the mail is feed to /usr/sbin/sendmail.
> /usr/sbin/sendmail typically exist on every GNU/Linux systems, however
> on today's end-user desktops, it's quite likely that it has not have
> been configured correctly.
> 
> On system-type darwin and windows-nt, send-mail-function defaults to
> mailclient-send-it which passes the mail to "the system's mail client"
> via a mailto-URL.  If we would use this on gnu/linux as well, it would
> pass the mail to browse-url-browser-function, which is the first one
> installed on the system out of: gnome-moz-remote, mozilla (this should
> be moved down the list and be replace by seamonkey, IMHO), firefox,
> galeon (is galeon still alive?), kfmclient (KDE), etc.  Now it depends
> on whether this *browser* handles mailto-URLs in a sensible way.
> [I hope I understood the code correctly. If not, please correct me.]

Thanks Reiner. On w32 it is however the system that decide which program 
to use. Emacs calls this with w32-shell-execute.

Is there not something similar on GNU/Linux?

> One might argue that this is better then relying on
> /usr/sbin/sendmail.  I'd tend to agree.
> 
> Bye, Reiner.
> 
> [1] Gnus' message.el tries a bit harder to ensure /usr/sbin/sendmail
>     exist.

Re: Default of send-mail-function

[Reiner Steib]

On Mon, Apr 07 2008, Lennart Borgman (gmail) wrote:

> Reiner Steib wrote:
>> On system-type darwin and windows-nt, send-mail-function defaults to
>> mailclient-send-it which passes the mail to "the system's mail client"
>> via a mailto-URL.  If we would use this on gnu/linux as well, it would
>> pass the mail to browse-url-browser-function, [...].  Now it depends
>> on whether this *browser* handles mailto-URLs in a sensible way.
>> [I hope I understood the code correctly. If not, please correct me.]
>
> Thanks Reiner. On w32 it is however the system that decide which program to
> use. Emacs calls this with w32-shell-execute.
>
> Is there not something similar on GNU/Linux?

IIRC, the "big" desktop environments (Gnome[1], KDE) also have
something like a system mail handler.  Maybe
http://www.freedesktop.org/ specifies some standard way.

Bye, Reiner.

[1] I use fluxbox (i.e. a simple window manager, no desktop
    environment), but Firefox (a GTK application) uses the setting
    from Gnome.  I.i. the handler specified in
    `~/.gconf/desktop/gnome/url-handlers/mailto/%gconf.xml'.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Default of send-mail-function

[Jason Rumney]

Reiner Steib wrote:
> IIRC, the "big" desktop environments (Gnome[1], KDE) also have
> something like a system mail handler.  Maybe
> http://www.freedesktop.org/ specifies some standard way.
>   

On Gnome, we could use gconftool -g 
/desktop/gnome/url-handlers/mailto/command
We'd probably also want to check 
/desktop/gnome/url-handlers/mailto/enabled to ensure it is enabled.

If this information is available via dbus, that might be a better way of 
getting it.

Re: Default of send-mail-function

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote:
> Reiner Steib wrote:
>> [ Shifting this to emacs-devel ]
>>
>> On Mon, Apr 07 2008, Lennart Borgman (gmail) wrote:
>>
>>> Just a question since I do not understand:
>>>
>>> I told earlier that on w32 this works because the bug reporter falls
>>> back to using the system mail program (as an example this in my case
>>> Thunderbird). Why can't this be done on other systems as well today?
>>
>> On GNU/Linux, send-mail-function typically defaults to
>> send-mail-function. [1] I.e. the mail is feed to /usr/sbin/sendmail.
>> /usr/sbin/sendmail typically exist on every GNU/Linux systems, however
>> on today's end-user desktops, it's quite likely that it has not have
>> been configured correctly.
>>

> Is there not something similar on GNU/Linux?


On vaguely recent desktops following freedesktop.org ,
"xdg-email" should be a command that will open and populate a new mail
in the user's "preferred email composer".

xdg-email --subject foo --body bar address@example.com

Emacs presumably could/should try to use that on gnu/linux...

http://portland.freedesktop.org/wiki/XdgUtils
http://portland.freedesktop.org/wiki/EmailConfig

Re: Default of send-mail-function

[Jason Rumney]

David De La Harpe Golden wrote:
> On vaguely recent desktops following freedesktop.org ,
> "xdg-email" should be a command that will open and populate a new mail
> in the user's "preferred email composer".
>
> xdg-email --subject foo --body bar address@example.com
>
> Emacs presumably could/should try to use that on gnu/linux...
>
> http://portland.freedesktop.org/wiki/XdgUtils
> http://portland.freedesktop.org/wiki/EmailConfig
>   

How about a new `unconfigured-send-it', for use as the default 
`send-mail-function', which checks for the existence of xdg-email, and 
uses it if found. If not available, it could fall back on 
`sendmail-send-it'. Alternately we could modify `mailclient-send-it' to 
use xdg-email when it exists rather than browse-url (which will only 
work if browse-url-browser-function is set to an external program that 
recognizes mailto: URLs).

Re: Default of send-mail-function

[Manoj Srivastava]

On Tue, 08 Apr 2008 09:24:57 +0100, Jason Rumney <jasonr@gnu.org> said: 

> David De La Harpe Golden wrote:
>> On vaguely recent desktops following freedesktop.org , "xdg-email"
>> should be a command that will open and populate a new mail in the
>> user's "preferred email composer".
>> 
>> xdg-email --subject foo --body bar address@example.com
>> 
>> Emacs presumably could/should try to use that on gnu/linux...
>> 
>> http://portland.freedesktop.org/wiki/XdgUtils> http://portland.freedesktop.org/wiki/EmailConfig>   

> How about a new `unconfigured-send-it', for use as the default
> send-mail-function', which checks for the existence of xdg-email, and
> uses it if found. If not available, it could fall back on
> sendmail-send-it'. Alternately we could modify `mailclient-send-it' to
> use xdg-email when it exists rather than browse-url (which will only
> work if browse-url-browser-function is set to an external program that
> recognizes mailto: URLs).

        I have xdg-email configured to use this as the preferred mail
 client:
--8<---------------cut here---------------start------------->8---
  emacsclient -s gnus -c \
    -e "(progn (gnus-url-mailto \"$url\") (set-buffer-modified-p nil))"
--8<---------------cut here---------------end--------------->8---

        Would your proposal not result in a loop?

        manoj
-- 
The difference between legal separation and divorce is that legal
separation gives the man time to hide his money.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Default of send-mail-function

[Jason Rumney]

Manoj Srivastava wrote:
> On Tue, 08 Apr 2008 09:24:57 +0100, Jason Rumney <jasonr@gnu.org> said: 
>
>   
>> David De La Harpe Golden wrote:
>>     
>>> On vaguely recent desktops following freedesktop.org , "xdg-email"
>>> should be a command that will open and populate a new mail in the
>>> user's "preferred email composer".
>>>
>>> xdg-email --subject foo --body bar address@example.com
>>>
>>> Emacs presumably could/should try to use that on gnu/linux...
>>>
>>> http://portland.freedesktop.org/wiki/XdgUtils> http://portland.freedesktop.org/wiki/EmailConfig>   
>>>       
>
>   
>> How about a new `unconfigured-send-it', for use as the default
>> send-mail-function', which checks for the existence of xdg-email, and
>> uses it if found. If not available, it could fall back on
>> sendmail-send-it'. Alternately we could modify `mailclient-send-it' to
>> use xdg-email when it exists rather than browse-url (which will only
>> work if browse-url-browser-function is set to an external program that
>> recognizes mailto: URLs).
>>     
>
>         I have xdg-email configured to use this as the preferred mail
>  client:
> --8<---------------cut here---------------start------------->8---
>   emacsclient -s gnus -c \
>     -e "(progn (gnus-url-mailto \"$url\") (set-buffer-modified-p nil))"
> --8<---------------cut here---------------end--------------->8---
>
>         Would your proposal not result in a loop?
>   

Yes, that can currently happen with the default on Windows and Mac too. 
But the fact that obviously experienced users who have set Emacs as 
their default mail client end up with a loop if they don't change the 
default configuration should not prevent us from making a change that 
benefits less experienced users who currently experience a broken mail 
configuration and may not have the knowledge to configure their way out 
of it.

Re: Default of send-mail-function

[Manoj Srivastava]

On Tue, 08 Apr 2008 12:50:49 +0100, Jason Rumney <jasonr@gnu.org> said: 


> Yes, that can currently happen with the default on Windows and Mac
> too. But the fact that obviously experienced users who have set Emacs
> as their default mail client end up with a loop if they don't change
> the default configuration should not prevent us from making a change
> that benefits less experienced users who currently experience a broken
> mail configuration and may not have the knowledge to configure their
> way out of it.

        I am not sure that this is th case, xdg-email is as likely to be
 broken as anything else. Indeed, on Debian, when the sysadmin installs
 a MTA, and sets it up correctly, _every_ user on the system has a
 working email. If xdg-email defaults to thunderbird; then every user
 has to set it up correctly, which they  might not have expertise to do.

        At my last install of a Debian system, I recall being asked how
 to set up my MTA -- and local delivery was only one of five options.

        These decisions we are making do not come at no cost. Right now,
 emacs works out of the box with no user setup for sending email on the
 corporate debian boxes at my place of work; this change would mean
 every single user will have to customize emacs on every single box at
 work.

        I would find that degrades the quality of implementation for
 emacs.  How are we so sure that I am in the minority here?

        manoj
-- 
"Sour, sweet, bitter, pungent, all must be tasted." -Chinese Proverb
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Default of send-mail-function

[Lennart Borgman (gmail)]

Manoj Srivastava wrote:
> On Tue, 08 Apr 2008 12:50:49 +0100, Jason Rumney <jasonr@gnu.org> said: 
> 
> 
>> Yes, that can currently happen with the default on Windows and Mac
>> too. But the fact that obviously experienced users who have set Emacs
>> as their default mail client end up with a loop if they don't change
>> the default configuration should not prevent us from making a change
>> that benefits less experienced users who currently experience a broken
>> mail configuration and may not have the knowledge to configure their
>> way out of it.
> 
>         I am not sure that this is th case, xdg-email is as likely to be
>  broken as anything else. Indeed, on Debian, when the sysadmin installs
>  a MTA, and sets it up correctly, _every_ user on the system has a
>  working email. If xdg-email defaults to thunderbird; then every user
>  has to set it up correctly, which they  might not have expertise to do.
> 
>         At my last install of a Debian system, I recall being asked how
>  to set up my MTA -- and local delivery was only one of five options.
> 
>         These decisions we are making do not come at no cost. Right now,
>  emacs works out of the box with no user setup for sending email on the
>  corporate debian boxes at my place of work; this change would mean
>  every single user will have to customize emacs on every single box at
>  work.
> 
>         I would find that degrades the quality of implementation for
>  emacs.  How are we so sure that I am in the minority here?

Don't now, but a little table might grow to help us:

* w32: system default mail most likely to work
* mac: system default mail most likely to work
* GNU/Linux
   - debian: manoj, please help me fill in this. Desktop? Other?
   - ubuntu: I guess system default mail, but other knows better than me

Re: Default of send-mail-function

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> * GNU/Linux
>   - debian: manoj, please help me fill in this. Desktop? Other?
>   - ubuntu: I guess system default mail, but other knows better than me

I don't think its as simple as which distribution you use. It depends on 
whether you choose to install a full mail server (which may be part of 
the defaults on some distributions, or it may depend on choices made at 
install time), and it depends on whether that server is configured 
correctly.
Manoj is right - in multi-user environments with a qualified 
administrator looking after the machines, sendmail is going to be less 
problematic than expecting all users to set up their mail client. But 
increasingly GNU/Linux is being used in single user desktop environments.

Re: Default of send-mail-function

[Manoj Srivastava]

On Tue, 08 Apr 2008 16:15:23 +0100, Jason Rumney <jasonr@gnu.org> said: 

> Lennart Borgman (gmail) wrote:
>> * GNU/Linux
>> - debian: manoj, please help me fill in this. Desktop? Other?
>> - ubuntu: I guess system default mail, but other knows better than me

> I don't think its as simple as which distribution you use. It depends
> on whether you choose to install a full mail server (which may be part
> of the defaults on some distributions, or it may depend on choices
> made at install time), and it depends on whether that server is
> configured correctly.  Manoj is right - in multi-user environments
> with a qualified administrator looking after the machines, sendmail is
> going to be less problematic than expecting all users to set up their
> mail client. But increasingly GNU/Linux is being used in single user
> desktop environments.

        Fair enough. But at least in Debian, 
Package: exim4
Priority: standard
Description: meta-package to ease Exim MTA (v4) installation
Depends: ..., exim4-daemon-light | exim4-daemon-heavy | exim4-daemon-custom

        So the default install would instal exim4-daemon-light,  an
 MTA -- and installation time configuration leads the user through basic
 setup. Choices are:
 1. internet site; mail is sent and received directly using SMTP,
 2. mail sent by smarthost; received via SMTP or fetchmail,
 3. mail sent by smarthost; no local mail,
 4. local delivery only; not on a network,
 5. no configuration at this time

        I suspect a lot of single user machines are using the first 3
 choices; but I have no data to back up my suspicion.

        manoj
-- 
There is more to life than increasing its speed. Mahatma Gandhi
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Default of send-mail-function

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Manoj Srivastava wrote:
>>         I have xdg-email configured to use this as the preferred mail
>>  client:
>> --8<---------------cut here---------------start------------->8---
>>   emacsclient -s gnus -c \
>>     -e "(progn (gnus-url-mailto \"$url\") (set-buffer-modified-p nil))"
>> --8<---------------cut here---------------end--------------->8---
>>
>>         Would your proposal not result in a loop?
>>   
> 
> Yes, that can currently happen with the default on Windows and Mac too. 
> But the fact that obviously experienced users who have set Emacs as 
> their default mail client end up with a loop if they don't change the 
> default configuration should not prevent us from making a change that 
> benefits less experienced users who currently experience a broken mail 
> configuration and may not have the knowledge to configure their way out 
> of it.


Ask the user whether to use the system default mail program?

Re: Default of send-mail-function (was: 23.0.60; Feature request: Menu item "load init files" after -q/-Q)

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Date: Mon, 07 Apr 2008 23:05:49 +0200
> Cc: emacs-devel@gnu.org
> 
> On GNU/Linux, send-mail-function typically defaults to
> send-mail-function. [1] I.e. the mail is feed to /usr/sbin/sendmail.
> /usr/sbin/sendmail typically exist on every GNU/Linux systems, however
> on today's end-user desktops, it's quite likely that it has not have
> been configured correctly.
> 
> On system-type darwin and windows-nt, send-mail-function defaults to
> mailclient-send-it which passes the mail to "the system's mail client"
> via a mailto-URL.

But it's not guaranteed that "the system's mail client" on Windows is
configured correctly, either.  You need at the very least to tell it
the name or address of your ISP's mail server; that isn't automatic.

For example, at home I have 4 users on an XP machine, only one of
which is configured to send and receive email via the standard Windows
mail client.  Another user (me) uses Emacs and smtp-mail (which also
needs a 3-line setup), and the other 2 users cannot send mail at all,
because the mail client wasn't set up for their accounts.

So I don't see how a Windows box is so very different from a GNU/Linux
system.  It needs email setup as well.

Re: Default of send-mail-function

[Reiner Steib]

On Mon, Apr 07 2008, Eli Zaretskii wrote:

>> From: Reiner Steib <reinersteib+gmane@imap.cc>
[...]
>> /usr/sbin/sendmail typically exist on every GNU/Linux systems, however
>> on today's end-user desktops, it's quite likely that it has not have
>> been configured correctly.
>> 
>> On system-type darwin and windows-nt, send-mail-function defaults to
>> mailclient-send-it which passes the mail to "the system's mail client"
>> via a mailto-URL.
>
> But it's not guaranteed that "the system's mail client" on Windows is
> configured correctly, either.  You need at the very least to tell it
> the name or address of your ISP's mail server; that isn't automatic.

Sure.

> So I don't see how a Windows box is so very different from a GNU/Linux
> system.  It needs email setup as well.

The main difference WRT send-mail-function is that it is extremely
unlikely to find a functional /usr/sbin/sendmail on Windows systems.
If people think that it is more likely to find a functional mailto-URL
handler also on GNU/Linux, we can discuss if Emacs should follow "the
tyranny of numbers" (as Manoj calls it).

I don't have a very strong opinion about it (that's why I wrote "One
might argue [...].  I'd tend to agree").

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Default of send-mail-function

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Cc: lennart borgman <lennart.borgman@gmail.com>, emacs-devel@gnu.org
> Date: Tue, 08 Apr 2008 00:20:49 +0200
> 
> > So I don't see how a Windows box is so very different from a GNU/Linux
> > system.  It needs email setup as well.
> 
> The main difference WRT send-mail-function is that it is extremely
> unlikely to find a functional /usr/sbin/sendmail on Windows systems.

I was not arguing about that, surely.  I thought people were saying
that the Windows defaults somehow magically solve the problem that
GNU/Linux defaults cannot, which I thought was at least inaccurate if
not plain wrong.

Re: Default of send-mail-function

[Manoj Srivastava]

On Mon, 07 Apr 2008 23:05:49 +0200, Reiner Steib
<reinersteib+gmane@imap.cc> said:  

> One might argue that this is better then relying on
> /usr/sbin/sendmail.  I'd tend to agree.

        It depends.  On most of my machines where I use emacs, and even
 resting those on which I use gnus, mail is always configured in order
 for various system processes to send reports out (like cron).  Most of
 these machines I do not have an http client installed, since my usage
 pattern differs.

        If I may put in my 2 cents as a user, I am not thrilled at what
 I perceive to be a current trend (in Debian, and now in emacs) to
 favour novice users at the expense of loyal old timers, and often the
 response given to me in Debian is that the tyranny of numbers leads to
 setting defaults that are less useful to people not coming into the
 fold from windows. The CUA and tmm discussions recently seem to
 reinforce this perception.

        While I have been using Emacs as my preferred editor since 1987,
 I am not a computer science graduate, nor have I any formal training in
 computers or lisp, so the argument that "expert" user can diagnose and
 fix behaviors they do not like fails to convince me; my reaction to the
 functionp/symbolp change was to remove developmental software I was
 helping to test.

        Sorry for the rant. I'll go back to lurking silently now.

        manoj
-- 
These PRESERVES should be FORCE-FED to PENTAGON OFFICIALS!!
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stefan Monnier]

>> Sorry, I did not intend to be argumentative.  The thread is just a bit
>> long and with many unrelated aspects mixed together.  As far as I can
>> tell the only interesting aspect of a "load .emacs" button is to setup
>> the mail system so that M-x report-emacs-bug works.  So it's the only
>> part of the thread that I'm focusing on.

> Just a question since I do not understand:

> I told earlier that on w32 this works because the bug reporter falls back to
> using the system mail program (as an example this in my case
> Thunderbird). Why can't this be done on other systems as well today?

Maybe this can be done, but AFAICT this hasn't been done yet.  I'm not
sure if there is such a thing as "the system mail program" under unix.
It used to be that `sendmail' did just that (tho it only took care of
sending the mail), but it can't be relied upon nowadays thanks to the
braindead measures taken against spam.


        Stefan

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Lennart Borgman (gmail) writes:

 > I told earlier that on w32 this works because the bug reporter falls 
 > back to using the system mail program (as an example this in my case 
 > Thunderbird). Why can't this be done on other systems as well today?

Primarily because Windows workstations don't provide a mail server,
and so if you use mail at all you must configure your mail client to
send and receive via an external server, typically managed by
professionals in a for-pay service such as your employer or an ISP.
If you do not have an ISP, your mail will normally fail in a rather
obvious way.  Ie, mail works, or you know that it didn't, and you'll
try something else.

Free OSes *do* usually provide mail servers, and configure clients to
communicate with the local mail server.  This includes clients like
Thunderbird that on Windows you would expect to configure to use a
smart host.  On the other hand, it's not so easy to use webmail
services like Gmail as batch mailers (which is what report-emacs-bug
expects), so as far as I know report-emacs-bug doesn't even try to use
those.

In the past (not so distant, either), the default configuration of a
free OS as a non-relaying Internet mail host worked quite well.
Today, however, these hosts typically are subject to spam filtering
and firewalling for various reasons.  You can no longer expect to
receive notice of problems with your mail service unless you have set
it up quite carefully.  In fact, it is quite common for messages to
disappear silently into a black hole.  However, since mail still works
fairly well most of the time even if misconfigured, many users make
the dubious choice (or simply accept a partially functional default)
of providing their own mail transfer service, rather than using a
smart host provided by qualified mail administrators.

HTH

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Jason Rumney]

Stephen J. Turnbull wrote:

> Free OSes *do* usually provide mail servers, and configure clients to
> communicate with the local mail server.

In my experience, the desktop oriented distributions often have a 
default configuration that includes only local mail delivery (for cron 
etc), and expect you to configure your mail client for your ISP's smtp 
and pop/imap servers just like on Windows.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Stephen J. Turnbull]

Stefan Monnier writes:

 > As far as I can tell the only interesting aspect of a "load .emacs"
 > button is to setup the mail system so that M-x report-emacs-bug
 > works.  So it's the only part of the thread that I'm focusing on.

OK.  FWIW, I and other XEmacs users do find having that button there
useful occasionally.  But of course .emacs can be empty, so loading it
cannot be asked to do anything reliably -- except make the user more
comfortable.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>>> when XEmacs is started with `--vanilla' or `-q', it displays an item
>>>> "Load init files" in the menu bar.  The name of the command in XEmacs
>>>> is `load-user-init-file'.
>>>>
>>>> Maybe Emacs should do have something similar.
> 
>> The common use case for this feature is a user reports a bug, we ask
>> them to replicate with "xemacs -vanilla", and now they have error
>> messages and stuff in buffers.  So they hit the "Send Mail" menu item
>> and get the horrible default MUA when they were expecting Gnus or VM.
> 
> That's a good point.  We need to work harder to make sure that
> `emacs -Q' either refuses to try and send mail (with an error that
> explains that mail is not configured) or that does something
> sufficiently safe that we're pretty sure it'll work.  It used to be that
> running `sendmail' was good enough, but nowadays that sadly doesn't cut
> it any more.
> 
> As for the default MUA itself, I think it's OK as long as it works.


On w32 the default system mail program is used in this case and it works 
quite good IMO.

Re: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Chong Yidong]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> when XEmacs is started with `--vanilla' or `-q', it displays an item
> "Load init files" in the menu bar.  The name of the command in XEmacs
> is `load-user-init-file'.
>
> Maybe Emacs should do have something similar.  I'm not sure about
> where to add it. Maybe a menu entry in the Options menu and a tool bar
> button?

How about the startup screen?  It can replace the Customize Startup
button for `-q' startups.

bug#108: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Lars Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> when XEmacs is started with `--vanilla' or `-q', it displays an item
> "Load init files" in the menu bar.  The name of the command in XEmacs
> is `load-user-init-file'.
>
> Maybe Emacs should do have something similar.  I'm not sure about
> where to add it. Maybe a menu entry in the Options menu and a tool bar
> button?

Hm...  I'm not quite sure what the use case here is.  I mean, if you say
"-q" or "-Q", it's because you want an Emacs without any
customisations.  So why would you then load ~/.emacs?

Hm...  OK...  I could see that it could help with debugging the init
file, for instance.  You'd (setq debug-on-error t) or whatever and then
hit the load button.  But...  if you're doing that, you're probably
better off just `M-x eval-buffer' in ~/.emacs.

So I'm not sure.  Anybody got an opinion?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#108: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 30 Sep 2019 07:54:14 +0200
> Cc: Reiner Steib <Reiner.Steib@gmx.de>
> 
> Reiner Steib <reinersteib+gmane@imap.cc> writes:
> 
> > when XEmacs is started with `--vanilla' or `-q', it displays an item
> > "Load init files" in the menu bar.  The name of the command in XEmacs
> > is `load-user-init-file'.
> >
> > Maybe Emacs should do have something similar.  I'm not sure about
> > where to add it. Maybe a menu entry in the Options menu and a tool bar
> > button?
> 
> Hm...  I'm not quite sure what the use case here is.  I mean, if you say
> "-q" or "-Q", it's because you want an Emacs without any
> customisations.  So why would you then load ~/.emacs?
> 
> Hm...  OK...  I could see that it could help with debugging the init
> file, for instance.  You'd (setq debug-on-error t) or whatever and then
> hit the load button.  But...  if you're doing that, you're probably
> better off just `M-x eval-buffer' in ~/.emacs.
> 
> So I'm not sure.  Anybody got an opinion?

I can only contribute a caveat: loading (via 'load') of init files
from within a running Emacs session will not 100% reproduce what
happens when those init files are loaded during startup, so if the
purpose is to allow debugging those files, loading them from Emacs
might not recreate the problems one wants to debug.

OTOH, I thought we already have some means of debugging the init
files, no?

bug#108: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

> OTOH, I thought we already have some means of debugging the init
> files, no?

Such as --debug-init?

-- 
Basil

bug#108: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  108@debbugs.gnu.org,
>   Reiner.Steib@gmx.de
> Date: Mon, 30 Sep 2019 14:20:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OTOH, I thought we already have some means of debugging the init
> > files, no?
> 
> Such as --debug-init?

Among others, yes.

bug#108: 23.0.60; Feature request: Menu item "load init files" after -q/-Q

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > OTOH, I thought we already have some means of debugging the init
>> > files, no?
>> 
>> Such as --debug-init?
>
> Among others, yes.

I think the general consensus here is that this doesn't sound like a
very useful feature, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no