As slim-mode uses GPLv3+, plug-mode, as a derived work of slim-mode, is required to use the same license.

pug-comment-block puts the pug markup block currently under the pointer into a comment block. Weird things happen when you try to run this command with lines selected in evil-visual-mode and evil-visual-line-mode.

It seems Pug Mode calculates the pointer position as being at the end of the selection. So, when I select through the end of the line, to the invisible end-of-line character, the commenting command calculates the pointer position as being at the beginning of the next line. The block comment therefore is put in the first column, and the rest of the entire document is commented.

I have not yet tested in a clean, non-evil Emacs environment.

Seems to me that Pug Mode should do one of these two things:

1. Add support for running the block comment command on a selection, as this is a fairly intuitive thing users might expect to be able to do. Probably all partial and complete blocks within the selection get moved to a block comment?
2. Document the fact that you don't need to make a selection, and in fact probably shouldn't.

Here, I would expect div.test to be highlighted even if hello follows it. Also, inline nested tags aren't highlighted — I would expect the span in span hi to be highlighted even if it's inside a div.

I would submit a pull request, but I'm afraid I'm not sure how to fix these.

Thank you for pug-mode!

Example code, this works properly:

div#myExampleDiv
    p An example paragraph

When I write the div, then hit enter, and then hit tab, pug-mode correctly indents the p tag.

This does not work:

#myExampleDiv
    p An example paragraph

When the tag name is not provided, Pug assumes a div is desired. Pug-mode does not, however, detect that this is a valid div and does not properly indent the p tag inside the div.

This is not a big deal on new projects, as I think it's cleaner to specify the div tag explicitly, however when working in codebases where the tag-less style is used, it makes indenting a pain.

I'm having a little issue with the indentation in the next cases, where I'm unable to put the selected line inside the previous one by pressing TAB:

As the other issues, I will check this out by myself, but it know where the error could be please let me know!

I tend to use hard wraps. but when I hit ALT-Q on a long bullet entry, it turns it into two bullet entries (instead of wrapping the entry, like org-mode or markdown-mode).

example:

- realy, really, really really really really .... long line

becomes

- realy, really, really really 
- really ... long line

So what do you suggest for working with long lines?

I'll check this out too.

pug-mode seems to indenting by 4 spaces, or tabs. in a file that has existing indentation of 2 spaces

Pug supports multi-line attributes. For example:

h1(
        color="red"
        style="background: orange"
        class="my-class"
)
        | This is my heading

That code is completely valid now in Pug.

With pug-mode, I notice that the mode doesn't easily allow me to write this code out.

I'm relatively new to Pug, but as far as I can determine, it's essentially HTML with the addition of some template tags. As such, I wonder whether it might not make more sense for the functionality of this major mode to instead be implemented as a minor mode, which could be added to html-mode's hook in order to provide Pug-specific capabilities while still leveraging the full power of html-mode, as well as whatever other minor modes a user chooses to add to that hook. (For example, I'm strongly accustomed to html-mode's automatic tag closing, indenting, et cetera, all of which is configured to taste - and also to emmet-mode's amazing HTML generation capabilities, without which I find myself quite at sea!)

I haven't yet had time to examine pug-mode's code, so I don't know whether this is feasible at all, and I totally get that throwing a "hey, why not rework everything?" ask over the transom like this is kind of questionable. As time permits, I intend to take a look in more detail, and the outcome I have in mind is a PR. In the meantime, I'd like to solicit opinion on this change, hence the issue.

Hi Henrik, I have been using this mode but I keep getting some problems with indentation, I don't know if is this mode or just my emacs setup though.

For example, here I'm deleting a line I don't want:

However, if I use C-k I can delete the line without modifying the indentation of the rest of the file.

Thanks.

Currently, the default is to create "buffered" // comments when running either the pug-comment-block or evilnc-comment-operator commands. It would be nice if there were also a way to create "unbuffered" //- comments.

Or, personally, my comments are almost always specific to the Pug templating logic (or TODO type of placeholder comments), and almost never really pertinent to the output HTML. So for me, I think it would also be okay, maybe even better, if pug-mode defaulted to unbuffered //- comments instead. I guess I have no idea what the worldwide usage rates of the different types of comments are, though.

If you only supported one type, it might also make sense to do unbuffered comments because the included hyphen means the command shortcuts would save users an extra keystroke versus buffered comments.

System Info 💻

• OS: gnu/linux
• Emacs: 25.3.1
• Spacemacs: 0.200.9
• Spacemacs branch: master (rev. 8e1af145)
• pug-mode-20170914.208
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers: (emacs-lisp html helm javascript markdown shell-scripts vimscript)
• System configuration features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS

When editing a template that includes each iterating through elements in an array, I get the following message when the cursor is over the "each x in [array]" line:

cannot read property 'length' of undefined

Take the following snippet:

extends layout

block content
  div.container
    each person in people // ---> red dot on left margin, whole line underlined in red, as in error
      div.person
        div.person-image(style=`background: url('/images/${person.imgSrc}') top center
        no-repeat; background-size: cover;`)
        h2.person-name
          | #{person.firstname} #{person.lastname}
        a(href=`/profile?id=${person.id}`)
          | View Profile

On the each person in people line, I'm going through each person element in a people array (imported from a json) to generate a profile view for each user.

The code runs OK in the Express project I'm using pug in, only that pug-mode seems to assume an error where there is none.

Let me know how I can help getting rid of the annoyance.

I wrote an issue here. I assume it's relevant for pug-mode too.

Neither buffered (//) nor unbuffered (//-) comments are highlighted. I have a face for comments set via Emacs Customizer, which makes it so comments in files normally appear as bold white, but in pug files, comments seem to render as plain text.

(custom-set-faces
  '(font-lock-comment-face ((t (:background "Transparent" :foreground "White" :weight bold))))
  ;; and other faces...
)

If the comment includes a colon, the word after it is highlighted as if it were a tag.

System Info 💻

• OS: Fedora 26 Workstation x86_64 (gnu/linux)
• Emacs: 25.2.1, both in an X window or in GNOME Terminal 3.24
• Spacemacs: 0.200.9
• Spacemacs branch: master (rev. 8e1af145)
• Distribution: spacemacs
• pug-mode 20170127.1949 (installed from MELPA)
• Editing style: vim
• Completion: helm
• System configuration features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS

I might take a look at it though. I wanted to submit the issue just in case.

Currently pug-mode not support double quotes as HTML tag attribute, it's very inconvenient.

I try to uncomment L150 ~ L151, but I don't know what's going on with the uppercased "P" in this screenshot

I think I can fix this, I'm adding the issue so I don't forget it.

Error on emacs 25.3.1
Error during redisplay: (jit-lock-function 1) signaled (no-catch --cl-block-pug-extend-region-- nil)

All the text next to the interpolation gets highlighted when used with attributes.