7

On 10k reputation you get inline tag edit possibility. But this edits are rejected on switching to full edit mode. E.g.:

Before inline tag edit there are tags: :

enter image description here

In inline tag edit mode I added and removed , and decided to continue with full edit mode by tapping on "edit" link:

enter image description here

After that all tags were rolled back to post origin state:

enter image description here

I know this's minor, but can we revert made edits only on cancellation, but not on the switching from inline tag edit mode to full edit mode?

Improve this question
16
  • 4
    One common case of this is that the inline tag editor doesn't have the option to add an edit summary. If one wants to change tags and realizes it may not be clear to others why they're doing so, they have to switch to the full editor to do so.
    – Sonic the Anonymous Hedgehog
    Jan 31 at 21:27
  • 2
    IMO, this definitely isn't a bug. It's a feature request (i.e. the interface is currently performed exactly as designed and intended and that operation isn't wrong; a different operation is just desired by this question).
    – Makyen
    Jan 31 at 22:25
  • 1
    It's not clear to me that this is a good idea or that it satisfies the principal of "least surprise". You, the user, have performed the very clear action of starting an inline, full edit, which requires stopping the inline tag edit you're in the process of making. I'm unsure if I'd want what you're asking for to happen when I manipulated the controls in the manner you've described, because it keeping any changed tags would be something I'm not expecting. If I've done what you're describing, without saving the tag edit, then I'm intending to toss away any edits I've made to the tags.
    – Makyen
    Jan 31 at 22:31
  • 4
    ^ agree with @Makyen. If I change my edit mode I expect my current changes to be lost, just like if I abandoned my in-progress edits to navigate to a different URL or edit an answer on the same page... also it strikes me that I wonder really how often this behavior affects you in a negative way, and what the payoff would be for dev / test / release / announce / field (probably not all positive) feedback on the behavior change.
    – Aaron Bertrand Staff
    Jan 31 at 22:41
  • 2
    There seems to be a lot of focus lately on minor nits - pluralization bugs, extreme edge case behaviors, wording that has been unchanged for years. Consider that the more and more minor nits we add to the pile, if you expect them all to be fixed, there's just never going to be enough time to get to even a reasonable percentage of them. Sure, we all want the product to be perfect. But perfect is the enemy of... well, just about everything.
    – Aaron Bertrand Staff
    Jan 31 at 22:45
  • 4
    @Sonic you can save the tag edits and then perform a full edit where you can add a summary, those should be consolidated into a single edit. Or you can type the tag again, if it was an important change it shouldn't be that hard to remember. Again I'm just not sure how often this is a problem, and how disastrous it could possibly be when it is.
    – Aaron Bertrand Staff
    Jan 31 at 22:46
  • 1
    @AaronBertrand One thing I've noticed is that in order to change an edit summary during the grace period, you must make some other edit at the same time. If you only change the edit summary without making other changes, the new edit summary won't be saved. Having to make some other random edit to change the summary and then a third edit to change the random thing back is annoying.
    – Sonic the Anonymous Hedgehog
    Jan 31 at 22:54
  • 2
    @AaronBertrand Speaking of minor edits, the recommendations regarding these has changed quite a bit since the past. In 2014, developers encouraged users to file reports on minor issues since they're super easy for developers to fix. I remember back then that those would often be very quickly resolved by developers.
    – Sonic the Anonymous Hedgehog
    Jan 31 at 23:01
  • 2
    @SonictheAnonymousHedgehog Understood, however the mountain of "bugs" that have been reported in the 8+ years since has outpaced developer hours available to spend on them by several orders of magnitude. Report away, I'm just trying to make sure we have reasonable expectations on how many pluralization bugs are going to be made top priority at this stage in the product's maturity.
    – Aaron Bertrand Staff
    Jan 31 at 23:04
  • 1
    @SonictheAnonymousHedgehog Also, adding a space to the end of any random paragraph in the question so that the important tag edit summary can be saved is a small price to pay and imho doesn't need to be rolled back later.
    – Aaron Bertrand Staff
    Jan 31 at 23:09
  • 2
    @SonictheAnonymousHedgehog This is not a formal and official staff response, to be clear. But you're quoting what one developer said as a comment 8+ years ago. Not only has the number of "minor things that are easy to fix" increased exponentially, but so have the size of the team (which doesn't mean N more developers means N x velocity), the number and duration of tests that have to be completed for every change, the complexity of the deployment process, and the likelihood of a minor change impacting a lot more than it used to. So yes, lots of things have changed, including cowboy fixes.
    – Aaron Bertrand Staff
    Jan 31 at 23:21
  • @AaronBertrand I'm aware of the length of time since that comment. I've noticed quite a few of these minor bugs myself but have held off on reporting these unless they affect my usability of the site. This particular report definitely falls into that category, while other ones (such as the other one today about the duplicate notice) don't.
    – Sonic the Anonymous Hedgehog
    Jan 31 at 23:43
  • @AaronBertrand I suspect pluralisation bugs and 'minor' errors have always been an annoyance. While "Beating people with a giant S" dosen't quite work with SE's current mindset, the 'spirit' of this, that these minor bugs are annoying to fix is still true. If I wanted a "pony" so to speak, I'd argue that having these caught early, with a combination of better QA and having fairly clear 'styleguides' would be nice but there's never ever really enough resources for that, are there ._.
    – Journeyman Geek
    Feb 1 at 0:55
  • 1
    I think that at the least, it'd be nice to show some sort of warning that changes will be lost before the page proceeds to load the full editor – rather than merely loading the full editor and losing the current changes without warning.
    – V2Blast
    Feb 1 at 6:11
  • @V2Blast warning is better than nothing. But I'm not sure that spending resources on warning is better than implementing non-rejectable edit mode switching.
    – αλεχολυτ
    Feb 1 at 8:55

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .