bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Drew Adams]

Enhancement request.

1. Be able to specify the output directory for *.elc files to
`byte-compile-file'.  See this emacs.SE question:
http://emacs.stackexchange.com/q/13596/105.

This could be done by adding an optional arg, but to let users take
advantage of it interactively the current prefix-arg behavior would need
to be split.  E.g., numeric value <= 0 could mean prompt for the output
dir; numeric value >= 0 could mean also load the byte-compiled file.

That would not hurt any existing code that passed a non-nil and
non-numeric second arg.

Another possibility would be to define another command for this, e.g.,
`byte-compile-file-to-directory'.

2. Let commands such as `dired-do-byte-compile' (hence function
`dired-byte-compile') support this also, e.g. by a particular prefix-arg
value that does not conflict (much) with the current prefix-arg
behavior.  For example, plain `C-u' - a user can still use `M-4' to get
the current `C-u' behavior.

3. In addition, maybe provide a way (e.g. option) for users to specify a
default value for the directory.  #1 and #2 would provide this as the
default when you are asked to specify the output dir.
        

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2015-05-29 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/mingw32 --host=i686-pc-mingw32
 --enable-checking=yes,glyphs'

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Glenn Morris]

> Enhancement request.
>
> 1. Be able to specify the output directory for *.elc files to
> `byte-compile-file'.  See this emacs.SE question:
> http://emacs.stackexchange.com/q/13596/105.

This request doesn't make a lot of sense to me (I feel like saying this
for many of these "here's a forward of a thing I read on Stack-foo"),
because Emacs expects .el and .elc to live in the same place.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Drew Adams]

> > Enhancement request.
> >
> > 1. Be able to specify the output directory for *.elc files to
> > `byte-compile-file'.  See this emacs.SE question:
> > http://emacs.stackexchange.com/q/13596/105.
> 
> This request doesn't make a lot of sense to me (I feel like saying
> this for many of these "here's a forward of a thing I read on Stack-
> foo"), because Emacs expects .el and .elc to live in the same place.

I don't necessarily disagree with the first part.  I won't be
using this feature myself, in any case.

Emacs expects .el and .elc to be in the same place only in the
general sense of providing for that and of being written from
the point of view that that is what users will likely do: put
them in the same place.

Emacs expects this only because that's all it's ever known.
That's what an enhancement request is about: teaching Emacs
something new.

Emacs does not "expect" it in the sense of requiring it, AFAIK.
Even now a user could put *.el and *.elc in different dirs, and
put both dirs in `load-path' (in whichever order).

Anyway, I won't argue strongly for this, but I also don't (yet)
see it as something undesirable or unsurmountable.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Date: Thu, 2 Jul 2015 16:51:04 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> I don't necessarily disagree with the first part.  I won't be
> using this feature myself, in any case.

Who will?

> Anyway, I won't argue strongly for this, but I also don't (yet)
> see it as something undesirable or unsurmountable.

What would be the reason for providing such a feature?  (Yes, I've
read that discussion; no, I don't see why the user wanted this.)

If you dwell a lot on those sites, how about encouraging people to use
the Emacs forums, where they will get definitive answers, instead of
talking to random people (present company excluded) on Stack-foo?  I
cannot for the life of me figure out why these sites are so popular,
given that Emacs has such a helpful community and such a good
documentation.  Fashion and bad habits are the only explanations I
came up with.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Stefan Monnier]

>> I don't necessarily disagree with the first part.  I won't be
>> using this feature myself, in any case.
> Who will?

The case I know of where the .elc and .el are not next to each other is
to place the byte-compiled files in a directory specific to the Emacs
version used to compile.  This is used in Debian so as to be able to
have Elisp packages and byte-compiled for many different
(X)Emacs versions.

I haven't looked at how Debian packages manage to place the compiled
files at the right place, tho.


        Stefan


> If you dwell a lot on those sites, how about encouraging people to use
> the Emacs forums, where they will get definitive answers, instead of
> talking to random people (present company excluded) on Stack-foo?

FWIW, I answer also on stack-foo, and I like the fact that answers can
be edited/fixed: it's a bit halfway between a forum and wiki, which
has its advantages.  I do thoroughly dislike the centralized aspect of
it, tho.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Glenn Morris]

Stefan Monnier wrote:

> The case I know of where the .elc and .el are not next to each other is
> to place the byte-compiled files in a directory specific to the Emacs
> version used to compile.  This is used in Debian so as to be able to
> have Elisp packages and byte-compiled for many different
> (X)Emacs versions.

I had a vague memory that this caused Some Issues, but I don't remember
any details.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Glenn Morris]

Glenn Morris wrote:

> Stefan Monnier wrote:
>
>> The case I know of where the .elc and .el are not next to each other is
>> to place the byte-compiled files in a directory specific to the Emacs
>> version used to compile.  This is used in Debian so as to be able to
>> have Elisp packages and byte-compiled for many different
>> (X)Emacs versions.
>
> I had a vague memory that this caused Some Issues, but I don't remember
> any details.

