* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode [not found] ` <mailman.1991.1592327403.2541.bug-gnu-emacs@gnu.org> @ 2020-06-20 17:18 ` Alan Mackenzie 2020-06-20 18:27 ` Simen Heggestøyl [not found] ` <87d05ta8z9.fsf@simenheg@gmail.com> 0 siblings, 2 replies; 30+ messages in thread From: Alan Mackenzie @ 2020-06-20 17:18 UTC (permalink / raw) To: Simen Heggestøyl; +Cc: acm, 41897 Hello, Simen. In article <mailman.1991.1592327403.2541.bug-gnu-emacs@gnu.org> you wrote: > In js-mode, the following JavaScript comment is filled as expected when > fill-paragraph (M-q) is used with point within it: > /* > * This is a long comment that should break over multiple lines when fill-paragraph is used. > */ > Is filled as: > /* > * This is a long comment that should break over multiple lines when > * fill-paragraph is used. > */ > In mhtml-mode however, the same JavaScript comment: > <html> > <script> > /* > * This is a long comment that should break over multiple lines when fill-paragraph is used. > */ > </script> > </html> > Is filled as: > <html> > <script> > /* * This is a long comment that should break over multiple lines > when fill-paragraph is used. */ > </script> > </html> Yes. This is happening because the mechanism mhtml-mode is using to "switch to" js-mode is imperfect. Having more than one major mode in a buffer is a difficult problem for Emacs, and there are currently no really satisfactory solutions. "Switching to" another mode essentially means setting buffer local variable copies. In the existing code, a variable essential to filling, adaptive-fill-regexp, isn't getting set to a value suitable for js-mode. Also, there was an error in the js-mode setting of the variable comment-start-skip. The patch below fixes both these errors, and seems to allow your test case to work. However, it is an incomplete solution - in particular, filling caused by typing at the end of a long line still isn't working properly. Still, it may be better than nothing, at least for now. I intend to carry on working on this bug. You haven't said what version of Emacs you're running. The patch applies cleanly both to the upcoming emacs-27 branch and the master branch at GNU savannah. To apply it, cd into ..../emacs/lisp, and execute: $ patch -p2 < this-email . Then byte-compile the two changed files and load them (possibly by restarting Emacs). Here's the patch: diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el index 04b449ecd2..f5b6a4c260 100644 --- a/lisp/progmodes/js.el +++ b/lisp/progmodes/js.el @@ -4570,7 +4570,7 @@ js-mode ;; Comments (setq-local comment-start "// ") - (setq-local comment-start-skip "\\(//+\\|/\\*+\\)\\s *") + (setq-local comment-start-skip "\\(?://+\\|/\\*+\\)\\s *") (setq-local comment-end "") (setq-local fill-paragraph-function #'js-fill-paragraph) (setq-local normal-auto-fill-function #'js-do-auto-fill) diff --git a/lisp/textmodes/mhtml-mode.el b/lisp/textmodes/mhtml-mode.el index 1ae07c0a30..069329f4e4 100644 --- a/lisp/textmodes/mhtml-mode.el +++ b/lisp/textmodes/mhtml-mode.el @@ -73,7 +73,8 @@ mhtml-tag-relative-indent (defconst mhtml--crucial-variable-prefix (regexp-opt '("comment-" "uncomment-" "electric-indent-" - "smie-" "forward-sexp-function" "completion-" "major-mode")) + "smie-" "forward-sexp-function" "completion-" "major-mode" + "adaptive-fill-" "fill-")) "Regexp matching the prefix of \"crucial\" buffer-locals we want to capture.") (defconst mhtml--variable-prefix -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-20 17:18 ` bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode Alan Mackenzie @ 2020-06-20 18:27 ` Simen Heggestøyl [not found] ` <87d05ta8z9.fsf@simenheg@gmail.com> 1 sibling, 0 replies; 30+ messages in thread From: Simen Heggestøyl @ 2020-06-20 18:27 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 41897 [-- Attachment #1: Type: text/plain, Size: 775 bytes --] Hi Alan, thanks for working on this. Alan Mackenzie <acm@muc.de> writes: > The patch below fixes both these errors, and seems to allow your test > case to work. Yes, this seems to fix it in both emacs-27 and master, thanks. However in emacs-27 with the patch applied I now get a strange side-effect: After filling the comment, mhtml-mode seems to lose track of where the JavaScript portion of the buffer is. Please see the attached image. The position where point is should still be recognized as HTML+JS, but it's recognized as plain HTML+ instead after filling. This doesn't happen on master. > You haven't said what version of Emacs you're running. I put the version number in the bug subject but forgot to mention it in the description, sorry about that. -- Simen [-- Attachment #2: bug41897.png --] [-- Type: image/png, Size: 47390 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <87d05ta8z9.fsf@simenheg@gmail.com>]
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode [not found] ` <87d05ta8z9.fsf@simenheg@gmail.com> @ 2020-06-21 16:55 ` Alan Mackenzie 2020-06-22 19:17 ` Alan Mackenzie 1 sibling, 0 replies; 30+ messages in thread From: Alan Mackenzie @ 2020-06-21 16:55 UTC (permalink / raw) To: Simen Heggestøyl; +Cc: 41897 Hello again, Simen. On Sat, Jun 20, 2020 at 20:27:22 +0200, Simen Heggestøyl wrote: > Alan Mackenzie <acm@muc.de> writes: > > The patch below fixes both these errors, and seems to allow your test > > case to work. > Yes, this seems to fix it in both emacs-27 and master, thanks. > However in emacs-27 with the patch applied I now get a strange > side-effect: After filling the comment, mhtml-mode seems to lose track > of where the JavaScript portion of the buffer is. Please see the > attached image. The position where point is should still be recognized > as HTML+JS, but it's recognized as plain HTML+ instead after > filling. This doesn't happen on master. Yes. mhtml-mode keeps track of the position of the JavaScript bit by applying text-properties. In certain circumstances, when point is at (point-min), it fails to re-apply those properties after removing them. This was happening in the filling, which uses narrowing. I think I've got this fixed, now. (See patch below.) > > You haven't said what version of Emacs you're running. > I put the version number in the bug subject but forgot to mention it in > the description, sorry about that. No, my apologies: I completely missed it in the subject line. I'm happy that you're working in master, and not Emacs 26. :-) Anyhow, I've made significant progress on the problem. As well as the problem above, I've repaired a few defects with auto-fill-mode. It's more or less working. But M-q isn't completely working. If a buffer contains the long line of your test case, followed by another line, M-q doesn't fill them together, leaving the short line untouched. I've had problems with auto-fill-function, and the current state in the patch involves mhtml-mode assuming auto-fill-function is enabled. This obviously needs fixing, but that's the way it is for now. Sorry. There's still a bug with M-q where it sometimes throws an error about a search being "on the wrong side of point". I haven't had time to investigate this, yet. So here's the current patch for the problem. Please install it on master after removing yesterday's patch. From the .../emacs/lisp directory, it should work with $ patch -p2 < this-email. (Or, maybe there's a git command to do it more directly.) diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el index 04b449ecd2..f5b6a4c260 100644 --- a/lisp/progmodes/js.el +++ b/lisp/progmodes/js.el @@ -4570,7 +4570,7 @@ js-mode ;; Comments (setq-local comment-start "// ") - (setq-local comment-start-skip "\\(//+\\|/\\*+\\)\\s *") + (setq-local comment-start-skip "\\(?://+\\|/\\*+\\)\\s *") (setq-local comment-end "") (setq-local fill-paragraph-function #'js-fill-paragraph) (setq-local normal-auto-fill-function #'js-do-auto-fill) diff --git a/lisp/textmodes/mhtml-mode.el b/lisp/textmodes/mhtml-mode.el index 1ae07c0a30..c5970cbcd1 100644 --- a/lisp/textmodes/mhtml-mode.el +++ b/lisp/textmodes/mhtml-mode.el @@ -73,15 +73,18 @@ mhtml-tag-relative-indent (defconst mhtml--crucial-variable-prefix (regexp-opt '("comment-" "uncomment-" "electric-indent-" - "smie-" "forward-sexp-function" "completion-" "major-mode")) + "smie-" "forward-sexp-function" "completion-" "major-mode" + "adaptive-fill-" "fill-" "auto-fill-function")) "Regexp matching the prefix of \"crucial\" buffer-locals we want to capture.") (defconst mhtml--variable-prefix (regexp-opt '("font-lock-" "indent-line-function")) "Regexp matching the prefix of buffer-locals we want to capture.") -(defun mhtml--construct-submode (mode &rest args) - "A wrapper for make-mhtml--submode that computes the buffer-local variables." +(defun mhtml--construct-submode (mode crucial-localized localized &rest args) + "A wrapper for make-mhtml--submode that computes the buffer-local variables. +CRUCIAL-LOCALIZED and LOCALIZED are lists of symbols which must +be considered crucial-local and local variables respectively." (let ((captured-locals nil) (crucial-captured-locals nil) (submode (apply #'make-mhtml--submode args))) @@ -94,6 +97,16 @@ mhtml--construct-submode (unless (variable-binding-locus 'font-lock-fontify-region-function) (setq-local font-lock-fontify-region-function #'font-lock-default-fontify-region)) + ;; Get the values from global variables which might become buffer local. + (dolist (iter crucial-localized) + (let ((sym (if (symbolp iter) iter (car iter))) + (val (symbol-value (if (symbolp iter) iter (cdr iter))))) + (push (cons sym val) crucial-captured-locals))) + (dolist (iter localized) + (let ((sym (if (symbolp iter) iter (car iter))) + (val (symbol-value (if (symbolp iter) iter (cdr iter))))) + (push (cons sym val) captured-locals))) + (dolist (iter (buffer-local-variables)) (when (string-match mhtml--crucial-variable-prefix (symbol-name (car iter))) @@ -119,6 +132,8 @@ mhtml--mark-crucial-buffer-locals (defconst mhtml--css-submode (mhtml--construct-submode 'css-mode + '((auto-fill-function . normal-auto-fill-function)) + nil :name "CSS" :end-tag "</style>" :syntax-table css-mode-syntax-table @@ -127,6 +142,8 @@ mhtml--css-submode (defconst mhtml--js-submode (mhtml--construct-submode 'js-mode + '((auto-fill-function . normal-auto-fill-function)) + nil :name "JS" :end-tag "</script>" :syntax-table js-mode-syntax-table @@ -202,12 +219,16 @@ mhtml--stashed-crucial-variables (defun mhtml--stash-crucial-variables () (setq mhtml--stashed-crucial-variables (mapcar (lambda (sym) - (cons sym (buffer-local-value sym (current-buffer)))) + (if (boundp sym) + (cons sym (buffer-local-value sym (current-buffer))) + sym)) mhtml--crucial-variables))) (defun mhtml--map-in-crucial-variables (alist) (dolist (item alist) - (set (car item) (cdr item)))) + (if (symbolp item) + (makunbound item) + (set (car item) (cdr item))))) (defun mhtml--pre-command () (let ((submode (get-text-property (point) 'mhtml-submode))) @@ -255,17 +276,14 @@ mhtml--syntax-propertize sgml-syntax-propertize-rules)) (defun mhtml-syntax-propertize (start end) - ;; First remove our special settings from the affected text. They - ;; will be re-applied as needed. - (remove-list-of-text-properties start end - '(syntax-table local-map mhtml-submode)) - (goto-char start) - ;; Be sure to look back one character, because START won't yet have - ;; been propertized. - (unless (bobp) - (let ((submode (get-text-property (1- (point)) 'mhtml-submode))) - (if submode - (mhtml--syntax-propertize-submode submode end)))) + (let ((submode (get-text-property start 'mhtml-submode))) + ;; First remove our special settings from the affected text. They + ;; will be re-applied as needed. + (remove-list-of-text-properties start end + '(syntax-table local-map mhtml-submode)) + (goto-char start) + (if submode + (mhtml--syntax-propertize-submode submode end))) (sgml-syntax-propertize (point) end mhtml--syntax-propertize)) (defun mhtml-indent-line () > -- Simen -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode [not found] ` <87d05ta8z9.fsf@simenheg@gmail.com> 2020-06-21 16:55 ` Alan Mackenzie @ 2020-06-22 19:17 ` Alan Mackenzie 2020-06-23 0:02 ` Dmitry Gutov ` (2 more replies) 1 sibling, 3 replies; 30+ messages in thread From: Alan Mackenzie @ 2020-06-22 19:17 UTC (permalink / raw) To: Simen Heggestøyl; +Cc: acm, 41897 Hello, Simen. We're gradually converging on working code. Since yesterday, the improvements are: (i) (slightly) better handling of auto-fill-mode, which is no longer automatically enabled; (ii) An enhancement to CC Mode, used by mhtml-mode and js-mode, which invalidates a CC Mode cache used by the filling code. This gets rid of a few strange looking bugs; (iii) The inclusion of "paragraph-" in the "crucial variables" thing, so that paragraph-start and paragraph-separate from js-mode get into mhtml-mode. On Sat, Jun 20, 2020 at 20:27:22 +0200, Simen Heggestøyl wrote: > Hi Alan, thanks for working on this. > Alan Mackenzie <acm@muc.de> writes: > > The patch below fixes both these errors, and seems to allow your test > > case to work. > Yes, this seems to fix it in both emacs-27 and master, thanks. > However in emacs-27 with the patch applied I now get a strange > side-effect: After filling the comment, mhtml-mode seems to lose track > of where the JavaScript portion of the buffer is. Please see the > attached image. The position where point is should still be recognized > as HTML+JS, but it's recognized as plain HTML+ instead after > filling. This doesn't happen on master. I think this is now properly fixed. Would you please try the latest patch, which might, just might, be fully working code. As always, this is a diff on the code _without_ previous patches. I haven't tested bits of enclosed css-mode source - you're certainly better equipped to do this than I am. diff --git a/lisp/progmodes/cc-engine.el b/lisp/progmodes/cc-engine.el index 8c8296fd6d..d8279ba4f0 100644 --- a/lisp/progmodes/cc-engine.el +++ b/lisp/progmodes/cc-engine.el @@ -3209,6 +3209,24 @@ c-truncate-lit-pos-cache c-semi-near-cache-limit (min c-semi-near-cache-limit pos) c-full-near-cache-limit (min c-full-near-cache-limit pos))) +(defun c-foreign-truncate-lit-pos-cache (beg _end) + "Truncate CC Mode's literal cache. + +This function should be added to the `before-change-functions' +hook by major modes that use CC Mode's filling functionality +without initializing CC Mode. Currently (2020-06) these are +js-mode and mhtml-mode." + (c-truncate-lit-pos-cache beg)) + +(defun c-foreign-init-lit-pos-cache () + "Initialize CC Mode's literal cache. + +This function should be called from the mode functions of major +modes which use CC Mode's filling functionality without +initializing CC Mode. Currently (2020-06) these are js-mode and +mhtml-mode." + (c-truncate-lit-pos-cache 1)) + \f ;; A system for finding noteworthy parens before the point. diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el index 04b449ecd2..5c50e2accd 100644 --- a/lisp/progmodes/js.el +++ b/lisp/progmodes/js.el @@ -4570,7 +4570,7 @@ js-mode ;; Comments (setq-local comment-start "// ") - (setq-local comment-start-skip "\\(//+\\|/\\*+\\)\\s *") + (setq-local comment-start-skip "\\(?://+\\|/\\*+\\)\\s *") (setq-local comment-end "") (setq-local fill-paragraph-function #'js-fill-paragraph) (setq-local normal-auto-fill-function #'js-do-auto-fill) @@ -4591,6 +4591,8 @@ js-mode (setq imenu-create-index-function #'js--imenu-create-index) ;; for filling, pretend we're cc-mode + (c-foreign-init-lit-pos-cache) + (add-hook 'before-change-functions #'c-foreign-truncate-lit-pos-cache nil t) (setq-local comment-line-break-function #'c-indent-new-comment-line) (setq-local comment-multi-line t) (setq-local electric-indent-chars diff --git a/lisp/textmodes/mhtml-mode.el b/lisp/textmodes/mhtml-mode.el index 1ae07c0a30..bed0ced618 100644 --- a/lisp/textmodes/mhtml-mode.el +++ b/lisp/textmodes/mhtml-mode.el @@ -73,7 +73,9 @@ mhtml-tag-relative-indent (defconst mhtml--crucial-variable-prefix (regexp-opt '("comment-" "uncomment-" "electric-indent-" - "smie-" "forward-sexp-function" "completion-" "major-mode")) + "smie-" "forward-sexp-function" "completion-" "major-mode" + "adaptive-fill-" "fill-" "normal-auto-fill-function" + "paragraph-")) "Regexp matching the prefix of \"crucial\" buffer-locals we want to capture.") (defconst mhtml--variable-prefix @@ -94,6 +96,7 @@ mhtml--construct-submode (unless (variable-binding-locus 'font-lock-fontify-region-function) (setq-local font-lock-fontify-region-function #'font-lock-default-fontify-region)) + (dolist (iter (buffer-local-variables)) (when (string-match mhtml--crucial-variable-prefix (symbol-name (car iter))) @@ -255,17 +258,14 @@ mhtml--syntax-propertize sgml-syntax-propertize-rules)) (defun mhtml-syntax-propertize (start end) - ;; First remove our special settings from the affected text. They - ;; will be re-applied as needed. - (remove-list-of-text-properties start end - '(syntax-table local-map mhtml-submode)) - (goto-char start) - ;; Be sure to look back one character, because START won't yet have - ;; been propertized. - (unless (bobp) - (let ((submode (get-text-property (1- (point)) 'mhtml-submode))) - (if submode - (mhtml--syntax-propertize-submode submode end)))) + (let ((submode (get-text-property start 'mhtml-submode))) + ;; First remove our special settings from the affected text. They + ;; will be re-applied as needed. + (remove-list-of-text-properties start end + '(syntax-table local-map mhtml-submode)) + (goto-char start) + (if submode + (mhtml--syntax-propertize-submode submode end))) (sgml-syntax-propertize (point) end mhtml--syntax-propertize)) (defun mhtml-indent-line () @@ -333,6 +333,18 @@ mhtml-mode ;: Hack (js--update-quick-match-re) + ;; Setup the appropriate js-mode value of auto-fill-function. + (setf (mhtml--submode-crucial-captured-locals mhtml--js-submode) + (push (cons 'auto-fill-function + (if (and (boundp 'auto-fill-function) auto-fill-function) + #'js-do-auto-fill + nil)) + (mhtml--submode-crucial-captured-locals mhtml--js-submode))) + + ;; This mode might be using CC Mode's filling functionality. + (c-foreign-init-lit-pos-cache) + (add-hook 'before-change-functions #'c-foreign-truncate-lit-pos-cache nil t) + ;; This is sort of a prog-mode as well as a text mode. (run-hooks 'prog-mode-hook)) > -- Simen -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-22 19:17 ` Alan Mackenzie @ 2020-06-23 0:02 ` Dmitry Gutov 2020-06-23 8:36 ` Alan Mackenzie 2020-06-25 20:49 ` Tom Tromey 2020-07-04 13:13 ` Alan Mackenzie 2 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-23 0:02 UTC (permalink / raw) To: Alan Mackenzie, Simen Heggestøyl; +Cc: 41897 Hi Alan, On 22.06.2020 22:17, Alan Mackenzie wrote: > +(defun c-foreign-truncate-lit-pos-cache (beg _end) > + "Truncate CC Mode's literal cache. > + > +This function should be added to the `before-change-functions' > +hook by major modes that use CC Mode's filling functionality > +without initializing CC Mode. Currently (2020-06) these are > +js-mode and mhtml-mode." > + (c-truncate-lit-pos-cache beg)) Could you explain this part? Is that literal cache looked up once during filling, or is it used multiple times during the execution of c-fill-paragraph? If the latter (and it does serve as a cache this way), perhaps it could be cleared once, at the beginning of c-fill-paragraph, instead of adding a runtime cost to every edit? Or if that's undesirable, js-fill-paragraph could do that. This way, I think it would automatically make it compatible with mmm-mode. Or at least more compatible. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 0:02 ` Dmitry Gutov @ 2020-06-23 8:36 ` Alan Mackenzie 2020-06-23 14:23 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-23 8:36 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Tue, Jun 23, 2020 at 03:02:48 +0300, Dmitry Gutov wrote: > Hi Alan, > On 22.06.2020 22:17, Alan Mackenzie wrote: > > +(defun c-foreign-truncate-lit-pos-cache (beg _end) > > + "Truncate CC Mode's literal cache. > > + > > +This function should be added to the `before-change-functions' > > +hook by major modes that use CC Mode's filling functionality > > +without initializing CC Mode. Currently (2020-06) these are > > +js-mode and mhtml-mode." > > + (c-truncate-lit-pos-cache beg)) > Could you explain this part? > Is that literal cache looked up once during filling, or is it used > multiple times during the execution of c-fill-paragraph? It's used several times during each filling operation. This cache persists between commands, too. > If the latter (and it does serve as a cache this way), perhaps it > could be cleared once, at the beginning of c-fill-paragraph, instead > of adding a runtime cost to every edit? The cost is tiny. c-truncate-lit-pos-cache is a defsubst which does nothing but three copies of (setq cache-limit (min beg cache-limit)) . All the intricacies of manipulating the cache take place whilst it is being used. > Or if that's undesirable, js-fill-paragraph could do that. No, it really has to be in a before-change-functions function, to keep track of the bound of the valid cache. > This way, I think it would automatically make it compatible with > mmm-mode. Or at least more compatible. Maybe putting the two c-foreign-* functions into mmm-mode would work. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 8:36 ` Alan Mackenzie @ 2020-06-23 14:23 ` Dmitry Gutov 2020-06-23 16:28 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-23 14:23 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 On 23.06.2020 11:36, Alan Mackenzie wrote: >> If the latter (and it does serve as a cache this way), perhaps it >> could be cleared once, at the beginning of c-fill-paragraph, instead >> of adding a runtime cost to every edit? > > The cost is tiny. c-truncate-lit-pos-cache is a defsubst which does > nothing but three copies of > > (setq cache-limit (min beg cache-limit)) > > . All the intricacies of manipulating the cache take place whilst it is > being used. > >> Or if that's undesirable, js-fill-paragraph could do that. > > No, it really has to be in a before-change-functions function, to keep > track of the bound of the valid cache. So it's really fine if it's called from HTML/CSS hunks as well? And there's no way to just "reset" it to an appropriate value? >> This way, I think it would automatically make it compatible with >> mmm-mode. Or at least more compatible. > > Maybe putting the two c-foreign-* functions into mmm-mode would work. mmm-mode is a minor mode, it doesn't always deal with CC Mode. And its configurations don't usually result in new major modes either. I wouldn't say it's very hard to make it work, but I don't see a "neat" way to do either. Have you considered adding variables that hold the cache to mhtml--crucial-variable-prefix as well? Would that make it work? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 14:23 ` Dmitry Gutov @ 2020-06-23 16:28 ` Alan Mackenzie 2020-06-23 17:59 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-23 16:28 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, 41897 Hello, Dmitry. On Tue, Jun 23, 2020 at 17:23:53 +0300, Dmitry Gutov wrote: > On 23.06.2020 11:36, Alan Mackenzie wrote: > >> If the latter (and it does serve as a cache this way), perhaps it > >> could be cleared once, at the beginning of c-fill-paragraph, instead > >> of adding a runtime cost to every edit? > > The cost is tiny. c-truncate-lit-pos-cache is a defsubst which does > > nothing but three copies of > > (setq cache-limit (min beg cache-limit)) > > . All the intricacies of manipulating the cache take place whilst it > > is being used. > >> Or if that's undesirable, js-fill-paragraph could do that. > > No, it really has to be in a before-change-functions function, to > > keep track of the bound of the valid cache. > So it's really fine if it's called from HTML/CSS hunks as well? Not only fine, but necessary. The literal cache contains entries that record things like "C comment between positions 23 and 130". If somebody inserts text before that comment, or inside of it, that cache entry is no longer valid, and must be invalidated. Hence the necessity of the before-change function. > And there's no way to just "reset" it to an appropriate value? No. Not without killing its utility as a cache. > >> This way, I think it would automatically make it compatible with > >> mmm-mode. Or at least more compatible. > > Maybe putting the two c-foreign-* functions into mmm-mode would work. > mmm-mode is a minor mode, it doesn't always deal with CC Mode. The question to consider here is whether any sub-mode of mmm-mode uses CC Mode's comment filling without initialising CC Mode. js-mode and mhtml-mode do this. > And its configurations don't usually result in new major modes either. > I wouldn't say it's very hard to make it work, but I don't see a "neat" > way to do either. OK. > Have you considered adding variables that hold the cache to > mhtml--crucial-variable-prefix as well? Would that make it work? Not without the before-change function, no. I'm trying to see what the point of putting these variables into mhtml's crucial variables would be. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 16:28 ` Alan Mackenzie @ 2020-06-23 17:59 ` Dmitry Gutov 2020-06-23 19:17 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-23 17:59 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 Hi Alan, On 23.06.2020 19:28, Alan Mackenzie wrote: >> So it's really fine if it's called from HTML/CSS hunks as well? > > Not only fine, but necessary. The literal cache contains entries that > record things like "C comment between positions 23 and 130". If somebody > inserts text before that comment, or inside of it, that cache entry is no > longer valid, and must be invalidated. Hence the necessity of the > before-change function. But isn't CC Mode confused by chunks of text with a totally different syntax? >> And there's no way to just "reset" it to an appropriate value? > > No. Not without killing its utility as a cache. What do you mean? Even if the cache is reset at the beginning of a function, if the function refers to it multiple times, the first time should refill the cache, and the rest of the calls will be able to make use of it properly. >>>> This way, I think it would automatically make it compatible with >>>> mmm-mode. Or at least more compatible. > >>> Maybe putting the two c-foreign-* functions into mmm-mode would work. > >> mmm-mode is a minor mode, it doesn't always deal with CC Mode. > > The question to consider here is whether any sub-mode of mmm-mode uses CC > Mode's comment filling without initialising CC Mode. js-mode and > mhtml-mode do this. js-mode can be one of its submodes. c-mode as well, but none of CC Mode family of major modes ever worked okay with it, I think. js-mode mostly works, aside from features like this one. >> Have you considered adding variables that hold the cache to >> mhtml--crucial-variable-prefix as well? Would that make it work? > > Not without the before-change function, no. I'm trying to see what the > point of putting these variables into mhtml's crucial variables would be. Hopefully, it would make the submode regions inside independent "islands", so to speak. Each of them having its own cache structure (used or not). TBH I'm not sure if mhtml-mode does the save-and-restore dance which would be necessary for this. mmm-mode does, though. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 17:59 ` Dmitry Gutov @ 2020-06-23 19:17 ` Alan Mackenzie 2020-06-23 23:11 ` Dmitry Gutov 2020-06-25 20:53 ` Tom Tromey 0 siblings, 2 replies; 30+ messages in thread From: Alan Mackenzie @ 2020-06-23 19:17 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Tue, Jun 23, 2020 at 20:59:22 +0300, Dmitry Gutov wrote: > Hi Alan, > On 23.06.2020 19:28, Alan Mackenzie wrote: > >> So it's really fine if it's called from HTML/CSS hunks as well? > > Not only fine, but necessary. The literal cache contains entries > > that record things like "C comment between positions 23 and 130". If > > somebody inserts text before that comment, or inside of it, that > > cache entry is no longer valid, and must be invalidated. Hence the > > necessity of the before-change function. > But isn't CC Mode confused by chunks of text with a totally different > syntax? It might well be, probably is. But this isn't CC Mode we're talking about - just a tiny part of its low level functionality, namely the bit dealing with literals and filling them. > >> And there's no way to just "reset" it to an appropriate value? > > No. Not without killing its utility as a cache. > What do you mean? Even if the cache is reset at the beginning of a > function, if the function refers to it multiple times, the first time > should refill the cache, and the rest of the calls will be able to make > use of it properly. That's what I mean. The cache persists over commands, reducing the amount of recalculation needed, particularly for fast typing. Refilling it from scratch on every keypress would likely make it sluggish. Anyhow, it works fine at the moment, so why change it? [ .... ] > >> mmm-mode is a minor mode, it doesn't always deal with CC Mode. > > The question to consider here is whether any sub-mode of mmm-mode > > uses CC Mode's comment filling without initialising CC Mode. js-mode > > and mhtml-mode do this. > js-mode can be one of its submodes. c-mode as well, but none of CC Mode > family of major modes ever worked okay with it, I think. Having several major modes in a single buffer has always been problematic in Emacs. Personally, I think there needs to be amendments in the low-level C code to support it properly, but I'm not able to do this work on my own, and there doesn't seem to be enough enthusiasm on other people's part to help out. > js-mode mostly works, aside from features like this one. With the current patch, comment filling should work fine in js-mode. > >> Have you considered adding variables that hold the cache to > >> mhtml--crucial-variable-prefix as well? Would that make it work? > > Not without the before-change function, no. I'm trying to see what the > > point of putting these variables into mhtml's crucial variables would be. > Hopefully, it would make the submode regions inside independent > "islands", so to speak. Each of them having its own cache structure > (used or not). Ah, OK. So, buffer positions would be offsets from the island start, or something like that. > TBH I'm not sure if mhtml-mode does the save-and-restore dance which > would be necessary for this. mmm-mode does, though. mhtml-mode does do saving and restoring of local variables. I can't judge how well in comparison with, say, mmm-mode. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 19:17 ` Alan Mackenzie @ 2020-06-23 23:11 ` Dmitry Gutov 2020-06-24 17:43 ` Alan Mackenzie 2020-06-25 20:53 ` Tom Tromey 1 sibling, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-23 23:11 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 On 23.06.2020 22:17, Alan Mackenzie wrote: >> But isn't CC Mode confused by chunks of text with a totally different >> syntax? > > It might well be, probably is. But this isn't CC Mode we're talking > about - just a tiny part of its low level functionality, namely the bit > dealing with literals and filling them. So this cache is really serving the filling functionality only in this case. >>>> And there's no way to just "reset" it to an appropriate value? > >>> No. Not without killing its utility as a cache. > >> What do you mean? Even if the cache is reset at the beginning of a >> function, if the function refers to it multiple times, the first time >> should refill the cache, and the rest of the calls will be able to make >> use of it properly. > > That's what I mean. The cache persists over commands, reducing the > amount of recalculation needed, particularly for fast typing. Refilling > it from scratch on every keypress would likely make it sluggish. Not on every keypress. Only when js-fill-paragraph is called. One-time delay only when required. > Anyhow, it works fine at the moment, so why change it? The above scheme would require fewer references to CC Mode functions from outside. js-mode support would automatically transfer to mhtml-mode and mmm-mode with associated changes in them necessary. One fewer before-change-functions element is also nothing to sneeze at. >> js-mode can be one of its submodes. c-mode as well, but none of CC Mode >> family of major modes ever worked okay with it, I think. > > Having several major modes in a single buffer has always been problematic > in Emacs. Personally, I think there needs to be amendments in the > low-level C code to support it properly, but I'm not able to do this work > on my own, and there doesn't seem to be enough enthusiasm on other > people's part to help out. We've learned to deal with most other major modes and features in mmm context. >> js-mode mostly works, aside from features like this one. > > With the current patch, comment filling should work fine in js-mode. Above, I meant that js-mode mostly works fine with mmm-mode. And my suggestion might make comment filling work there, too. Automatically. >>>> Have you considered adding variables that hold the cache to >>>> mhtml--crucial-variable-prefix as well? Would that make it work? > >>> Not without the before-change function, no. I'm trying to see what the >>> point of putting these variables into mhtml's crucial variables would be. > >> Hopefully, it would make the submode regions inside independent >> "islands", so to speak. Each of them having its own cache structure >> (used or not). > > Ah, OK. So, buffer positions would be offsets from the island start, or > something like that. Not necessarily, but possibly. The key aspect is that the cache inside a particular submode is not affected by user actions outside of its bounds. Not directly, at least. But that's an mmm-mode feature anyway. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 23:11 ` Dmitry Gutov @ 2020-06-24 17:43 ` Alan Mackenzie 2020-06-24 18:28 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-24 17:43 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Wed, Jun 24, 2020 at 02:11:31 +0300, Dmitry Gutov wrote: > On 23.06.2020 22:17, Alan Mackenzie wrote: [ .... ] > >>>> And there's no way to just "reset" it to an appropriate value? > >>> No. Not without killing its utility as a cache. > >> What do you mean? Even if the cache is reset at the beginning of a > >> function, if the function refers to it multiple times, the first time > >> should refill the cache, and the rest of the calls will be able to make > >> use of it properly. > > That's what I mean. The cache persists over commands, reducing the > > amount of recalculation needed, particularly for fast typing. Refilling > > it from scratch on every keypress would likely make it sluggish. > Not on every keypress. Only when js-fill-paragraph is called. One-time > delay only when required. But a substantial delay, involving (I think) analysing the code from BOB each time. The current working setup has a negligible delay at each buffer change (and, of course, recalculation of cache entries only when required). > > Anyhow, it works fine at the moment, so why change it? > The above scheme would require fewer references to CC Mode functions > from outside. js-mode support would automatically transfer to mhtml-mode > and mmm-mode with associated changes in them necessary. It sounds like you want to use a facility without initialising it. This feels a bit unreasonable. > One fewer before-change-functions element is also nothing to sneeze at. There's nothing wrong with having functions in before/after-change-functions. It's a standard Emacs programming technique. [ .... ] > >> js-mode mostly works, aside from features like this one. > > With the current patch, comment filling should work fine in js-mode. > Above, I meant that js-mode mostly works fine with mmm-mode. And my > suggestion might make comment filling work there, too. Automatically. It works automatically at the moment (with the current patch applied). I think you're saying again you don't want to be troubled by initialising it. > >>>> Have you considered adding variables that hold the cache to > >>>> mhtml--crucial-variable-prefix as well? Would that make it work? > >>> Not without the before-change function, no. I'm trying to see what the > >>> point of putting these variables into mhtml's crucial variables would be. > >> Hopefully, it would make the submode regions inside independent > >> "islands", so to speak. Each of them having its own cache structure > >> (used or not). > > Ah, OK. So, buffer positions would be offsets from the island start, or > > something like that. > Not necessarily, but possibly. The key aspect is that the cache inside a > particular submode is not affected by user actions outside of its > bounds. Not directly, at least. Well, when a cached holds buffer positions, something has to give - either markers need to be used, or an offset from a variable position, or something. > But that's an mmm-mode feature anyway. OK. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-24 17:43 ` Alan Mackenzie @ 2020-06-24 18:28 ` Dmitry Gutov 2020-06-25 16:33 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-24 18:28 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 Hi Alan, On 24.06.2020 20:43, Alan Mackenzie wrote: >>> That's what I mean. The cache persists over commands, reducing the >>> amount of recalculation needed, particularly for fast typing. Refilling >>> it from scratch on every keypress would likely make it sluggish. > >> Not on every keypress. Only when js-fill-paragraph is called. One-time >> delay only when required. > > But a substantial delay, involving (I think) analysing the code from BOB > each time. The current working setup has a negligible delay at each > buffer change (and, of course, recalculation of cache entries only when > required). I imagine that would not be a significant problem for the rare cases that fill-paragraph is called in a JS region. Considering most of the contents in mhtml-mode buffers are not JS code, on average, that should tilt the scales in favor of parsing lazily, rather than affecting every character insertion. >>> Anyhow, it works fine at the moment, so why change it? > >> The above scheme would require fewer references to CC Mode functions >> from outside. js-mode support would automatically transfer to mhtml-mode >> and mmm-mode with associated changes in them necessary. > > It sounds like you want to use a facility without initialising it. This > feels a bit unreasonable. That cache reset at the beginning of js-fill-paragraph could as well re-initialize the cache. >> One fewer before-change-functions element is also nothing to sneeze at. > > There's nothing wrong with having functions in > before/after-change-functions. It's a standard Emacs programming > technique. I'm not saying it's a terrible idea, but it has its downsides. >>>> js-mode mostly works, aside from features like this one. > >>> With the current patch, comment filling should work fine in js-mode. > >> Above, I meant that js-mode mostly works fine with mmm-mode. And my >> suggestion might make comment filling work there, too. Automatically. > > It works automatically at the moment (with the current patch applied). I > think you're saying again you don't want to be troubled by initialising > it. It doesn't automatically work in mmm-mode. With my suggestion, it very likely would. >>>>>> Have you considered adding variables that hold the cache to >>>>>> mhtml--crucial-variable-prefix as well? Would that make it work? > >>>>> Not without the before-change function, no. I'm trying to see what the >>>>> point of putting these variables into mhtml's crucial variables would be. > >>>> Hopefully, it would make the submode regions inside independent >>>> "islands", so to speak. Each of them having its own cache structure >>>> (used or not). > >>> Ah, OK. So, buffer positions would be offsets from the island start, or >>> something like that. > >> Not necessarily, but possibly. The key aspect is that the cache inside a >> particular submode is not affected by user actions outside of its >> bounds. Not directly, at least. > > Well, when a cached holds buffer positions, something has to give - > either markers need to be used, or an offset from a variable position, or > something. Makes sense. The alternative would be to index the positions from the beginning of the submode region. But then the related feature must respect narrowing, and it would require explicit integration from mmm-mode and friends. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-24 18:28 ` Dmitry Gutov @ 2020-06-25 16:33 ` Alan Mackenzie 2020-06-25 16:48 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-25 16:33 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Wed, Jun 24, 2020 at 21:28:09 +0300, Dmitry Gutov wrote: > Hi Alan, > On 24.06.2020 20:43, Alan Mackenzie wrote: [ .... ] > > But a substantial delay, involving (I think) analysing the code from > > BOB each time. The current working setup has a negligible delay at > > each buffer change (and, of course, recalculation of cache entries > > only when required). > I imagine that would not be a significant problem for the rare cases > that fill-paragraph is called in a JS region. Considering most of the > contents in mhtml-mode buffers are not JS code, on average, that should > tilt the scales in favor of parsing lazily, rather than affecting every > character insertion. The current patch does parse lazily. You want to remove the benefit of using this cache, no matter how small, for reasons I still can't grasp. This removal will hurt performance, and possibly cause new bugs to solve. [ .... ] > > It sounds like you want to use a facility without initialising it. > > This feels a bit unreasonable. > That cache reset at the beginning of js-fill-paragraph could as well > re-initialize the cache. You're misusing the work "initialize" here. If you initialise a variable every time you read it, you might as well not have that variable. [ .... ] > >>>> js-mode mostly works, aside from features like this one. > >>> With the current patch, comment filling should work fine in js-mode. > >> Above, I meant that js-mode mostly works fine with mmm-mode. And my > >> suggestion might make comment filling work there, too. Automatically. > > It works automatically at the moment (with the current patch applied). I > > think you're saying again you don't want to be troubled by initialising > > it. > It doesn't automatically work in mmm-mode. With my suggestion, it very > likely would. It would work fine with the current patch, together with calls to initialise the mechanism. What precisely is the problem in mmm-mode? [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 16:33 ` Alan Mackenzie @ 2020-06-25 16:48 ` Dmitry Gutov 2020-06-25 18:07 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-25 16:48 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 On 25.06.2020 19:33, Alan Mackenzie wrote: >> I imagine that would not be a significant problem for the rare cases >> that fill-paragraph is called in a JS region. Considering most of the >> contents in mhtml-mode buffers are not JS code, on average, that should >> tilt the scales in favor of parsing lazily, rather than affecting every >> character insertion. > > The current patch does parse lazily. You want to remove the benefit of > using this cache, no matter how small, for reasons I still can't grasp. That's not true. Like you confirmed, c-fill-paragraph refers to that cache multiple times. We'll only make sure the cache is reset in the beginning. >>> It sounds like you want to use a facility without initialising it. >>> This feels a bit unreasonable. > >> That cache reset at the beginning of js-fill-paragraph could as well >> re-initialize the cache. > > You're misusing the work "initialize" here. If you initialise a variable > every time you read it, you might as well not have that variable. Like explained above, not *every* time. >> It doesn't automatically work in mmm-mode. With my suggestion, it very >> likely would. > > It would work fine with the current patch, together with calls to > initialise the mechanism. What precisely is the problem in mmm-mode? That there is no good place to plug in your new functions. And, in general, to have per-mode before-change-functions contents. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 16:48 ` Dmitry Gutov @ 2020-06-25 18:07 ` Alan Mackenzie 2020-06-25 18:19 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-25 18:07 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Thu, Jun 25, 2020 at 19:48:57 +0300, Dmitry Gutov wrote: > On 25.06.2020 19:33, Alan Mackenzie wrote: > >> I imagine that would not be a significant problem for the rare cases > >> that fill-paragraph is called in a JS region. Considering most of the > >> contents in mhtml-mode buffers are not JS code, on average, that should > >> tilt the scales in favor of parsing lazily, rather than affecting every > >> character insertion. > > The current patch does parse lazily. You want to remove the benefit of > > using this cache, no matter how small, for reasons I still can't grasp. > That's not true. Like you confirmed, c-fill-paragraph refers to that > cache multiple times. We'll only make sure the cache is reset in the > beginning. OK, first of all, I think I was mistaken in saying c-literal-limits is called several times. I think it's just called once per filling action. But if it were called several times, it would likely need to be updated at every buffer change between calls. The purpose of this cache is to avoid repeated scanning from BOB. Your proposed continual splatting of it would remove the benefit of it entirely. > >>> It sounds like you want to use a facility without initialising it. > >>> This feels a bit unreasonable. > >> That cache reset at the beginning of js-fill-paragraph could as well > >> re-initialize the cache. > > You're misusing the work "initialize" here. If you initialise a > > variable every time you read it, you might as well not have that > > variable. > Like explained above, not *every* time. > >> It doesn't automatically work in mmm-mode. With my suggestion, it very > >> likely would. > > It would work fine with the current patch, together with calls to > > initialise the mechanism. What precisely is the problem in mmm-mode? > That there is no good place to plug in your new functions. That would appear to be a deficiency in mmm-mode. Does mmm-mode not call js-mode when that is one of the submodes? If it doesn't, then why not add a general init function-variable/hook/whatever into which initialisations can be plugged? > And, in general, to have per-mode before-change-functions contents. There's no problem with before/after-change-functions. They're the canonical way to react to buffer changes. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 18:07 ` Alan Mackenzie @ 2020-06-25 18:19 ` Dmitry Gutov 2020-06-25 19:13 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-25 18:19 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 Hi Alan, On 25.06.2020 21:07, Alan Mackenzie wrote: >> That's not true. Like you confirmed, c-fill-paragraph refers to that >> cache multiple times. We'll only make sure the cache is reset in the >> beginning. > > OK, first of all, I think I was mistaken in saying c-literal-limits is > called several times. I think it's just called once per filling action. > > But if it were called several times, it would likely need to be updated > at every buffer change between calls. > > The purpose of this cache is to avoid repeated scanning from BOB. Your > proposed continual splatting of it would remove the benefit of it > entirely. That's unfortunate. Guess the only thing that remains for me here is to express a wish for a syntax-ppss based design here. Because mmm-mode knows how to deal with major modes based on it, as a group. >>> It would work fine with the current patch, together with calls to >>> initialise the mechanism. What precisely is the problem in mmm-mode? > >> That there is no good place to plug in your new functions. > > That would appear to be a deficiency in mmm-mode. > > Does mmm-mode not call js-mode when that is one of the submodes? If it > doesn't, then why not add a general init function-variable/hook/whatever > into which initialisations can be plugged? It does not pick up each and every hook. If it did, though, it would only call your before-change-functions inside js-mode regions, but it would have ignored them in HTML and CSS regions. Which doesn't appear to be what you want anyway. >> And, in general, to have per-mode before-change-functions contents. > > There's no problem with before/after-change-functions. They're the > canonical way to react to buffer changes. They're not very manageable, from mmm's point of view. And like the current example shows, it's not obvious what to do with such hooks outside of submode regions of major modes that added them. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 18:19 ` Dmitry Gutov @ 2020-06-25 19:13 ` Alan Mackenzie 2020-06-25 19:28 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-25 19:13 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Thu, Jun 25, 2020 at 21:19:11 +0300, Dmitry Gutov wrote: > Hi Alan, > On 25.06.2020 21:07, Alan Mackenzie wrote: > > The purpose of this cache is to avoid repeated scanning from BOB. > > Your proposed continual splatting of it would remove the benefit of > > it entirely. > That's unfortunate. Indeed. Let's assume that keeping it working is a requirement here. > Guess the only thing that remains for me here is to express a wish for a > syntax-ppss based design here. > Because mmm-mode knows how to deal with major modes based on it, as a group. How about enhancing mmm-mode to handle any major mode, rather than a restricted subset? > >>> It would work fine with the current patch, together with calls to > >>> initialise the mechanism. What precisely is the problem in mmm-mode? > >> That there is no good place to plug in your new functions. > > That would appear to be a deficiency in mmm-mode. > > Does mmm-mode not call js-mode when that is one of the submodes? If it > > doesn't, then why not add a general init function-variable/hook/whatever > > into which initialisations can be plugged? > It does not pick up each and every hook. > If it did, though, it would only call your before-change-functions > inside js-mode regions, but it would have ignored them in HTML and CSS > regions. Which doesn't appear to be what you want anyway. Then why not do in mmm-mode what I'm doing in CC Mode, mhtml-mode and js-mode, i.e. add ad hoc code to handle precisely the case of js-mode? It's not very nice, but it helps to analyse in the abstract how we reached the point we are at. That abstract reason is js-mode using part of CC Mode without initialising it. This is bound to lead to trouble, and it has lead to trouble. > >> And, in general, to have per-mode before-change-functions contents. > > There's no problem with before/after-change-functions. They're the > > canonical way to react to buffer changes. > They're not very manageable, from mmm's point of view. And like the > current example shows, it's not obvious what to do with such hooks > outside of submode regions of major modes that added them. Like I said earlier on in the thread, making several major modes in a buffer work is problematic in Emacs, and we really want better support from the C core for it. Here we seem to want "global" and "mode-local" before-change-functionses. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 19:13 ` Alan Mackenzie @ 2020-06-25 19:28 ` Dmitry Gutov 2020-06-25 20:11 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-25 19:28 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 On 25.06.2020 22:13, Alan Mackenzie wrote: >> That's unfortunate. > Indeed. Let's assume that keeping it working is a requirement here. Still, buffers that user mixed modes are usually not so big as some of the files we have in src/*.c. So even forgoing caching might result in a satisfying user experience 98% of the time. >> Guess the only thing that remains for me here is to express a wish for a >> syntax-ppss based design here. > >> Because mmm-mode knows how to deal with major modes based on it, as a group. > > How about enhancing mmm-mode to handle any major mode, rather than a > restricted subset? I don't know how. before-change-functions don't make it easy. >> It does not pick up each and every hook. > >> If it did, though, it would only call your before-change-functions >> inside js-mode regions, but it would have ignored them in HTML and CSS >> regions. Which doesn't appear to be what you want anyway. > > Then why not do in mmm-mode what I'm doing in CC Mode, mhtml-mode and > js-mode, i.e. add ad hoc code to handle precisely the case of js-mode? That would be something every user that configures a submode class using js-mode have to be aware of. That's not easy to document, or even if we made sure it's documented, to be sure that users read it. >>> There's no problem with before/after-change-functions. They're the >>> canonical way to react to buffer changes. > >> They're not very manageable, from mmm's point of view. And like the >> current example shows, it's not obvious what to do with such hooks >> outside of submode regions of major modes that added them. > > Like I said earlier on in the thread, making several major modes in a > buffer work is problematic in Emacs, and we really want better support > from the C core for it. Here we seem to want "global" and "mode-local" > before-change-functionses. These do seem to be the options: some C core support (though I'm not clear on the particulars of the proposed design), or switching from ad-hoc caches to syntax-propertize-function and and associated syntax-ppss cache. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 19:28 ` Dmitry Gutov @ 2020-06-25 20:11 ` Alan Mackenzie 2020-06-25 21:20 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-25 20:11 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Thu, Jun 25, 2020 at 22:28:17 +0300, Dmitry Gutov wrote: > On 25.06.2020 22:13, Alan Mackenzie wrote: > >> That's unfortunate. > > Indeed. Let's assume that keeping it working is a requirement here. > Still, buffers that user mixed modes are usually not so big as some of > the files we have in src/*.c. So even forgoing caching might result in > a satisfying user experience 98% of the time. Sluggish performance isn't about "usually" and 98% of the time; it's about unusual constellations and the other 2%. [ .... ] > >> If it did, though, it would only call your before-change-functions > >> inside js-mode regions, but it would have ignored them in HTML and CSS > >> regions. Which doesn't appear to be what you want anyway. > > Then why not do in mmm-mode what I'm doing in CC Mode, mhtml-mode and > > js-mode, i.e. add ad hoc code to handle precisely the case of js-mode? > That would be something every user that configures a submode class using > js-mode have to be aware of. That's not easy to document, or even if we > made sure it's documented, to be sure that users read it. Are you telling me that mmm-mode couldn't keep a watch out for js-mode, leaving other libraries untroubled? Again, the trouble here appears to arise from using something (a mode) without first initialising it. > >>> There's no problem with before/after-change-functions. They're the > >>> canonical way to react to buffer changes. > >> They're not very manageable, from mmm's point of view. And like the > >> current example shows, it's not obvious what to do with such hooks > >> outside of submode regions of major modes that added them. > > Like I said earlier on in the thread, making several major modes in a > > buffer work is problematic in Emacs, and we really want better > > support from the C core for it. Here we seem to want "global" and > > "mode-local" before-change-functionses. > These do seem to be the options: some C core support (though I'm not > clear on the particulars of the proposed design), or switching from > ad-hoc caches to syntax-propertize-function and and associated > syntax-ppss cache. The syntax-propertize-function approach is poor design. It restricts the use of the syntax-table text property too much. syntax-ppss has had a troubled history and doesn't do the right thing in narrowed buffers. It advertises itself as a magic wand which does everything, but when you've been enticed into committing your SW to it, you then find out it's less than magic, and you've got to call ugly functions by hand at strange times, and are restricted in how and when you can use it. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 20:11 ` Alan Mackenzie @ 2020-06-25 21:20 ` Dmitry Gutov 2020-06-27 11:06 ` Alan Mackenzie 0 siblings, 1 reply; 30+ messages in thread From: Dmitry Gutov @ 2020-06-25 21:20 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 On 25.06.2020 23:11, Alan Mackenzie wrote: > Sluggish performance isn't about "usually" and 98% of the time; it's > about unusual constellations and the other 2%. Still, a slow-ish fill-paragraph is nowhere near as bad as, say, slowdown during typing. >>> Then why not do in mmm-mode what I'm doing in CC Mode, mhtml-mode and >>> js-mode, i.e. add ad hoc code to handle precisely the case of js-mode? > >> That would be something every user that configures a submode class using >> js-mode have to be aware of. That's not easy to document, or even if we >> made sure it's documented, to be sure that users read it. > > Are you telling me that mmm-mode couldn't keep a watch out for js-mode, > leaving other libraries untroubled? Again, the trouble here appears to > arise from using something (a mode) without first initialising it. Sounds like special-casing js-mode, before-change-functions and this particular function all together. Basically, like a magic constant in the code. This is ultimately doable, but I'm not sure how to write a patch for it which wouldn't leave me feeling dirty after. >> These do seem to be the options: some C core support (though I'm not >> clear on the particulars of the proposed design), or switching from >> ad-hoc caches to syntax-propertize-function and and associated >> syntax-ppss cache. > > The syntax-propertize-function approach is poor design. It restricts the > use of the syntax-table text property too much. syntax-ppss has had a > troubled history and doesn't do the right thing in narrowed buffers. It > advertises itself as a magic wand which does everything, but when you've > been enticed into committing your SW to it, you then find out it's less > than magic, and you've got to call ugly functions by hand at strange > times, and are restricted in how and when you can use it. Despite certain edge cases, I've had a lot of success with it. Both in major modes, and in mmm-mode thanks to it. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 21:20 ` Dmitry Gutov @ 2020-06-27 11:06 ` Alan Mackenzie 2020-06-28 0:18 ` Dmitry Gutov 0 siblings, 1 reply; 30+ messages in thread From: Alan Mackenzie @ 2020-06-27 11:06 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Simen Heggestøyl, acm, 41897 Hello, Dmitry. On Fri, Jun 26, 2020 at 00:20:07 +0300, Dmitry Gutov wrote: > On 25.06.2020 23:11, Alan Mackenzie wrote: > > Sluggish performance isn't about "usually" and 98% of the time; it's > > about unusual constellations and the other 2%. > Still, a slow-ish fill-paragraph is nowhere near as bad as, say, > slowdown during typing. We're talking about a long pause at the end of each line when typing in a longish block comment whilst auto-fill-mode is enabled. > >>> Then why not do in mmm-mode what I'm doing in CC Mode, mhtml-mode and > >>> js-mode, i.e. add ad hoc code to handle precisely the case of js-mode? > >> That would be something every user that configures a submode class using > >> js-mode have to be aware of. That's not easy to document, or even if we > >> made sure it's documented, to be sure that users read it. > > Are you telling me that mmm-mode couldn't keep a watch out for js-mode, > > leaving other libraries untroubled? Again, the trouble here appears to > > arise from using something (a mode) without first initialising it. > Sounds like special-casing js-mode, before-change-functions and this > particular function all together. Basically, like a magic constant in > the code. > This is ultimately doable, but I'm not sure how to write a patch for it > which wouldn't leave me feeling dirty after. If I understand correctly, there is already special case code for js-mode anyway, in mmm-erb.el. The :creation-hook for js-mode is currently set to mmm-erb-mark-as-special, a function shared with ruby-mode. Would it really be all that distressing to write a new :creation-hook for js-mode which additionally initialises the part of CC Mode which needs it? We'd be talking about something like (defun mmm-js-init () "Doc string." (overlay-put mmm-current-overlay 'mmm-special-tag t) (c-foreign-init-lit-pos-cache) (add-hook 'before-change-functions #'c-foreign-truncate-lit-pos-cache nil t)) . Would that really be so bad? It would even be possible to move the explicit add-hook into a small function in CC Mode and call that instead. But I think it's better to see the add-hook where it might make a difference. That's all assuming I've understood mmm-mode properly. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-27 11:06 ` Alan Mackenzie @ 2020-06-28 0:18 ` Dmitry Gutov 0 siblings, 0 replies; 30+ messages in thread From: Dmitry Gutov @ 2020-06-28 0:18 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 On 27.06.2020 14:06, Alan Mackenzie wrote: > Hello, Dmitry. > > On Fri, Jun 26, 2020 at 00:20:07 +0300, Dmitry Gutov wrote: >> On 25.06.2020 23:11, Alan Mackenzie wrote: > >>> Sluggish performance isn't about "usually" and 98% of the time; it's >>> about unusual constellations and the other 2%. > >> Still, a slow-ish fill-paragraph is nowhere near as bad as, say, >> slowdown during typing. > > We're talking about a long pause at the end of each line when typing in > a longish block comment whilst auto-fill-mode is enabled. OK, that's an argument. I'm inclined to believe it should be acceptably small for all such files in practice, but I don't have any solid data to back that up. >>>>> Then why not do in mmm-mode what I'm doing in CC Mode, mhtml-mode and >>>>> js-mode, i.e. add ad hoc code to handle precisely the case of js-mode? > >>>> That would be something every user that configures a submode class using >>>> js-mode have to be aware of. That's not easy to document, or even if we >>>> made sure it's documented, to be sure that users read it. > >>> Are you telling me that mmm-mode couldn't keep a watch out for js-mode, >>> leaving other libraries untroubled? Again, the trouble here appears to >>> arise from using something (a mode) without first initialising it. > >> Sounds like special-casing js-mode, before-change-functions and this >> particular function all together. Basically, like a magic constant in >> the code. > >> This is ultimately doable, but I'm not sure how to write a patch for it >> which wouldn't leave me feeling dirty after. > > If I understand correctly, there is already special case code for js-mode > anyway, in mmm-erb.el. The :creation-hook for js-mode is currently set > to mmm-erb-mark-as-special, a function shared with ruby-mode. Good find, in a way: to satisfy your requirement, :creation-hook is likely the property to use. But the code you pointed to (mmm-erb.el) contains specialized major mode that uses js-mode, among other modes, to implement support for ERB, EJS and JSP templates, together with indentation logic. It is also the only built-in example of a major mode in mmm-mode. Whereas people use js-mode also in other contexts, a lot of the time in configurations that they create themselves (called submode classes, which are then associated with existing major modes, to be used as "primary" mode, and file extensions). As such, any user who creates such a configuration involving js-mode will need to be aware of c-foreign-init-lit-pos-cache and c-foreign-truncate-lit-pos-cache. > Would it really be all that distressing to write a new :creation-hook for > js-mode which additionally initialises the part of CC Mode which needs > it? We'd be talking about something like > > (defun mmm-js-init () > "Doc string." > (overlay-put mmm-current-overlay 'mmm-special-tag t) > (c-foreign-init-lit-pos-cache) > (add-hook 'before-change-functions #'c-foreign-truncate-lit-pos-cache nil t)) It's not by itself distressing as long the one who needs to write it remembers and understands its necessity. In any case, I tried this solution together with the patch you attached (assuming patching the code and evaluating the new contents of cc-engine.el should be enough to make it work), but it didn't help with the same scenario in html-erb-mode. It didn't make anything worse, though. Since mmm-mode is actually out of scope of this bug report, though, perhaps I should stop with this thread of discussion. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-23 19:17 ` Alan Mackenzie 2020-06-23 23:11 ` Dmitry Gutov @ 2020-06-25 20:53 ` Tom Tromey 2020-06-25 21:14 ` Dmitry Gutov 2020-06-26 16:31 ` Alan Mackenzie 1 sibling, 2 replies; 30+ messages in thread From: Tom Tromey @ 2020-06-25 20:53 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897, Dmitry Gutov >>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes: Alan> Having several major modes in a single buffer has always been problematic Alan> in Emacs. Personally, I think there needs to be amendments in the Alan> low-level C code to support it properly, but I'm not able to do this work Alan> on my own, and there doesn't seem to be enough enthusiasm on other Alan> people's part to help out. mhtml-mode was a stab at making this work. It does require some more changes in Emacs (there's another bug open about font-lock that requires some changes to the font-lock code, but there are also a few more I could list), but I didn't come across anything requiring C changes. What changes are you thinking of? Dmitry> TBH I'm not sure if mhtml-mode does the save-and-restore dance which Dmitry> would be necessary for this. mmm-mode does, though. It does. Whatever happened to the idea of pulling mmm into Emacs core? Maybe we could get rid of mhtml-mode. Tom ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 20:53 ` Tom Tromey @ 2020-06-25 21:14 ` Dmitry Gutov 2020-06-26 16:31 ` Alan Mackenzie 1 sibling, 0 replies; 30+ messages in thread From: Dmitry Gutov @ 2020-06-25 21:14 UTC (permalink / raw) To: Tom Tromey, Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 On 25.06.2020 23:53, Tom Tromey wrote: > Dmitry> TBH I'm not sure if mhtml-mode does the save-and-restore dance which > Dmitry> would be necessary for this. mmm-mode does, though. > > It does. When moving between regions? > Whatever happened to the idea of pulling mmm into Emacs core? > Maybe we could get rid of mhtml-mode. It's in ELPA now, which is a good place to be. I'm maintaining it to keep it usable, but depending on your end goals, it might require a more significant rewrite. Help welcome. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 20:53 ` Tom Tromey 2020-06-25 21:14 ` Dmitry Gutov @ 2020-06-26 16:31 ` Alan Mackenzie 1 sibling, 0 replies; 30+ messages in thread From: Alan Mackenzie @ 2020-06-26 16:31 UTC (permalink / raw) To: Tom Tromey; +Cc: Simen Heggestøyl, 41897, Dmitry Gutov Hello, Tom. On Thu, Jun 25, 2020 at 14:53:44 -0600, Tom Tromey wrote: > >>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes: > Alan> Having several major modes in a single buffer has always been problematic > Alan> in Emacs. Personally, I think there needs to be amendments in the > Alan> low-level C code to support it properly, but I'm not able to do this work > Alan> on my own, and there doesn't seem to be enough enthusiasm on other > Alan> people's part to help out. > mhtml-mode was a stab at making this work. It does require some more > changes in Emacs (there's another bug open about font-lock that requires > some changes to the font-lock code, but there are also a few more I > could list), but I didn't come across anything requiring C changes. > What changes are you thinking of? In 2016, I came up with a preliminary, but detailed, design for "islands" which would make several major modes per buffer natively and naturally supported, without awkward workarounds. This included "island-local" variables to supplement buffer-local variables. All this would be implemented at the C level and would obviate the awkward pre/post-command-hook functions currently used by mhtml-mode for swapping in and out the buffer local variables. The post to emacs-devel which started the discussion was: Subject: A vision for multiple major modes: some design notes To: emacs-devel@gnu.org, Dmitry Gutov <dgutov@yandex.ru> Date: Wed, 20 Apr 2016 19:44:50 +0000 Although interest was expressed, in the end there was nobody else jumping up shouting "hey, that's great! Can I help?" (not that I specifically asked for help), so the idea didn't advance beyond that preliminary design. I still think that parts of it could be helpful in mmm-mode (or its successor). > Dmitry> TBH I'm not sure if mhtml-mode does the save-and-restore dance which > Dmitry> would be necessary for this. mmm-mode does, though. > It does. Whatever happened to the idea of pulling mmm into Emacs core? > Maybe we could get rid of mhtml-mode. > Tom -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-22 19:17 ` Alan Mackenzie 2020-06-23 0:02 ` Dmitry Gutov @ 2020-06-25 20:49 ` Tom Tromey 2020-06-26 16:46 ` Alan Mackenzie 2020-07-04 13:13 ` Alan Mackenzie 2 siblings, 1 reply; 30+ messages in thread From: Tom Tromey @ 2020-06-25 20:49 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Simen Heggestøyl, 41897 >>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes: Alan> (ii) An enhancement to CC Mode, used by mhtml-mode and js-mode, which Alan> invalidates a CC Mode cache used by the filling code. This gets rid of Alan> a few strange looking bugs; I wonder if js-mode can be changed not to use cc-mode like this. Looking at js.el, it seems like this is the origin of a use of advice in-core, which is generally frowned upon: ;; FIXME: Such redefinitions are bad style. We should try and use some other ;; way to get the same result. (defun js--fill-c-advice (js-fun) ... Tom ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-25 20:49 ` Tom Tromey @ 2020-06-26 16:46 ` Alan Mackenzie 0 siblings, 0 replies; 30+ messages in thread From: Alan Mackenzie @ 2020-06-26 16:46 UTC (permalink / raw) To: Tom Tromey; +Cc: Simen Heggestøyl, acm, 41897 Hello, Tom. On Thu, Jun 25, 2020 at 14:49:57 -0600, Tom Tromey wrote: > >>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes: > Alan> (ii) An enhancement to CC Mode, used by mhtml-mode and js-mode, which > Alan> invalidates a CC Mode cache used by the filling code. This gets rid of > Alan> a few strange looking bugs; > I wonder if js-mode can be changed not to use cc-mode like this. The main filling function in CC Mode is 390 lines long. It deals with lots of special cases, like comment markers being or not being on lines by themselves, and so on. It's understandable to want to reuse it rather than copying it into a js-... function. > Looking at js.el, it seems like this is the origin of a use of advice > in-core, which is generally frowned upon: > ;; FIXME: Such redefinitions are bad style. We should try and use some other > ;; way to get the same result. > (defun js--fill-c-advice (js-fun) > ... Funnily enough, as CC Mode maintainer, I don't find this artifice particularly objectionable. Advice has its uses, even in the core. > Tom -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode 2020-06-22 19:17 ` Alan Mackenzie 2020-06-23 0:02 ` Dmitry Gutov 2020-06-25 20:49 ` Tom Tromey @ 2020-07-04 13:13 ` Alan Mackenzie 2 siblings, 0 replies; 30+ messages in thread From: Alan Mackenzie @ 2020-07-04 13:13 UTC (permalink / raw) To: Simen Heggestøyl; +Cc: Tom Tromey, 41897-done, Dmitry Gutov Hello, Simen. On Mon, Jun 22, 2020 at 19:17:50 +0000, Alan Mackenzie wrote: > We're gradually converging on working code. Since yesterday, the > improvements are: > (i) (slightly) better handling of auto-fill-mode, which is no longer > automatically enabled; > (ii) An enhancement to CC Mode, used by mhtml-mode and js-mode, which > invalidates a CC Mode cache used by the filling code. This gets rid of > a few strange looking bugs; > (iii) The inclusion of "paragraph-" in the "crucial variables" thing, so > that paragraph-start and paragraph-separate from js-mode get into > mhtml-mode. I've committed more or less the patch from my post of 2020-06-22, which I'm convinced fixes the bug. I'm closing the bug with this post. [ .... ] -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 30+ messages in thread
![[-- Attachment #2: bug41897.png --] [-- Type: image/png, Size: 47390 bytes --]](../../20324.4313410082$1592677823@news.gmane.org/2-bug41897.png){kind=link}
* bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode
@ 2020-06-16 17:08 Simen Heggestøyl
0 siblings, 0 replies; 30+ messages in thread
From: Simen Heggestøyl @ 2020-06-16 17:08 UTC (permalink / raw)
To: 41897
In js-mode, the following JavaScript comment is filled as expected when
fill-paragraph (M-q) is used with point within it:
/*
* This is a long comment that should break over multiple lines when fill-paragraph is used.
*/
Is filled as:
/*
* This is a long comment that should break over multiple lines when
* fill-paragraph is used.
*/
In mhtml-mode however, the same JavaScript comment:
<html>
<script>
/*
* This is a long comment that should break over multiple lines when fill-paragraph is used.
*/
</script>
</html>
Is filled as:
<html>
<script>
/* * This is a long comment that should break over multiple lines
when fill-paragraph is used. */
</script>
</html>
^ permalink raw reply [flat|nested] 30+ messages in threadend of thread, other threads:[~2020-07-04 13:13 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <874krbaqg3.fsf@simenheg@gmail.com>
[not found] ` <mailman.1991.1592327403.2541.bug-gnu-emacs@gnu.org>
2020-06-20 17:18 ` bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode Alan Mackenzie
2020-06-20 18:27 ` Simen Heggestøyl
[not found] ` <87d05ta8z9.fsf@simenheg@gmail.com>
2020-06-21 16:55 ` Alan Mackenzie
2020-06-22 19:17 ` Alan Mackenzie
2020-06-23 0:02 ` Dmitry Gutov
2020-06-23 8:36 ` Alan Mackenzie
2020-06-23 14:23 ` Dmitry Gutov
2020-06-23 16:28 ` Alan Mackenzie
2020-06-23 17:59 ` Dmitry Gutov
2020-06-23 19:17 ` Alan Mackenzie
2020-06-23 23:11 ` Dmitry Gutov
2020-06-24 17:43 ` Alan Mackenzie
2020-06-24 18:28 ` Dmitry Gutov
2020-06-25 16:33 ` Alan Mackenzie
2020-06-25 16:48 ` Dmitry Gutov
2020-06-25 18:07 ` Alan Mackenzie
2020-06-25 18:19 ` Dmitry Gutov
2020-06-25 19:13 ` Alan Mackenzie
2020-06-25 19:28 ` Dmitry Gutov
2020-06-25 20:11 ` Alan Mackenzie
2020-06-25 21:20 ` Dmitry Gutov
2020-06-27 11:06 ` Alan Mackenzie
2020-06-28 0:18 ` Dmitry Gutov
2020-06-25 20:53 ` Tom Tromey
2020-06-25 21:14 ` Dmitry Gutov
2020-06-26 16:31 ` Alan Mackenzie
2020-06-25 20:49 ` Tom Tromey
2020-06-26 16:46 ` Alan Mackenzie
2020-07-04 13:13 ` Alan Mackenzie
2020-06-16 17:08 Simen Heggestøyl
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).