Re: A couple of things that I think should be in byte bytecode meta comments

[Robert Weiner <rsw@gnu.org>]

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

On Sat, Dec 23, 2017 at 12:16 PM, Rocky Bernstein <rocky@gnu.org> wrote:

>
> 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.
>

​People are just sharing their thoughts on whether that appears to be
helpful or not.  You have acknowledged that at runtime, the absolute path
may be invalid, but you have not provided your use case to show where and
when it might be helpful.

​​
>   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.
>
​​
​Only when it is accurate.  But you haven't yet made a suggestion about how
to make absolute paths in .elc files accurate during runtime, as far as I
recall.
Maybe a static absolute path would provide a heuristic for finding the
run-time absolute path, maybe not.  You haven't shown anything either way
yet.

> ​​
> ​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).
>

​It is a matter of utility, not of havoc.
​

> ​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.
>

​Yes, an easy to follow use case would be helpful.  I am very much in favor
of improving Emacs' error messages, especially anything that leads to the
source of an error when a backtrace is not produced.  If you can explain
how something you envision could make that happen, then you'll likely see
feedback change.

BTW, I think there might be a good idea in there about using hash codes to
verify valid use of a file, though my personal experience is that
incompatible byte codes are well reported by Emacs and have not caused me
any problems to date.  The much bigger problem is tracing an error raised
from C code back to the source function that raised it when running without
a C debugger active.  Without that, users can't provide much of a bug
report except possibly how to trigger the problem.

Bob

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