The obvious one is whether .el is newer than .elc.
I also thought it was something to do with the documentation lookup.

In fact on my Debian system, looks like they use symlinks to link the
source .el into the directory with the version-specific .elc. Probably
to avoid those very problems that come from separating the .el and .elc.

But hey, patches welcome if someone wants to address this long-standed,
complicated issue.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  20968@debbugs.gnu.org
> Date: Fri, 03 Jul 2015 11:10:30 -0400
> 
> > If you dwell a lot on those sites, how about encouraging people to use
> > the Emacs forums, where they will get definitive answers, instead of
> > talking to random people (present company excluded) on Stack-foo?
> 
> FWIW, I answer also on stack-foo, and I like the fact that answers can
> be edited/fixed: it's a bit halfway between a forum and wiki, which
> has its advantages.  I do thoroughly dislike the centralized aspect of
> it, tho.

Those sites make our job harder.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Artur Malabarba]

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

> Those sites make our job harder.

In what way?

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

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Date: Fri, 3 Jul 2015 23:48:13 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: 20968@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > Those sites make our job harder.
> 
> In what way? 

Instead of having the discussions in a small number of well-defined
forums, that are reliably read by Emacs developers, and are archived
and indexed by the GNU servers, we have some of them going on
"elsewhere".  This produces annoying complications, including, but not
limited to:

  . There are more places to search when you are after some specific
    issue.

  . Issues that reveal Emacs bugs are many times not reported to the
    bug tracker, and remain unknown to us for many moons, sometimes
    years.

  . If and when people eventually do submit bug reports, they cannot
    be bothered to report all the details, and just provide a link to
    those "elsewhere" discussions, so whoever wants to fix the problem
    needs to read through them, which is not easy (the messages aren't
    sorted by date, etc.).

This becomes worse as time goes by.  I had my share of fixing bugs
caused by changes made years ago.  When that happens, you want to be
able to establish (a) why was the change made, and (b) what was the
use case or test case that served as the reason for the changes.
That's because whatever change you are going to install, you will want
to make sure it doesn't reintroduce back the original problem, so you
will want a good understanding of that past issue, and a test case.
Having to search 3 Emacs lists is already bad enough, having to search
in addition 2 stack-foo forums, which are not archived by dates (at
least I know of now way to search them given the date of the change in
Emacs) makes that unbearable, so I usually give up.

What's more, I don't understand why people use those places.  The
Emacs forums are quite friendly, so there should be no reason for them
to avoid us.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Alexis]

Eli Zaretskii <eliz@gnu.org> writes:

> What's more, I don't understand why people use those places. 
> The Emacs forums are quite friendly, so there should be no 
> reason for them to avoid us.

Sadly, it seems increasing numbers of people are finding that, 
compared to Web-based fora, email and mailing lists are too much 
hassle / too complicated / too annoying / etc. Some feel that even 
low-traffic lists (say, a few emails per day) are "too much 
email", and filtering is either too complicated for them to set 
up, or simply not available.

i also guess that Web fora might tend to rank higher in search 
engine results than mailing lists; if so, that might result in 
more people signing up for the former than the latter.[1]

Having said that, there are things like the rust-dev mailing being 
abandoned in favour of a Web forum, on the basis that the mailing 
list was "not scalable". i'm not sure how the existence of, say, 
the LKML fits in with that ....

For me, it's easier to follow multiple communities via the 'push' 
mechanism of email than the 'pull' mechanism of Web fora; a number 
of Web fora have poor or non-existent email notifications, so i 
have to rely on a browser extension to regularly check a given 
Web-based discussion for any new or changed content. The increased 
inconvenience means i follow fewer communities nowadays than i 
used to. But my guess is that Web fora are only going to increase 
in importance, and that people will increasingly expect that 
'official' support will be provided via the Web.


Alexis.

[1] i continue to regularly have bad experiences with the "search 
our archives" functionality of mailing lists. i've recently been 
unable to find an email on a mailing list - i can't remember which 
one - which i /knew/ was there, but wasn't discoverable via Google 
or the mailing list search functionality. In the end i resorted to 
trawling through the archives manually, and thus found the email i 
was after.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> From: Alexis <flexibeast@gmail.com>
> Date: Sat, 04 Jul 2015 20:38:40 +1000
> 
> Sadly, it seems increasing numbers of people are finding that, 
> compared to Web-based fora, email and mailing lists are too much 
> hassle / too complicated / too annoying / etc. Some feel that even 
> low-traffic lists (say, a few emails per day) are "too much 
> email", and filtering is either too complicated for them to set 
> up, or simply not available.

Traffic is irrelevant: no one needs to subscribe in order to post.

> i also guess that Web fora might tend to rank higher in search 
> engine results than mailing lists; if so, that might result in 
> more people signing up for the former than the latter.[1]

That's not my experience.  They are both indexed and appear in
searches alike.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Artur Malabarba]

