[ELPA] New package: dape

[ELPA] New package: dape

[Daniel Pettersson]

This package integrates debug adapters within Emacs.
Alternative to the well known package dap-mode.

See repository for code and more information https://github.com/svaante/dape

Re: [ELPA] New package: dape

[Philip Kaludercic]

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

Daniel Pettersson <daniel@dpettersson.net> writes:

> This package integrates debug adapters within Emacs.
> Alternative to the well known package dap-mode.

Very interesting!

> See repository for code and more information https://github.com/svaante/dape

Here are a few comments and suggestions I found from a brief skim over
the code:


[-- Attachment #2: Type: text/plain, Size: 12223 bytes --]

diff --git a/dape.el b/dape.el
index 7ce7132..47a1b17 100644
--- a/dape.el
+++ b/dape.el
@@ -5,6 +5,7 @@
 ;; License: GPL-3.0-or-later
 ;; Version: 0.1
 ;; Homepage: https://github.com/svaante/dape
+;; Package-Requires: ((emacs "29.1"))
 
 ;; This file is not part of GNU Emacs.
 
@@ -55,7 +56,7 @@
 (defcustom dape-configs nil
   "This variable holds the Dape configurations as an alist.
 In this alist, the car element serves as a symbol identifying each
-configuration. Each configuration, in turn, is a property list (plist)
+configuration.  Each configuration, in turn, is a property list (plist)
 where keys can be symbols or keywords.
 
 Symbol Keys (Used by Dape):
@@ -72,13 +73,13 @@ Debug adapter connection in configuration:
 - If only command is specified (without host and port), Dape
   will communicate with the debug adapter through stdin/stdout.
 - If both host and port are specified, Dape will connect to the
-  debug adapter. If `command is specified, Dape will wait until the
+  debug adapter.  If `command is specified, Dape will wait until the
   command is initiated before it connects with host and port.
 
 Keywords in configuration:
   Keywords are transmitted to the adapter during the initialize and
-  launch/attach requests. Refer to `json-serialize' for detailed
-  information on how Dape serializes these keyword elements. Dape
+  launch/attach requests.  Refer to `json-serialize' for detailed
+  information on how Dape serializes these keyword elements.  Dape
   uses nil as false.
 
 Functions and symbols in configuration:
@@ -160,10 +161,10 @@ The hook is run with one argument, the compilation buffer."
 (defcustom dape--debug-on
   '(io info error std-server)
   "Types of logs should be printed to *dape-debug*."
-  :type '(list (const io :tag "dap IO")
-               (const info :tag "info logging")
-               (const error :tag "error logging")
-               (const std-server :tag "dap tcp server stdout")))
+  :type '(list (const :tag "dap IO" io)
+               (const :tag "info logging" info)
+               (const :tag "error logging" error)
+               (const :tag "dap tcp server stdout" std-server)))
 ;;; Face
 
 (defface dape-log-face
@@ -323,8 +324,8 @@ The hook is run with one argument, the compilation buffer."
        default-directory)))
 
 (defun dape-find-file (&optional default)
-  (let* ((completion-ignored-extensions nil)
-         (default-directory (funcall dape-cwd-fn)))
+  (let ((completion-ignored-extensions nil)
+        (default-directory (funcall dape-cwd-fn)))
     (expand-file-name
      (read-file-name (if default
                          (format "Program (default %s): " default)
@@ -387,8 +388,8 @@ The hook is run with one argument, the compilation buffer."
                                             (symbol-name type))
                                     'face 'match)
                         " "
-                        (apply 'format string objects)))
-        (newline)))))
+                        (apply 'format string objects))
+		"\n")))))
 
 (defun dape--live-process (&optional nowarn)
   (if (and dape--process
@@ -684,7 +685,7 @@ The hook is run with one argument, the compilation buffer."
 (defun dape--stack-trace (process thread cb)
   (cond
    ((or (plist-get (dape--current-thread) :stackFrames)
-        (not (numberp (plist-get thread :id))))
+        (not (numberp (plist-get thread :id)))) ;any number?  including floats?
     (funcall cb process))
    (t
     (dape-request process
@@ -840,7 +841,7 @@ The hook is run with one argument, the compilation buffer."
 
 (cl-defmethod dape-handle-event (_process (_event (eql output)) body)
   (let ((category (plist-get body :category)))
-    (cond
+    (cond				;perhapse `pcase' would be nice
      ((equal category "stdout")
       (dape--repl-insert-text (plist-get body :output)))
      ((equal category "stderr")
@@ -996,8 +997,7 @@ The hook is run with one argument, the compilation buffer."
     (dape-request dape--process "restart" nil))
    ((and dape--name dape--config)
     (dape dape--name dape--config))
-   (t
-    (user-error "Unable to derive session to restart."))))
+   ((user-error "Unable to derive session to restart"))))
 
 (defun dape-kill ()
   "Kill debug session."
@@ -1164,7 +1164,7 @@ Executes launch `dape-configs' with :program as \"bin\"."
            (seq-reduce (apply-partially 'apply 'plist-put)
                        (seq-partition options 2)
                        (copy-tree base-config))))
-    (when (called-interactively-p)
+    (when (called-interactively-p 'interactive)
       (push (dape--config-to-string name
                                     base-config
                                     config)
@@ -1232,13 +1232,9 @@ Watched symbols are displayed in *dape-info* buffer.
 ;;; Memory viewer
 
 (defun dape--address-to-number (address)
-  (cond
-   ((and (> (length address) 2)
-         (equal "0x" (substring address 0 2)))
-    (string-to-number (string-trim-left address "0x0*")
-                      16))
-   (t
-    (string-to-number address))))
+  (if (string-match "\\`0x\\([[:alnum:]]+\\)" address)
+      (string-to-number (match-string 1 address) 16)
+    (string-to-number address)))
 
 (defun dape-read-memory (memory-reference count)
   "Read COUNT bytes of memory at MEMORY-REFERENCE."
@@ -1796,10 +1792,12 @@ See `dape-info' for more information."
               desktop-save-buffer      nil
               tree-widget-image-enable nil))
 
-(defun dape-info ()
+(defun dape-info (&optional select-buffer)
   "Create or select *dape-info* buffer.
-Buffer contains debug session information."
-  (interactive)
+Buffer contains debug session information.  If the optional
+argument SELECT-BUFFER is nil, or the command is not invoked
+interactively, then the buffer is not displayed." ;perhaps rephrase this
+  (interactive (list t))
   (let ((buffer (get-buffer-create "*dape-info*"))
         window)
     (with-current-buffer buffer
@@ -1867,7 +1865,8 @@ Buffer contains debug session information."
     (setq window (display-buffer buffer
                                  '((display-buffer-in-side-window)
                                    . ((side . left)))))
-    (when (called-interactively-p)
+
+    (when select-buffer
       (select-window window)
       (goto-char (point-min)))))
 
@@ -1882,32 +1881,31 @@ Buffer contains debug session information."
    (dape--repl-insert-text-guard
     (run-with-timer 0.1 nil 'dape--repl-insert-text msg))
    (t
-    (progn
-      (setq dape--repl-insert-text-guard t)
-      (when-let ((buffer (get-buffer "*dape-repl*")))
-        (with-current-buffer buffer
-          (save-excursion
-            (condition-case err
-                (progn
-                  (goto-char (point-max))
-                  (comint-previous-prompt 0)
-                  (forward-line -1)
-                  (end-of-line)
-                  (when-let (line (thing-at-point 'line))
-                    (when (eq (aref line 0) ?>)
-                      (let ((inhibit-read-only t))
-                        (insert "\n"))))
-                  (let ((inhibit-read-only t))
-                    (insert (propertize msg 'font-lock-face face))))
-              (error
-               (setq dape--repl-insert-text-guard nil)
-               (signal (car err) (cdr err))))
-            (setq dape--repl-insert-text-guard nil))))
-      (unless (get-buffer-window "*dape-repl*")
-        (when (stringp msg)
-          (message (format "%s"
-                           (string-trim msg "\\\n" "\\\n"))
-                   'face face)))))))
+    (setq dape--repl-insert-text-guard t)
+    (when-let ((buffer (get-buffer "*dape-repl*")))
+      (with-current-buffer buffer
+        (save-excursion
+          (condition-case err
+              (progn
+                (goto-char (point-max))
+                (comint-previous-prompt 0)
+                (forward-line -1)
+                (end-of-line)
+                (when-let (line (thing-at-point 'line))
+                  (when (eq (aref line 0) ?>)
+                    (let ((inhibit-read-only t))
+                      (insert "\n"))))
+                (let ((inhibit-read-only t))
+                  (insert (propertize msg 'font-lock-face face))))
+            (error
+             (setq dape--repl-insert-text-guard nil)
+             (signal (car err) (cdr err))))
+          (setq dape--repl-insert-text-guard nil))))
+    (unless (get-buffer-window "*dape-repl*")
+      (when (stringp msg)
+        (message (format "%s"
+                         (string-trim msg "\\\n" "\\\n"))
+                 'face face))))))
 
 (defun dape--repl-input-sender (dummy-process input)
   (let (cmd)
@@ -2050,7 +2048,7 @@ Buffer contains debug session information."
   :group 'dape
   :interactive nil
   (when dape-repl-mode
-    (user-error "`dape-repl-mode' all ready enabled."))
+    (user-error "`dape-repl-mode' all ready enabled"))
   (setq-local dape-repl-mode t
               comint-prompt-read-only t
               comint-input-sender 'dape--repl-input-sender
@@ -2099,7 +2097,7 @@ Empty input will rerun last command.\n\n\n"
                                       display-buffer-in-side-window)
                                      . ((side . bottom)
                                         (slot . -1)))))
-      (when (called-interactively-p)
+      (when (called-interactively-p)	;‘called-interactively-p’ called with 0 arguments, but requires 1!
         (select-window window)))))
 
 \f
@@ -2131,14 +2129,14 @@ Empty input will rerun last command.\n\n\n"
 (defun dape--config-from-string (str)
   (let (name read-config base-config)
     (when (string-empty-p str)
-      (user-error "Expected config name."))
+      (user-error "Expected config name"))
     (setq name (read str)
           base-config (copy-tree (alist-get name dape-configs))
           str (substring str (length (symbol-name name))))
     (unless (string-empty-p str)
       (setq read-config (read (format "(%s)" str))))
     (unless (plistp read-config)
-      (user-error "Unexpected config format, see `dape-configs'."))
+      (user-error "Unexpected config format, see `dape-configs'"))
     (cl-loop for (key value) on read-config by 'cddr
              do (setq base-config (plist-put base-config key value)))
     (list name base-config)))
@@ -2153,8 +2151,7 @@ Empty input will rerun last command.\n\n\n"
   (let ((config-diff (dape--config-diff pre-eval-config
                                         post-eval-config)))
     (concat (format "%s" name)
-            (when-let ((config-str (and config-diff
-                                        (prin1-to-string config-diff))))
+            (and-let* ((config-diff) (config-str (prin1-to-string config-diff)))
               (format " %s"
                       (substring config-str
                                  1
@@ -2181,6 +2178,7 @@ Empty input will rerun last command.\n\n\n"
 ;;; Hover
 
 (defun dape-hover-function (cb)
+  ;; Please consider addressing checkdoc issues like those raised here.
   (when-let ((symbol (thing-at-point 'symbol)))
     (dape--evaluate-expression (dape--live-process)
                                (plist-get (dape--current-stack-frame) :id)
@@ -2232,6 +2230,8 @@ Empty input will rerun last command.\n\n\n"
 \f
 ;;; Keymaps
 
+;; this raises the minimum version to 29.1, but you could take a look
+;; at Compat to avoid this
 (defvar-keymap dape-global-map
   :doc "Keymap to repeat dape commands.  Used in `repeat-mode'."
   "d" #'dape
@@ -2251,6 +2251,8 @@ Empty input will rerun last command.\n\n\n"
   "w" #'dape-watch-dwim
   "q" #'dape-quit)
 
+;; Why are you mapping over the keymap, instead of just iterating over
+;; the command you want to mark as repeatable?
 (map-keymap-internal (lambda (_ cmd)
                        (unless (memq cmd '(dape
                                            dape-repl

[-- Attachment #3: Type: text/plain, Size: 72 bytes --]


Also, sorry for bringing this up, but how married are you to the name?

Re: [ELPA] New package: dape

[Daniel Pettersson]

On Fri, Oct 13, 2023 at 2:24 PM Philip Kaludercic <philipk@posteo.net> wrote:
> Very interesting!
Thank you for your interest :)

> Here are a few comments and suggestions I found from a brief skim over
> the code:
I made some updates based on your suggestions and added a todo for
Compat. Couldn't bring myself to fix all of the checkdoc stuff, but made
some improvments.

> Also, sorry for bringing this up, but how married are you to the name?
I'm not overly attached to it. What are your objections? And do you have
any suggestions? I find it quite difficult to name things like this.

Re: [ELPA] New package: dape

[Philip Kaludercic]

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

Daniel Pettersson <daniel@dpettersson.net> writes:

> On Fri, Oct 13, 2023 at 2:24 PM Philip Kaludercic <philipk@posteo.net> wrote:
>> Very interesting!
> Thank you for your interest :)

I have tried to try it out right now, but because I've never used DAP
before, I am not sure how to get it running properly.  Nevertheless, I
think it would be useful to have something along these lines:


[-- Attachment #2: Type: text/plain, Size: 1909 bytes --]

diff --git a/dape.el b/dape.el
index 3b27104..e24b0ea 100644
--- a/dape.el
+++ b/dape.el
@@ -2320,22 +2320,24 @@ If SKIP-FUNCTIONS function values are not called during evaluation."
 
 (defun dape--read-config ()
   "Read config name and options."
-  (let ((candidate
-         (completing-read "Dape config: "
-                          (append
-                           (mapcan
-                            (lambda (name-config)
-                              (let* ((config (cdr name-config))
-                                     (modes (plist-get config 'modes)))
-                                (when (apply 'provided-mode-derived-p major-mode modes)
-                                  (list (car name-config)))))
-                            dape-configs)
-                           dape--config-history)
-                          nil nil nil 'dape-history)))
-    (if-let ((config
-              (alist-get (intern candidate) dape-configs)))
-        (list (intern candidate) config)
-      (dape--config-from-string candidate))))
+  (if (null dape-configs)
+      (customize-variable 'dape-configs)
+    (let ((candidate
+           (completing-read "Dape config: "
+                            (append
+                             (mapcan
+                              (lambda (name-config)
+				(let* ((config (cdr name-config))
+                                       (modes (plist-get config 'modes)))
+                                  (when (apply 'provided-mode-derived-p major-mode modes)
+                                    (list (car name-config)))))
+                              dape-configs)
+                             dape--config-history)
+                            nil nil nil 'dape-history)))
+      (if-let ((config
+		(alist-get (intern candidate) dape-configs)))
+          (list (intern candidate) config)
+	(dape--config-from-string candidate)))))
 \f
 ;;; Hover
 

[-- Attachment #3: Type: text/plain, Size: 1957 bytes --]


Another interesting idea to pursue might be to have modular UIs.
Instead of splitting up the current Emacs frame, I think a minimalist,
more edebug-like interface would be nice, where variable values could be
displayed using overlays instead of having a separate buffer. 

>> Here are a few comments and suggestions I found from a brief skim over
>> the code:
> I made some updates based on your suggestions and added a todo for
> Compat. 

Note that you don't need to add Compat just for `defvar-keymap', as you
could also just use the traditional method of defining a keymap instead:

--8<---------------cut here---------------start------------->8---
(defvar dape-global-map
  (let ((map (make-sparse-keymap)))
    (define-key map "d" #'dape)
    ;; ...
    map))
--8<---------------cut here---------------end--------------->8---

>         Couldn't bring myself to fix all of the checkdoc stuff, but made
> some improvments.

It is not urgent or in any way blocking inclusion to GNU ELPA, it is
just something I think one should keep in mind in the long-term to make
maintaining and contributing to the package easier.

>> Also, sorry for bringing this up, but how married are you to the name?
> I'm not overly attached to it. What are your objections? And do you have
> any suggestions? I find it quite difficult to name things like this.

It just doesn't say that much, and I don't know if it is intended, but
the usual way I would read/pronounce it (rhyming with cape) wouldn't
immediately signal any relation to DAP.  Note that you can use (elisp)
Shorthands to avoid writing out a longer name inside the file, in case a
longer name like debuger-adapter.  It seems there is no package by the
name of "dbg"?  If we are not interested in a self-descriptive and
memorable name, and would want to create a parallel to Eglot (IIRC Emacs
polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
Ebugger?  Edebugger?) might be possible as well.

Re: [ELPA] New package: dape

[James Thomas]

Philip Kaludercic wrote:

>>> Also, sorry for bringing this up, but how married are you to the name?
>> I'm not overly attached to it. What are your objections? And do you have
>> any suggestions? I find it quite difficult to name things like this.
>
> It just doesn't say that much, and I don't know if it is intended, but
> the usual way I would read/pronounce it (rhyming with cape) wouldn't
> immediately signal any relation to DAP.  Note that you can use (elisp)
> Shorthands to avoid writing out a longer name inside the file, in case a
> longer name like debuger-adapter.  It seems there is no package by the
> name of "dbg"?  If we are not interested in a self-descriptive and
> memorable name, and would want to create a parallel to Eglot (IIRC Emacs
> polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
> Ebugger?  Edebugger?) might be possible as well.

There's also 'gudap':

https://github.com/joaotavora/eglot/issues/716#issuecomment-895866818

--

Re: [ELPA] New package: dape

[Philip Kaludercic]

James Thomas <jimjoe@gmx.net> writes:

> Philip Kaludercic wrote:
>
>>>> Also, sorry for bringing this up, but how married are you to the name?
>>> I'm not overly attached to it. What are your objections? And do you have
>>> any suggestions? I find it quite difficult to name things like this.
>>
>> It just doesn't say that much, and I don't know if it is intended, but
>> the usual way I would read/pronounce it (rhyming with cape) wouldn't
>> immediately signal any relation to DAP.  Note that you can use (elisp)
>> Shorthands to avoid writing out a longer name inside the file, in case a
>> longer name like debuger-adapter.  It seems there is no package by the
>> name of "dbg"?  If we are not interested in a self-descriptive and
>> memorable name, and would want to create a parallel to Eglot (IIRC Emacs
>> polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
>> Ebugger?  Edebugger?) might be possible as well.
>
> There's also 'gudap':
>
> https://github.com/joaotavora/eglot/issues/716#issuecomment-895866818

That would make sense if the package was based on gud, but unless I
missed something that is not the case with Daniel's implementation.

That name would make sense when combining the existing GUD/GDB interface
with the DAP extension[0], as an alternative implementation for more
traditional users.

[0] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=de7d7cb58e6209ed11c31f635545ee2ee6ded307

-- 
Philip Kaludercic

Re: [ELPA] New package: dape

[John Yates]

On Sun, Oct 15, 2023 at 11:36 AM Philip Kaludercic <philipk@posteo.net> wrote:
>
> That name would make sense when combining the existing GUD/GDB interface
> with the DAP extension[0], as an alternative implementation for more
> traditional users.

Jaoa made a similar point in the referenced thread:
>
> I would also reuse as much of gud.el as possible, and add to it when the needed functionality isn't there yet.

/john

Re: [ELPA] New package: dape

[Daniel Pettersson]

On Sat, Oct 14, 2023 at 4:54 PM Philip Kaludercic <philipk@posteo.net> wrote:

> I have tried to try it out right now, but because I've never used DAP
> before, I am not sure how to get it running properly.  Nevertheless, I
> think it would be useful to have something along these lines:

Did you get working?

> +      (customize-variable 'dape-configs)

Implemented

> Another interesting idea to pursue might be to have modular UIs.
> Instead of splitting up the current Emacs frame, I think a minimalist,
> more edebug-like interface would be nice, where variable values could be
> displayed using overlays instead of having a separate buffer.

Nice suggestion. I did try to implement a more minimalist interface with
variable overlays.

Which can be enabled with the following.
(setq dape-inline-variables t)
(setq dape-on-start-hooks nil)

Second screenshot in the README.org, it's more inline with edebug. But
there is some issues with placement and variable lookup. The current
implementation relies on regex and font lock to search for symbols.
If that work could be offloaded to Eglot/lsp-mode via xref (*I don't
know if lsp support it). But currently that is not possible because
Eglot only supports looking up reference at point.

> Note that you don't need to add Compat just for `defvar-keymap', as you
> could also just use the traditional method of defining a keymap instead:

Fixed.

> It just doesn't say that much, and I don't know if it is intended, but
> the usual way I would read/pronounce it (rhyming with cape) wouldn't
> immediately signal any relation to DAP.  Note that you can use (elisp)
> Shorthands to avoid writing out a longer name inside the file, in case a
> longer name like debuger-adapter.  It seems there is no package by the
> name of "dbg"?  If we are not interested in a self-descriptive and
> memorable name, and would want to create a parallel to Eglot (IIRC Emacs
> polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
> Ebugger?  Edebugger?) might be possible as well.

"dbg" is nice and sweet, but I think it's a + for discoverability to have
dap in the name of the package. How about eldap? If it should signify
a connection to Eglot, maybe Ebug or even closer Dpoly? Or maybe a
reference to Grace Hopper, hopper.
Personally I like eldap, probably because it feels familiar.

Re: [ELPA] New package: dape

[Adam Porter]

Hi Daniel,

> "dbg" is nice and sweet, but I think it's a + for discoverability to have
> dap in the name of the package. How about eldap? If it should signify
> a connection to Eglot, maybe Ebug or even closer Dpoly? Or maybe a
> reference to Grace Hopper, hopper.
> Personally I like eldap, probably because it feels familiar.

Not that I was invited to this conversation, but I just wanted to point 
out that "eldap" sounds and looks a lot like "LDAP," which might lead 
users to think that it's related to LDAP rather than DAP.  :)

Re: [ELPA] New package: dape

[Krister Schuchardt]

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

Has `dapper` been suggested? Or `edapter`? Might be too silly.

Thanks for the initiative to provide an alternative.

Adam Porter <adam@alphapapa.net> schrieb am Do., 19. Okt. 2023, 05:36:

> Hi Daniel,
>
> > "dbg" is nice and sweet, but I think it's a + for discoverability to have
> > dap in the name of the package. How about eldap? If it should signify
> > a connection to Eglot, maybe Ebug or even closer Dpoly? Or maybe a
> > reference to Grace Hopper, hopper.
> > Personally I like eldap, probably because it feels familiar.
>
> Not that I was invited to this conversation, but I just wanted to point
> out that "eldap" sounds and looks a lot like "LDAP," which might lead
> users to think that it's related to LDAP rather than DAP.  :)
>
>

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

Re: [ELPA] New package: dape

[Dmitry Gutov]

On 19/10/2023 13:52, Krister Schuchardt wrote:
> Has `dapper` been suggested?

I wanted to suggest 'dapper' too. XD

That could be interpreted as a subtle dig at dap-mode, though. Like, 
you're dap, and I'm dapper. ;) Which is probably not the intention.

Re: [ELPA] New package: dape

[John Yates]

On Thu, Oct 19, 2023 at 7:07 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 19/10/2023 13:52, Krister Schuchardt wrote:
> > Has `dapper` been suggested?
>
> I wanted to suggest 'dapper' too. XD
>
> That could be interpreted as a subtle dig at dap-mode, though. Like,
> you're dap, and I'm dapper. ;) Which is probably not the intention.

If we want to avoid the suggestion of a dig, how about dappel?

Re: [ELPA] New package: dape

[Dmitry Gutov]

On 20/10/2023 17:53, John Yates wrote:
> On Thu, Oct 19, 2023 at 7:07 AM Dmitry Gutov<dmitry@gutov.dev>  wrote:
>> On 19/10/2023 13:52, Krister Schuchardt wrote:
>>> Has `dapper` been suggested?
>> I wanted to suggest 'dapper' too. XD
>>
>> That could be interpreted as a subtle dig at dap-mode, though. Like,
>> you're dap, and I'm dapper. 😉 Which is probably not the intention.
> If we want to avoid the suggestion of a dig, how about dappel?

I do like the "dapper" option (it could some with stylized image or 
whatever). "dappel" isn't bad, though there is no noun by that name.

Anyway, it's all up to the author, whether he wants to rename or not.

Re: [ELPA] New package: dape

[João Távora]

On Wed, Nov 1, 2023 at 7:14 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 20/10/2023 17:53, John Yates wrote:
> > On Thu, Oct 19, 2023 at 7:07 AM Dmitry Gutov<dmitry@gutov.dev>  wrote:
> >> On 19/10/2023 13:52, Krister Schuchardt wrote:
> >>> Has `dapper` been suggested?
> >> I wanted to suggest 'dapper' too. XD
> >>
> >> That could be interpreted as a subtle dig at dap-mode, though. Like,
> >> you're dap, and I'm dapper. 😉 Which is probably not the intention.
> > If we want to avoid the suggestion of a dig, how about dappel?
>
> I do like the "dapper" option (it could some with stylized image or
> whatever). "dappel" isn't bad, though there is no noun by that name.
>
> Anyway, it's all up to the author, whether he wants to rename or not.

Just found out about this initiative, great stuff.

I especially like the fact that like Eglot, it seems to be completely
language agnostic and doesn't require little dape-<language>.el
add-ons.

But shouldn't it be using jsonrpc.el?  It seems to implement
that base protocol all over again, much like eglot.el did
in its early days. Was this intentional, is there a limitation
in jsonrpc.el that should be addressed?

As to the name, I think "dape" is fine.

Re: [ELPA] New package: dape

[Daniel Pettersson]

On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net> wrote:
> Did we ever come to a conclusion on this point?

Sorry I have been putting the naming thing off as this thread sparked
a bit of interest in the package which lead to a lot of great input and
bugfixing. There have been a lot of good suggestions and no consensus
which has made the even task harder.

On Thu, Nov 2, 2023 at 5:24 PM João Távora <joaotavora@gmail.com> wrote:
> Just found out about this initiative, great stuff.

Thanks for the encouragement.

> I especially like the fact that like Eglot, it seems to be completely
> language agnostic and doesn't require little dape-<language>.el
> add-ons.
>
> But shouldn't it be using jsonrpc.el?  It seems to implement
> that base protocol all over again, much like eglot.el did
> in its early days. Was this intentional, is there a limitation
> in jsonrpc.el that should be addressed?

Would be great to reuse jsonrpc but for some extremely strange reason
DAP is not an JSONRPC 2.0 protocol.

https://microsoft.github.io/debug-adapter-protocol/specification#Base_Protocol_ProtocolMessage

It's close but not close enough, it's able to reuse jsonrpc process
filter but it falls to pieces in `jsonrpc-connection-receive', due to
slight differences in the protocol. The protocol request/response id is
replaced by seq or request_seq and method is command in DAP to name a
few differences.

If jsonrpc is generalized of any jsonrpc like protocol DAP could make
use of it, but I don't know if that would be a good idea.

> As to the name, I think "dape" is fine.

You would be the first one :) or maybe the second one as someone in
the reddit thread said "dape is dope".

Re: [ELPA] New package: dape

[Philip Kaludercic]

Daniel Pettersson <daniel@dpettersson.net> writes:

> On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net> wrote:
>> Did we ever come to a conclusion on this point?
>
> Sorry I have been putting the naming thing off as this thread sparked
> a bit of interest in the package which lead to a lot of great input and
> bugfixing. There have been a lot of good suggestions and no consensus
> which has made the even task harder.

In the end that is your call, it is just currently a blocking issue
before we add the package to GNU ELPA.

Re: [ELPA] New package: dape

[Philip Kaludercic]

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

Philip Kaludercic <philipk@posteo.net> writes:

> Daniel Pettersson <daniel@dpettersson.net> writes:
>
>> On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net> wrote:
>>> Did we ever come to a conclusion on this point?
>>
>> Sorry I have been putting the naming thing off as this thread sparked
>> a bit of interest in the package which lead to a lot of great input and
>> bugfixing. There have been a lot of good suggestions and no consensus
>> which has made the even task harder.
>
> In the end that is your call, it is just currently a blocking issue
> before we add the package to GNU ELPA.

It seems that the name is here to stay, so I'd go ahead and add the
package to GNU ELPA.  It just seems that you forgot to add a copyright
notice to the package header.  Could you apply a change along these
lines:


[-- Attachment #2: Type: text/plain, Size: 319 bytes --]

diff --git a/dape.el b/dape.el
index f5de1cd..949049d 100644
--- a/dape.el
+++ b/dape.el
@@ -1,5 +1,7 @@
 ;;; dape.el --- Debug Adapter Protocol for Emacs -*- lexical-binding: t -*-
 
+;; Copyright (C) 2023  Free Software Foundation, Inc.
+
 ;; Author: Daniel Pettersson
 ;; Created: 2023
 ;; License: GPL-3.0-or-later

[-- Attachment #3: Type: text/plain, Size: 111 bytes --]


Followed by a  commit (or in the same one) that bumps the "Version"
header, indicating a new package release?

Re: [ELPA] New package: dape

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Daniel Pettersson <daniel@dpettersson.net> writes:
>>
>>> On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net> wrote:
>>>> Did we ever come to a conclusion on this point?
>>>
>>> Sorry I have been putting the naming thing off as this thread sparked
>>> a bit of interest in the package which lead to a lot of great input and
>>> bugfixing. There have been a lot of good suggestions and no consensus
>>> which has made the even task harder.
>>
>> In the end that is your call, it is just currently a blocking issue
>> before we add the package to GNU ELPA.
>
> It seems that the name is here to stay, so I'd go ahead and add the
> package to GNU ELPA.  It just seems that you forgot to add a copyright
> notice to the package header.  Could you apply a change along these
> lines:
>
> diff --git a/dape.el b/dape.el
> index f5de1cd..949049d 100644
> --- a/dape.el
> +++ b/dape.el
> @@ -1,5 +1,7 @@
>  ;;; dape.el --- Debug Adapter Protocol for Emacs -*- lexical-binding: t -*-
>  
> +;; Copyright (C) 2023  Free Software Foundation, Inc.
> +
>  ;; Author: Daniel Pettersson
>  ;; Created: 2023
>  ;; License: GPL-3.0-or-later
>
>
> Followed by a  commit (or in the same one) that bumps the "Version"
> header, indicating a new package release?

I have resolved the issue directly with Daniel.  The package has been
added to GNU ELPA.

Depending on how it is received, it would be nice to see the package be
added to the core in some form or another.  By my book, the naming issue
could be resolved by adding a `start-dap' command (a `start-lsp' alias
for Eglot would also be nice).

Re: [ELPA] New package: dape

[João Távora]

On Tue, Dec 5, 2023 at 8:41 AM Philip Kaludercic <philipk@posteo.net> wrote:

> I have resolved the issue directly with Daniel.  The package has been
> added to GNU ELPA.
>
> Depending on how it is received, it would be nice to see the package be
> added to the core in some form or another.

Yes to this.  I'm working to make it as well received as possible.

In fact, I've been working on dape.el (slightly late unfortunately,
but hope to pick up on that soon) and these enhancements need
`jsonrpc.el` changes too, so I've been working on a branch of Emacs
where dape.el lives alongside eglot.el in core.  Of course this was
just for practical reasons, I'll take it out if there when I'm done,
unless someone tells me to _not_ take it out ;-).

> By my book, the naming issue
> could be resolved by adding a `start-dap' command (a `start-lsp' alias
> for Eglot would also be nice).

There is no real naming issue, but I'm not opposed to adding those
aliases if M-x dape and M-x eglot both stay)

Re: [ELPA] New package: dape

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> On Tue, Dec 5, 2023 at 8:41 AM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> I have resolved the issue directly with Daniel.  The package has been
>> added to GNU ELPA.
>>
>> Depending on how it is received, it would be nice to see the package be
>> added to the core in some form or another.
>
> Yes to this.  I'm working to make it as well received as possible.
>
> In fact, I've been working on dape.el (slightly late unfortunately,
> but hope to pick up on that soon) and these enhancements need
> `jsonrpc.el` changes too, so I've been working on a branch of Emacs
> where dape.el lives alongside eglot.el in core.  Of course this was
> just for practical reasons, I'll take it out if there when I'm done,
> unless someone tells me to _not_ take it out ;-).

I guess that depends on what model of development Daniel would prefer.

>> By my book, the naming issue
>> could be resolved by adding a `start-dap' command (a `start-lsp' alias
>> for Eglot would also be nice).
>
> There is no real naming issue, but I'm not opposed to adding those
> aliases if M-x dape and M-x eglot both stay)

Hence the "in my book", I know there is disagreement there, it is just
that my main objection "Arbitrary names are difficult to memorise and
communicate" would be sufficiently resolved by adding these kinds of
aliases.

Re: [ELPA] New package: dape

[João Távora]

On Tue, Dec 5, 2023 at 10:59 AM Philip Kaludercic <philipk@posteo.net> wrote:
 the "in my book", I know there is disagreement there, it is just
> that my main objection "Arbitrary names are difficult to memorise and
> communicate" would be sufficiently resolved by adding these kinds of
> aliases.

Every name is arbitrary.  Sausurre reminded us of that 100
years ago, the Greeks knew it much earlier [1] </pedant>.  In
practice, please remember that reaming things and introducing aliases
_also_ has a cost in terms of brain stress (maybe not your brain,
granted).

[1] https://www.degruyter.com/document/doi/10.1515/semi.1989.75.1-2.63/html

Re: [ELPA] New package: dape

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

  > Every name is arbitrary. 

That is true, when "arbitrary" is understood with the appropriate
broad meaning.  No choice of name is absolutely forced.

But that's not the meaning that Kaludercic was using, so your reply
changes the question under discussion.  Certainly some names can fit
their meanings in a way that is more memorable while others fit less
memorably.



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] New package: dape

[Daniel Pettersson]

For those of you asking for a "gud" (gdb-mi) like interface, I have
spent some time and effort to make that happen. I am not a gdb-mi user
myself so I can't really tell whats parts are missing for a gdb-mi
like experience, ontop of that I can't run gdb on my machine.

I would greatly appreciate some feedback on this change.

(setq dape-buffer-window-arrangment 'gud)
(setq dape-info-hide-mode-line nil)

Unfortunately there is no "real" integration with gdb-mi as I couldn't
find a way to decouple the UI from gdb-mi. It does however greatly
rely on gdb-table. And I took some liberties of keeping the tree
nature of the old variable explorer.

Re: [ELPA] New package: dape

[Eli Zaretskii]

> From: Daniel Pettersson <daniel@dpettersson.net>
> Date: Wed, 6 Dec 2023 11:09:15 +0100
> Cc: Philip Kaludercic <philipk@posteo.net>, Dmitry Gutov <dmitry@gutov.dev>, 
>  John Yates <john@yates-sheets.org>,
>  Krister Schuchardt <krister.schuchardt@gmail.com>, 
>  Adam Porter <adam@alphapapa.net>, emacs-devel@gnu.org
> 
> For those of you asking for a "gud" (gdb-mi) like interface, I have
> spent some time and effort to make that happen. I am not a gdb-mi user
> myself so I can't really tell whats parts are missing for a gdb-mi
> like experience, ontop of that I can't run gdb on my machine.
> 
> I would greatly appreciate some feedback on this change.
> 
> (setq dape-buffer-window-arrangment 'gud)
> (setq dape-info-hide-mode-line nil)
> 
> Unfortunately there is no "real" integration with gdb-mi as I couldn't
> find a way to decouple the UI from gdb-mi. It does however greatly
> rely on gdb-table. And I took some liberties of keeping the tree
> nature of the old variable explorer.

Thanks for working on this, but would you mind explaining in more
detail what are you trying to achieve?  Recent versions of GDB support
the DAP protocol internally, so why do we need to support it in Emacs
when working with GDB as the debugging back-end?  I'm probably missing
something.

Re: [ELPA] New package: dape

[João Távora]

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

On Wed, Dec 6, 2023, 12:30 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Daniel Pettersson <daniel@dpettersson.net>
> > Date: Wed, 6 Dec 2023 11:09:15 +0100
> > Cc: Philip Kaludercic <philipk@posteo.net>, Dmitry Gutov <
> dmitry@gutov.dev>,
> >  John Yates <john@yates-sheets.org>,
> >  Krister Schuchardt <krister.schuchardt@gmail.com>,
> >  Adam Porter <adam@alphapapa.net>, emacs-devel@gnu.org
> >
> > For those of you asking for a "gud" (gdb-mi) like interface, I have
> > spent some time and effort to make that happen. I am not a gdb-mi user
> > myself so I can't really tell whats parts are missing for a gdb-mi
> > like experience, ontop of that I can't run gdb on my machine.
> >
> > I would greatly appreciate some feedback on this change.
> >
> > (setq dape-buffer-window-arrangment 'gud)
> > (setq dape-info-hide-mode-line nil)
> >
> > Unfortunately there is no "real" integration with gdb-mi as I couldn't
> > find a way to decouple the UI from gdb-mi. It does however greatly
> > rely on gdb-table. And I took some liberties of keeping the tree
> > nature of the old variable explorer.
>
> Thanks for working on this, but would you mind explaining in more
> detail what are you trying to achieve?  Recent versions of GDB support
> the DAP protocol internally, so why do we need to support it in Emacs
> when working with GDB as the debugging back-end?  I'm probably missing
> something.
>

I think what you're missing is that the support is the other way round. I'm
recent versions of GDB you can talk to it via DAP.

But that doesn't help when reusing the UI of gdb-mi.el to talk to non-gdb
DAP debuggers. And that interface reuse (which would be a great thing if it
were particle and clean, granted) is what Daniel is presumably trying to
achieve.

At least this is my understanding.
João

>

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

Re: [ELPA] New package: dape

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 6 Dec 2023 12:56:12 +0000
> Cc: Daniel Pettersson <daniel@dpettersson.net>,
>  "Philip K." <philipk@posteo.net>, 
>  Dmitry Gutov <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>, 
>  Krister Schuchardt <krister.schuchardt@gmail.com>,
>  Adam Porter <adam@alphapapa.net>, emacs-devel <emacs-devel@gnu.org>
> 
> I think what you're missing is that the support is the other way round. I'm recent versions of GDB you
> can talk to it via DAP. 

Why would we want to do that in Emacs, when we already have gdb-mi?

> But that doesn't help when reusing the UI of gdb-mi.el to talk to non-gdb DAP debuggers.

Like what?

> And that
> interface reuse (which would be a great thing if it were particle and clean, granted) is what Daniel is
> presumably trying to achieve.

gdb-mi is explicitly meant to be used with the GDB/MI interface, not
with anything else.  It makes little sense with other interpreters.
The only part that could be theoretically extracted is the setup of
several debugging-related windows, but doing that from scratch should
be a very simple task, and there's nothing in gdb-mi that AFAICT is
unique in those few portions.  Moreover, I won't be surprised if some
UI decisions in gdb-mi were not made specifically to cater to G|DB and
its MI protocol.

IOW, I don't see why someone would want to reuse gdb-mi's code if we
only need to reuse the few UI parts of it.  It sounds like more
trouble than worth it.

Re: [ELPA] New package: dape

[João Távora]

On Wed, Dec 6, 2023 at 1:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 6 Dec 2023 12:56:12 +0000
> > Cc: Daniel Pettersson <daniel@dpettersson.net>,
> >  "Philip K." <philipk@posteo.net>,
> >  Dmitry Gutov <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>,
> >  Krister Schuchardt <krister.schuchardt@gmail.com>,
> >  Adam Porter <adam@alphapapa.net>, emacs-devel <emacs-devel@gnu.org>
> >
> > I think what you're missing is that the support is the other way round. I'm recent versions of GDB you
> > can talk to it via DAP.
>
> Why would we want to do that in Emacs, when we already have gdb-mi?

Noone proposed that, AFAIU.  But that's what DAP support in GDB is
and that's what you asked about.

As to "why we would want"... No idea... But imagine that dape.el ends
up supporting a much nicer UI than gdb-mi.el?  More responsive,
robust, great keybindings, etc.  Than I imagine some people would
want to talk to GDB using that UI instead of gdb-mi.el's.

> > But that doesn't help when reusing the UI of gdb-mi.el to talk to non-gdb DAP debuggers.
>
> Like what?

Like a lot of non-GDB debuggers these days talk DAP.  Here's a
big list: https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/

> > And that
> > interface reuse (which would be a great thing if it were particle and clean, granted) is what Daniel is
> > presumably trying to achieve.
>
> gdb-mi is explicitly meant to be used with the GDB/MI interface, not
> with anything else.  It makes little sense with other interpreters.
> The only part that could be theoretically extracted is the setup of
> several debugging-related windows, but doing that from scratch should
> be a very simple task, and there's nothing in gdb-mi that AFAICT is
> unique in those few portions.  Moreover, I won't be surprised if some
> UI decisions in gdb-mi were not made specifically to cater to G|DB and
> its MI protocol.
>
> IOW, I don't see why someone would want to reuse gdb-mi's code if we
> only need to reuse the few UI parts of it.  It sounds like more
> trouble than worth it.

I don't know gdb-mi.el very well, but if it has code for displaying
and interacting with lists of threads, local variables, registers,
breakpoints, displaying assembly, then IMO it could well make sense
to lift that interface to something that both gdb-mi.el and dape.el
could use.  That's less code for us to maintain and potential
improvements to that liften code would benefit both extensions.

As you know, Eglot uses this approach: it tries to add as little UI
as possible and reuse existing things in Emacs.  Frequently I end up
doing work to generalize these existing components in
backward-compatible fashion for that effect.   Which is not always,
because sometimes it's not an easy job.

I personally wouldn't write it off as "more trouble than it's
worth", without a more or less thorough analysis of the similarities
and differences between these UIs.  Cost-benefit analysis are
usually hard questions to answer.

João

Re: [ELPA] New package: dape

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 6 Dec 2023 13:38:54 +0000
> Cc: daniel@dpettersson.net, philipk@posteo.net, dmitry@gutov.dev, 
> 	john@yates-sheets.org, krister.schuchardt@gmail.com, adam@alphapapa.net, 
> 	emacs-devel@gnu.org
> 
> As to "why we would want"... No idea... But imagine that dape.el ends
> up supporting a much nicer UI than gdb-mi.el?

If the gdb-mi UI needs improvement, I'd rather we improve it instead
of ditching it.  GDB/MI is _the_ official GDB way for GUI front-ends,
and will remain so for the years to come.  It will take the DAP
interface some time to get there, and even when it does, GDB/MI will
always integrate better with GDB, since it is being developed by the
GDB project, unlike DAP which is primarily modeled on "other
debuggers".

> More responsive, robust, great keybindings, etc.  Than I imagine
> some people would want to talk to GDB using that UI instead of
> gdb-mi.el's.

Only if we fail to keep gdb-mi up to the job.

> > > But that doesn't help when reusing the UI of gdb-mi.el to talk to non-gdb DAP debuggers.
> >
> > Like what?
> 
> Like a lot of non-GDB debuggers these days talk DAP.  Here's a
> big list: https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/

I know the list.  I was asking which of them we'd need to support, and
why?

> > IOW, I don't see why someone would want to reuse gdb-mi's code if we
> > only need to reuse the few UI parts of it.  It sounds like more
> > trouble than worth it.
> 
> I don't know gdb-mi.el very well, but if it has code for displaying
> and interacting with lists of threads, local variables, registers,
> breakpoints, displaying assembly, then IMO it could well make sense
> to lift that interface to something that both gdb-mi.el and dape.el
> could use.  That's less code for us to maintain and potential
> improvements to that liften code would benefit both extensions.

What gdb-mi has is code that parses the GDB/MI output and shows the
results.  Factoring out the display part out of that will leave you
with mostly trivial stuff.  For example, the display part of showing
the threads in a program is gdb-table-add-row and a couple of simple
subroutines, whereas the function that handles threads display is
built around code specific to GDB/MI output and structures into which
that output is parsed, and relies on thread info provided by GDB; see
gdb-thread-list-handler-custom.

> As you know, Eglot uses this approach: it tries to add as little UI
> as possible and reuse existing things in Emacs.

Eglot started from LSP and provides only features supported by LSP.
gdb-mi started from GDB/MI and supports only that protocol.  A better
analogy for this discussion is how easy will it be to move Eglot to a
completely different protocol, and on top of that a protocol that is
not based on JSON but on some other structured output.

Moreover, where Eglot plugs itself into Emacs editing features, a
debugging package has no features to plug itself into, because
debugging is very different from editing programs.

> I personally wouldn't write it off as "more trouble than it's
> worth", without a more or less thorough analysis of the similarities
> and differences between these UIs.

Which UIs are we talking about here?

Re: [ELPA] New package: dape

[João Távora]

On Wed, Dec 6, 2023 at 5:00 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > As to "why we would want"... No idea... But imagine that dape.el ends
> > up supporting a much nicer UI than gdb-mi.el?
>
> If the gdb-mi UI needs improvement, I'd rather we improve it instead
> of ditching it.

Who proposed "ditching"?  If a much nicer general free software UI
appears that supports GDB perfectly, does everything gdb-mi.el's
does and more, and yet also supports DAP, it seems nonsensical to me
not to want gdb-mi.el (and why not edebug.el) to use it.

> > > > But that doesn't help when reusing the UI of gdb-mi.el to talk to non-gdb DAP debuggers.
> > > Like what?
> > Like a lot of non-GDB debuggers these days talk DAP.  Here's a
> > big list: https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/
>
> I know the list.  I was asking which of them we'd need to support, and
> why?

All of them.  DAP is like LSP.  Eglot supports all LSP servers and Dape
supports all DAP debuggers.

> Eglot started from LSP and provides only features supported by LSP.
> gdb-mi started from GDB/MI and supports only that protocol.  A better
> analogy for this discussion is how easy will it be to move Eglot to a
> completely different protocol, and on top of that a protocol that is
> not based on JSON but on some other structured output.

No, that's not a good analogy at all.  Noone is advocating for
making GDB/MI support DAP.  If anything, I (and others?) suggested
that some existing debugger interaction code could be lifted from
existing debugger UI's in Emacs (gdb-mi.el, gud.el, edebug.el, etc)
to be reusable by all these debuggers, along with Dape.  Much like
Flymake, Xref, Eldoc, Imenu etc UI can be used by many other
extensions, along with Eglot.

Tangentially, despite not being a good analogy at all, it wouldn't
be very hard to move Eglot to that other imaginary LSP not
based on JSON at all.  Eglot deals with plists as the representation
of structured output.  jsonrpc.el knows JSON things, Eglot barely.

> Moreover, where Eglot plugs itself into Emacs editing features, a
> debugging package has no features to plug itself into, because
> debugging is very different from editing programs.

That's a self-fulfilling prophecy: it has none of these because things
like breakpoint management in Emacs are not generalized in a way
that allows plugging in.  It's as if ElDoc had stayed heavily
Elisp-centric and async-incapable.  Then there would be no good
place for Eglot to plug itself in for at-point documentation purposes.
But we changed ElDoc for the better and now both Elisp and Eglot take
advantage of that UI.

> > I personally wouldn't write it off as "more trouble than it's
> > worth", without a more or less thorough analysis of the similarities
> > and differences between these UIs.
>
> Which UIs are we talking about here?

Breakpoint setting and management, thread display, stepping,
data examination, debugger-specific window management, etc.
Synchronizing these things between Elisp presentation and
backend debugger objects don't seem a trivial thing to me,
but then again I've never had to implement them.  If they are
trivial to you, that's great I guess.  I'll take simpler over
complicated any day.

Anyway, I'd just like to state here that I just entered this
conversation to clarify something about DAP support in GDB.

In particular, and detecting some defensive tones here, I'd
like to state that I have 0 intention to undermine gdb-mi.el,
gud.el or GDB (my favourite debugger, though not thru Emacs) in
any way.  I won't speak for Daniel, but I would guess he also
doesn't have this intention.

Finally, I have no indication that it's actually worth the
trouble to do the lifting I suggested, or that it's worth
looking into right away.  I merely suggested it should be
taken into consideration and not hastily written off.  This
is just good software architecture practice in my book, a
book I won't impinge on the gdb-mi.el maintainers or anyone
that doesn't want to read it.

I've had a look at dape.el and it looks very well programmed
except perhaps for the part where it doesn't use jsonrpc.el
and thus can't benefit from its primitives.  But that is not the
programmer's fault, since DAP is similar but not quite JSONRPC
and I not have yet published the changes in scratch/jsonrpc-things
that would make such use possible.  And that is the part that
I'm working to enhance.  I haven't given much thought to its
UI.

João

Re: [ELPA] New package: dape

[Daniel Pettersson]

First off I got a bunch of request of making the interface for dape
more like GUD, which is to say that they requested an interface more
like the gdb-mi.el's interface. This is where gdb-mi.el enters the
picture.

First of I am not saying that it's worth the effort, but if this is
the consensus that the best thing for "dape" or whatever it should be
called is if it should be more like "GUD" it seams like it would be
preferable if it could reuse ui "components"  and it's bindings from
gdb-mi.el

On Wed, Dec 6, 2023 at 6:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
> If the gdb-mi UI needs improvement, I'd rather we improve it instead
> of ditching it.  GDB/MI is _the_ official GDB way for GUI front-ends,
> and will remain so for the years to come.  It will take the DAP
> interface some time to get there, and even when it does, GDB/MI will
> always integrate better with GDB, since it is being developed by the
> GDB project, unlike DAP which is primarily modeled on "other
> debuggers".

This speaks to my point really, if gdb-mi is THE ui for debugging
wouldn't it be great if you could use the sameish ui to debug python,
java, javascript, dart, godot etc.. I am not suggesting that gdb-mi.el
should be replaced by "dape" just that they share some UI and
keybindings.

I don't think it's fair to say that DAP is primarily modeled on "other
debuggers". My opinion is that DAP has been developed to get vs code
to support launching and debugging programs in a variety of
programming languages. To use words like modeled or designed gives it
to much credit. But the adapter implementations is very capable
of getting the job done. For some reasons unbeknownst to me there has
been no big leaps in debugging, we still set breakpoints, watch
variables and step through our code. All of this and more is supported
by DAP and gdb-mi.el has the interface and keybindings to support such
a workflow, it's just tightly coupled with gdb-mi.

Maybe it's fine as it is is and dape can incorporate improvements to
gdb-mi.el's interface and maybe vise versa.

I made an effort to get dape to feel like it's somewhat consistent
with gdb-mi.el and to gauge the progress I would greatly appreciate
some feedback, it would be great if Eli or any other person who has
experience with gdb-mi.el could help me out.

Daniel

Re: [ELPA] New package: dape

[Eli Zaretskii]

> From: Daniel Pettersson <daniel@dpettersson.net>
> Date: Thu, 7 Dec 2023 00:55:46 +0100
> Cc: João Távora <joaotavora@gmail.com>, 
> 	philipk@posteo.net, dmitry@gutov.dev, john@yates-sheets.org, 
> 	krister.schuchardt@gmail.com, adam@alphapapa.net, emacs-devel@gnu.org
> 
> I don't think it's fair to say that DAP is primarily modeled on "other
> debuggers". My opinion is that DAP has been developed to get vs code
> to support launching and debugging programs in a variety of
> programming languages. To use words like modeled or designed gives it
> to much credit. But the adapter implementations is very capable
> of getting the job done. For some reasons unbeknownst to me there has
> been no big leaps in debugging, we still set breakpoints, watch
> variables and step through our code. All of this and more is supported
> by DAP and gdb-mi.el has the interface and keybindings to support such
> a workflow, it's just tightly coupled with gdb-mi.

If you want to mimic the UX of gdb-mi, in the sense that you want to
support the same windows and key bindings, that is okay.  But it
doesn't require to take code out of gdb-mi or factor out that code.
Arranging windows and binding commands to keys is a simple matter that
can be coded from scratch, whereas factoring out code that wasn't
supposed to be factored out is a much larger job.

> Maybe it's fine as it is is and dape can incorporate improvements to
> gdb-mi.el's interface and maybe vise versa.
> 
> I made an effort to get dape to feel like it's somewhat consistent
> with gdb-mi.el and to gauge the progress I would greatly appreciate
> some feedback, it would be great if Eli or any other person who has
> experience with gdb-mi.el could help me out.

Feel free to ask specific questions, I'm sure you will get the best
answers we can provide (although the person who originally wrote
gdb-mi is no longer seen around here).

Thanks.

Re: [ELPA] New package: dape

[Adam Porter]

Hi Daniel,

On 11/4/23 04:51, Daniel Pettersson wrote:
> On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net>wrote:
>> Did we ever come to a conclusion on this point?
> Sorry I have been putting the naming thing off as this thread
> sparked a bit of interest in the package which lead to a lot of great
> input and bugfixing. There have been a lot of good suggestions and no
> consensus which has made the even task harder.
My friendly advice is to keep the name you chose and not entertain any 
more suggestions.  The package is your work, and you are generously 
contributing it to Emacs and the community.  It is yours to name.

While friendly, gentle suggestions are ok, the pressure being put on 
authors in this process is unbecoming, to say the least.  It definitely 
discourages further submissions.  I'm noticing that the GNU ELPA 
submission process is developing a poor reputation in the outside world 
due to this kind of bikeshedding.

Re: [ELPA] New package: dape

[Eli Zaretskii]

> Date: Sat, 4 Nov 2023 08:46:35 -0500
> Cc: Dmitry Gutov <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>,
>  Krister Schuchardt <krister.schuchardt@gmail.com>, emacs-devel@gnu.org,
>  philipk@posteo.net
> From: Adam Porter <adam@alphapapa.net>
> 
> While friendly, gentle suggestions are ok, the pressure being put on 
> authors in this process is unbecoming, to say the least.

Please stop the insinuations.  There's no pressure.  We are asking
authors to consider changing the names, that's all; if they don't
agree, the issue is dropped on the floor.  It is, after all, our
prerogative and even our job, out of the wish to serve our users
better, to try to have packages with reasonablt self-explanatory names
where possible.  You don't have to like it, but at least please
respect our views on that and our perspective.  Your flat rejection of
it is unbecoming, to say the least.

Re: [ELPA] New package: dape

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 4 Nov 2023 08:46:35 -0500
>> Cc: Dmitry Gutov <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>,
>>  Krister Schuchardt <krister.schuchardt@gmail.com>, emacs-devel@gnu.org,
>>  philipk@posteo.net
>> From: Adam Porter <adam@alphapapa.net>
>> 
>> While friendly, gentle suggestions are ok, the pressure being put on 
>> authors in this process is unbecoming, to say the least.
>
> Please stop the insinuations.  There's no pressure.  We are asking
> authors to consider changing the names, that's all; if they don't
> agree, the issue is dropped on the floor.  It is, after all, our
> prerogative and even our job, out of the wish to serve our users
> better, to try to have packages with reasonablt self-explanatory names
> where possible.  You don't have to like it, but at least please
> respect our views on that and our perspective.  Your flat rejection of
> it is unbecoming, to say the least.

In addition to this, there have on multiple occasions been authors who
have been open and appreciative of names being suggested here on the
mailing list, especially if they don't have a strong opinion wrt the
name to begin with.  It seems unjustified to claim that mentioning the
topic will necessarily scare people away.  (I didn't want to bring this
up initially, but one of the reasons I mentioned changing the name is
due to the small edit distance between "dape" and "r*pe", that I can
imagine would make other people more uncomfortable).

Re: [ELPA] New package: dape

[Adam Porter]

Hello Philip,

> In addition to this, there have on multiple occasions been authors
> who have been open and appreciative of names being suggested here on
> the mailing list, especially if they don't have a strong opinion wrt
> the name to begin with.  It seems unjustified to claim that
> mentioning the topic will necessarily scare people away.

Please don't misunderstand me.  I am not claiming that it will
necessarily scare people away.  I am claiming that the bikeshedding can
be discouraging to authors who consider submitting to GNU ELPA.  This
should not be surprising, as I don't think anyone would enjoy having to
endure a lengthy thread second-guessing their decision, which usually
seems to proceed with the assumption that the author hasn't already
spent time making it deliberately.

As well, I can go through the list of packages on GNU ELPA and find tens 
of them whose names don't bear any apparent relation to their purpose or 
description.  Should that stop us from seeking better names?  Of course 
not.  But at what point do we admit that Shakespeare was right?

> (I didn't want to bring this up initially, but one of the reasons I
> mentioned changing the name is due to the small edit distance between
> "dape" and "r*pe", that I can imagine would make other people more
> uncomfortable).

Well, let's see, in QWERTY order: tape, ape, gape, jape, cape, vape, 
nape...  I think that's not a practical reason to reject an author's 
name, and not a very polite association to make with the name he chose.

Re: [ELPA] New package: dape

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> Hello Philip,
>
>> In addition to this, there have on multiple occasions been authors
>> who have been open and appreciative of names being suggested here on
>> the mailing list, especially if they don't have a strong opinion wrt
>> the name to begin with.  It seems unjustified to claim that
>> mentioning the topic will necessarily scare people away.
>
> Please don't misunderstand me.  I am not claiming that it will
> necessarily scare people away.  I am claiming that the bikeshedding can
> be discouraging to authors who consider submitting to GNU ELPA.  This
> should not be surprising, as I don't think anyone would enjoy having to
> endure a lengthy thread second-guessing their decision, which usually
> seems to proceed with the assumption that the author hasn't already
> spent time making it deliberately.

In this context, as is usually the case with a package submission, I
submitted comments and suggestions on how to improve the package, and
then apologised for braining up the topic of naming the package, to see
if Daniel was committed or not to the name (implying they have spent
time making a deliberate decision), to which he responded:

  I'm not overly attached to it. What are your objections? And do you have
  any suggestions? I find it quite difficult to name things like this.

Which I think is a fair starting point for a discussion.

> As well, I can go through the list of packages on GNU ELPA and find
> tens of them whose names don't bear any apparent relation to their
> purpose or description.  Should that stop us from seeking better
> names?  Of course not.  But at what point do we admit that Shakespeare
> was right?

That is true, but there are a number of them with great names IMO:

- aggressive-completion
- comint-mime
- cycle-at-point
- idle-highlight-mode
- notmuch-indicator
- page-break-lines
- rainbow-delimiters
- scroll-on-jump
- visual-fill-column

I have always associated GNU ELPA with having proper and expressive
names, that either are self-descriptive or re-use nomenclature that
Emacs users would be familiar with to begin with (things like "electric"
or "i"-something for interactive).  Makes it easier to remember the
names and builds on intuition, which we shouldn't underestimate as a
measure for user comfort.  Not everyone is young and enthusiastic enough
to keep memorising and associating new names.

>> (I didn't want to bring this up initially, but one of the reasons I
>> mentioned changing the name is due to the small edit distance between
>> "dape" and "r*pe", that I can imagine would make other people more
>> uncomfortable).
>
> Well, let's see, in QWERTY order: tape, ape, gape, jape, cape, vape,
> nape...  I think that's not a practical reason to reject an author's
> name, and not a very polite association to make with the name he
> chose.

I am not sure what you are trying to say here, this is just the
association I made.  I usually think about how saying packages names out
loud, when speaking with other people feels like.  Names name "eglot"
(not 'elgot) or "vertico" (not "vertigo") are frequently misunderstood
in my experience, and names in this case I could imagine a third person
listening in on a conversation could misunderstand something, because it
sounds like a slang word.  FWIW urban dictionary doesn't have the nicest
entry when you look up "dape"...

Re: [ELPA] New package: dape

[Adam Porter]

Hello Eli,

>> Date: Sat, 4 Nov 2023 08:46:35 -0500 Cc: Dmitry Gutov 
>> <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>, Krister 
>> Schuchardt <krister.schuchardt@gmail.com>, emacs-devel@gnu.org, 
>> philipk@posteo.net From: Adam Porter <adam@alphapapa.net>
>> 
>> While friendly, gentle suggestions are ok, the pressure being put 
>> on authors in this process is unbecoming, to say the least.
> 
> Please stop the insinuations.  There's no pressure.  We are asking 
> authors to consider changing the names, that's all; if they don't 
> agree, the issue is dropped on the floor.

I don't mean to insinuate.  I mean to share observations and 
experiences.  You and others may not intend to pressure authors, but 
when a thread bikeshedding a name goes on for 10 or 20 messages with 
numerous authors piling on their own hues, it can feel, to the author, 
like he is being pressured to change his mind, or that his contribution 
is being, well, taken away, to an extent.

This is especially so when it is not made clear, up front, that the 
author's decision will be accepted in the end, even if he politely 
declines to rename the library.

This is not only my own experience.  The way this issue recurs when 
packages are submitted is noticed in the wider community, and it harms 
GNU ELPA's reputation.  I report this observation with the intent to 
help, not to insinuate or insult.
> It is, after all, our prerogative and even our job, out of the wish 
> to serve our users better, to try to have packages with reasonably
> self-explanatory names where possible.

As I've said numerous times on this list, I agree with that principle.
> You don't have to like it, but at least please respect our views on
> that and our perspective. Your flat rejection of it is unbecoming, to
> say the least.

As I've said numerous times on this list, including in the past few 
days, I do not reject your view, flatly or otherwise.  Please don't 
misrepresent my view, either.

My view is that a name should be chosen with respect to various 
criteria; a name's being self-explanatory is one of them, but is not the 
only, nor even the highest, concern.

To try to make this message productive, I have a concrete suggestion: 
When a package is submitted to GNU ELPA, and it is suggested that the 
author consider renaming it, it should be made clear at the time that 
the suggestion is merely that, and that the author's final decision will 
be accepted.  That would likely help to defuse any feelings of pressure 
that might be felt as the discussion proceeds (and perhaps even make the 
author more receptive to suggestions).

Thanks,
Adam

Re: [ELPA] New package: dape

[Eli Zaretskii]

> Date: Sat, 4 Nov 2023 09:53:46 -0500
> Cc: adam@alphapapa.net, daniel@dpettersson.net, dmitry@gutov.dev,
>  emacs-devel@gnu.org, joaotavora@gmail.com, john@yates-sheets.org,
>  krister.schuchardt@gmail.com, philipk@posteo.net
> From: Adam Porter <adam@alphapapa.net>
> 
> >> While friendly, gentle suggestions are ok, the pressure being put 
> >> on authors in this process is unbecoming, to say the least.
> > 
> > Please stop the insinuations.  There's no pressure.  We are asking 
> > authors to consider changing the names, that's all; if they don't 
> > agree, the issue is dropped on the floor.
> 
> I don't mean to insinuate.  I mean to share observations and 
> experiences.  You and others may not intend to pressure authors, but 
> when a thread bikeshedding a name goes on for 10 or 20 messages with 
> numerous authors piling on their own hues, it can feel, to the author, 
> like he is being pressured to change his mind, or that his contribution 
> is being, well, taken away, to an extent.

I very much doubt that authors feel this way, but even if they do,
that feeling is unjustified, even if the 10 or 20 figures are correct
(which I'm not at all sure they are: for example, in the current case
I don't think there were anywhere near 10 or 20 messages asking to
change the name).

> This is especially so when it is not made clear, up front, that the 
> author's decision will be accepted in the end, even if he politely 
> declines to rename the library.

It should be abundantly clear that the authors have the last word on
this.  How else can it be?  It is the author who contributes the
package, so we have no means of forcing him or her to do anything they
don't want.  Even suggesting that is an insult of sorts.

> This is not only my own experience.  The way this issue recurs when 
> packages are submitted is noticed in the wider community, and it harms 
> GNU ELPA's reputation.  I report this observation with the intent to 
> help, not to insinuate or insult.

I'm sorry, but these experiences are wrong, and I dare to say that
posts like yours are at least one factor for these incorrect
conclusions.

Once again: there's no pressure, and there can be no pressure.  It's
an illusion.

> My view is that a name should be chosen with respect to various 
> criteria; a name's being self-explanatory is one of them, but is not the 
> only, nor even the highest, concern.

There can always be a better name, all these considerations
notwithstanding.  So we will continue asking authors to consider
changing the names when the original name is far from being
self-explanatory.  Once again, it is our _duty_, exactly as it's our
duty to make sure the code's copyright is assigned to the FSF and that
the code follows our coding conventions.  (The latter issues, btw, are
much more significant contributors to "harming ELPA reputation".)

> To try to make this message productive, I have a concrete suggestion: 
> When a package is submitted to GNU ELPA, and it is suggested that the 
> author consider renaming it, it should be made clear at the time that 
> the suggestion is merely that, and that the author's final decision will 
> be accepted.  That would likely help to defuse any feelings of pressure 
> that might be felt as the discussion proceeds (and perhaps even make the 
> author more receptive to suggestions).

Here's the text I posted in this particular case:

  I wonder if you could come up with a name that tells something about
  the package's purpose.  "plz-see" tells me "please see", and I don't
  see any relation to HTTP, REST, pretty-printing, or popup buffers.

Please tell me how is this anything but "a mere suggestion".

P.S. I took the liberty of removing addressees from the CC list and
leaving on the mailing list, as I don't see the need to bother people
personally, especially since all or almost all of them read this list
anyway.

Re: [ELPA] New package: dape

[Adam Porter]

Hi Eli,

>> I don't mean to insinuate.  I mean to share observations and 
>> experiences.  You and others may not intend to pressure authors, but 
>> when a thread bikeshedding a name goes on for 10 or 20 messages with 
>> numerous authors piling on their own hues, it can feel, to the author, 
>> like he is being pressured to change his mind, or that his contribution 
>> is being, well, taken away, to an extent.
> 
> I very much doubt that authors feel this way, but even if they do,
> that feeling is unjustified, even if the 10 or 20 figures are correct >
> It should be abundantly clear that the authors have the last word on
> this.  How else can it be?  It is the author who contributes the
> package, so we have no means of forcing him or her to do anything they
> don't want.  Even suggesting that is an insult of sorts.
> 
> I'm sorry, but these experiences are wrong, and I dare to say that
> posts like yours are at least one factor for these incorrect
> conclusions.
> 
> Once again: there's no pressure, and there can be no pressure.  It's
> an illusion.

I understand and appreciate that no pressure is intended toward me or 
any other authors who submit their packages to ELPA, with regard to the 
name that is chosen for a package.

However, what I'm trying to say is that that intention is not always 
clearly communicated to the authors.  As well, observers also take note 
of these discussions, and from talking with some of them, it's not 
uncommonly interpreted as pressure--and that is, I think, to the 
detriment of ELPA's reputation (only my opinion, of course).

I've been using Emacs and participating in the wider community for a 
number of years now.  I have a decent understanding of the varying 
cultures and norms of emacs-devel, Reddit's Emacs-related subreddits, 
the "blogosphere," IRC/Matrix chat, etc.  I interact regularly with 
users who are new to Emacs, and users who are new to writing and 
contributing Elisp code and packages.  I've advised many of them, 
written my own Elisp packaging guide, etc.

And something I've observed is that people are often intimidated by 
emacs-devel, the ELPA submission process, etc.  That is not to say that 
they *should be* intimidated, but they are.  It often takes some 
encouraging to "get over the hump" and actually submit a package to ELPA.

So imagine being one of those authors, likely new to Elisp development, 
often not considering oneself to "really" be a "programmer" (even though 
they are), and presenting one's work in this "hallowed" place for 
evaluation by the legendary hackers and maintainers of Emacs (not that 
these hackers and maintainers view themselves that way).

When they reply asking that the package be renamed--and sometimes more 
than just asking or suggesting; sometimes the name is criticized as 
being unhelpful, and then it's even said that such names are harmful to 
Emacs and to users--well, I think it's easy for a contributor to 
interpret such replies as more than just asking or suggesting.

> There can always be a better name, all these considerations
> notwithstanding.  So we will continue asking authors to consider
> changing the names when the original name is far from being
> self-explanatory.  Once again, it is our _duty_, exactly as it's our
> duty to make sure the code's copyright is assigned to the FSF and that
> the code follows our coding conventions.  (The latter issues, btw, are
> much more significant contributors to "harming ELPA reputation".)

I wouldn't expect otherwise.  I would suggest only that you (or whoever 
asks) consider making the suggestion more gently (less as a criticism), 
and that it be made clear that the request is just a request, not a 
requirement to be met in order to proceed.  It seems common for an 
impression to be left that the package may be added after a consensus is 
reached on a name, which, as you said, isn't intended.

> Here's the text I posted in this particular case:
> 
>   I wonder if you could come up with a name that tells something about
>   the package's purpose.  "plz-see" tells me "please see", and I don't
>   see any relation to HTTP, REST, pretty-printing, or popup buffers.
> 
> Please tell me how is this anything but "a mere suggestion".

I should have been more clear: I did not write to criticize you, 
personally, but to discuss the general pattern I've observed from the 
replies on this list when packages are submitted (e.g. there being two 
such threads going on now).

> P.S. I took the liberty of removing addressees from the CC list and
> leaving on the mailing list, as I don't see the need to bother people
> personally, especially since all or almost all of them read this list
> anyway.

No objection here.  I was "replying to all" as I've seen you say several 
times that to do so is SOP here.  As well, I don't subscribe to the list 
myself, reading by other means.

Thanks,
Adam

Re: [ELPA] New package: dape

[João Távora]

On Sat, Nov 4, 2023 at 9:51 AM Daniel Pettersson <daniel@dpettersson.net> wrote:
>
> On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net> wrote:
> > Did we ever come to a conclusion on this point?
>
> Sorry I have been putting the naming thing off as this thread sparked
> a bit of interest in the package which lead to a lot of great input and
> bugfixing. There have been a lot of good suggestions and no consensus
> which has made the even task harder.

I, like others, am of the opinion that you should spend little to no
time in this naming bikeshedding discussion.  Reserve that energy
for things that actually matter.  Dape or Daisy or Alberto are fine
names for this package.

> On Thu, Nov 2, 2023 at 5:24 PM João Távora <joaotavora@gmail.com> wrote:

> It's close but not close enough, it's able to reuse jsonrpc process
> filter but it falls to pieces in `jsonrpc-connection-receive', due to
> slight differences in the protocol. The protocol request/response id is
> replaced by seq or request_seq and method is command in DAP to name a
> few differences.

Ah, I see.  Indeed it's very strange that it's not JSONRPC.

So I see the main difference, and it's the one you mention.  It seems
that if I were to change jsonrpc.el sufficiently to accomodate that particular
difference, then it _could_ be used.

Do you know of any other significant/fundamental differences (say, such as a
message type which is neither a request, nor a response, nor a notification)?

If I were to try to do these jsonrpc.el changes to accomodate DAP protocols,
would you accept a PR to dape.el adding jsonrpc.el as a dependency to
dape.el?

João

Re: [ELPA] New package: dape

[Daniel Pettersson]

> > On Thu, Nov 2, 2023 at 5:24 PM João Távora <joaotavora@gmail.com> wrote:

> Do you know of any other significant/fundamental differences (say, such as a
> message type which is neither a request, nor a response, nor a notification)?

Notification, request and response maps to events, request and
response. The biggest difference might be the reverse request
but that could be implemented as an notification/event in a pinch.
There are two things that can be a bit of a challenge, maybe:
- DAP servers are not that well behaved in general, with a pipe
  connection they like to use std out as they please (none DAP
  messages).
- I don't know its a dape problem or not but it's not that hard to
  provoke some servers to send broken messages if they user chooses to
  continue the execution while the server is in the middle of responding

This means that the parsing needs to do some cleanup during.

> If I were to try to do these jsonrpc.el changes to accomodate DAP protocols,
> would you accept a PR to dape.el adding jsonrpc.el as a dependency to
> dape.el?

More then happy to offload some of the work ;) I think that would
greatly improve the performance and stability of dape to reuse some
well tested software. I also thin that dape might be able to reuse
some parts of eglot, the repl completion for example, I don't know
what the way forward would be for that.

Re: [ELPA] New package: dape

[João Távora]

On Tue, Nov 7, 2023 at 10:19 AM Daniel Pettersson
<daniel@dpettersson.net> wrote:
>
> > > On Thu, Nov 2, 2023 at 5:24 PM João Távora <joaotavora@gmail.com> wrote:
>
> > Do you know of any other significant/fundamental differences (say, such as a
> > message type which is neither a request, nor a response, nor a notification)?
>
> Notification, request and response maps to events, request and
> response. The biggest difference might be the reverse request
> but that could be implemented as an notification/event in a pinch.

If I understand correctly, reverse requests _are_ supported in JSONRPC.
Can you give a short example transcript illustrating such a conversation?

> There are two things that can be a bit of a challenge, maybe:
> - DAP servers are not that well behaved in general, with a pipe
>   connection they like to use std out as they please (none DAP
>   messages).

Meaning they put non-JSON cruft in the stdout as well?  Not great, but
not dramatic, I guess  as long as they don't do it in the middle of the
message right?

Again, helpful if you could attach a stdout dump of a conversation
where some of this takes place.

> - I don't know its a dape problem or not but it's not that hard to
>   provoke some servers to send broken messages if they user chooses to
>   continue the execution while the server is in the middle of responding

OK.  Then in your opinion what is the easiest (and or most representative)
DAP server to start playing with?  Hopefully some C/C++ one, but feel
free to suggest another.

> This means that the parsing needs to do some cleanup during.
>
> > If I were to try to do these jsonrpc.el changes to accomodate DAP protocols,
> > would you accept a PR to dape.el adding jsonrpc.el as a dependency to
> > dape.el?
>
> More then happy to offload some of the work ;) I think that would
> greatly improve the performance and stability of dape to reuse some
> well tested software. I also thin that dape might be able to reuse
> some parts of eglot, the repl completion for example, I don't know
> what the way forward would be for that.

Extract parts of eglot.el into a reusable library, I guess.

But yes, I would be very glad to see DAP dape.el become the DAP
coutnerpart to LSP eglot.el, with most analogous abstractions
having analogous interfaces.  Happy to change eglot.el
significantly to make that happen (backward-compatibility
permitting, of course).

João

Re: [ELPA] New package: dape

[Daniel Pettersson]

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

On Tue, Nov 7, 2023 at 12:47 PM João Távora <joaotavora@gmail.com>
wrote:

> If I understand correctly, reverse requests _are_ supported in JSONRPC.
> Can you give a short example transcript illustrating such a conversation?

Server ->>
{ "type": "request", "seq": 123, "command": "someCommand",
  "arguments": {...}}

Client ->>
{ "type": "response", "request_seq": 123, "command": "someCommand",
  "success": true, "body": {...}}

> Meaning they put non-JSON cruft in the stdout as well?  Not great, but
> not dramatic, I guess  as long as they don't do it in the middle of the
> message right?

If it breaks the json in half it's a them problem but if not it can be
useful for the user to see when getting a debugging configuration to
work.

See attachment.

> OK.  Then in your opinion what is the easiest (and or most representative)
> DAP server to start playing with?  Hopefully some C/C++ one, but feel
> free to suggest another.

The C/C++ ones are well behaved, attached install and dape-configs for
you to able to pick and choose. They are quite quiet though so for
checking performance vscode-js-debug and debugpy are better
options. But start with the C/C++ ones.

Included attachment with install fns and configs for the C/C++
adapters.

> Extract parts of eglot.el into a reusable library, I guess.
>
> But yes, I would be very glad to see DAP dape.el become the DAP
> coutnerpart to LSP eglot.el, with most analogous abstractions
> having analogous interfaces.  Happy to change eglot.el
> significantly to make that happen (backward-compatibility
> permitting, of course).

Super! But maybe that can wait, jsonrpc seams to me like a higher
priority thing.

For the changes in dape.el to accommodate jsonrpc, I think it would be
beneficial to collaborate on a some type of feature branch.

[-- Attachment #2: flutter_startup.stdout --]
[-- Type: application/octet-stream, Size: 26606 bytes --]


[   +2 ms] executing: sw_vers -productName
[   +7 ms] Exit code 0 from: sw_vers -productName
[        ] macOS
[        ] executing: sw_vers -productVersion
[   +6 ms] Exit code 0 from: sw_vers -productVersion
[        ] 11.5.2
[        ] executing: sw_vers -buildVersion
[   +6 ms] Exit code 0 from: sw_vers -buildVersion
[        ] 20G95
[        ] executing: uname -m
[   +1 ms] Exit code 0 from: uname -m
[        ] arm64
[   +1 ms] executing: sysctl hw.optional.arm64
[   +1 ms] Exit code 0 from: sysctl hw.optional.arm64
[        ] hw.optional.arm64: 1
[   +4 ms] Unable to locate an Android SDK.
[  +24 ms] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[        ] Artifact Instance of 'LegacyCanvasKitRemover' is not required, skipping update.
[        ] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[  +14 ms] Artifact Instance of 'MaterialFonts' is not required, skipping update.
[        ] Artifact Instance of 'GradleWrapper' is not required, skipping update.
[        ] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[        ] Artifact Instance of 'LegacyCanvasKitRemover' is not required, skipping update.
[        ] Artifact Instance of 'FlutterSdk' is not required, skipping update.
[        ] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FontSubsetArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'PubDependencies' is not required, skipping update.
Content-Length: 556
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":1,"type":"response","body":{"exceptionBreakpointFilters":[{"default":false,"filter":"All","label":"All Exceptions"},{"default":true,"filter":"Unhandled","label":"Uncaught Exceptions"}],"supportsClipboardContext":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsLogPoints":true,"supportsRestartRequest":false,"supportsTerminateRequest":true,"supportsValueFormattingOptions":true},"command":"initialize","request_seq":1,"success":true}Content-Length: 56
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":2,"type":"event","body":{},"event":"initialized"}Content-Length: 104
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":3,"type":"response","body":{},"command":"setExceptionBreakpoints","request_seq":3,"success":true}Content-Length: 141
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":4,"type":"response","body":{"breakpoints":[{"id":100000,"verified":false}]},"command":"setBreakpoints","request_seq":4,"success":true}Content-Length: 88
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":5,"type":"response","command":"configurationDone","request_seq":5,"success":true}Content-Length: 124
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":6,"type":"event","body":{"message":"Launching…","progressId":"launch_1","title":"Flutter"},"event":"progressStart"}Content-Length: 77
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":7,"type":"response","command":"launch","request_seq":2,"success":true}Content-Length: 103
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":8,"type":"event","body":{"capabilities":{"supportsRestartRequest":true}},"event":"capabilities"}Content-Length: 242
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":9,"type":"event","body":{"appId":"48930844-5782-4859-a980-c4737377432f","deviceId":"macos","directory":"/Users/dpettersson/Workspace/flutter/testapp","supportsRestart":true,"launchMode":"run","mode":"debug"},"event":"flutter.appStart"}Content-Length: 135
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":10,"type":"event","body":{"category":"console","output":"Launching lib/main.dart on macOS in debug mode...\n"},"event":"output"}Content-Length: 354
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":11,"type":"event","body":{"category":"stderr","output":"objc[25178]: Class AMSupportURLConnectionDelegate is implemented in both /usr/lib/libauthinstall.dylib (0x20b037ad8) and /System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1105ec2c8). One of the two will be used. Which one is undefined.\n"},"event":"output"}Content-Length: 343
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":12,"type":"event","body":{"category":"stderr","output":"objc[25178]: Class AMSupportURLSession is implemented in both /usr/lib/libauthinstall.dylib (0x20b037b28) and /System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice (0x1105ec318). One of the two will be used. Which one is undefined.\n"},"event":"output"}Content-Length: 83
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":13,"type":"event","body":{"category":"stderr","output":""},"event":"output"}Content-Length: 242
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":14,"type":"event","body":{"category":"stderr","output":"--- xcodebuild: WARNING: Using the first of multiple matching destinations:\n","source":{"name":"---","path":"/Users/dpettersson/Workspace/flutter/testapp/---"}},"event":"output"}Content-Length: 223
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":15,"type":"event","body":{"category":"stderr","output":"{ platform:macOS, arch:arm64, id:00008103-001608A92233001E }\n","source":{"name":"{","path":"/Users/dpettersson/Workspace/flutter/testapp/{"}},"event":"output"}Content-Length: 224
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":16,"type":"event","body":{"category":"stderr","output":"{ platform:macOS, arch:x86_64, id:00008103-001608A92233001E }\n","source":{"name":"{","path":"/Users/dpettersson/Workspace/flutter/testapp/{"}},"event":"output"}Content-Length: 83
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":17,"type":"event","body":{"category":"stderr","output":""},"event":"output"}Content-Length: 80
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":18,"type":"event","body":{"progressId":"launch_1"},"event":"progressEnd"}Content-Length: 129
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":19,"type":"event","body":{"output":"Connecting to VM Service at ws://127.0.0.1:55897/E_sRxkTwblI=/ws\n"},"event":"output"}Content-Length: 116
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":20,"type":"event","body":{"vmServiceUri":"ws://127.0.0.1:55897/E_sRxkTwblI=/ws"},"event":"dart.debuggerUris"}Content-Length: 83
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":21,"type":"event","body":{"reason":"started","threadId":1},"event":"thread"}Content-Length: 64
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":22,"type":"event","body":{},"event":"flutter.appStarted"}Content-Length: 121
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":23,"type":"event","body":{"service":"reloadSources","method":"s0.reloadSources"},"event":"dart.serviceRegistered"}Content-Length: 115
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":24,"type":"event","body":{"service":"hotRestart","method":"s0.hotRestart"},"event":"dart.serviceRegistered"}Content-Length: 123
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":25,"type":"event","body":{"service":"flutterVersion","method":"s0.flutterVersion"},"event":"dart.serviceRegistered"}Content-Length: 129
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":26,"type":"event","body":{"service":"compileExpression","method":"s0.compileExpression"},"event":"dart.serviceRegistered"}Content-Length: 129
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":27,"type":"event","body":{"service":"flutterMemoryInfo","method":"s0.flutterMemoryInfo"},"event":"dart.serviceRegistered"}Content-Length: 123
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":28,"type":"event","body":{"service":"flutterGetSkSL","method":"s0.flutterGetSkSL"},"event":"dart.serviceRegistered"}Content-Length: 145
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":29,"type":"event","body":{"service":"flutterGetIOSBuildOptions","method":"s0.flutterGetIOSBuildOptions"},"event":"dart.serviceRegistered"}Content-Length: 155
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":30,"type":"event","body":{"service":"flutterGetAndroidBuildVariants","method":"s0.flutterGetAndroidBuildVariants"},"event":"dart.serviceRegistered"}Content-Length: 163
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":31,"type":"event","body":{"service":"flutterGetIOSUniversalLinkSettings","method":"s0.flutterGetIOSUniversalLinkSettings"},"event":"dart.serviceRegistered"}Content-Length: 159
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":32,"type":"event","body":{"service":"flutterGetAndroidAppLinkSettings","method":"s0.flutterGetAndroidAppLinkSettings"},"event":"dart.serviceRegistered"}Content-Length: 128
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":33,"type":"event","body":{"breakpoint":{"id":100000,"line":27,"verified":false},"reason":"changed"},"event":"breakpoint"}Content-Length: 151
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":34,"type":"event","body":{"extensionRPC":"ext.flutter.reassemble","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 145
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":35,"type":"event","body":{"extensionRPC":"ext.flutter.exit","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 162
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":36,"type":"event","body":{"extensionRPC":"ext.flutter.connectedVmServiceUri","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 168
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":37,"type":"event","body":{"extensionRPC":"ext.flutter.activeDevToolsServerAddress","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 157
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":38,"type":"event","body":{"extensionRPC":"ext.flutter.platformOverride","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 159
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":39,"type":"event","body":{"extensionRPC":"ext.flutter.brightnessOverride","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 153
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":40,"type":"event","body":{"extensionRPC":"ext.flutter.timeDilation","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 146
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":41,"type":"event","body":{"extensionRPC":"ext.flutter.evict","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 162
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":42,"type":"event","body":{"extensionRPC":"ext.flutter.invertOversizedImages","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 151
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":43,"type":"event","body":{"extensionRPC":"ext.flutter.debugPaint","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 167
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":44,"type":"event","body":{"extensionRPC":"ext.flutter.debugPaintBaselinesEnabled","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 155
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":45,"type":"event","body":{"extensionRPC":"ext.flutter.repaintRainbow","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 159
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":46,"type":"event","body":{"extensionRPC":"ext.flutter.debugDumpLayerTree","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 163
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":47,"type":"event","body":{"extensionRPC":"ext.flutter.debugDisableClipLayers","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 172
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":48,"type":"event","body":{"extensionRPC":"ext.flutter.debugDisablePhysicalShapeLayers","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 166
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":49,"type":"event","body":{"extensionRPC":"ext.flutter.debugDisableOpacityLayers","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 160
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":50,"type":"event","body":{"extensionRPC":"ext.flutter.debugDumpRenderTree","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 179
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":51,"type":"event","body":{"extensionRPC":"ext.flutter.debugDumpSemanticsTreeInTraversalOrder","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 184
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":52,"type":"event","body":{"extensionRPC":"ext.flutter.debugDumpSemanticsTreeInInverseHitTestOrder","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 166
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":53,"type":"event","body":{"extensionRPC":"ext.flutter.profileRenderObjectPaints","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 167
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":54,"type":"event","body":{"extensionRPC":"ext.flutter.profileRenderObjectLayouts","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 153
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":55,"type":"event","body":{"extensionRPC":"ext.flutter.debugDumpApp","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 159
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":56,"type":"event","body":{"extensionRPC":"ext.flutter.debugDumpFocusTree","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 163
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":57,"type":"event","body":{"extensionRPC":"ext.flutter.showPerformanceOverlay","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 163
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":58,"type":"event","body":{"extensionRPC":"ext.flutter.didSendFirstFrameEvent","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 173
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":59,"type":"event","body":{"extensionRPC":"ext.flutter.didSendFirstFrameRasterizedEvent","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 155
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":60,"type":"event","body":{"extensionRPC":"ext.flutter.fastReassemble","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 160
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":61,"type":"event","body":{"extensionRPC":"ext.flutter.profileWidgetBuilds","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 164
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":62,"type":"event","body":{"extensionRPC":"ext.flutter.profileUserWidgetBuilds","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 157
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":63,"type":"event","body":{"extensionRPC":"ext.flutter.debugAllowBanner","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 167
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":64,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.structuredErrors","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 155
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":65,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.show","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 175
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":66,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.trackRebuildDirtyWidgets","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 170
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":67,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.trackRepaintWidgets","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 167
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":68,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.disposeAllGroups","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 163
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":69,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.disposeGroup","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 168
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":70,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.isWidgetTreeReady","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 160
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":71,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.disposeId","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 172
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":72,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.setPubRootDirectories","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 172
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":73,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.addPubRootDirectories","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 175
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":74,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.removePubRootDirectories","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 172
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":75,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getPubRootDirectories","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 167
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":76,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.setSelectionById","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 165
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":77,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getParentChain","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 164
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":78,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getProperties","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 162
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":79,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getChildren","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 173
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":80,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getChildrenSummaryTree","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 176
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":81,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getChildrenDetailsSubtree","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 164
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":82,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getRootWidget","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 175
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":83,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getRootWidgetSummaryTree","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 187
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":84,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getRootWidgetSummaryTreeWithPreviews","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 168
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":85,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getDetailsSubtree","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 168
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":86,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getSelectedWidget","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 175
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":87,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getSelectedSummaryWidget","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 174
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":88,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.isWidgetCreationTracked","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 161
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":89,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.screenshot","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 172
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":90,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.getLayoutExplorerNode","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 161
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":91,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.setFlexFit","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 164
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":92,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.setFlexFactor","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 168
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":93,"type":"event","body":{"extensionRPC":"ext.flutter.inspector.setFlexProperties","isolateId":"isolates/4275925240961007"},"event":"dart.serviceExtensionAdded"}Content-Length: 167
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":94,"type":"event","body":{"extension":"ext.flutter.activeDevToolsServerAddress","value":"http://127.0.0.1:9100"},"event":"flutter.serviceExtensionStateChanged"}Content-Length: 176
Content-Type: application/vscode-jsonrpc; charset=utf-8

{"seq":95,"type":"event","body":{"extension":"ext.flutter.connectedVmServiceUri","value":"http://127.0.0.1:55897/E_sRxkTwblI=/"},"event":"flutter.serviceExtensionStateChanged"}

[-- Attachment #3: c-c++-dape-configs.el --]
[-- Type: application/octet-stream, Size: 3590 bytes --]

(require 'dape)
(require 'dired-aux)
(require 'seq)

(setq dape-configs-port 6667)

(setq dape-configs-adapter-dir
      (file-name-as-directory (concat user-emacs-directory "dape-debuggers")))

(setq dape-configs-codelldb-version "v1.10.0")
(setq dape-configs-cppdbg-version "v1.17.5")

(defun dape-configs--ensure-dir ()
  (unless (file-directory-p dape-configs-adapter-dir)
    (make-directory dape-configs-adapter-dir)))

(defun dape-configs--download (url &optional filename)
  (dape-configs--ensure-dir)
  (let ((file-name (or filename (car (last (split-string url "/")))))
        (default-directory dape-configs-adapter-dir))
    (url-copy-file url file-name t)
    (dired-compress-file file-name)
    (delete-file file-name)))

(defun dape-configs-download-codelldb ()
  "Download codelldb."
  (interactive)
  (let ((system
         (pcase system-type
           ('darwin "darwin")
           ('gnu/linux "linux")
           ('windows-nt "windows")
           (_ (user-error "Unknow platform"))))
        (processor (car (split-string system-configuration "-"))))
    (dape-configs--download
     (format
      "https://github.com/vadimcn/codelldb/releases/download/%s/codelldb-%s-%s.vsix"
      dape-configs-codelldb-version processor system)
     "codelldb.zip")))

(defun dape-configs-download-cppdbg (platform)
  "Download cppdbg for platform."
  (interactive
   (list
    (completing-read "System: "
                     '("alpine-aarch64" "alpine" "linux-aarch64"
                       "linux-armhf" "linux" "osx-arm64" "osx"
                       "win-arm64" "win32" "win64")
                     nil t)))
  (dape-configs--download
     (format
      "https://github.com/microsoft/vscode-cpptools/releases/download/%s/cpptools-%s.vsix"
      dape-configs-cppdbg-version platform)
     "cpptools.zip")
  (let ((debug-adapters-folder
         (concat dape-configs-adapter-dir
                 (file-name-as-directory "cpptools")
                 (file-name-as-directory "extension")
                 (file-name-as-directory "debugAdapters"))))
    (chmod (concat debug-adapters-folder
                   (file-name-as-directory "bin")
                   "OpenDebugAD7")
           #o755)
    (when (string-match-p "^osx" platform)
      (chmod (concat debug-adapters-folder
                     (file-name-as-directory "lldb-mi")
                     (file-name-as-directory "bin")
                     "lldb-mi")
             #o755))))

(setq dape-configs
      `((cppdbg
         modes (c-mode c-ts-mode c++-mode c++-ts-mode)
         command ,(concat dape-configs-adapter-dir
                          (file-name-as-directory "cpptools")
                          (file-name-as-directory "extension")
                          (file-name-as-directory "debugAdapters")
                          (file-name-as-directory "bin")
                          "OpenDebugAD7")
         :type "cppdbg"
         :request "launch"
         :cwd dape-cwd-fn
         :program dape-find-file
         :MIMode ,(seq-find 'executable-find '("lldb" "gdb")))
        (codelldb
         modes (c-mode c-ts-mode c++-mode c++-ts-mode)
         command ,(concat dape-configs-adapter-dir
                          (file-name-as-directory "codelldb")
                          (file-name-as-directory "extension")
                          (file-name-as-directory "adapter")
                          "codelldb")
         command-args ("--port" ,(format "%d" dape-configs-port))
         port ,dape-configs-port
         :type "lldb"
         :cwd dape-cwd-fn
         :program dape-find-file)))

Re: [ELPA] New package: dape

[Philip Kaludercic]

Daniel Pettersson <daniel@dpettersson.net> writes:

> On Sat, Oct 14, 2023 at 4:54 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> I have tried to try it out right now, but because I've never used DAP
>> before, I am not sure how to get it running properly.  Nevertheless, I
>> think it would be useful to have something along these lines:
>
> Did you get working?

I haven't had the time to try since.

>> +      (customize-variable 'dape-configs)
>
> Implemented

1+

>> Another interesting idea to pursue might be to have modular UIs.
>> Instead of splitting up the current Emacs frame, I think a minimalist,
>> more edebug-like interface would be nice, where variable values could be
>> displayed using overlays instead of having a separate buffer.
>
> Nice suggestion. I did try to implement a more minimalist interface with
> variable overlays.
>
> Which can be enabled with the following.
> (setq dape-inline-variables t)
> (setq dape-on-start-hooks nil)

This sounds great, I'll have to try it out at some point!  It might be
nice to have this as a minor mode that you could enable with a hook or
as a global minor mode.

> Second screenshot in the README.org, it's more inline with edebug. 

Just FYI these don't appear to be displayed on the GitHub page.

>                                                                    But
> there is some issues with placement and variable lookup. The current
> implementation relies on regex and font lock to search for symbols.
> If that work could be offloaded to Eglot/lsp-mode via xref (*I don't
> know if lsp support it). But currently that is not possible because
> Eglot only supports looking up reference at point.

Have you contacted João?

>> Note that you don't need to add Compat just for `defvar-keymap', as you
>> could also just use the traditional method of defining a keymap instead:
>
> Fixed.
>
>> It just doesn't say that much, and I don't know if it is intended, but
>> the usual way I would read/pronounce it (rhyming with cape) wouldn't
>> immediately signal any relation to DAP.  Note that you can use (elisp)
>> Shorthands to avoid writing out a longer name inside the file, in case a
>> longer name like debuger-adapter.  It seems there is no package by the
>> name of "dbg"?  If we are not interested in a self-descriptive and
>> memorable name, and would want to create a parallel to Eglot (IIRC Emacs
>> polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
>> Ebugger?  Edebugger?) might be possible as well.
>
> "dbg" is nice and sweet, but I think it's a + for discoverability to have
> dap in the name of the package. How about eldap? If it should signify
> a connection to Eglot, maybe Ebug or even closer Dpoly? Or maybe a
> reference to Grace Hopper, hopper.

While I like eldap, note that this doesn't have a direct connection to
Eglot -- which is /not/ Elgot.

> Personally I like eldap, probably because it feels familiar.

Re: [ELPA] New package: dape

[Björn Bidar]

Daniel Pettersson <daniel@dpettersson.net> writes:

>> It just doesn't say that much, and I don't know if it is intended, but
>> the usual way I would read/pronounce it (rhyming with cape) wouldn't
>> immediately signal any relation to DAP.  Note that you can use (elisp)
>> Shorthands to avoid writing out a longer name inside the file, in case a
>> longer name like debuger-adapter.  It seems there is no package by the
>> name of "dbg"?  If we are not interested in a self-descriptive and
>> memorable name, and would want to create a parallel to Eglot (IIRC Emacs
>> polyGLOT), perhaps something like based on "Emacs Debugger" (Egger?
>> Ebugger?  Edebugger?) might be possible as well.
>
> "dbg" is nice and sweet, but I think it's a + for discoverability to have
> dap in the name of the package. How about eldap? If it should signify
> a connection to Eglot, maybe Ebug or even closer Dpoly? Or maybe a
> reference to Grace Hopper, hopper.
> Personally I like eldap, probably because it feels familiar.

Ebug sounds more like bug handling package than a debugger related
package.

Re: [ELPA] New package: dape

[Philip Kaludercic]

Daniel Pettersson <daniel@dpettersson.net> writes:

> "dbg" is nice and sweet, but I think it's a + for discoverability to have
> dap in the name of the package. How about eldap? If it should signify
> a connection to Eglot, maybe Ebug or even closer Dpoly? Or maybe a
> reference to Grace Hopper, hopper.
> Personally I like eldap, probably because it feels familiar.

Did we ever come to a conclusion on this point?

Re: [ELPA] New package: dape

[Mauro Aranda]

On 13/10/23 07:35, Daniel Pettersson wrote:

I have some comments about the defcustoms in dape.el:

 > (defcustom dape-configs nil
 >   "This variable holds the Dape configurations as an alist.
 > In this alist, the car element serves as a symbol identifying each
 > configuration.  Each configuration, in turn, is a property list (plist)
 > where keys can be symbols or keywords.
 >
 > Symbol Keys (Used by Dape):
 > - command: Shell command to initiate the debug adapter.
 > - command-args: List of string arguments for the command.
 > - command-cwd: Working directory for the command.
 > - host: Host of the debug adapter.
 > - port: Port of the debug adapter.
 > - modes: List of modes where the configuration is active in `dape'
 >   completions.
 > - compile: Executes a shell command with `dape-compile-fn'.
 >
 > Debug adapter connection in configuration:
 > - If only command is specified (without host and port), Dape
 >   will communicate with the debug adapter through stdin/stdout.
 > - If both host and port are specified, Dape will connect to the
 >   debug adapter.  If `command is specified, Dape will wait until the
 >   command is initiated before it connects with host and port.
 >
 > Keywords in configuration:
 >   Keywords are transmitted to the adapter during the initialize and
 >   launch/attach requests.  Refer to `json-serialize' for detailed
 >   information on how Dape serializes these keyword elements.  Dape
 >   uses nil as false.
 >
 > Functions and symbols in configuration:
 >  If a value in a key is a function, the function's return value will
 >  replace the key's value before execution.
 >  If a value in a key is a symbol, the symbol will recursively resolve
 >  at runtime."
 >   :type '(alist :key-type (symbol :tag "Name")
 >                 :value-type
 >                 (plist :options
 >                        (((const :tag "Shell command to start the 
debug adapter" command) string)
 >                         ((const :tag "List of string arguments for 
command" command-args) (list string))
 >                         ((const :tag "Working directory for command" 
command-cwd) string)
 >                         ((const :tag "Host of debug adapter" host) 
string)
 >                         ((const :tag "Port of debug adapter" port) 
integer)
 >                         ((const :tag "List of modes where config is 
active in `dape' completions" modes) function)
 >                         ((const :tag "Runs shell command with 
`dape-compile-fn'" compile) function)
 >                         (keyword sexp)))))

(keyword sexp) as the last :options looks really weird.  Are you sure
that is the intention?

 > (defcustom dape-key-prefix "\C-x\C-a"
 >   "Prefix of all dape commands."
 >   :type 'key-sequence)

If you're going to depend on 29.1, then perhaps it's better to use 'key,
since a decision was made to obsolete 'key-sequence.  If something
doesn't work with 'key but works with 'key-sequence, then please report
it.

 > (defcustom dape-buffers-on-start '(dape-info dape-repl)
 >   "Dape buffers to open when debugging starts."
 >   :type '(list (const dape-info) (const dape-repl)))

This doesn't allow for any customization at all when using Customize.  I
think you want to use '(repeat function)

 > (defcustom dape-main-functions '("main")
 >   "Functions to set breakpoints at startup if no other breakpoints 
are set."
 >   :type '(list string))

I think you want (repeat string) here.

 > (defcustom dape-read-memory-default-count 1024
 >   "The default count for `dape-read-memory'."
 >   :type '(integer))

Is natnum better suited here?

 > (defcustom dape--debug-on
 >   '(io info error std-server)
 >   "Types of logs should be printed to *dape-debug*."
 >   :type '(list (const :tag "dap IO" io)
 >                (const :tag "info logging" info)
 >                (const :tag "error logging" error)
 >                (const :tag "dap tcp server stdout" std-server)))

Similar to dape-buffers-on-start.

Re: [ELPA] New package: dape

[Daniel Pettersson]

On Sun, Oct 15, 2023 at 3:55 PM Mauro Aranda <maurooaranda@gmail.com> wrote:

> I have some comments about the defcustoms in dape.el:
Super! I am not that familiar with customs.

> (keyword sexp) as the last :options looks really weird.  Are you sure
> that is the intention?
Removed :)

> If you're going to depend on 29.1, then perhaps it's better to use 'key,
> since a decision was made to obsolete 'key-sequence.  If something
> doesn't work with 'key but works with 'key-sequence, then please report
> it.
Makes sense.

> This doesn't allow for any customization at all when using Customize.  I
> think you want to use '(repeat function)

This has been changed to 'hooks.

>  > (defcustom dape-main-functions '("main")
>  >   "Functions to set breakpoints at startup if no other breakpoints
> are set."
>  >   :type '(list string))
> I think you want (repeat string) here.
Fixed!

>  > (defcustom dape-read-memory-default-count 1024
>  >   "The default count for `dape-read-memory'."
>  >   :type '(integer))
>
> Is natnum better suited here?
Sure, changed.

>  > (defcustom dape--debug-on
>  >   '(io info error std-server)
>  >   "Types of logs should be printed to *dape-debug*."
>  >   :type '(list (const :tag "dap IO" io)
>  >                (const :tag "info logging" info)
>  >                (const :tag "error logging" error)
>  >                (const :tag "dap tcp server stdout" std-server)))
>
> Similar to dape-buffers-on-start.
Fixed, `set' instead of `list'. Should do it right.

Great input!

Re: [ELPA] New package: dape

[Milan Glacier]

Daniel Pettersson <daniel@dpettersson.net> writes:

> This package integrates debug adapters within Emacs.
> Alternative to the well known package dap-mode.
>
> See repository for code and more information 
> https://github.com/svaante/dape

This is definitely a very exciting news and a long lasting wish for a
lot of emacsers is finally fulfilled.

Given the fact that eglot is part of the core emacs, a brand new
implementation of DAP protocal that does not rely on lsp-mode would be
definitely be a killer feature and has the potential integrating into
the core.