Re: [O] Org-edit-special and C-x C-s strange behavior

2012-02-14 Thread Andreas Leha
Leo Alekseyev dnqu...@gmail.com writes:

 I am afraid this might have caused a regression (although it could've
 been something else).  With the latest org-mode pull, C-x C-s in
 org-src buffer does not save the underlying org-file (as expected) but
 instead prompts for file name to save.  This is rather bad behavior.

 On Tue, Jan 24, 2012 at 9:25 AM, Bastien b...@altern.org wrote:
 Hi Leo,

 Leo Alekseyev dnqu...@gmail.com writes:

 Folks, I still think that the fact that buffer-file-name is not nil is
 a bug and should be fixed.

 So do I.  I think this is fixed now -- thanks!

 --
  Bastien

Hi all,

I am also seeing this behaviour and classify it as regression.

Regards,
Andreas




Re: [O] Org-edit-special and C-x C-s strange behavior

2012-02-14 Thread Andreas Leha
Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Leo Alekseyev dnqu...@gmail.com writes:

 I am afraid this might have caused a regression (although it could've
 been something else).  With the latest org-mode pull, C-x C-s in
 org-src buffer does not save the underlying org-file (as expected) but
 instead prompts for file name to save.  This is rather bad behavior.

 On Tue, Jan 24, 2012 at 9:25 AM, Bastien b...@altern.org wrote:
 Hi Leo,

 Leo Alekseyev dnqu...@gmail.com writes:

 Folks, I still think that the fact that buffer-file-name is not nil is
 a bug and should be fixed.

 So do I.  I think this is fixed now -- thanks!

 --
  Bastien

 Hi all,

 I am also seeing this behaviour and classify it as regression.

 Regards,
 Andreas

Hi all,

please ignore my last message.  Saw this too late:
http://article.gmane.org/gmane.emacs.orgmode/52334 (thanks, Leo!)

- Andreas




Re: [O] Org-edit-special and C-x C-s strange behavior

2012-02-08 Thread Leo Alekseyev
I am afraid this might have caused a regression (although it could've
been something else).  With the latest org-mode pull, C-x C-s in
org-src buffer does not save the underlying org-file (as expected) but
instead prompts for file name to save.  This is rather bad behavior.

On Tue, Jan 24, 2012 at 9:25 AM, Bastien b...@altern.org wrote:
 Hi Leo,

 Leo Alekseyev dnqu...@gmail.com writes:

 Folks, I still think that the fact that buffer-file-name is not nil is
 a bug and should be fixed.

 So do I.  I think this is fixed now -- thanks!

 --
  Bastien



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-24 Thread Bastien
Hi Leo,

Leo Alekseyev dnqu...@gmail.com writes:

 Folks, I still think that the fact that buffer-file-name is not nil is
 a bug and should be fixed.

So do I.  I think this is fixed now -- thanks!

-- 
 Bastien



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-13 Thread Leo Alekseyev

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.


 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?


 I am using 24.0.92 and I have no problems at all (just tried right
 now).

 One difference, however, could be the window configurations we
 use.  Specifically, I have

       (setq org-src-window-setup (quote current-window))


 Yes, this works. It's also a more sensible default. However, it
 doesn't change the fact that there's a bug, it just switches to a case
 where the bug isn't triggered :)


 It is also not triggered by the other-window option, which behaves more
 like
 reorganize-frame than current-window (emacs 24.0.92)

Folks, I still think that the fact that buffer-file-name is not nil is
a bug and should be fixed.  If I'm wrong, can someone point out why
this is so?

I have seen many functions that test whether or not a buffer is
visiting a file by checking buffer-file-name.  For instance, if I
wanted to enable autosave for org-src buffers, it would break since my
make-auto-save-file-name checks whether a file is being visited.

--Leo



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-12 Thread Eric S Fraga
Leo Alekseyev dnqu...@gmail.com writes:

 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience

 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?

I am using 24.0.92 and I have no problems at all (just tried right
now).  

One difference, however, could be the window configurations we
use.  Specifically, I have

  (setq org-src-window-setup (quote current-window))
  
in my configuration: the special editing window replaces the current
window entirely.  When I hit C-x C-s, the buffer is saved but nothing
changes (nothing is buried, etc.).  Maybe you have the default
configuration which is to reorganize-frame and maybe that is where the
problem is?

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.106.gc835)



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-12 Thread Andreas Leha
Eric S Fraga e.fr...@ucl.ac.uk writes:

 Leo Alekseyev dnqu...@gmail.com writes:

 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience

 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?

 I am using 24.0.92 and I have no problems at all (just tried right
 now).  

 One difference, however, could be the window configurations we
 use.  Specifically, I have

   (setq org-src-window-setup (quote current-window))
   
 in my configuration: the special editing window replaces the current
 window entirely.  When I hit C-x C-s, the buffer is saved but nothing
 changes (nothing is buried, etc.).  Maybe you have the default
 configuration which is to reorganize-frame and maybe that is where the
 problem is?

Thanks for this Eric!
I can confirm, that the problem does not occur with this setting here,
too (emacs 24.0.92 as well).




Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-12 Thread Leo Alekseyev
On Thu, Jan 12, 2012 at 4:14 AM, Andreas Leha
andreas.l...@med.uni-goettingen.de wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 Leo Alekseyev dnqu...@gmail.com writes:

 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience

 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?

 I am using 24.0.92 and I have no problems at all (just tried right
 now).

 One difference, however, could be the window configurations we
 use.  Specifically, I have

       (setq org-src-window-setup (quote current-window))

