rswgnu
Many features work incorrectly in Emacs 28.1
Hello! Thank you for all your time and effort you put in Hyperbole!
I've updated from GNU Emacs 27.2 to 28.1 with native compilation recently. Suddenly, most of Hyperbole's features (mouse drags, some implicit buttons, klinks and more) stopped working. There are so many bugs that I can't report all of them properly. Plus, I don't use all of Hyperbole's features, so there must be more bugs than I encountered. Hyperbole 8.0 used to work just fine in Emacs 27.2 on my machine.
Here is the information about my system gathered via Hyperbole's reporting facilities: I use: Editor: GNU Emacs 28.1 Hyperbole: 8.0.1pre Sys Type: x86_64-unknown-linux-gnu OS Type: gnu/linux Window Sys: x News Reader: Gnus v5.13 Install: elpa-devel, 8.0.1pre0.20220619.202654
Could native compilation break something in Hyperbole? If yes, what can I do to fix it, or at least figure out the exact cause of the problem?
I would first try uninstalling the Hyperbole package and then re-installing. Both Hyperbole devs use 28.1 so that is not likely the issue but there was a change of one macro into a function that if not compiled cleanly could be a problem.
Nativecomp could definitely be an issue. Send 1 or two drags or Action Key presses that fail and explain what you see and we’ll look into it.
Thanks for the report.
On Jun 28, 2022, at 1:48 PM, tre-flip @.***> wrote:
Hello! Thank you for all your time and effort you put in Hyperbole!
I've updated from GNU Emacs 27.2 to 28.1 with native compilation recently. Suddenly, most of Hyperbole's features (mouse drags, some implicit buttons, klinks and more) stopped working. There are so many bugs that I can't report all of them properly. Plus, I don't use all of Hyperbole's features, so there must be more bugs than I encountered. Hyperbole 8.0 used to work just fine in Emacs 27.2 on my machine.
Here is the information about my system gathered via Hyperbole's reporting facilities: I use: Editor: GNU Emacs 28.1 Hyperbole: 8.0.1pre Sys Type: x86_64-unknown-linux-gnu OS Type: gnu/linux Window Sys: x News Reader: Gnus v5.13 Install: elpa-devel, 8.0.1pre0.20220619.202654
Could native compilation break something in Hyperbole? If yes, what can I do to fix it, or at least figure out the exact cause of the problem?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
I reinstalled Hyperbole, but it didn't solve the problem. However, I figured out the point where mouse drags fail. On GNU/Linux with FVWM as a window manager hmouse-drag-outside-all-windows always returns t and prevents the correct operation of mouse drags and mouse smart key (tested in Hyperbole 7.3 and 8.0 in both Emacs 27.2 and 28.1 with nativecomp). Mouse drags work fine with other window managers (for example Openbox which I use now). Sorry, I should have studied this issue in more details before reporting it.
But I still have some problems. Klinks to viewspecs work incorrectly in 28.1 with nativecomp. They not just activate viewspecs, but also open the same buffer in a new window. I had to rewrite the definition of link-to-kcell like that to make it work:
(defact link-to-kcell (file cell-ref)
"Display FILE with kcell given by CELL-REF at window top.
See documentation for `kcell:ref-to-id' for valid cell-ref formats.
If FILE is nil, use the current buffer.
If CELL-REF is nil, show the first cell in the view."
(interactive "fKotl file to link to: \n+KKcell to link to: ")
(require 'kfile)
(cond ((and (stringp cell-ref) (> (length cell-ref) 0)
(eq ?| (aref cell-ref 0)))
;; Activate view spec in current window.
(kotl-mode:goto-cell cell-ref))
((if file
(hpath:find file)
(hpath:display-buffer (current-buffer)))
(if cell-ref
(kotl-mode:goto-cell cell-ref)
(kotl-mode:beginning-of-buffer))
(recenter 0))))
Here's the diff:
diff --git a/hactypes.el b/hactypes.el
index f78e204..b046320 100644
--- a/hactypes.el
+++ b/hactypes.el
@@ -540,17 +540,17 @@ If FILE is nil, use the current buffer.
If CELL-REF is nil, show the first cell in the view."
(interactive "fKotl file to link to: \n+KKcell to link to: ")
(require 'kfile)
- (cond ((if file
- (hpath:find file)
- (hpath:display-buffer (current-buffer)))
- (if cell-ref
- (kotl-mode:goto-cell cell-ref)
- (kotl-mode:beginning-of-buffer))
- (recenter 0))
- ((and (stringp cell-ref) (> (length cell-ref) 0)
- (eq ?| (aref cell-ref 0)))
- ;; Activate view spec in current window.
- (kotl-mode:goto-cell cell-ref))))
+ (cond ((and (stringp cell-ref) (> (length cell-ref) 0)
+ (eq ?| (aref cell-ref 0)))
+ ;; Activate view spec in current window.
+ (kotl-mode:goto-cell cell-ref))
+ ((if file
+ (hpath:find file)
+ (hpath:display-buffer (current-buffer)))
+ (if cell-ref
+ (kotl-mode:goto-cell cell-ref)
+ (kotl-mode:beginning-of-buffer))
+ (recenter 0))))
(defact link-to-mail (mail-msg-id &optional mail-file)
"Display mail msg with MAIL-MSG-ID from optional MAIL-FILE.
EDIT: Mouse drags work occasionally on Emacs 28.1 with nativecomp. Keybinding "M-o" which emulates smart mouse key works occasionally too. So far I haven't found the reason why it happens and I'm still trying to find out when exactly it works and when it doesn't work.
Sometimes, when I press the mouse smart key, I get the following error:
hmouse-x-coord: Symbol’s function definition is void: nil
Here's its backtrace:
Debugger entered--Lisp error: (void-function nil)
nil((keyboard-drag (#<window 3 on *text-scratch*> 345 (40 . 144) 0 nil 345 (4 . 8) nil (0 . 0) (10 . 18))))
hmouse-x-coord((keyboard-drag (#<window 3 on *text-scratch*> 345 (40 . 144) 0 nil 345 (4 . 8) nil (0 . 0) (10 . 18))))
hmouse-drag-horizontally()
(setq hkey-value (hmouse-drag-horizontally))
eval((setq hkey-value (hmouse-drag-horizontally)))
hkey-execute(nil)
action-key-internal()
hmouse-function(action-key-internal nil (mouse-2 (#<window 3 on *text-scratch*> 265 (847 . 79) 4964557 nil 265 (84 . 4) nil (87 . 7) (10 . 18))))
action-mouse-key(mouse-2 (#<window 3 on *text-scratch*> 265 (847 . 79) 4964557 nil 265 (84 . 4) nil (87 . 7) (10 . 18)))
apply(action-mouse-key (mouse-2 (#<window 3 on *text-scratch*> 265 (847 . 79) 4964557 nil 265 (84 . 4) nil (87 . 7) (10 . 18))))
action-mouse-key-emacs((mouse-2 (#<window 3 on *text-scratch*> 265 (847 . 79) 4964557 nil 265 (84 . 4) nil (87 . 7) (10 . 18))))
funcall-interactively(action-mouse-key-emacs (mouse-2 (#<window 3 on *text-scratch*> 265 (847 . 79) 4964557 nil 265 (84 . 4) nil (87 . 7) (10 . 18))))
command-execute(action-mouse-key-emacs)
Thanks for the detailed report and great to see you using Hyperbole mouse drags. In the future, try to report one issue/scenario per message. It will be easier to respond to and track. Just open a new issue for each report, even if there is some connection.
On the first issue could you use edebug-defun on hmouse-drag-outside-all-windows and then depress the Action mouse button within a window, drag to outside of an Emacs window and release. Edebug will hit your instrumented function and then hit the space bar to step until you see the value of action-key-release-window. It is supposed to be nil. If it is a live window, then that is the problem. Somehow Emacs is not registering that the release event occurred outside of an Emacs frame.
On the second issue, klinks, this is the correct behavior. Hyperbole uses the variable, 'hpath:display-where' to determine where to display all link referents and its default value is 'other-window'. This allows you to follow a link to another position in the same buffer but not lose your current place in the buffer. You can change this to be the same window if you prefer. You could argue that links to positions within the current buffer should be handled differently than other links and we could possibly add another setting to hpath:display-where for this but I think it is a reasonable default. We also might look at using indirect buffers when viewspecs are set so that you could have multiple views over the same buffer.
On the third issue, hmouse-x-coord failing due to a nil value, it seems again your Emacs is returning the wrong value because of whatever value your window manager is delivering. Maybe there is an error in the way Emacs consumes events from fvwm. We could probably add some better error handling there but to resolve this you'll have to delve into the fvwm event reporting, I think. Does this work properly with another window manager?
Thanks for following up on these.
Hi tre-flip:
If we don't hear any follow ups from you on this, we'll close it within a week. We have done a lot of work on the pre-release version of Hyperbole that includes better nativecomp support, so you may want to try that by using the 'elpa-devel' version as described in the Hyperbole manager (uses Emacs package manager for installation).