Re: [O] Kill ring contains non-killed output after an export

2014-04-17 Thread Bastien
Hi Konstantin and Richard,

Richard Lawrence richard.lawre...@berkeley.edu writes:

 The behavior you are seeing is as expected, though I agree that this
 behavior is usually not all that useful.  See the variable
 org-export-copy-to-kill-ring if you want to turn it off.

 Changing the default value of this variable was recently discussed on
 this list:

 http://thread.gmane.org/gmane.emacs.orgmode/84048/focus=84055

 Looks like there haven't been any strong objections to changing it,

Indeed.  The default in now `nil'.

-- 
 Bastien



Re: [O] Kill ring contains non-killed output after an export

2014-04-17 Thread Bastien
Hi Konstantin,

Konstantin Kliakhandler ko...@slumpy.org writes:

 Thanks! Now the export is much more usable for me. Out of curiousity,
 what is the use case of the default behavior?

I think this comes from the time where only the HTML existed, and
where it was only a hack to export small snippets -- in which case
it makes sense to have the copied buffer in the kill-ring, because
you mainly export for the purpose of copying some HTML elsewhere.

Not sure though.

-- 
 Bastien



Re: [O] Kill ring contains non-killed output after an export

2014-04-17 Thread Nicolas Goaziou
Hello,

Bastien b...@gnu.org writes:

 Indeed.  The default in now `nil'.

You forgot to update :version and :package-version keywords in the
defcustom.


Regards,

-- 
Nicolas Goaziou



Re: [O] Kill ring contains non-killed output after an export

2014-04-17 Thread Bastien
Nicolas Goaziou n.goaz...@gmail.com writes:

 You forgot to update :version and :package-version keywords in the
 defcustom.

Indeed, fixed, thanks,

-- 
 Bastien



Re: [O] Kill ring contains non-killed output after an export

2014-04-06 Thread Konstantin Kliakhandler
Hi Richard,

Richard Lawrence richard.lawre...@berkeley.edu writes:

 ...
 The behavior you are seeing is as expected, though I agree that this
 behavior is usually not all that useful.  See the variable
 org-export-copy-to-kill-ring if you want to turn it off.

Thanks! Now the export is much more usable for me. Out of curiousity,
what is the use case of the default behavior?

Best,
Kosta




Re: [O] Kill ring contains non-killed output after an export

2014-04-06 Thread Richard Lawrence

Konstantin Kliakhandler ko...@slumpy.org writes:

 Richard Lawrence richard.lawre...@berkeley.edu writes:
 The behavior you are seeing is as expected, though I agree that this
 behavior is usually not all that useful.  See the variable
 org-export-copy-to-kill-ring if you want to turn it off.

 Thanks! Now the export is much more usable for me. Out of curiousity,
 what is the use case of the default behavior?

I have no idea...if I had to take a guess, it would be that when
exporting a region as a LaTeX *snippet*, such as a table, it could be
useful to yank the resulting code into another buffer.  But I really
can't think of a situation where yanking a whole .tex document from the
kill ring is preferable to just visiting the exported file/buffer.  So
I'm all for changing the default behavior.

Best,
Richard




Re: [O] Kill ring contains non-killed output after an export

2014-04-05 Thread Richard Lawrence
Hi Konstantin,

Konstantin Kliakhandler ko...@slumpy.org writes:

 Whenever I export an org file to pdf, subsequently my kill-ring contains
 the tex code of the intermediate latex stage.
 ...
 What I would expect to get: the last thing I killed.

The behavior you are seeing is as expected, though I agree that this
behavior is usually not all that useful.  See the variable
org-export-copy-to-kill-ring if you want to turn it off.

Changing the default value of this variable was recently discussed on
this list:

http://thread.gmane.org/gmane.emacs.orgmode/84048/focus=84055

Looks like there haven't been any strong objections to changing it, but
maybe the subject of this thread will grab some more attention for the
issue.

Best,
Richard


(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)