>   . There are more places to search when you are after some specific
>     issue.

If you mean “a developer looking for the discussion around an old
bug”, see what I wrote on the 3rd item below.
If you mean “a user looking for an answer/solution to a
question/issue”, see here.

To most people nowadays there's only one place to search, their search
engine of choice. So, to them, it's not yet another place to search.
StackOverflow (SO) questions in particular are usually very easy to
find like that. When I have a programming question/issue I never visit
SO, I just Google it and 90% it lands me on SO, even if the post is
many years old.

It is much rarer for my searches to take me to a relevant mailing list
on the subject. And then I usually have to read through several
(many?) messages to get what I want, whereas SO posts are more focused
and self-contained.

Understand, I'm not arguing whether search engines do a good or a bad
job in that regard. I'm just saying that is where most people will
look for answers, and to them the availability of information on these
other sites only helps.

>   . Issues that reveal Emacs bugs are many times not reported to the
>     bug tracker, and remain unknown to us for many moons, sometimes
>     years.

That's probably true of other sites, but on emacs.stackexchange the
gurus are frequently telling users to file a report when something
looks like a bug (and so far I usually see them follow through). We
also occasionally tell them to file feature requests, and a lot of
times a new package/feature has arisen as a result of a question
there.

>   . If and when people eventually do submit bug reports, they cannot
>     be bothered to report all the details, and just provide a link to
>     those "elsewhere" discussions, so whoever wants to fix the problem
>     needs to read through them, which is not easy (the messages aren't
>     sorted by date, etc.).
A discussion on SO usually consists of a question with comments (or an
answer with comments), and these comments are sorted by date. The
global list of questions is indeed not sorted by date. But if anyone
files a bug and links me to the site's frontpage instead of linking to
the specific discussion, then they're just being daft and I wouldn't
hesitate to ask for a better link (or, really, ask them to bring in
more information).

> This becomes worse as time goes by.  I had my share of fixing bugs
> caused by changes made years ago.  When that happens, you want to be
> able to establish (a) why was the change made, and (b) what was the
> use case or test case that served as the reason for the changes.
> That's because whatever change you are going to install, you will want
> to make sure it doesn't reintroduce back the original problem, so you
> will want a good understanding of that past issue, and a test case.
> Having to search 3 Emacs lists is already bad enough, having to search
> in addition 2 stack-foo forums, which are not archived by dates (at
> least I know of now way to search them given the date of the change in
> Emacs) makes that unbearable, so I usually give up.

Yes, that sounds frustrating. When a bug is filed it's definitely
important to have the bug information here. Some people have enough
common sense to do that when filing the bug, others will need to be
asked to do that.
Besides, links the one Drew provided above are pretty straightforward
too. If you follow it, it takes you straight to the post where a user
details his use-case and asks about such a feature. So there really
isn't any searching around involved (though I personally think all
these details should be provided here too).

> What's more, I don't understand why people use those places.  The
> Emacs forums are quite friendly, so there should be no reason for them
> to avoid us.

They're not avoiding us, they're just defaulting to what they know.
Different groups of people (be it due to generation or expertise) are
accustomed to different sets of technologies, and few are those who
take the time to learn something outside their set.
It's not a good thing, it's just the way things are and it goes way above Emacs.

Besides, these other places have their advantages too. I'm sure we can
find discussions somewhere about the pros and cons of other media vs
mailing lists.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Date: Sat, 4 Jul 2015 12:10:36 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: 20968@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> They're not avoiding us, they're just defaulting to what they know.

My point was precisely a call to teach them to know better.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Stefan Monnier]

> My point was precisely a call to teach them to know better.

In my experience the number of questions on stack-foo which should be
bug-reports is no worse than the number of questions on gnu.emacs.help
which should be bug reports.

So, for me, stack-foo is no worse than gnu.emacs.help in that respect.

I do see some downsides to stack-foo:
- the "pull rather than push" is indeed annoying (there are ways to
  circumvent it, tho).
- for people whose workflow is email-based it's annoying that you can't
  reply from Gnus (for example) in the "usual" way.
- it's centralized and "out of control": e.g. there's no archive
  available.  As long as it exists, we can still access it, and by
  nature it tends to add data so it's in a sense "self-archiving", but
  since questions and answers can be edited (and are edited) there's no
  way to really see what it was like two years ago.

In any case, it exists and it's not like we have the power to force
people to use something else.


        Stefan

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: bruce.connor.am@gmail.com, 20968@debbugs.gnu.org
> Date: Sat, 04 Jul 2015 14:46:50 -0400
> 
> for me, stack-foo is no worse than gnu.emacs.help in that respect.

Having 2 such forums is twice worse than having one.  And actually
it's more than twice worse, because I cannot selectively read only the
issues I'm interested in, without lurking there all the time,
something I cannot afford.

> In any case, it exists and it's not like we have the power to force
> people to use something else.

We have the power to convince.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Stefan Monnier]

>> In any case, it exists and it's not like we have the power to force
>> people to use something else.
> We have the power to convince.

I think it's an illusion,


        Stefan

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: bruce.connor.am@gmail.com, 20968@debbugs.gnu.org
> Date: Sat, 04 Jul 2015 15:26:26 -0400
> 
> >> In any case, it exists and it's not like we have the power to force
> >> people to use something else.
> > We have the power to convince.
> 
> I think it's an illusion,

I know it isn't.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Dmitry Gutov]

On 07/04/2015 11:24 AM, Eli Zaretskii wrote:

> What's more, I don't understand why people use those places.  The
> Emacs forums are quite friendly, so there should be no reason for them
> to avoid us.

An average user doesn't really want to talk to someone. They want to 
find an answer to their question, and maybe a bunch of settings to apply 
to their init file.

The stack-foo platform is extremely geared towards the ease of finding 
existing answers (via editing, tagging and voting), or contributing an 
answer that's comprehensive and easy to find (without searching through 
all the messages in a mailing list discussion).

You can't beat that.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Cc: 20968@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 5 Jul 2015 14:54:07 +0300
> 
> On 07/04/2015 11:24 AM, Eli Zaretskii wrote:
> 
> > What's more, I don't understand why people use those places.  The
> > Emacs forums are quite friendly, so there should be no reason for them
> > to avoid us.
> 
> An average user doesn't really want to talk to someone. They want to 
> find an answer to their question, and maybe a bunch of settings to apply 
> to their init file.

To get a question answered, they must first ask it, exactly like they
would on gnu.emacs.help.  Then they need to read the answers, and
perhaps comment on them, exactly as they would on gnu.emacs.help.

> The stack-foo platform is extremely geared towards the ease of finding 
> existing answers (via editing, tagging and voting), or contributing an 
> answer that's comprehensive and easy to find (without searching through 
> all the messages in a mailing list discussion).

All our mailing lists are indexed by Google, exactly like stack-foo.

> You can't beat that.

It sounds like we don't want to, or have given up in advance.  In that
case, the result is known up front.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Dmitry Gutov]

On 07/05/2015 05:35 PM, Eli Zaretskii wrote:

> To get a question answered, they must first ask it, exactly like they
> would on gnu.emacs.help.

In all likelihood, someone has asked their question before.

> All our mailing lists are indexed by Google, exactly like stack-foo.

The strong points of stack-foo that I've mentioned in parentheses, make 
a big difference.

> It sounds like we don't want to, or have given up in advance.  In that
> case, the result is known up front.

Personally, I don't want to. The stack-foo people have put a lot of work 
into making asking questions and finding answers as smooth as possible.

An entirely open platform like that would be better, of course, but I 
don't think we have the manpower for that.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Cc: bruce.connor.am@gmail.com, 20968@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 5 Jul 2015 17:54:07 +0300
> 
> On 07/05/2015 05:35 PM, Eli Zaretskii wrote:
> 
> > To get a question answered, they must first ask it, exactly like they
> > would on gnu.emacs.help.
> 
> In all likelihood, someone has asked their question before.

That's not the use case I was talking about.  Looking up questions
already asked means using a search engine, which will find the answers
wherever they are, be it on gnu.emacs.help of stack-overflow.

I was talking about someone who wants to ask a question never
asked/answered before.

> > All our mailing lists are indexed by Google, exactly like stack-foo.
> 
> The strong points of stack-foo that I've mentioned in parentheses, make 
> a big difference.

I don't see it.

> > It sounds like we don't want to, or have given up in advance.  In that
> > case, the result is known up front.
> 
> Personally, I don't want to.

Yes, it's very clear.  Then I don't have any hope of convincing you.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Artur Malabarba]

Given that it has little to do with the feature requested, should this
discussion perhaps be moved out of debbugs?

Re: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Stefan Monnier]

[ Please take out the 20968@... from the Ccs.  ]

> That's not the use case I was talking about.  Looking up questions
> already asked means using a search engine, which will find the answers
> wherever they are, be it on gnu.emacs.help of stack-overflow.

No, the curating (tagging, voting, and editing) makes a significant
difference: you don't need to read N different messages (hopefully
connected via threading) to get the overall picture.

When I search (via, say, DuckDuckGo) for answers to a particular
problem, I generally find that the answers I find in stackoverflow are
generally more directly usable and of higher quality than what I may
find elsewhere.  Sometimes I can get more details and info in the
developer's mailing list archive, but it takes more effort and technical
expertise to find it and digest it.

> I was talking about someone who wants to ask a question never
> asked/answered before.

In that case it mostly depends on who's available to answer
the question.  I think in this respect the average proficiency level on
emacs.stackexchange is very much comparable to that of gnu.emacs.help.

As for redirecting people to *us* (i.e. emacs-devel or debbugs), I find
it neither harder nor easier on stack-foo than on gnu.emacs.help.


        Stefan

