sr-editable-pane doesn't show the modified file name when editing file name. #11

Closed
sunwayforever opened this Issue Oct 23, 2012 · 6 comments

Comments

Projects
None yet
2 participants
@sunwayforever
  1. place cursor on the first letter of a file name. e.g. for hello.txt, place the cursor on h
  2. C-x C-q to swith to sr-editable-pane
  3. press any letter, but the modified file name is not shown until C-c C-c to finish edit.
@escherdragon

This comment has been minimized.

Show comment Hide comment
@escherdragon

escherdragon Oct 23, 2012

Owner

On Tue, Oct 23, 2012 at 2:53 PM, sunway notifications@github.com wrote:

place cursor on the first letter of a file name. e.g. for hello.txt, place the cursor on h
C-x C-q to swith to sr-editable-pane
press any letter, but the modified file name is not shown until C-c C-c to finish edit.
(...)

Hello Sunway,

Can you please clarify? Where is the modified file name not being shown?

Cheers,

José A. Romero L.
escherdragon@gmail.com
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)

Owner

escherdragon commented Oct 23, 2012

On Tue, Oct 23, 2012 at 2:53 PM, sunway notifications@github.com wrote:

place cursor on the first letter of a file name. e.g. for hello.txt, place the cursor on h
C-x C-q to swith to sr-editable-pane
press any letter, but the modified file name is not shown until C-c C-c to finish edit.
(...)

Hello Sunway,

Can you please clarify? Where is the modified file name not being shown?

Cheers,

José A. Romero L.
escherdragon@gmail.com
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)

@sunwayforever

This comment has been minimized.

Show comment Hide comment
@sunwayforever

sunwayforever Oct 24, 2012

suppose the original file name is "hello.txt", place the cursor on h, and press C-x C-q, then input new, now the file name displayed on screen should be newhello.txt , right? but actually the file name displayed remains hello.txt unchanged, until after C-c C-c to commit the modification.

suppose the original file name is "hello.txt", place the cursor on h, and press C-x C-q, then input new, now the file name displayed on screen should be newhello.txt , right? but actually the file name displayed remains hello.txt unchanged, until after C-c C-c to commit the modification.

@escherdragon

This comment has been minimized.

Show comment Hide comment
@escherdragon

escherdragon Oct 24, 2012

Owner

On Wed, Oct 24, 2012 at 4:57 AM, sunway notifications@github.com wrote:

suppose the original file name is "hello.txt", place the cursor on h, and
press C-x C-q, then input new, now the file name displayed on screen should be
newhello.txt , right? but actually the file name displayed remains hello.txt
unchanged, until after C-c C-c to commit the modification.
(...)

We are dealing here not with one, but with two names: (1) the actual name of the
file in the filesystem and (2) the name of the buffer in Emacs. It would be
unwise to change the former on the fly: instead of one simple deterministic
operation, we'd have many operations that could potentially leave your
filesystem in an unknown (if not inconsistent) state if you abort (C-c C-k), or
if you kill the pane before committing, or if Emacs crashes. Believe me, you
don't want that to happen.

I could change the name of the buffer on the fly, but then: there may be more
than one buffer visiting the same file - should I rename them all? If you abort
the operation, I think I should rename them back to their original names, so I
guess I should remember them locally. Additionally, the usual behavior of file
buffers in Emacs is that the name of the buffer follows the name of the file,
now this would make some buffers work the other way around, making the name of
the buffer precede the name of the file -- I can imagine all the complains I
would receive if SC started juggling with buffer names... Naaaah, this is
definitely not worth the effort.

Maybe what is not completely right here is your interpretation of wdired (aka
"editable pane") buffers: what happens inside them does not effect the real
world as long as you don't press C-c C-c, so you may try all kind of crazy stuff
inside them without fearing that something will go wrong - if you happen to make
a mistake you can simply press C-c C-k and all your sins will be forgiven ;-)

Cheers,

José A. Romero L.
escherdragon@gmail.com
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)

Owner

escherdragon commented Oct 24, 2012

On Wed, Oct 24, 2012 at 4:57 AM, sunway notifications@github.com wrote:

suppose the original file name is "hello.txt", place the cursor on h, and
press C-x C-q, then input new, now the file name displayed on screen should be
newhello.txt , right? but actually the file name displayed remains hello.txt
unchanged, until after C-c C-c to commit the modification.
(...)

We are dealing here not with one, but with two names: (1) the actual name of the
file in the filesystem and (2) the name of the buffer in Emacs. It would be
unwise to change the former on the fly: instead of one simple deterministic
operation, we'd have many operations that could potentially leave your
filesystem in an unknown (if not inconsistent) state if you abort (C-c C-k), or
if you kill the pane before committing, or if Emacs crashes. Believe me, you
don't want that to happen.

