Button lock might cause removal of text property.

thomasf commented 9 years ago

Two examples of this problem:

(rear-nonsticky t) is removed from the end of many comint prompts, ielm is an example that is very common.
I cannot edit the first character in a wdired buffer when fixmee-mode is enabled. The space before the first file name character also loses the (rear-nonsticky read-only) property.

It is actually fixmee-mode that I am using, I chose to post the bug report here anyway.

I am not 100% sure that this library is the culprit but it happens the moment i enable fixmee-mode.

thomasf commented 9 years ago

This is possibly also caused by the bug.. That is a kind of wild guess.... http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17541

juan-leon commented 9 years ago

Your guess seems rigjht: I reported that bug originally and I was using fixmee-mode. It seems to trigger the issue in both wdired and dired-efap.

rolandwalker commented 9 years ago

Thanks! I can duplicate the issue in wdired-mode, though I have yet to track down the cause. I had seen it before, and just assumed it was a bug in wdired-mode.

thomasf commented 9 years ago

I haven't been able to reproduce this before looking into what was happening in detail. This is probably because I have fixee-mode loaded with an idle timer in my init.el. I somehow ruled out that fixmee mode was the problem earlier, the behavior.

Until yesterday the code below was in my init.el to work around the issue specifically in wdired. I don't know if it will help you in any way at all. I guess the combination of disabling font lock after remove most other stuff that also modifies text properties in a dired buffer.. However even with all these things disabled it did sometimes not work anyway, this is regardless of having dired-mode, wdired-mode etc. in fixmee-exclude-modes.

;; TODO figure out exactly what is prohibiting wdired mode from allowin
;; the first character to be edited. This is mostly disabling stuff at
;; random.
;; related: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17541
;; Rhe function that is resposible to do this is wdired-preprocess-files.
;; this is a manual way of fixing it for me in that function:
;; I cannot reproduce this reliably. If the problem does not happen
;; with some modes disabled I might continue to investigate
(defvar wdired-forbidden-modes
  '(dired-filter-mode
    dired-omit-mode
    dired-hide-details-mode
    font-lock-mode
    ))

(defvar wdired-disabled-modes nil)

(defadvice wdired-change-to-wdired-mode (before expand-view activate)
  (setq-local wdired-disabled-modes '())
  (--each wdired-forbidden-modes
    (and (boundp it)
         (symbol-value it)
         (add-to-list 'wdired-disabled-modes it )
         (funcall it -1))))

(defadvice wdired-change-to-dired-mode (after collapse-view activate)
  (--each wdired-disabled-modes
    (funcall it 1)))

At the moment I'm just happy that my emacs does not have this problem anymore :)

rolandwalker commented 9 years ago

This should be fixed by #4.

I was surprised to find that variable font-lock-extra-managed-props is not buffer-local. We now make it local in the buffers for which we modify it. Thus, the effects should no longer spill over into wdired buffers.

This was included in release 1.0.2, which was just tagged, and should percolate out to MELPA-stable soon.

thomasf commented 9 years ago

nice catch. will try it out soon, thanks!

Some day I will take the step to learn about the display stuff in more detail, it sure seems strange to me at times.

rolandwalker / button-lock

Button lock might cause removal of text property. #3