How can I debug font lock keywords I write? For example
(progn
(font-lock-add-keywords
nil
'(
;; ("hi1" . 'success)
("hi2" . (intern (concat "warn" "ing")))
))
(font-lock-fontify-buffer))
will produce the following message in Messages buffer:
Error during redisplay: (jit-lock-function 1) signaled (wrong-type-argument stringp 22)
In order to see the call stack upon wrong-type-argument error, I invoke toggle-debug-on-error and Emacs still doesn't enter debugger upon font lock error.
font-lock
can be applied in different ways. By default it is applied using
jit-lock-mode, which applies it "lazily" (aka "just-in-time"), which has
the disadvantage that it is applied at a time where we can't display
message (or enter the debugger) because that would make us inf-loop. So
there are two ways to work around the problem:
Use jit-lock-debug-mode (recently added to Emacs's development
code).
Set font-lock-support-mode to nil, then turn font-lock off and then
back on.
Both options should change font-lock so that it is applied at a time
where debugging can be used.
Related
As stated in previous questions, I'm quite new at Progress-4GL development.
I've just created a windows (*.w file), together with a procedure file (*.p file), which are based on an include file (*.i file).
I've done something wrong and I get an error message, copy-paste reveals the following:
---------------------------
Fout
---------------------------
** Begin positie voor SUBSTRING, OVERLAY, enz. moet 1 of groter zijn. (82)
---------------------------
OK
---------------------------
As you can see, this is the Dutch translation of error 82:
** Starting position for SUBSTRING, OVERLAY, etc. must be 1 or greater. (82)
The SUBSTRING, OVERLAY, etc, functions require that the start position (second argument) be greater than or equal to 1.
P
I'd like to know which procedure/function is launching this error message. I'm working with the AppBuilder release 11.6 and the corresponding procedure editor, so the debugging possibilities are very limited. One thing I'm thinking of, is taking a dump of the Windows process, in order to determine the call stack, but I'm not sure how to do this. I also tried using Process Explorer and check the stack of the individual stacks of the threads inside the "procwin32.exe" process, but I'm not sure how to proceed.
By the way, I'm regularly adding message boxes to my code, which look as follows (just an example):
MESSAGE "begin procedure combobox-value-changed" VIEW-AS ALERT-BOX.
As you see, the name of the procedure is hardcoded, while in other programming languages (like C++) the procedure/function name can be shown as follows:
OUTPUT("begin procedure %s", __FUNCTION__);
Next to __FUNCTION__, C++ also knows __FILE__ (for filename) and __LINE__ (for line number).
Do such predefined values also exist in Progress 4GL, preferably release 11.6 or previous?
As ABL code is not compiled into Windows byte-code a windows debugger will not be really helpful.
You should start by adding the -debugalert startup parameter to prowin/prowin32.exe. Or add this
ASSIGN SESSION:DEBUG-ALERT = TRUE .
That will add a HELP button to all (error) messages which will open a dialog with the ABL stack trace.
As you'Re using include files, be aware that the line numbers referenced in the stack-trace are based on the debug listing, not the actual source code. So execute
COMPILE myfile.w DEBUG-LIST c:\temp\myfile.debuglist .
to receive the debug-listing file with the correct line numbers.
Are you aware of the visual debugger that's available for the AVM? https://docs.progress.com/de-DE/bundle/openedge-abl-troubleshoot-applications-117/page/Introduction.html
%DLC%\bin\proDebugger.bat
Or the Compile -> Debug menu in the AppBuilder.
It looks a bit antique, but usually does it's job.
Debugging needs to be enabled as an Administrator in proenv:
prodebugenable -enable-all
Of course the grass is greener when you switch to Progress Developer Studio as your IDE.
Regarding the second part of your question. See the PROGRAM-NAME function.
message
program-name(1) skip
program-name(2)
.
Additionally see the {} preprocessor name reference.
message 'file: {&file-name} line: {&line-number}'.
My expectation would be for debug-on-error to trap most anomalous events and show me what went wrong. However, this is not the case with json.el which uses signal instead of error.
The documentation cautions against using debug-on-signal and my brief experimentation with it pretty much confirms this -- there are signals all over the place, so I would have to trap on just the json-* signals to get anything useful out of this. But I can't get even that to work.
I was about to submit a bug report for json.el but I feel that I may be missing something. Is there a good, established reason why json.el prefers signal over error?
Steps to repro:
(require 'json)
(setq debug-on-error t
debug-on-signal t) ; "json" ; '("json") ;; Still nothing
(json-read-from-string "")
Somewhat more realistically, you would have an actual, real-life problem when you pass the output from something to json-read (or one of its convenience wrappers json-read-from-string, json-read-file, json-read-object, etc) and it doesn't contain what you expect.
The result, even with debug-on-signal set to t, is the following text in the *Messages* buffer, and not much else:
with no indication as to the source of the error, or anything. (In real code with a similar problem, I was seeing if: End of file during parsing .)
In fact, the default value of debug-ignore-errors includes end-of-file so you have to remove that to be able to debug this particular problem.
(delete 'end-of-file debug-ignored-errors)
or perhaps more realistically
(let (debug-ignored-errors)
(json-something))
to temporarily override the value of debug-ignored-errors for the duration of the json-something call.
... and then you don't need debug-on-signal at all.
So my speculation that the use of signal instead of error causes the problematic behavior turned out to be false.
I have a personal elisp function that performs an multi-directory grep. It uses compilation-start, which creates a compilation-mode buffer with the results, in which I can press RET (bound to compile-goto-error) to jump to the corresponding location.
However, compile-goto-error always visits the location in another window, leaving the compilation buffer up. Half the time I am just searching for one particular location, so what I would like to do is bind some other key (say C-RET) to also visit the corresponding location in a buffer, but stay in the current window, replacing the compilation buffer with the location's buffer.
I've traced the relevant execution from compile-goto-error to next-error-internal to next-error-function to compilation-next-error-function to compilation-find-file, but can't find a nice place to hook in my differing behavior. Is there a simple way (or, failing that, a complicated one) to create a compile-goto-error variant that switches to the new buffer in-place in the window that held the compilation buffer?
I suggest just advising the compile-goto-error function to do the right thing, rather than creating a custom function and keybinding. The following does the right thing for me (following Stefan's suggestion):
(defadvice compile-goto-error (around my-compile-goto-error activate)
(let ((display-buffer-overriding-action '(display-buffer-reuse-window (inhibit-same-window . nil))))
ad-do-it))
I think you should be able to get what you want by let-binding display-buffer-overriding-action, something like:
(defun my-next-error ()
(interactive)
(let ((display-buffer-overriding-action '(display-buffer-same-window)))
(next-error)))
I needed to go through an XML file looking for certain tags whose contents were human-recognizable but not regex-recognizable and to work on those tags. I put together a keyboard macro that did the work I needed, then tried to use the following elisp to let me step through the file and just press y or n for each tag instead of going back and forth between movement commands and macro executions.
(while t
(progn
(search-forward "<Name>")
(move-beginning-of-line nil)
(if (y-or-n-p "Problem? ")
(call-last-kbd-macro)
(next-line)
)))
However, when I M-: evaluated this, it got to y-or-n-p and then emacs became unresponsive. I am using emacs on an OS X 10.7 machine. In Activity Monitor, emacs was taking up the normal amount of RAM and CPU time, not making escalating resource requests, so I don't think I ran into an infinite loop. Emacs simply stopped responding to typing and clicks altogether, including things like repeatedly hitting Escape or C-g. An additional detail: the one y-or-n-p interaction I got was a dialog box, not in the minibuffer, which was strange - I clicked Yes on it and the dialog box went away, which was the last interaction I was able to get with emacs before it disappeared into deep space.
Is there something in the above elisp code that's inherently dangerous? My thought was that the (search-forward) would fail at the end of the buffer, signal an error, and the loop would end.
Try this so that the search fails the loop terminates. This code could still loop forever if the call-last-kbd-macro moves point back before the previous search.
(while (search-forward "<Name>" nil t)
(progn
(move-beginning-of-line nil)
(if (y-or-n-p "Problem? ")
(call-last-kbd-macro)
(next-line))))
Some sample, straight forward gtk2 within-main-loop
I'm currently trying to add code at key-press-event
If I make an error in the guy code, the gui thread will hang in the repl, I can still get the repl back but I didn't find a way to continue with gui development without restarting sbcl and reloading all the packages
(defun run ()
(within-main-loop
; match the controls that matter to vars
(let ((window (builder-get-object builder "window"))
;....
; on window close keep the gtk running. helps with debugging
(g-signal-connect search-field "key-press-event" (lambda (w) (declare (ignore w)) (format "~a" "danut")))
(g-signal-connect window "destroy" (lambda (w) (declare (ignore w)) (leave-gtk-main)))
(widget-show window)))))
The error I get when I run this function is :
debugger invoked on a SIMPLE-ERROR in thread #:
There is no applicable method for the generic function
#
when called with arguments
(NIL).
With enough work I can fix the error, but everytime I get something broken in the gui I can't make the backend thread to continue from where it hanged.
I tried all kinds of thread functions. list-all-treads will show:
(#<SB-THREAD:THREAD "cl-gtk2 main thread" RUNNING {CF48EF1}>
#<SB-THREAD:THREAD "initial thread" RUNNING {AA5F591}>)
This is all I tried until now:
(sb-thread:list-all-threads)
(sb-thread:interrupt-thread (first (sb-thread:list-all-threads)) #'leave-gtk-main)
(sb-thread:terminate-thread (first (sb-thread:list-all-threads)))
I just can't get it unstuck.
What's your normal workflow with cl-gtk2-gtk, how do you avoid this problem?
Use sb-thread:release-foreground to switch between threads waiting for input. See Threads in SBCL for an example session.