[Edit] Feature Request: Named Custom Tags with auto-complete

[meins111]

Hi there, first of all thanks for your add-ons, they are really pushing up that productivity!

One thing I wish for a while now, is to have a convenient addon managing text snippets for web-fonts, like I use in Development-IDEs (or in VIM under linux). What's that? I have a lot of BBCode snippets I use very frequently, that could profit from macro-ing and snippeting. One can do that with EDIT just now, but I can see two crucial additional features:

1. Have names for your custom tags (to be able to distinguish them easier)
2. Allow the definition of a custom tag that will be auto-searched&replaced with the custom snippet.

E.g. have a BBCode snippet [b]"Say something!"[/b] with the name "Talking" and the auto-complete tag \talk. What I would imagine, is that if I write \talk in my form, it will be auto-replaced with the stored snippet. Also, if I have EDIT sidebar open, I will see a custom snippet called "Talking" that allows the input of the snippet (just as it is now).

See where I am going with this? Think it worthwhile and doable?

Thanks for considering Greetings Meins

[erosman]

Thank you for your kind comment.

I thought about names and personally found them to be complicating the issue further. Besides the need for storing more data, it can become more confusing to have to name and then recall them. For example, the application that I use on my computer to write code, has the code snippet function which I use all the time. It also has a naming option which I have never used since I find it easier to locate the item visually.

AFA auto-enter, maybe. I have to see if/how that is possible.

I must confess that I haven't work on Edit for a good while and once I go to work on it (or any of the others) I often add more features. Another issue was the handling of the drop-down menu in Firefox Sidebar which had quirks at the time I released Edit and personally, I wasn't happy with the way it had to be done at the time.

More than likely, that will change to a list that can be seen visually instead of a drop down. (something like the list on the side-menu screenshot of my latest extension FireMonkey)

I will consider all you have said (and any other suggestions/requests), when I start working on Edit.

[meins111]

Cool. @Names: Yeah, that one is more of a convenience thing to distinghuish similar-looking snippets if there a many in your list. Not too important if they are very different/short or one uses the tag-driven auto-replace (which is basically a name anyway) @List-instead-Dropdown: Hell yes. @Autocomplete: Really, that is the one I'd love to see most in fact. Implementation-wise ... I'd imagine one would have a shortcut (similar to the strg-shift-y to call the sidebar) which will trigger the tag-search'n'replace of text-boxes on the page.

Again, thanks for considering :-)

[erosman]

@autocomplete: Really, that is the one I'd love to see most in fact. Implementation-wise ... I'd imagine one would have a shortcut (similar to the strg-shift-y to call the sidebar) which will trigger the tag-search'n'replace of text-boxes on the page.

I have no idea how (if) it can be done. Once I start writing the code, then I can see what is possible/feasible. :)

[Korb]

1. Have names for your custom tags (to be able to distinguish them easier)

I often have to use a lot of BBCode and HTML tags to mark up my blog posts. Some of them are offered by the Edit add-on, but I had to add a few dozen to the Custom menu. I'm really sorry that I still can't add three submenus, calling them in my case "BBCode", "HTML" and "Snippets". In the third submenu, I would place code snippets like these used for the dynamic table of contents in our CMS:

Start:

<ol class="cp-article__contents-list">
_

End:

_
</ol>

Start:

<li class="cp-article__contents-item cm-scroll" data-ca-scroll=".section_№">
_

`End:

_
</li>

Start:

<section class="№">
_

End:

_
</section>

(Underscores here represent empty lines. It seems that on Github it is not possible to make the first and last lines of a block of code empty.) Of course, I would prefer to see them not as tags, but as named context menu items.

I don't use the sidebar, and if the development of the add-on is hampered by the lack of flexibility in sidebar programming, I would prefer to remove this functionality. Or, as an option, splitting the application into two — with a context menu and with a sidebar (for those who use it).

[erosman]

Thank you. All suggestions and requests will be looked into when working on the next update of the extension.