# \[RFE\] standard fields should not be deletable via shift+del

**URL:** https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282
**Category:** General Discussion
**Created:** [July 16, 2011, 9:49pm UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282 "2011-07-16T21:49:32Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![chrizoo](https://community.mp3tag.de/user_avatar/community.mp3tag.de/chrizoo/32/233_2.png) [@chrizoo](https://community.mp3tag.de/u/chrizoo)
#### Post date: [July 16, 2011, 9:49pm UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/1 "2011-07-16T21:49:32Z")

</div>

In the extended tag editor (ALT+T):  
_standard field names should **NOT** be deletable from drop-down list via shift+del_

... **or** if they remain deletable, there should at least be a warning pop-up issued prior to such a deletion ~~**PLUS** a way to restore all standard fiels.~~ _(already implemented in 2.49)_

_(PS: "standard fields" refers to all non-userdefined fields,  
i.e. all the fields MP3Tag ships with out-of-the-box)_

---

<div class="post-metadata">

### Author: ![JJ\_Johnson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/jj_johnson/32/67_2.png) [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [July 16, 2011, 9:57pm UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/2 "2011-07-16T21:57:49Z")

</div>

Why?

And who determines what qualifies as a 'standard' field?

---

<div class="post-metadata">

### Author: ![chrizoo](https://community.mp3tag.de/user_avatar/community.mp3tag.de/chrizoo/32/233_2.png) [@chrizoo](https://community.mp3tag.de/u/chrizoo)
#### Post date: [July 16, 2011, 10:43pm UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/3 "2011-07-16T22:43:08Z")

</div>

I added a PS in OP to clarify. "why" should be self-explanatory now.

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [July 17, 2011, 5:58am UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/4 "2011-07-17T05:58:26Z")

</div>

~~Against misuse by the user, there is already the undo function.  
Therefore my vote -1.  
DD.20110717.1000.CEST~~

After reading the OP's post again and the other posts following I have to revise my own post hereby.

OP 'chrizoo' speaks about the combo box "Field" in the sub dialog "Edit tag info" within the dialog "Extended Tags...", where someone can choose a predefined tag-field name or enter a new tag-field name, which will be automatically inserted into the combo box list of tag-field names when the dialog has been closed by the OK button.

The combo box "Field" in the sub dialog "Edit tag info" within the dialog "Extended Tags..." dialog has already an optional tool set accessible by the Right Arrow button, which allows to choose from three options:

- Remove field
- Remove all fields...
- Reset fields...

I think this tool set needs only one more option:

- Reset fields keeping all user defined tag-field names...

"User Defined Tag-Field Name" would be any name, which is not defined in the MP3tag documentation, section 'Names and mapping of ID3v2/WMA/MP4 tag fields'

A warning message would be handsome, when the user is going to remove a "User Defined Tag-Field Name" from the list.

DD.20110717.1625.CEST

---

<div class="post-metadata">

### Author: ![chrizoo](https://community.mp3tag.de/user_avatar/community.mp3tag.de/chrizoo/32/233_2.png) [@chrizoo](https://community.mp3tag.de/u/chrizoo)
#### Post date: [July 17, 2011, 9:45am UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/5 "2011-07-17T09:45:40Z")

</div>

Please read OP. Fields deleted via shift+del cannot be undeleted via undo.

---

<div class="post-metadata">

### Author: ![mjcm](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/9d8465/32.png) [@mjcm](https://community.mp3tag.de/u/mjcm)
#### Post date: [July 17, 2011, 11:24am UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/6 "2011-07-17T11:24:01Z")

</div>

I find the OP very confusing, now I have read all the add. post, it would have been better if the OP would have been something like:

_Standard fields, when deleted with Shift+Del, cannot be undeleted via undo_

---

<div class="post-metadata">

### Author: ![JJ\_Johnson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/jj_johnson/32/67_2.png) [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [July 17, 2011, 5:59pm UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/7 "2011-07-17T17:59:36Z")

</div>

I don't use shift+del, so couldn't care less if there was a popup warning. If implemented, though, I would just do it and not worry about whether or not the fields are someone's definition of 'standard'.

---

<div class="post-metadata">

### Author: ![chrizoo](https://community.mp3tag.de/user_avatar/community.mp3tag.de/chrizoo/32/233_2.png) [@chrizoo](https://community.mp3tag.de/u/chrizoo)
#### Post date: [July 20, 2011, 11:56am UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/8 "2011-07-20T11:56:56Z")

</div>

JJ Johson, it's not about defintions. But being speaking creatures, we have to use words, right? You can call them Paul and Peter if you prefer that. I was just distinguishing between standard fields (shipped with MP3Tag) AND fields created by the user individually, i.e. "my-super-additional-user-field". ok?

My point was that if a user deletes a vital field, such as "title" or "album" (or any other standard field), there is no way to bring it back, as there is no undelete function (I am refering to the FIELD NAMES, not FIELD CONTENT!). Hence my idea of a pop-up warning before a standard field would be deleted.

However I have just figured out -- thanks to Detlev's posting above -- that there already is a way to reset the list (i.e. to resurrect any possibly deleted standard field names).

So seeing this new situation, I am actually satisfied personally. So the RFE might be cancelled.

However I do still think that a pop-up message before deleting any field name would make sense.  
Why?  
Because it is a safety measure against accidental deletions.  
And I don't think deleting field names happens so often that a pop-up message would be annoying.

In case it could be construed as being considered annoying, there would still be the possibility to add a checkbox "don't show warning again".

---

<div class="post-metadata">

### Author: ![chrizoo](https://community.mp3tag.de/user_avatar/community.mp3tag.de/chrizoo/32/233_2.png) [@chrizoo](https://community.mp3tag.de/u/chrizoo)
#### Post date: [July 20, 2011, 12:08pm UTC](https://community.mp3tag.de/t/rfe-standard-fields-should-not-be-deletable-via-shift-del/12282/9 "2011-07-20T12:08:41Z")

</div>

> [@Mike\_nl](#):
>
> I find the OP very confusing, now I have read all the add. post, it would have been better if the OP would have been something like:
> 
> _Standard fields, when deleted with Shift+Del, cannot be undeleted via undo_

You can indeed find everything you have written in my OP.  
uhm ... it's even the thread title ...

Everything except "cannot be undeleted via undo" which is in #5, but it is not needed in my OP because it _is not my point._ (_Even if_ undeleting via undo _were_ possible, I would _still_ have called for a warning message and/or a way to restore all fields.)
