Fork me on GitHub

can someone try enabling global-superword-modeand see if they suffer the line-ending hangs that the other workaround I mentioned does? both approaches suffer this problem for me and superword-mode is something built in to emacs so that should definitely be supported.


sure, do you have exact steps to repeat?


Enable superword mode. Then hit ‘w’ a few times. See if the cursor gets stuck at the end of any lines.


@U0E98NQG2 with global-superword-mode on I get the same sticking experience as using the modify-syntax-entry custom code I shared with you previously.


specifically in the latest test it sticks on a closing backtick character, but its not at the end of a line, its at the end of the first word in a comment


In the tests I rebooted Emacs after commenting the modify syntax code. w did not stick. Enabling superword mode then sticks in the same place.


I also get sticky cursor randomly at the end of a commented line where it has a hyphenated word; a line that has an hyphenated word at the end followed by ) , sticking before the closing paren; the end of a line with a hypenated word followed by )] ; the end of a line with only a hyphenated word


It does not stick on a hyphenated word followed by another word. If I add a non-hypenated word after any point that is sticking, it does not seem to stick (more testing required for this)


I tested superword mode on the following Clojure code. I have added the word fish directly after all the places where the cursor sticks when pressing w, thus stopping the cursor from ever sticking. If you remove the word fish , the cursor will stick in all those places. So it seems where ever there is a hyphenated word at the end of a line or before a closing character, eg. parens or backtick, the w key will stick If a hyphenated word is followed by a non-hyphenated word or parens that do not close, e.g. [] then w does not stick. I dont have time at the moment to find the root cause of this, but feel free to use my tests to raise issues or diagnose the issue yourself. Thanks.


Where would be the correct place to report this bug as with this repro it requires no custom code, just enabling a mode that one would presume should work.


If superword mode or function is part of Emacs, then report on Emacs itself. If superword mode is a separate package, then report it on that. For the custom code, then reporting it to the relevant evil package seems appropriate.


The problem isn’t with superword mode: it’s with the combination of superword mode and clojure mode.


And I’m not going to do anything about reporting the custom code as a fix for superword mode would be a fix for that custom code as well.


And as you’ve demonstrated, people aren’t exactly keen to step up and make fixes for “custom code”. A built in mode however seems much more relevant


Certainly if they don't use it themselves. Even if you find a fix, I don't need it. I don't use Evil the way you do so this is irrelevant and of no benefit to myself.


Yep understood


I’m having a little bit of trouble getting a function to work as intended (I’m pretty new to elisp) Basically I want the hook to run and check the root of the project for a file called WORKSPACE, and if that exists activate the minor mode called bazel-build-mode. Would be grateful if someone could take a look. Cheers!


@cfeckardt I suggest you also share your issue in the Spacemacs Gitter chat, probably get more help for this particular challenge there