GNU bug report logs -
#79685
30.1; sgml-close-tag changes indentation
Previous Next
To reply to this bug, email your comments to 79685 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Thu, 23 Oct 2025 14:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Anders Munch <ajm <at> flonidan.dk>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 23 Oct 2025 14:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In mhtml-mode, when C-c / (sgml-close-tag) is used to add a closing tag,
and the start tag is on the same line, then the indentation is
changed in the same way that TAB (indent-for-tab-command) would do.
To reproduce, make an mhtml-mode buffer containing the text:
<p>Hello
then press C-c / at the end of the line.
Outcome: </p> is appended, and the leading indentation is removed.
Expected and desired outcome: </p> is appended.
In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.26100
System Description: Microsoft Windows 10 Pro (v10.0.2009.26100.6899)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter CFLAGS=-O2
prefix=/g/rel/install/emacs-30.1'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: DAN
locale-coding-system: cp1252
Major mode: HTML+
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired dired-loaddefs rfc822 mml
mml-sec epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums yank-media mhtml-mode css-mode smie eww xdg url-queue
thingatpt shr pixel-fill kinsoku url-file svg xml browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs icons password-cache url-vars mailcap puny
mm-url gnus nnheader gnus-util text-property-search time-date mail-utils
range wid-edit mm-util mail-prsvr color js c-ts-common treesit json
subr-x map byte-opt gv bytecomp byte-compile imenu cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
sgml-mode facemenu dom cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel touch-screen dos-w32 ls-lisp disp-table term/w32-win
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)
Memory information:
((conses 16 156465 15120) (symbols 48 13247 0) (strings 32 42662 1234)
(string-bytes 1 1323343) (vectors 16 20531)
(vector-slots 8 274699 11866) (floats 8 184 4) (intervals 56 283 0)
(buffers 992 10))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Sat, 25 Oct 2025 10:46:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79685 <at> debbugs.gnu.org (full text, mbox):
> From: Anders Munch <ajm <at> flonidan.dk>
> Date: Thu, 23 Oct 2025 14:05:20 +0000
>
> In mhtml-mode, when C-c / (sgml-close-tag) is used to add a closing tag,
> and the start tag is on the same line, then the indentation is
> changed in the same way that TAB (indent-for-tab-command) would do.
>
> To reproduce, make an mhtml-mode buffer containing the text:
> <p>Hello
> then press C-c / at the end of the line.
> Outcome: </p> is appended, and the leading indentation is removed.
> Expected and desired outcome: </p> is appended.
Thanks, but I'm not sure I understand why this behavior (which was
always there since many years ago) is deemed inappropriate. Many
Emacs commands that insert text behave like that. Can you explain
what is wrong with this reindentation?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Mon, 27 Oct 2025 09:09:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79685 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org>
> Thanks, but I'm not sure I understand why this behavior (which was always there
> since many years ago) is deemed inappropriate. [...] Can you explain what is
> wrong with this reindentation?
At the time when I'm inserting the closing tag, I'm way past formatting the
opening tag, which is therefore already at the indentation level I desire. The
only thing Emacs can possibly do at this point is mess it up.
Which it does. In part because I can't figure out how to set the indentation
level or levels. The sgml-close-tag docstring doesn't mention indentation at
all. Going through TAB (indent-for-tab-command) and indent-line-function, I
eventually find mhtml-indent-line, whose docstring is "Indent the current line
as HTML, JS, or CSS, according to its context.". Where do I go from here?
In other part because when I'm editing an old HTML document that doesn't do
super-consistent indentation, there may not be any global setting that gets it
right.
Or, I may be editing a templated document with intermixed template language
instructions, which messes with anything that automatically infers a desired
indentation.
> Many Emacs commands that insert text behave like that.
Yes, it's not the first time I've had trouble with Emacs commands to insert
things, that change text to the left of the cursor. I'm usually able to
configure my way out of it, but there isn't a way to do that here, short of
copying sgml-close-tag and editing the copy. Which admittedly doesn't look
that hard in this particular case, it's a simple function.
regards,
Anders
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Mon, 27 Oct 2025 14:20:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79685 <at> debbugs.gnu.org (full text, mbox):
> From: Anders Munch <ajm <at> flonidan.dk>
> CC: "79685 <at> debbugs.gnu.org" <79685 <at> debbugs.gnu.org>
> Date: Mon, 27 Oct 2025 09:08:42 +0000
>
> From: Eli Zaretskii <eliz <at> gnu.org>
> > Thanks, but I'm not sure I understand why this behavior (which was always there
> > since many years ago) is deemed inappropriate. [...] Can you explain what is
> > wrong with this reindentation?
>
> At the time when I'm inserting the closing tag, I'm way past formatting the
> opening tag, which is therefore already at the indentation level I desire. The
> only thing Emacs can possibly do at this point is mess it up.
How come your buffer is already indented, but in a way that TAB
reindents it in a different way? Are you using indentation that
differs from what this mode assumes? If so, why?
> Which it does. In part because I can't figure out how to set the indentation
> level or levels. The sgml-close-tag docstring doesn't mention indentation at
> all. Going through TAB (indent-for-tab-command) and indent-line-function, I
> eventually find mhtml-indent-line, whose docstring is "Indent the current line
> as HTML, JS, or CSS, according to its context.". Where do I go from here?
Did you try to customize sgml-basic-offset?
If that doesn't help, can you explain what in the default indentation
of the mode is not to your liking and why?
> In other part because when I'm editing an old HTML document that doesn't do
> super-consistent indentation, there may not be any global setting that gets it
> right.
> Or, I may be editing a templated document with intermixed template language
> instructions, which messes with anything that automatically infers a desired
> indentation.
If worse comes to worst, you can always define your own function,
which is just a copy of sgml-close-tag, just without the part that
calls indent-according-to-mode, and bind that function to "C-c /".
> > Many Emacs commands that insert text behave like that.
>
> Yes, it's not the first time I've had trouble with Emacs commands to insert
> things, that change text to the left of the cursor. I'm usually able to
> configure my way out of it, but there isn't a way to do that here, short of
> copying sgml-close-tag and editing the copy. Which admittedly doesn't look
> that hard in this particular case, it's a simple function.
Right. In general, first try to use the customizations available for
controlling what the auto-indentation does (this varies with major
modes), and if that doesn't help you can always redefine some function
to do what you want.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Tue, 28 Oct 2025 09:32:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 79685 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org>:
> How come your buffer is already indented, but in a way that TAB reindents it in a different way?
Because GNU Emacs mhtml-mode was not used to create it, originally.
Because sections have been copy-pasted from an outside source and I did not do a mass reformatting.
Because there are templating language processing instructions intermixed with the HTML.
Because sometimes I have manually indented by more or less than the default.
In short, life happens. Not all documents are alike.
> Did you try to customize sgml-basic-offset?
Obviously not, since I did not know that it existed. I mean, I knew that
something like that had to exist, but not what it was called, and for once
browsing help and info failed me.
By which path I was meant to have found it?
> If that doesn't help, can you explain what in the default indentation of the mode is not to your liking and why?
> Are you using indentation that differs from what this mode assumes? If so, why?
I don't expect mhtml-mode to perfectly support every idiosyncrasy of every
document I might ever work with. Not need to support it - just allow it.
I still say it's a bug: sgml-close-tag is not documented to make changes around
the opening tag. Electric behaviour can be expected at the site of the cursor,
but not there. And I don't see that it's much useful: If you used the electric
<return> before writing the opening tag, then it's already indented properly,
and if it's not, then fixing the indentation is only a TAB away. Why touch the
opening tag at all, when writing the closing tag?
regards, Anders
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Tue, 28 Oct 2025 13:14:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79685 <at> debbugs.gnu.org (full text, mbox):
> From: Anders Munch <ajm <at> flonidan.dk>
> CC: "79685 <at> debbugs.gnu.org" <79685 <at> debbugs.gnu.org>
> Date: Tue, 28 Oct 2025 09:31:33 +0000
>
> From: Eli Zaretskii <eliz <at> gnu.org>:
> > How come your buffer is already indented, but in a way that TAB reindents it in a different way?
>
> Because GNU Emacs mhtml-mode was not used to create it, originally.
> Because sections have been copy-pasted from an outside source and I did not do a mass reformatting.
> Because there are templating language processing instructions intermixed with the HTML.
> Because sometimes I have manually indented by more or less than the default.
> In short, life happens. Not all documents are alike.
Well, I hope Emacs can be tweaked to support whatever indentation
style that file was using originally.
> > Did you try to customize sgml-basic-offset?
>
> Obviously not, since I did not know that it existed.
Neither did I, before I looked into this.
> I mean, I knew that
> something like that had to exist, but not what it was called, and for once
> browsing help and info failed me.
> By which path I was meant to have found it?
I found it by looking at mhtml-indent-line, which is the function
called to indent a line in mhtml-mode, and which is called when Emacs
reindents the line you edited.
In general, it is always recommended to review the available
customization options of the mode you are trying to tweak to your
liking. Since mhtml-mode is a derivative of html-mode, my
recommendation is to also look at the customizable options of the
parent mode(s).
Did that variable help you solve your problem in this case?
> > If that doesn't help, can you explain what in the default indentation of the mode is not to your liking and why?
> > Are you using indentation that differs from what this mode assumes? If so, why?
>
> I don't expect mhtml-mode to perfectly support every idiosyncrasy of every
> document I might ever work with. Not need to support it - just allow it.
That would mean either (a) refrain from TAB-indenting lines, leaving
that to the user, or (b) somehow dynamically learning the indentation
pattern used by the file and adapting to it. The first would make
Emacs a dumb editor, and is contrary to what Emacs users expect. The
second is just too hard to implement (but patches are welcome, of
course).
> I still say it's a bug: sgml-close-tag is not documented to make changes around
> the opening tag. Electric behaviour can be expected at the site of the cursor,
> but not there. And I don't see that it's much useful: If you used the electric
> <return> before writing the opening tag, then it's already indented properly,
> and if it's not, then fixing the indentation is only a TAB away. Why touch the
> opening tag at all, when writing the closing tag?
Just Emacs tradition, I'd say. We do that in many modes, and the way
to support various indentation schemes is to allow users to customize
indentation to fit what the file already uses, in case the user wants
to preserve the original indentation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Tue, 28 Oct 2025 14:43:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79685 <at> debbugs.gnu.org (full text, mbox):
>> Why touch the opening tag at all, when writing the closing tag?
> Just Emacs tradition, I'd say. We do that in many modes, and the way to support various indentation schemes is to allow users to customize indentation to fit what the file already uses, in case the user wants to preserve the original indentation.
Tradition, eh? sgml-insert-end-tag from pgsml-edit.el did not move the start tag.
I have another theory.
(indent-according-to-mode) was added to sgml-close-tag as a quick'n'dirty way of
adjusting the indentation of a line with only closing tags. Changing the
indentation of the opening tag was an unintentional side-effect.
regards, Anders
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Tue, 28 Oct 2025 15:22:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 79685 <at> debbugs.gnu.org (full text, mbox):
> From: Anders Munch <ajm <at> flonidan.dk>
> CC: "79685 <at> debbugs.gnu.org" <79685 <at> debbugs.gnu.org>
> Date: Tue, 28 Oct 2025 14:42:39 +0000
>
> >> Why touch the opening tag at all, when writing the closing tag?
> > Just Emacs tradition, I'd say. We do that in many modes, and the way to support various indentation schemes is to allow users to customize indentation to fit what the file already uses, in case the user wants to preserve the original indentation.
>
> Tradition, eh? sgml-insert-end-tag from pgsml-edit.el did not move the start tag.
>
> I have another theory.
> (indent-according-to-mode) was added to sgml-close-tag as a quick'n'dirty way of
> adjusting the indentation of a line with only closing tags. Changing the
> indentation of the opening tag was an unintentional side-effect.
Git history indicates that the call to indent-according-to-mode was
there since the very first day sgml-close-tag (which was then called
sgml-insert-end-tag) was added, so I don't think your theory is
correct.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Wed, 29 Oct 2025 08:26:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 79685 <at> debbugs.gnu.org (full text, mbox):
> Git history indicates that the call to indent-according-to-mode was there since the very first day sgml-close-tag (which was then called
> sgml-insert-end-tag) was added, so I don't think your theory is correct.
Not a theory. I tried it out on an old computer.
;; $Id: psgml-edit.el,v 2.73 2005/03/02 19:46:31 lenst Exp $
;; Copyright (C) 1994, 1995, 1996 Lennart Staflin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79685; Package
emacs.
(Wed, 29 Oct 2025 12:41:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79685 <at> debbugs.gnu.org (full text, mbox):
> From: Anders Munch <ajm <at> flonidan.dk>
> CC: "79685 <at> debbugs.gnu.org" <79685 <at> debbugs.gnu.org>
> Date: Wed, 29 Oct 2025 08:25:35 +0000
>
> > Git history indicates that the call to indent-according-to-mode was there since the very first day sgml-close-tag (which was then called
> > sgml-insert-end-tag) was added, so I don't think your theory is correct.
>
> Not a theory. I tried it out on an old computer.
> ;; $Id: psgml-edit.el,v 2.73 2005/03/02 19:46:31 lenst Exp $
> ;; Copyright (C) 1994, 1995, 1996 Lennart Staflin
I don't know what psgml-edit.el is. It isn't part of Emacs and AFAICT
never was.
Here's the Git history that I see: the character '/' was made to
behave "electrically" on Apr 1, 2002, by commit 2394187c2c9. That
commit added the sgml-insert-end-tag function, which is the one that
calls indent-according-to-mode; this call was there since that commit
which added this function and made '/' behave electrically.
This bug report was last modified 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.