# Cut does not work reliably w/o CutPaste Buttons

**URL:** <https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060>\
**Category:** TotalFinder\
**Created:** [December 5, 2013, 3:15am UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060 "2013-12-05T03:15:12Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![danderson](https://discuss.binaryage.com/letter_avatar_proxy/v4/letter/d/f19dbf/32.png) [@danderson](https://discuss.binaryage.com/u/danderson)\
**Post date:** [December 5, 2013, 3:15am UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/1 "2013-12-05T03:15:12Z")

</div>

I have noticed on two different machines running 10.9 that cut via the Cmd+X keystroke does not work reliably (or at all) unless the CutPaste buttons are enabled in the menus. I would like to turn the buttons off because I never use them.

TotalFinder v 1.5.5. Not sure if it makes a difference, but I usually use column view with auto width enabled. I have tabs turned off.

---

<div class="post-metadata">

**Author:** ![1112](https://discuss.binaryage.com/letter_avatar_proxy/v4/letter/1/ba8739/32.png) [@1112](https://discuss.binaryage.com/u/1112)\
**Post date:** [December 9, 2013, 4:17pm UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/2 "2013-12-09T16:17:20Z")

</div>

This problem is at least 10 months old.  
In the past I wrote several complains about cmd-X not working (username Singularity2033).

Unfortunately, TotalFinder authors are busy implementing useless new features, but cannot find several hours to fix the most important core functionality of their product.

HEY GUYS !!! HELOOOOO !!  
PLEASE FIX THE GODDAMN CMD-X ALREADY !!!  
PLEASE !!! PLEASE !!!

---

<div class="post-metadata">

**Author:** ![willynanita](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/willynanita/32/47_2.png) [@willynanita](https://discuss.binaryage.com/u/willynanita)\
**Post date:** [December 18, 2013, 3:42am UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/3 "2013-12-18T03:42:34Z")

</div>

Can someone please confirm if those buttons are really needed…

I don’t have them on (and Cmd+x doesn’t work here neither), but I always have a Cut and Paste there without those buttons being enabled, if they weren’t there before, they are now. I don’t know at what point they were included in 10.9, but the buttons are not useful anymore, so the Cmd+x fix is really needed.

---

<div class="post-metadata">

**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\
**Post date:** [March 18, 2014, 12:02pm UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/4 "2014-03-18T12:02:54Z")

</div>

I have revisited the code again and I have found a possible code-path which would cause cut-operation to stop working suddenly. This will be fixed in 1.5.25 (I will release it this week on beta channel).

Hope this will fix this nasty issue once for all.

---

<div class="post-metadata">

**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\
**Post date:** [March 19, 2014, 3:53am UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/5 "2014-03-19T03:53:02Z")

</div>

Ok, since 1.5.25 I have added special logging in release mode for cut-related code.

When you again experience broken cut operation, please go to Terminal.app and execute this command:

```
touch ~/.debug-totalfinder-cut

```

Do not restart TotalFinder. TotalFinder should immediately start reporting verbose logging info into Console.app.

Then please try to:

1. open Main Menu -\> Edit, see if Cut menu item is not grayed out
2. hit CMD+X on some file
3. execute CMD+X on some file via menu item in Edit menu

You should see bunch of lines prefixed [debug cut] in Console.app. I’m interested in those outputs, please paste them here or send them to [support@binaryage.com](mailto:support@binaryage.com).

Thanks a bunch!

---

<div class="post-metadata">

**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\
**Post date:** [March 19, 2014, 6:15am UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/6 "2014-03-19T06:15:26Z")

</div>

v1.2.25 is out:  
[http://totalfinder.binaryage.com/beta-changes](http://totalfinder.binaryage.com/beta-changes)

---

<div class="post-metadata">

**Author:** ![danderson](https://discuss.binaryage.com/letter_avatar_proxy/v4/letter/d/f19dbf/32.png) [@danderson](https://discuss.binaryage.com/u/danderson)\
**Post date:** [March 23, 2014, 2:50pm UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/7 "2014-03-23T14:50:47Z")

</div>

Just experienced this issue again. Followed the debug steps above. Here are the results…

1. open Main Menu -\> Edit, see if Cut menu item is not grayed out  
It is greyed out.

2. hit CMD+X on some file  
Does nothing.

3. execute CMD+X on some file via menu item in Edit menu  
It is disabled. Does nothing.

Here’s the console output from CMD-X:

```
3/23/14 10:36:01.105 AM Finder[70449]: [debug cut] validateCut: sender=<NSMenuItem: 0x6080000a4fe0 Cut> 
3/23/14 10:36:01.106 AM Finder[70449]: [debug cut] set item title to 'Cut' 
3/23/14 10:36:01.106 AM Finder[70449]: [debug cut] context is AHCMContainerContext => bail out 
3/23/14 10:36:03.774 AM Finder[70449]: [debug cut] validateCut: sender=<NSMenuItem: 0x6080000a4fe0 Cut> 
3/23/14 10:36:03.774 AM Finder[70449]: [debug cut] set item title to 'Cut' 
3/23/14 10:36:03.775 AM Finder[70449]: [debug cut] context is AHCMContainerContext => bail out 
3/23/14 10:36:03.775 AM Finder[70449]: [debug cut] validateCut: sender=<NSMenuItem: 0x6180000a95a0 Cut> 
3/23/14 10:36:03.775 AM Finder[70449]: [debug cut] set item title to 'Cut' 
3/23/14 10:36:03.775 AM Finder[70449]: [debug cut] context is AHCMContainerContext => bail out

```

Here’s the console output from the disabled menu item:

```
3/23/14 10:39:09.966 AM Finder[70449]: [debug cut] validateCut: sender=<NSMenuItem: 0x6080000a4fe0 Cut>
3/23/14 10:39:09.967 AM Finder[70449]: [debug cut] set item title to 'Cut'
3/23/14 10:39:09.967 AM Finder[70449]: [debug cut] context is AHCMContainerContext => bail out
3/23/14 10:39:09.967 AM Finder[70449]: [debug cut] validateCut: sender=<NSMenuItem: 0x6180000a95a0 Cut>
3/23/14 10:39:09.968 AM Finder[70449]: [debug cut] set item title to 'Cut'
3/23/14 10:39:09.968 AM Finder[70449]: [debug cut] context is AHCMContainerContext => bail out

```

Re-enabling the “Show CutPaste buttons in Context Menus” immediately fixes the issue.

---

<div class="post-metadata">

**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\
**Post date:** [March 24, 2014, 2:58am UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/8 "2014-03-24T02:58:33Z")

</div>

Thank you very much.

`AHCMContainerContext` test should prevent cut operation when you right-click into container background. But it is probably more broad and affects normal operation. I have removed that restriction. Cut should be more flexible since 1.5.27 (to be released).

---

<div class="post-metadata">

**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\
**Post date:** [March 24, 2014, 4:20am UTC](https://discuss.binaryage.com/t/cut-does-not-work-reliably-w-o-cutpaste-buttons/1060/9 "2014-03-24T04:20:55Z")

</div>

Now I can explain why could CutAndPaste feature got broken. This is a bug which caused hundreds of emails and endless hours of frustration.

Up until version 1.5.27 the behaviour was following:  
Right-click context menu sets TotalFinder’s “context of operation” for subsequent cut attempt (context may be sidebar, file item, toolbar, etc.). This context is tested during cut operation and validation of menu items. I had a special condition there which disabled cut for “container” contexts which seemed like a reasonable behaviour. The problem was that this context stayed set until next opening of right-click context menu elsewhere. In other words context of last context menu determined future cut menu item availability (including keyboard shortcuts).

The problem why it was so hard for me to reproduce was that I never tried to click specifically into empty background window. I always tested it right-clicking some files. And didn’t see any clues up until now from @danderson.

I’m so glad. @danderson you deserve a bounty. Please drop me an email to [antonin@binaryage.com](mailto:antonin@binaryage.com) with your bitcoin address, I will send some funny-internet-money your way 👍