Re: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, emacs-devel@gnu.org,
>         bruce.connor.am@gmail.com
> Date: Sun, 05 Jul 2015 12:27:48 -0400
> 
> > That's not the use case I was talking about.  Looking up questions
> > already asked means using a search engine, which will find the answers
> > wherever they are, be it on gnu.emacs.help of stack-overflow.
> 
> No, the curating (tagging, voting, and editing) makes a significant
> difference: you don't need to read N different messages (hopefully
> connected via threading) to get the overall picture.

The answers on Stack-overflow present discussion as well.  And at
least I always read everything there, not just the "best" answer.

> When I search (via, say, DuckDuckGo) for answers to a particular
> problem, I generally find that the answers I find in stackoverflow are
> generally more directly usable and of higher quality than what I may
> find elsewhere.

Then we may wish to make our answers better and more usable as well.
Again, if we want to; it doesn't sound to me people are too
enthusiastic about this.

Re: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Stefan Monnier]

> Then we may wish to make our answers better and more usable as well.

No, we can't: we can only reply with additional info, but we can't
retroactively fix our earlier replies.  That's the difference between
a curated answer site like SX and a mailing-list like GEH.


        Stefan

Re: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Artur Malabarba]

2015-07-05 19:09 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> Then we may wish to make our answers better and more usable as well.
>
> No, we can't: we can only reply with additional info, but we can't
> retroactively fix our earlier replies.  That's the difference between
> a curated answer site like SX and a mailing-list like GEH.

To be fair, that's the difference between mailing-lists and any online
forum whatsoever. Being able to edit answers is a basic requirement
for a Q&A system that wants to present quality answers that rank
highly in search engines. Being able to edit the questions themselves
is another one (since a lot of questions are asked very poorly, which
makes them difficult for other people to find).

Then there are the differences that stack-exchange presents, which are
what make them standout so much over all the other bajillion systems
that let you edit answers. Amongst them are the voting system, the
moderation philosophy, the objective-questions-only policy, and maybe
others I can't think off here.

I don't think help-gnu-emacs should strive to achieve all that. I
think it's a fine place for discussions, and an OK place for Q&A, but
trying to be awesome at Q&A (besides being a tremendous task) would
probably imply being bad at discussions (as is the case with
stack-foo).

Re: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Stefan Monnier]

> The answers on Stack-overflow present discussion as well.  And at
> least I always read everything there, not just the "best" answer.

Of course, but it's all in a single web-page, rather than in a tree of
web-pages.  And the info is not just sorted by time but by votes, which
should reflect the relevance/quality of the answer.


        Stefan

Re: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Artur Malabarba]

2015-07-05 19:11 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> The answers on Stack-overflow present discussion as well.  And at
>> least I always read everything there, not just the "best" answer.
>
> Of course, but it's all in a single web-page, rather than in a tree of
> web-pages.  And the info is not just sorted by time but by votes, which
> should reflect the relevance/quality of the answer.

*And* the discussions are usually reserved for comments, which are
much less emphasized than the information itself (the answers).

Re: bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Artur Malabarba]

>> When I search (via, say, DuckDuckGo) for answers to a particular
>> problem, I generally find that the answers I find in stackoverflow are
>> generally more directly usable and of higher quality than what I may
>> find elsewhere.
>
> Then we may wish to make our answers better and more usable as well.
> Again, if we want to; it doesn't sound to me people are too
> enthusiastic about this.

Yes, I find it a bit hard to be enthusiastic about it. There's nothing
wrong with trying to make help-gnu-emacs better, but as long as it's a
mailing list it's going to have a very hard time being highly ranked
in search engines.

