Re: some proposed tweaks to HTML mode

[Eric Abrahamsen]

Stefan Monnier <address@hidden> writes:

>> I've always found vanilla HTML mode kind of annoying to use, and finally
>> tried to figure out why. (I assume everyone is using some fancier HTML
>> authoring mode, but that's no reason not to fix this one.)
>
> I use nxml-mode, but I'd like to make it use more of sgml/html-mode
> (e.g. for indentation), so this is very welcome in any case.
>
>> @@ -1962,7 +1965,7 @@ html-tag-alist
>>        ("dd" ,(not sgml-xml-mode))
>>        ("del" nil ("cite") ("datetime"))
>>        ("dfn")
>> -      ("div")
>> +      ("div" nil ("class") ("id"))
>>
>> The <div> and <span> elements have literally no use except for a place
>> to hang the "class" and/or "id" attribute, so I don't see why we don't
>> accept those here. In fact, I'd rather just automatically add "class"
>> and "id" as potential attributes on all the tags.
>
> Indeed, `class` and `id` should be automatically added to all elements
> (i.e. not in the above list but directly in the sgml-attributes code).
> But for many elements it makes sense to not query any attributes at all
> since they almost never have any attributes (not even "class" nor "id").

I was also thinking `sgml-attributes', but I'm less sure about excluding
elements. Changing the structure of `html-tag-alist' to carry this
information seems like it would be asking for backward-compatibility
pain -- maybe a new defcustom listing elements that shouldn't get
attributes?

>> @@ -2451,26 +2455,38 @@ html-ordered-list
>>    nil
>>    "<ol>" \n
>>    "<li>" _ (if sgml-xml-mode "</li>") \n
>> -  "</ol>")
>> +  "</ol>" >)
>
> Since the skeleton uses several lines in all cases, I think it makes
> sense to use \n rather than > at the very end, to make sure that any
> text that follows is placed on another line.
> Same for the <ul> element, of course.
> [ I like to put consecutive close tags all on the same line, but I'd
> still prefer the skeleton to use \n here, even if it occasionally forces
> me to then remove the line break.  ]
>
>>  (define-skeleton html-list-item
>>    "HTML list item tag."
>>    nil
>> -  (if (bolp) nil '\n)
>> +  (if (re-search-backward "^[[:blank:]]+") nil '\n)
>>    "<li>" _ (if sgml-xml-mode "</li>"))
>
> I see you already fixed it to use save-excursion, but it's worth
> mentioning that there's `sgml-at-indentation-p` for that.
>
> Also, I wonder what this whole (if (bolp) nil '\n) is about.  I suspect
> that it's a remnant from many years when skeleton's \n was more naive:
> originally, \n in skeletons always inserted a newline, but I changed at
> many years ago such that a \n as first element behaves differently
> (basically it behaves like (if (sgml-at-indentation-p) nil '\n).
> Similarly, a \n at the very end of the skeleton only inserts a newline
> if we're not already followed by a newline.
>
> IOW, I think you can replace (if (sgml-at-indentation-p) nil '\n) with
> just \n

Making sure I follow you, the definition of eg `html-ordered-list' would
then look like:

(define-skeleton html-ordered-list
  "HTML ordered list tags."
  nil
  \n "<ol>" \n
  "<li>" _ (if sgml-xml-mode "</li>") \n
  "</ol>" > \n)

Is that right? This does more or less the right thing, though it does in
some cases still insert a newline. In the text below, with point at the
vertical bar, the above definition still inserts another closing
newline:

<div>
  <div>|
    
  </div>
</div>

I found this bit of the Autotype manual confusing:

‘?\n’
     Insert a newline and align under current line, but not if this is
     the last element of a skeleton and the newline would be inserted at
     end of line, or this is the first element and the newline would be
     inserted at beginning of line.  Use newline character ‘?\n’ to
     prevent alignment.  Use ‘"\n"’ as the first or last string element
     of a skeleton to insert a newline unconditionally.

Here, "align" has nothing to do with "indent", right? This appears to
describe the behavior of ?\n as newline-and-align, but then goes on to
say we should use ?\n to *prevent* alignment.

>> The above changes (in addition to adding skeletons for div and span
>> tags) assume that what we want is a nicely indented HTML buffer. Nested
>> divs should be indented, etc. This is what I want when writing HTML, but
>> it's an assumption that might not be welcomed by everyone.
>
> I for one welcome it.

Great!