I could change the name of the buffer on the fly, but then: there may be more
than one buffer visiting the same file - should I rename them all? If you abort
the operation, I think I should rename them back to their original names, so I
guess I should remember them locally. Additionally, the usual behavior of file
buffers in Emacs is that the name of the buffer follows the name of the file,
now this would make some buffers work the other way around, making the name of
the buffer precede the name of the file -- I can imagine all the complains I
would receive if SC started juggling with buffer names... Naaaah, this is
definitely not worth the effort.

Maybe what is not completely right here is your interpretation of wdired (aka
"editable pane") buffers: what happens inside them does not effect the real
world as long as you don't press C-c C-c, so you may try all kind of crazy stuff
inside them without fearing that something will go wrong - if you happen to make
a mistake you can simply press C-c C-k and all your sins will be forgiven ;-)

Cheers,

José A. Romero L.
escherdragon@gmail.com
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)

@sunwayforever

This comment has been minimized.

Show comment Hide comment
@sunwayforever

sunwayforever Oct 24, 2012

... seems that the issue is still not clear.

Fogot to mention that the issue only happens when sr-show-file-attribute is nil

suppose the sunrise buffer looks like this (with sr-show-file-attribute tured off):
/home/sunway/.elisp/sunrise-commander: total used in directory 380 available 155377244 README.md sunrise-commander.el sunrise-x-buttons.el sunrise-x-checkpoints.el sunrise-x-loop.el sunrise-x-mirror.el sunrise-x-modeline.el sunrise-x-old-checkpoints.el sunrise-x-popviewer.el sunrise-x-tabs.el sunrise-x-tree.el sunrise-x-w32-addons.el

then I place the cursor on R of README.md, and C-x C-q and input "new", then the buffer remains UNCHANGED.

But after C-c C-c, the buffer is changed to
/home/sunway/.elisp/sunrise-commander: total used in directory 380 available 155377244 newREADME.md sunrise-commander.el sunrise-x-buttons.el sunrise-x-checkpoints.el sunrise-x-loop.el sunrise-x-mirror.el sunrise-x-modeline.el sunrise-x-old-checkpoints.el sunrise-x-popviewer.el sunrise-x-tabs.el sunrise-x-tree.el sunrise-x-w32-addons.el

... seems that the issue is still not clear.

Fogot to mention that the issue only happens when sr-show-file-attribute is nil

suppose the sunrise buffer looks like this (with sr-show-file-attribute tured off):
/home/sunway/.elisp/sunrise-commander: total used in directory 380 available 155377244 README.md sunrise-commander.el sunrise-x-buttons.el sunrise-x-checkpoints.el sunrise-x-loop.el sunrise-x-mirror.el sunrise-x-modeline.el sunrise-x-old-checkpoints.el sunrise-x-popviewer.el sunrise-x-tabs.el sunrise-x-tree.el sunrise-x-w32-addons.el

then I place the cursor on R of README.md, and C-x C-q and input "new", then the buffer remains UNCHANGED.

But after C-c C-c, the buffer is changed to
/home/sunway/.elisp/sunrise-commander: total used in directory 380 available 155377244 newREADME.md sunrise-commander.el sunrise-x-buttons.el sunrise-x-checkpoints.el sunrise-x-loop.el sunrise-x-mirror.el sunrise-x-modeline.el sunrise-x-old-checkpoints.el sunrise-x-popviewer.el sunrise-x-tabs.el sunrise-x-tree.el sunrise-x-w32-addons.el

@escherdragon

This comment has been minimized.

Show comment Hide comment
@escherdragon

escherdragon Oct 24, 2012

Owner

On Wed, Oct 24, 2012 at 10:07 AM, sunway notifications@github.com wrote:

... seems that the issue is still not clear.

Fogot to mention that the issue only happens when sr-show-file-attribute is nil
(...)
then I place the cursor on R of README.md, and C-x C-q and input "new", then the buffer remains UNCHANGED.
(...)

A-HA! That's a bug indeed :-) Great, thanks for reporting -- probably
I would never find that myself.

Cheers,

José A. Romero L.
escherdragon@gmail.com
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)

Owner

escherdragon commented Oct 24, 2012

On Wed, Oct 24, 2012 at 10:07 AM, sunway notifications@github.com wrote:

... seems that the issue is still not clear.

Fogot to mention that the issue only happens when sr-show-file-attribute is nil
(...)
then I place the cursor on R of README.md, and C-x C-q and input "new", then the buffer remains UNCHANGED.
(...)

A-HA! That's a bug indeed :-) Great, thanks for reporting -- probably
I would never find that myself.

Cheers,

José A. Romero L.
escherdragon@gmail.com
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)

escherdragon added a commit that referenced this issue Oct 24, 2012

@escherdragon

This comment has been minimized.

Show comment Hide comment
@escherdragon

escherdragon Oct 24, 2012

Owner

Fixed in 6565b7f, released as 6r441. Thanks again for reporting.

Owner

escherdragon commented Oct 24, 2012

Fixed in 6565b7f, released as 6r441. Thanks again for reporting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment