On 2011-05-29 07:05 +0800, Chong Yidong wrote: [snipped 11 lines]
> Looks good. I've made a couple of tweaks, and have committed it to > trunk. The C-c c-c binding was removed in favor of just C-x C-q, as > Stefan suggested. For now, I also left out the part where C-x C-q in > Occur Edit mode saves the associated buffers, because this doesn't seem > to be properly thought out; what if the buffers have no associated > files?
> Also, I added a small fix to occur-after-change-function to avoid > screwing up the Occur Edit buffer when multi-line text is inserted. > Since we can't create new Occur entries, this just ignores everything > after the inserted newline. If you want to try and handle this properly > (i.e. by inserting a new Occur entry for each inserted line), go ahead.
Yidong, many thanks for the tweaks and fixes.
Let's keep this bug open for a bit longer. I am thinking of generalising occur-edit-mode (probably rename it to match-line-edit) so that it covers buffers from grep and the like.
On Sun, Apr 10, 2011 at 11:14, Leo <sdl....@gmail.com> wrote: > I have extended the occur feature in Emacs to allow direct editing in > the *Occur* buffer by propagating the changes to the original buffers.
> With the attached preliminary patch, one can press `C-x C-q' or `C-c > C-c' to enter occur-edit-mode and start editing. Pressing `C-x C-q' or > `C-c C-c' again finishes the edit.
> Comments are highly welcomed. Thanks in advance.
Is there a way to _disable_ this feature? I'm quite often edit the *Occur* and *grep* buffers for line-up results, etc, just for easier understanding results, but I don't want these edits to be mirrored into original lines or files from where they are come.
"Andrew W. Nosenko" wrote: > Is there a way to _disable_ this feature? I'm quite often edit the > *Occur* and *grep* buffers for line-up results, etc, just for easier > understanding results, but I don't want these edits to be mirrored > into original lines or files from where they are come.
Me too.
I expect C-x C-q to toggle the read-only state of a buffer, not switch me into some unusual mode. I suggest binding this new mode to some other key.
Other issues with this:
1. After C-x C-q, I can no longer kill entire lines in the occur buffer. Trying to do so reports "Text is read-only".
2. After C-x C-q, If I delete some text in the occur buffer, then use "undo", when I reach the point at which there is no more to undo, I get: "Wrong type argument: markerp, nil" rather than "No further undo information".
> Thank you for this feedback. I will try to address these issues when I > am back from a trip on Tuesday.
I think it makes sense to bind the occur-edit feature to some other key than C-x C-q. While C-x C-q is a cute binding for it, it does hide a command that is also useful.
Stefan Monnier <monn...@iro.umontreal.ca> writes: >> Thank you for this feedback. I will try to address these issues when I >> am back from a trip on Tuesday.
> I think it makes sense to bind the occur-edit feature to some other > key than C-x C-q. While C-x C-q is a cute binding for it, it does > hide a command that is also useful.
Unfortunately, C-x C-q is consistent with the command for switching to wdired mode.
Chong Yidong <c...@stupidchicken.com> writes: > Stefan Monnier <monn...@iro.umontreal.ca> writes:
>>> Thank you for this feedback. I will try to address these issues when I >>> am back from a trip on Tuesday.
>> I think it makes sense to bind the occur-edit feature to some other >> key than C-x C-q. While C-x C-q is a cute binding for it, it does >> hide a command that is also useful.
> Unfortunately, C-x C-q is consistent with the command for switching to > wdired mode.
I don't think this argument is really valid. First of all, C-x C-q is consistent with the command to switch read-only-ness of a buffer, and that's apparently what at least some people still expect and are used to in this case. It might have made sense to override it for Wdired, but not necessarily here.
>>> Thank you for this feedback. I will try to address these issues when I >>> am back from a trip on Tuesday. >> I think it makes sense to bind the occur-edit feature to some other >> key than C-x C-q. While C-x C-q is a cute binding for it, it does >> hide a command that is also useful. > Unfortunately, C-x C-q is consistent with the command for switching to > wdired mode.
Right, but wdired and occur-edit are two different things. Editing a dired buffer in wdired does not have any other side effect (at least not until you "commit" those changes), so its behavior is still pretty close to toggle-read-only. Occur-edit is somewhat reminiscent of wdired, but does not match the behavior of toggle-read-only quite as closely.
> 2. After C-x C-q, If I delete some text in the occur buffer, then use > "undo", when I reach the point at which there is no more to undo, I get: > "Wrong type argument: markerp, nil" rather than "No further undo information".
I think maybe we should assign C-c C-c to occur-edit-mode instead.
1. After C-x C-q, I can no longer kill entire lines in the occur buffer. Trying to do so reports "Text is read-only".
The text properties are now added when entering occur-edit-mode.
2. After C-x C-q, If I delete some text in the occur buffer, then use "undo", when I reach the point at which there is no more to undo, I get: "Wrong type argument: markerp, nil" rather than "No further undo information".
> > Speaking for myself, I have no idea what that means.
> That's what I saw on the annotation buffer (from C-x v g). I was able to > view the diff there with 'd'.
Git sha values are generally not useful for someone who uses bzr. It would be nice if people who report problems could also mention the bzr revision or revid.
>> That's what I saw on the annotation buffer (from C-x v g). I was able to >> view the diff there with 'd'.
> Git sha values are generally not useful for someone who uses bzr. It > would be nice if people who report problems could also mention the bzr > revision or revid.
>> I think maybe we should assign C-c C-c to occur-edit-mode instead.
I don't like that: C-c C-c means "done" usually so it'd be OK to leave edit mode, but not to enter it.
> Or "e" (for edit; like in Rmail).
That sounds good.
>> 1. After C-x C-q, I can no longer kill entire lines in the occur buffer. >> Trying to do so reports "Text is read-only". >> The text properties are now added when entering occur-edit-mode. > I don't understand if that means it's fixed. Deleting whole or even > multiple lines is an operation I might want to do in occur-edit-mode.
But its meaning is unclear and we get to choose what is allowed and what is not in edit mode since it's a new mode that the user requested explicitly.
On Fri, 10 Jun 2011 10:59:16 -0300 Stefan Monnier <monn...@iro.umontreal.ca> wrote:
>>> 1. After C-x C-q, I can no longer kill entire lines in the occur buffer. >>> Trying to do so reports "Text is read-only". >>> The text properties are now added when entering occur-edit-mode. >> I don't understand if that means it's fixed. Deleting whole or even >> multiple lines is an operation I might want to do in occur-edit-mode.
SM> But its meaning is unclear and we get to choose what is allowed and what SM> is not in edit mode since it's a new mode that the user SM> requested explicitly.
I'd suggest binding `d' to "delete entire line" outside the edit mode, so the edit mode does not need to provide it and still it's available in a convenient way.
On Fri, Jun 10, 2011 at 16:59, Stefan Monnier <monn...@iro.umontreal.ca> wrote: >>> I think maybe we should assign C-c C-c to occur-edit-mode instead.
> I don't like that: C-c C-c means "done" usually so it'd be OK to leave > edit mode, but not to enter it.
>> Or "e" (for edit; like in Rmail).
> That sounds good.
But not for case, when user already switched the *Occur* buffer into read/write mode for editing the buffer itself (not the underlying files/buffers, where occurrences come from).
The same applied for Ted's proposal for 'd' key and any other keys that used for regular text typing.
> But not for case, when user already switched the *Occur* buffer into > read/write mode for editing the buffer itself (not the underlying > files/buffers, where occurrences come from).
Then maybe `M-e' (like in isearch mode)?
> The same applied for Ted's proposal for 'd' key and any other keys > that used for regular text typing.
On Sat, Jun 11, 2011 at 21:00, Juri Linkov <j...@jurta.org> wrote: >>>> Or "e" (for edit; like in Rmail).
>>> That sounds good.
>> But not for case, when user already switched the *Occur* buffer into >> read/write mode for editing the buffer itself (not the underlying >> files/buffers, where occurrences come from).
> Then maybe `M-e' (like in isearch mode)?
If separate apply-changes-to-underlying-buffers action to the own function (may be even it already implemented in that way) then all controversy will gone. -- Enter to read-write mode -- the same, editing commands -- the same, all other behavior -- the same. Just because there will work one and the same code in the one and the same mode. Difference is only one between my usage model and usage model of Leo (original author) -- after finishing I simple kill the occur buffer, while Leo call the "apply-cachanges-to-underlying-buffers" for "commit" the final results.
IMHO anyone can benefit from solving the problem in that way.
"Andrew W. Nosenko" <andrew.w.nose...@gmail.com> writes:
>>> Or "e" (for edit; like in Rmail).
>> That sounds good.
> But not for case, when user already switched the *Occur* buffer into > read/write mode for editing the buffer itself (not the underlying > files/buffers, where occurrences come from).
That's already the case with "r" (occur-rename-buffer), "c" (clone-buffer), and "o" (occur-mode-goto-occurrence-other-window).
On Sat, Jun 18, 2011 at 22:35, Chong Yidong <c...@stupidchicken.com> wrote: > "Andrew W. Nosenko" <andrew.w.nose...@gmail.com> writes:
>>>> Or "e" (for edit; like in Rmail).
>>> That sounds good.
>> But not for case, when user already switched the *Occur* buffer into >> read/write mode for editing the buffer itself (not the underlying >> files/buffers, where occurrences come from).
> That's already the case with "r" (occur-rename-buffer), "c" > (clone-buffer), and "o" (occur-mode-goto-occurrence-other-window).
Yes, but: (1) these actions aren't destructive in respect to the original data, and (2) I would to prefer to see the number of such bindings decreasing, not increasing.
Also it has one little drawback: it adds too many undo boundaries,
so to undo changes in the source buffer, it requires too many `C-_'.
There is no such problem in all.el (from ELPA) because
`all-after-change-function' doesn't call `recenter' and `move-to-column'.
But there is a greater drawback: stealing the `C-x C-q' keybinding from
`toggle-read-only' and putting read-only properties on the *Occur* buffer
is unacceptable. I'm used to run `flush-lines' and `keep-lines' to narrow
the search results, but can't do this anymore. This is a regression.
