boruch-baum / emacs-w3m Goto Github PK

Normally GNU Emacs loads pretty quickly for me on startup (0.88 seconds); however, if I load w3m, it takes a whopping 19.42 seconds to load. I set debug-on-quit to t so I could interrupt w3m while it hangs. I did this from a vanilla GNU Emacs 27.1 (stable) version, and I saw a huge byte code for defvar w3m-content-type-alist that Emacs was trying to evaluate.

I grepped the source code for it and got this: w3m.el:1061:(defvar w3m-content-type-alist. When I went directly to that line and evaluated it, sure enough: It took ~20 seconds to load. My mailcap file is big, though (888 lines), so this lag time affects me a lot.

This bug was also experienced on the main branch about a year ago: emacs-w3m#73. Can you implement the same fix that they made to improve how the mailcap file is parsed and hence optimize the startup time?

The source code for command w3m-scroll-up-or-next-url is identical to w3m-scroll-down-or-previous-url. This causes the keybinding SPC to behave the same way as keybinding DEL - i.e., these commands always bring me to the previous url instead of the next url.

I noticed this behaviour when I was browsing through the gemini archives (open any of those threads to test this behaviour).

Should the defun on this repository match the definition on the main branch?

Hi.

I don't know how this happened (perhaps a version control bug?), but I see strange strings within the file mime-w3m.el, which look something like this:

<<<<<<< HEAD
=======
>>>>>>> b5ec8774904ac9be0879928283b99ac77c3e2b63

The last string appears to be a reference to commit b5ec877 (mime-w3m.el looks fine in this commit; no strange strings).

Attached is a patch - mime-w3m-patch.txt - to show the difference of the file on your branch and the main branch.