Button lock might cause removal of text property.

[thomasf]

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]

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]

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]

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]

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]

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]

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.