Besids, to have other sites dedicated to Emacs is only a sign of a
healthy (and dedicated) community. If we're worried that that
information might go away without notice, we could archive it
ourselves (that's pretty trivial, even).

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We could arrange to post messages once a month in those stack-foo
forums suggesting that if people would like Emacs developers to see
their ideas they should post them in emacs-devel.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> > Enhancement request.
>> >
>> > 1. Be able to specify the output directory for *.elc files to
>> > `byte-compile-file'.  See this emacs.SE question:
>> > http://emacs.stackexchange.com/q/13596/105.
>> 
>> This request doesn't make a lot of sense to me (I feel like saying
>> this for many of these "here's a forward of a thing I read on Stack-
>> foo"), because Emacs expects .el and .elc to live in the same place.
>
> I don't necessarily disagree with the first part.  I won't be
> using this feature myself, in any case.

It seems like no real use case was proposed in this long thread (if I
missed it, I'm sorry.  SORRY!!!).  But I don't see the point, either, so
I'm closing this bug report.

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

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Drew Adams]

> > I don't necessarily disagree with the first part.  I won't be
> > using this feature myself, in any case.
> 
> Who will?

Perhaps someone like the user who asked how to be able to easily
keep *.elc separate from *.el (without moving after compilation).

> > Anyway, I won't argue strongly for this, but I also don't (yet)
> > see it as something undesirable or unsurmountable.
> 
> What would be the reason for providing such a feature?  (Yes, I've
> read that discussion; no, I don't see why the user wanted this.)

Well, there was the reason given by the OP, which you apparently
reject.  Flexibility is another reason.

Why should the target dir be hardwired to the source dir?  Testing
might be a reason for the enhancement: quickly remove the *.elc dir
from `load-path' to take byte-compilation complications out of the
equation.  Having different compilation dirs for different Emacs
versions could be another argument for such flexibility.

Is there a compelling reason, beyond "we've always done without
this", not to let users specify the output dir?

But I'm not here to argue about this.  If you don't see the point
of such an enhancement then just move on.

Or seize the opportunity to instead rant about non-GNU Emacs forums...

> If you dwell a lot on those sites, how about encouraging people to
> use the Emacs forums, where they will get definitive answers,
> instead of talking to random people (present company excluded) on
> Stack-foo?

If you visited emacs.SE and StackOverflow (tag `emacs') occasionally,
you might observe that that is **EXACTLY** what I do do.  Far more
than anyone else, BTW.  And I encourage them to file bug reports if
they think they've found a bug or have an enhancement suggestion.

And most importantly (IMO), I try to teach them how to, and I
encourage them to, *ASK EMACS* first and foremost, instead of
immediately asking questions in a knee-jerk way.

Why not inform yourself a little before tossing out such advice?
Amazing that you would try to pooh-pooh helping Emacs users, in
any venu.  Tell it to Stefan.  Or Malabarba.  Or any number of
other people who try to help Emacs users on such sites.  They are
the same people (present company excepted) who try to help Emacs
users on help-gnu-emacs@gnu.org etc.

> I cannot for the life of me figure out why these sites are so
> popular,

Think harder.  Find out more about such sites - how they work,
how they don't work.

> given that Emacs has such a helpful community and such
> a good documentation.  Fashion and bad habits are the only
> explanations I came up with.

Another explanation: Many people, especially young people, do not
read documentation these days.  Q&A seems easy, and "these sites"
actually do do a good job of responding to questions.  Like it or
not.

You can call anything like this (e.g., not being apt to read doc)
a "bad habit".  But the effect of community help on such sites is
undeniable.  And you might well be surprised at the 3rd-party Emacs
code development that has come out of help provided on "such sites".

You want to vent about such sites - fine.  I have NO problem with
that.  This is not the best place for it, perhaps, but you are
welcome to do it, if it makes you feel better.

I filed this enhancement request because the suggested change
sounds to me like it could be useful.  So far, I haven't seen
any reason expressed against it (beyond the fact that it hasn't
been done before).  But if you don't find it useful then don't
bother with it.  Simple.

But I wouldn't mind an answer, for my curiosity: What's a good
reason not to let users specify the output directory?

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Date: Fri, 3 Jul 2015 07:55:55 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rgm@gnu.org, 20968@debbugs.gnu.org
> 
> Why should the target dir be hardwired to the source dir?  Testing
> might be a reason for the enhancement: quickly remove the *.elc dir
> from `load-path' to take byte-compilation complications out of the
> equation.  Having different compilation dirs for different Emacs
> versions could be another argument for such flexibility.
> 
> Is there a compelling reason, beyond "we've always done without
> this", not to let users specify the output dir?

One reason is to be able to use "M-x load-library RET", and have it
DTRT.  If the *.elc files are separate from *.el, then at best the
problem of deciding which version to load becomes harder and the
loading becomes slower, and at worst you'll have a subtle bug on your
hands.  E.g., what if more than one directory on load-path has a file
that goes by the same name?  And in what order do you search load-path
for the companion .el file, given that you found .elc in in some
directory?

Last, but not least: the current implementation of loading a Lisp file
is a 2-level loop, where the outer one loops over the directories, and
the inner one over the suffixes.  So this suggestion, if implemented,
will need C-level changes as well.

> Or seize the opportunity to instead rant about non-GNU Emacs forums...

Done.

> > If you dwell a lot on those sites, how about encouraging people to
> > use the Emacs forums, where they will get definitive answers,
> > instead of talking to random people (present company excluded) on
> > Stack-foo?
> 
> If you visited emacs.SE and StackOverflow (tag `emacs') occasionally,
> you might observe that that is **EXACTLY** what I do do.  Far more
> than anyone else, BTW.  And I encourage them to file bug reports if
> they think they've found a bug or have an enhancement suggestion.

Please carry on, and thanks.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Stefan Monnier]

> Last, but not least: the current implementation of loading a Lisp file
> is a 2-level loop, where the outer one loops over the directories, and
> the inner one over the suffixes.  So this suggestion, if implemented,
> will need C-level changes as well.

I'm not sure which suggestion you're referring to.


        Stefan

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Drew Adams]

> > Why should the target dir be hardwired to the source dir?  Testing
> > might be a reason for the enhancement: quickly remove the *.elc
> > dir from `load-path' to take byte-compilation complications out of
> > the equation.  Having different compilation dirs for different
> > Emacs versions could be another argument for such flexibility.
> >
> > Is there a compelling reason, beyond "we've always done without
> > this", not to let users specify the output dir?
> 
> One reason is to be able to use "M-x load-library RET", and have it
> DTRT.  If the *.elc files are separate from *.el, then at best the
> problem of deciding which version to load becomes harder and the
> loading becomes slower, and at worst you'll have a subtle bug on
> your hands.  E.g., what if more than one directory on load-path has
> a file that goes by the same name?  And in what order do you search
> load-path for the companion .el file, given that you found .elc in
> in some directory?

It can of course happen that someone is confused, doesn't know how
`load-library' works, and doesn't get the behavior that s?he
mistakenly expected.

But AFAIK, the behavior is well-defined.  And this was precisely
one of the possible use cases I outlined.  Ordering multiple dirs
in `load-path' is a way to control which version of a library gets
loaded (whether .el or .elc gets loaded, and which .el or .elc gets
loaded).

So yes, this gives users more, not less control.  And with greater
control comes more possibilities to shoot oneself in the foot.

(The control is not strictly greater than now, of course, since
even now you can move .elc and .el files to whatever dirs you like.
All the suggested enhancement does is facilitate separation of .el
and .elc, letting you do that at compilation time.)

So unless I'm missing something, I see no good argument against
the suggestion when it comes to `load-library'.

> Last, but not least: the current implementation of loading a Lisp
> file is a 2-level loop, where the outer one loops over the
> directories, and the inner one over the suffixes.

Which means that if there is only one suffix in a given directory
then the inner one becomes a trivial case, no?

> So this suggestion, if implemented, will need C-level changes as well.

I trust your estimation of that, but I don't understand why it
would be the case.  Can you give a concrete example showing why
separate dirs with .el and .elc would not be handled today?

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Date: Sat, 4 Jul 2015 07:41:47 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rgm@gnu.org, 20968@debbugs.gnu.org
> 
> > > Why should the target dir be hardwired to the source dir?  Testing
> > > might be a reason for the enhancement: quickly remove the *.elc
> > > dir from `load-path' to take byte-compilation complications out of
> > > the equation.  Having different compilation dirs for different
> > > Emacs versions could be another argument for such flexibility.
> > >
> > > Is there a compelling reason, beyond "we've always done without
> > > this", not to let users specify the output dir?
> > 
> > One reason is to be able to use "M-x load-library RET", and have it
> > DTRT.  If the *.elc files are separate from *.el, then at best the
> > problem of deciding which version to load becomes harder and the
> > loading becomes slower, and at worst you'll have a subtle bug on
> > your hands.  E.g., what if more than one directory on load-path has
> > a file that goes by the same name?  And in what order do you search
> > load-path for the companion .el file, given that you found .elc in
> > in some directory?
> 
> It can of course happen that someone is confused, doesn't know how
> `load-library' works, and doesn't get the behavior that s?he
> mistakenly expected.
> 
> But AFAIK, the behavior is well-defined.

It's well-defined only for the current behavior, where the *.el and
the corresponding *.elc files live in the same directory.

> Ordering multiple dirs in `load-path' is a way to control which
> version of a library gets loaded (whether .el or .elc gets loaded,
> and which .el or .elc gets loaded).

Users will get to manage the resulting complexity.  I bet the OP
didn't even understand what kind of hole he is digging for himself.

> So yes, this gives users more, not less control.

There's a limit where more becomes less.

> And with greater control comes more possibilities to shoot oneself
> in the foot.

Exactly.

> So unless I'm missing something, I see no good argument against
> the suggestion when it comes to `load-library'.

You see it, you just disagree with it.

> > Last, but not least: the current implementation of loading a Lisp
> > file is a 2-level loop, where the outer one loops over the
> > directories, and the inner one over the suffixes.
> 
> Which means that if there is only one suffix in a given directory
> then the inner one becomes a trivial case, no?

??? Are you saying we will no longer allow both *.el and *.elc, only
one of them?

> > So this suggestion, if implemented, will need C-level changes as well.
> 
> I trust your estimation of that, but I don't understand why it
> would be the case.

See above.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Drew Adams]

> > > One reason is to be able to use "M-x load-library RET", and have
> > > it DTRT.  If the *.elc files are separate from *.el, then at best
> > > the problem of deciding which version to load becomes harder and the
> > > loading becomes slower, and at worst you'll have a subtle bug on
> > > your hands.  E.g., what if more than one directory on load-path
> > > has a file that goes by the same name?  And in what order do you
> > > search load-path for the companion .el file, given that you found
> > > .elc in in some directory?
> >
> > It can of course happen that someone is confused, doesn't know how
> > `load-library' works, and doesn't get the behavior that s?he
> > mistakenly expected.
> >
> > But AFAIK, the behavior is well-defined.
> 
> It's well-defined only for the current behavior, where the *.el and
> the corresponding *.elc files live in the same directory.

How so?  Please give a concrete example where it is not well-defined
for a foo.el and a foo.elc that are in different directories.  Explain
what problems you think arise in such a case.

> > Ordering multiple dirs in `load-path' is a way to control which
> > version of a library gets loaded (whether .el or .elc gets loaded,
> > and which .el or .elc gets loaded).
> 
> Users will get to manage the resulting complexity.  I bet the OP
> didn't even understand what kind of hole he is digging for himself.

Who knows what the OP or other users might know?  Your point here
seems to be that even if the behavior is well-defined some users
might find it confusing.  Which is exactly what I already acknowledged:

  It can of course happen that someone is confused, doesn't know how
  `load-library' works, and doesn't get the behavior that s?he
  mistakenly expected.

> There's a limit where more becomes less.

Vague platitude, I'm afraid.  Please point to a specific problem,
if you expect us to make headway here in understanding.

> > So unless I'm missing something, I see no good argument against
> > the suggestion when it comes to `load-library'.
> 
> You see it, you just disagree with it.

I see (and already acknowledged) the possibility of a user, given
the additional control this provides, getting confused.  I have
not seen any other concrete argument.  There are plenty of places
in Emacs where we give users enough rope to hang themselves with.
`load-path' already presents plenty of such opportunity.

I don't see this enhancement as adding anything particular to the
possible confusion - someone confused by what it offers is very
likely confused about `load-path' behavior in general.  I don't
think this changes *anything* wrt `load-path' or the current
code that handles it.  You can already put .el and .elc wherever
you like, in the same dir, in separate dirs, mix&match - whatever.

You hand-wave about there being some problem with `load-library'
that would make the behavior ill-defined.  If you can show that with
an example, perhaps I will agree with you.  I really have no need
for the suggested enhancement, myself, and no axe to grind about this.
So far, it sounds to me like a reasonable request, but I welcome you
to provide an argument to the contrary.

> > > Last, but not least: the current implementation of loading a
> > > Lisp file is a 2-level loop, where the outer one loops over
> > > the directories, and the inner one over the suffixes.
> >
> > Which means that if there is only one suffix in a given directory
> > then the inner one becomes a trivial case, no?
> 
> ??? Are you saying we will no longer allow both *.el and *.elc, only
> one of them?

Did I say anything even vaguely suggesting such a thing?  Please
try to calm down.

Your argument is (as near as I can tell) that, because there is a
two-level loop, an enhancement that would let users automatically
place *.elc in a separate directory would be problematic and would
require changes in the C code.  You say nothing concrete about this.

I can only assume that you think it is a problem for the *current*
code to process multiple directories in `load-path', which might
have different .el or .elc files with the same (relative) file names.

I'm not aware of any such problem.  I think the code already
handles all such cases, regardless of where the .el and .elc files
might be located.  But as you know, I'm no expert in any of this,
and I am especially ignorant of the C code.

The case of the OP would put .el in one dir and .elc in another.
S?he would have to decide which of the two dirs, or both, to add
to `load-path' (and if both, in which order).  But in any case,
I see no problem or need for C code changes.

Can you please point out just what the problems are?

> > > So this suggestion, if implemented, will need C-level changes
> > > as well.
> >
> > I trust your estimation of that, but I don't understand why it
> > would be the case.
> 
> See above.

See above.  All I see is hand-waving, so far, I'm afraid.  But I
welcome a concrete example and explanation of the problem it poses
for the current code.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Eli Zaretskii]

> Date: Sat, 4 Jul 2015 11:20:05 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rgm@gnu.org, 20968@debbugs.gnu.org
> 
> > > But AFAIK, the behavior is well-defined.
> > 
> > It's well-defined only for the current behavior, where the *.el and
> > the corresponding *.elc files live in the same directory.
> 
> How so?  Please give a concrete example where it is not well-defined
> for a foo.el and a foo.elc that are in different directories.  Explain
> what problems you think arise in such a case.

I already did that: we search load-path linearly, only once, looking
for .el and .elc files in each directory.

> Can you please point out just what the problems are?

Sorry, don't have all that time.  You will have to read the code to
understand what I'm talking about.  The function 'openp' in lread.c is
the starting point, and the next step is to read the implementation of
'load'.

bug#20968: 25.0.50; Be able to specify the output directory for `byte-compile-file'

[Drew Adams]

> > > > But AFAIK, the behavior is well-defined.
> > >
> > > It's well-defined only for the current behavior, where the *.el
> > > and the corresponding *.elc files live in the same directory.
> >
> > How so?  Please give a concrete example where it is not well-
> > defined for a foo.el and a foo.elc that are in different
> > directories.  Explain what problems you think arise in such a case.
> 
> I already did that: we search load-path linearly, only once, looking
> for .el and .elc files in each directory.

And the problem with that is...?

> > Can you please point out just what the problems are?
> 
> Sorry, don't have all that time.

Then let's please move along.