On Sat, Dec 23, 2017 at 10:32 AM, Robert Weiner <rsw@gnu.org> wrote:

On Sat, Dec 23, 2017 at 3:44 AM, Rocky Bernstein <rocky@gnu.org> wrote:

Path names give you good places to start looking for the file.

And often they can quickly give information as to what's up, e.g. I am running from the stable or development branch. Or running from an Ubuntu build or a source-code build.

If you are actually running a branch of Emacs and using a .elc file included therein, then your load-path should be configured to take you to the proper associated source file with the find-library command, unless filenames are duplicated within the lisp tree. Only uses outside of that, i.e. working on files outside of the branch you are running, would this be an issue, I would think, or if there ever is a bundled format of .elc that combines the byte-compiled output of multiple files.

If anything of this nature is ever done, it should be based on the source file's default installed location relative to the Emacs root directory for portability. Any reasonable function/tool could then find the source file.

Bob

Let's back up a little. A function like byte-compile-file which is what would store this information into the bytecode file only has the path it is given. There are only two possible kinds of paths I know of: relative or absolute.

You have most forcefully convinced yourself that the only sane way that programmers or that programs written by programmers work would be to use relative paths. It matters not because, as I said, the function has only what is given it.

My suggestion was that when a relative path is given, (which is always in your world), also turn that into an absolute path and store in the bytecode file as well. In my experience in working in debugging, debuggers and in showing where errors are, sometimes the absolute path can be useful in addition to the relative path, for informative purposes.

I know others will not believe that, and furthermore claim most emphatically that were these paths included as meta comments in the bytecode file, that would be either useless, confusing and harmful and who knows what other bad things could happen. (By the way, as something similar, when I enter Emacs, I am shown a build string for a system is not mine, which so far has not caused such havoc, and I even find mildly interesting).

Ok. this was a just suggestion. That it has caused such negative reaction, I've seen before in other venues, and I'm sorry.

For my part, I know what I can do to handle my concerns when or if I decide to improve the error reporting and debugging situation on Emacs. Yes, I am sorry I didn't say at the outset that this is were I envision this getting used.