Yes, this works. It's also a more sensible default. However, it
doesn't change the fact that there's a bug, it just switches to a case
where the bug isn't triggered :)



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Eric S Fraga
Leo Alekseyev dnqu...@gmail.com writes:

 I often edit my org-babel code blocks via org-edit-special (C-'), in
 part because I find the tabbing behavior within the code blocks to be
 somewhat flaky. Inevitably, when editing the code block I will press
 C-x C-s (muscle memory). This causes all sorts of annoying
 consequences: the buffer with the code block gets buried, window

[...]

What version of org are you using?  I ask because I used to experience
the annoyance you describe a while back; more recently (since at least a
few months ago), hitting C-x C-s no longer has any negative impact: it
saves the file, or at least appears to.

You still have to C-c ' to get back to the full buffer, mind you, but
that's better, IMO, than changing the behaviour of such a fundamental
key binding as C-x C-s.
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.76.ga9c15)



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Andreas Leha
Eric S Fraga e.fr...@ucl.ac.uk writes:

 Leo Alekseyev dnqu...@gmail.com writes:

 I often edit my org-babel code blocks via org-edit-special (C-'), in
 part because I find the tabbing behavior within the code blocks to be
 somewhat flaky. Inevitably, when editing the code block I will press
 C-x C-s (muscle memory). This causes all sorts of annoying
 consequences: the buffer with the code block gets buried, window

 [...]

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

I am not sure, I understand this.

I do also experience the same behaviour as the OP since some time (weeks, I
guess).  Hitting C-x C-s in the org-edit-special buffer still saves the
org file, but the org-edit-special buffer gets buried.

Cheers,
Andreas




Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Leo Alekseyev
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

It appears that this bug is Emacs-version dependent: it functions as
you describe with 23.2, but the buffer gets buried (with an error
message basic-save-buffer: Wrong type argument: stringp, nil) in
24.0.92.  Org mode is the current git HEAD.  I tried to step through
basic-save-buffer in edebug, but I couldn't catch the error (I'm not
very experienced with edebug).  Can someone test this on Emacs 24 and
confirm what I'm seeing?



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Leo Alekseyev
On Wed, Jan 11, 2012 at 7:40 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?

I've done some more digging into why this is broken. I see a few
issues, but no clear indication of where the problem is.  This,
however, should be fixed: pressing C-x C-s should not break window
configuration.

On Emacs 24, with latest Org:

1. Somehow, (org-edit-src-save) screws up the window configuration and
buries the source edit buffer.  It appears that save-window-excursion
is not restoring windows correctly.  What's going on exactly is
unclear: in the process of getting saved, the source edit buffer is
killed and subsequently restored with   (org-src-switch-to-buffer
buffer 'edit).  Maybe this doesn't play well with
save-window-excursion in Emacs 24?

I stepped through the calls in Emacs 23 and 24, and it all looks
identical -- except for in 24, the call to save-window-excursion does
not in fact restore windows.

2. In file.el:4435 (basic-save-buffer)
(nthcdr 10 (file-attributes buffer-file-name)) often leads to
wrong-type-argument error.  The reason for this is that
buffer-file-name sometimes corresponds to the base .org buffer (no
error in this case), sometimes it corresponds to the name of the
src-edit buffer and sometimes it's nil (leads to wrong-type-argument
error).  By this point, the file should have been written using
'write-contents-functions that is set to (org-edit-src-save), so I
don't know if this error is important (nonetheless, buffer-file-name
should probably be valid).

3. Related, in the same function:
(if (or (buffer-modified-p)
;; handle the case when no modification has been made but
;; the file disappeared since visited
(and buffer-file-name
 (not (file-exists-p buffer-file-name

This if statement is always triggered, because buffer-file-name is not
nil, and because the buffer doesn't correspond to the file.  (Note
that in Emacs 23 this was just (if (buffer-modified-p)...).  This is
not be the appropriate behavior, but it persists because
buffer-file-name is not nil (which it probably should be).

--l



[O] Org-edit-special and C-x C-s strange behavior

2012-01-10 Thread Leo Alekseyev
I often edit my org-babel code blocks via org-edit-special (C-'), in
part because I find the tabbing behavior within the code blocks to be
somewhat flaky. Inevitably, when editing the code block I will press
C-x C-s (muscle memory). This causes all sorts of annoying
consequences: the buffer with the code block gets buried, window
splitting disappears, and if I go back to the original org buffer,
find the relevant code block and try to edit again via C-', I'm faced
with a rather cryptic message Return to existing edit buffer? [n]
will revert changes: (y or n) .

Since C-x C-s is such a basic operation, I think it should do
something more sensible in an edit buffer (for instance, it should
save the original org document and not screw with the window
configuration).  Alternatively, it could be configured to save, and
exit the edit buffer (i.e. simulate the effect of pressing C-' and
then C-x C-s in the original org buffer).  This would go a long way to
making working with code blocks more pleasant.  From my viewpoint /
usage patterns it makes a lot of sense for an edit buffer to behave
like a version of the original org buffer narrowed to the source code
block. If there's a particular reason for the current behavior, I'd be
very curious to know it.

--Leo