emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Weiner
Subject: Re: A couple of things that I think should be in byte bytecode meta comments
Date: Sat, 23 Dec 2017 13:30:49 -0500

On Sat, Dec 23, 2017 at 12:16 PM, Rocky Bernstein <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]