Cfg does not work with next master.

[tviti]

This config works with latest next-browser release v1.3.2, but seems to be broken when run with the latest dev version (i.e. the master branch of the next-browser repo). From what I can tell, this is due to the switch to functional style configurations (see this issue ticket), but I honestly haven't spent a whole lot of time debugging so far.

So far the problems are:

• Method of setting keybindings seems to have changed.
• My hack for setting command aliases no longer works.

[vindarel]

Hey,

The configuration should still work, even if functions are marked duplicated. ping @Ambrevar

For aliases, ideas: define a command that calls another command (dumb), see alexandria:define-alias, see serapeum:defalias.

I used your open-home-dir with a simpler set-url:

(define-command open-home-dir ()
  "Open my home directory in a browser window (useful for viewing html exports
e.g. from org-mode or an Rmarkdown doc)."
  (let ((url (concatenate 'string "file://"
			  (directory-namestring (truename "~/")))))
    (set-url url)))

[Ambrevar]

Indeed, define-key does not take modes / schemes anymore, only keymaps.

The :mode argument was broken so I remove it.
The :scheme could be restored (it's an oversight on my end) with a "deprecated" warning. Shall we do it?

[tviti]

Hey, thanks for taking the time to comment on this!

So it looks like I was incorrect earlier to say that release 1.3.2 works with
this cfg (it doesn't :P). I think the source of confusion was that I had
multiple versions of next floating around my ~/common-lisp dir. Since
cleaning that out, I have ascertained that at least
df99518
works, so I can at least "pin" that for day-to-day use.

Unfortunately, it looks like the issue may run deeper than just my init file,
since it looks like my custom port also is broken with the latest version. If I
remove init.lisp (i.e. run from NO user init file), I can start the browser,
and I am able to spin up a minibuffer (using M-x), but cannot actually enter
any text into the minibuffer. Based on the repl output, it looks like the core
is receiving the keypresses:

INFO:root:send code: 108 string: l modifiers: [''] low_level_data: 108
INFO:root:send code: 111 string: o modifiers: [''] low_level_data: 111
INFO:root:send code: 108 string: l modifiers: [''] low_level_data: 108

so I'm guessing there's been a change to the way that events are forwarded back
to the port (which now that I actually type it out, doesn't sound like it'll be
so bad to fix).

The configuration should still work, even if functions are marked duplicated.

Unfortunately this doesn't look to be the case. Here's an excerpt from the repl
after trying to start next:

; compilation unit finished
;   caught 1 WARNING condition
 <WARN> [02:06:55] next utility.lisp (setf get-default) -
  The (setf (get-default ...)) and (add-to-default-list ...) forms are deprecated.
WARNING: Command B doesn't have a documentation string
While evaluating the form starting at line 99, column 0
  of #P"/Users/taylor/.config/next/init.lisp":
While evaluating the form starting at line 9, column 0
  of #P"/Users/taylor/common-lisp/run_next_core.lisp":

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {10004F04C3}>:
  Error: could not load the init file:
EXPORT B causes name-conflicts in #<PACKAGE "NEXT/WEB-MODE"> between the
following symbols:
  NEXT::B, NEXT/WEB-MODE::B
See also:
  The ANSI Standard, Section 11.1.1.2.5

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

which confuses me a bit, since when I try to to inspect or call
next/web-mode::b, sbcl just tells me that it's unbound/undefined.

In any case, since exporting the symbol seems to be the root of the collision,
I'm guessing I can get around this by simply doing something like the following:

(push (make-instance 'command :sym 'b :pkg *package*) %%command-list)
(setf (fdefinition 'b) #'switch-buffer)

Although I'll have to sort out the port before I can test it :P

Indeed, define-key does not take modes / schemes anymore, only keymaps.

The :mode argument was broken so I remove it.
The :scheme could be restored (it's an oversight on my end) with a
"deprecated" warning. Shall we do it?

Cool, I think I have to take another look at your cfg then to figure out the new
way of doing keybindings. My C-[ mapping is the only one that is "mode
specific", but I think I can avoid that by just having it add push an ESCAPE
onto the key-chord stack (in effect making it an actual alias for ESCAPE).

[vindarel]

cannot actually enter any text into the minibuffer.

I experienced this. Did you rebuild next-gtk ?

[tviti]

cannot actually enter any text into the minibuffer.

I experienced this. Did you rebuild next-gtk ?

Nope, this is using a lightly modified version of the PyQtWebEngine port (https://github.com/tviti/next), although I should probably build next-gtk on my CentOS machine one of these days so I can compare the dbus events to make sure the ones sent from my port are the same.

[Ambrevar]

b is the argument of a couple of functions. We might have a leaking macro somewhere... Maybe define-command, need to look into it.

Anyways, the easy fix is to rename your command :)

I've just reverted the define-key function, so now your define-key should work as they used to.

Regarding strange RPC behaviour you are witnessing: I can't tell for sure for the PyQt port, but maybe you could try cleaning the fasls in ~/.cache/common-lisp and recompiling the whole thing.

[tviti]

b is the argument of a couple of functions. We might have a leaking macro somewhere... Maybe define-command, need to look into it.

When trying this with atlas-engineer/nyxt@09a66d0 the conflict seems to be with buffer-history-tree. With the command def for buffer-history-tree commented out, the def-cmd-aliascalls go just fine.

Anyways, the easy fix is to rename your command :)

Although this would totally defeat the purpose of being able to use vim ex style abbrevs from the minibuffer (e.g. like doing :b for switch-buffer) :p

I think you are right though, that dedicating an entire command def to the abbreviations (let alone using a single alpha-numeric character as a command name) is a really really bad idea, but sans an actual evil-ex command, its the path of least resistance to implement them.

One thought is I could get the same behavior by overriding the completion filter so that ex commands like b and e bring up their associated next command as the first suggestion. That or try to actually implement an evil-ex command entry prompt that is can filters commands to execute-command.

[Ambrevar]

tviti <notifications@github.com> writes:

> `b` is the argument of a couple of functions. We might have a leaking macro somewhere... Maybe `define-command`, need to look into it. When trying this with atlas-engineer/nyxt@09a66d0 the conflict seems to be with `buffer-history-tree`. With the command def for `buffer-history-tree` commented out, the `def-cmd-alias`calls go just fine.

Hmm... I think the reason it fails is because define-command automatically exports the symbol. web-mode has a `b` symbol because of the `:b` keyword in buffer-history-tree (nothing wrong there). And since web-mobe uses the 'next' package, it gets all its exported symbols including `b`, hence the conflict. I think the proper solution to this problem is to move the user config to the `next-user` package. I'll work on it.

[Ambrevar]

I've defined a "next-user" package on master. If you switch to it your "b" command should work now.