Patch: Added Lua functions for get/set clipboard
sdaau
I was bugged for a while on how to get an 'append to clipboard'
function in Scite. I have previously had trouble with that, see:
Linux, Lua/Scite, and xclip - hang - scite-interest | Google Groups -
http://groups.google.com/group/scite-interest/browse_thread/thread/3d2b123a0700457f/3b85aadbbf49fac2
What I basically wanted to do, is select a line, press Ctrl+C, then
select some line hundreds of rows afterwards, press say Ctrl+Shift+C,
and get that new line appended to the previous one already in
clipboard - so upon paste, both lines will be pasted (good for making
header files, lol :) )
In theory, that would be very easy to achieve with a Lua script like
this:
function SelAppendClipboard()
-- get current selection
local sel = editor:GetSelText()
-- get clipboard as string in Lua
local origclip = editor:GetClipboard()
-- append selection to the clipboard
local newclip = origclip .. sel
-- set the appended string as clipboard contents
editor:SetClipboard(newclip)
end
except that, there exist no functions in Scite that can get and set
the clipboard via Lua strings... until now :) The following patch adds
editor:GetClipboard() and editor:SetClipboard(string) Lua interface
functions:
http://scite-interest.googlegroups.com/web/scite-2.03-get-set-clipboard.patch
Although I didn't specifically code it for Unicode, it seems it will
handle UTF-8 international characters. The patch is done in respect to
the source retrieved by 'apt-get source scite' in Ubuntu 10.04, which
downloads:
scite_2.03.orig.tar.gz
scite_2.03-1.diff.gz
scite_2.03-1.dsc
Well, hope this helps someone - or even better, if it makes it into
the source :)
Cheers!
Neil Hodgson
> except that, there exist no functions in Scite that can get and set
> the clipboard via Lua strings... until now :)
http://www.scintilla.org/ScintillaDoc.html#SCI_COPYTEXT
Neil
sdaau
Hi Neil,
Thanks for your response !
> > except that, there exist no functions in Scite that can get and set
> > the clipboard via Lua strings... until now :)
>
> http://www.scintilla.org/ScintillaDoc.html#SCI_COPYTEXT
>
to have been a waste of work then.. :)
However, there still isn't anything that would correspond to a
"GetClipboard", right?
Cheers!
Neil Hodgson
> Oh dear - how could I have missed that !? Well, "SetClipboard" seems
> to have been a waste of work then.. :)
A problem with large APIs like Scintilla's is that its easy to
overlook things. Its one of the reasons I don't like adding
convenience methods that can be worked around in other ways.
> However, there still isn't anything that would correspond to a
> "GetClipboard", right?
There isn't currently a GetClipboard. I'm unsure about adding
GetClipboard to Scintilla. Except for some rare examples where a
particular platform really needs some help, Scintilla APIs should be
cross-platform.
CopyText was justified by some platform complexities like the
asynchronous nature of the X clipboard requiring callbacks in early
versions of GTK+. The current way of just calling
gtk_clipboard_wait_for_text is simple enough to be done by the script
if it loads a library with access to GTK+ (like LuaGnome
http://lua-gtk.luaforge.net/en/index.html).
There are some problems with the patch. There's some dead code that
looks exploratory like looping on
gtk_clipboard_wait_is_text_available. Even in the active code there is
a second call to gtk_clipboard_wait_for_text if the first returns NULL
- maybe this is really needed but if so, it at least deserves a
comment. The string returned is supposed to be freed with g_free but
its handed back to the platform-independent code in Editor which isn't
freeing it and doesn't know about g_free since that is only on GTK+.
Returning a std::string would be better.
http://library.gnome.org/devel/gtk/stable/gtk-Clipboards.html#gtk-clipboard-wait-for-text
Neil
sdaau
Thanks for writing down your thoughts regarding these methods!
>
> There isn't currently a GetClipboard. I'm unsure about adding
> GetClipboard to Scintilla. Except for some rare examples where a
> particular platform really needs some help, Scintilla APIs should be
> cross-platform.
>
issue in mind at all...
> CopyText was justified by some platform complexities like the
> asynchronous nature of the X clipboard requiring callbacks in early
> versions of GTK+. The current way of just calling
> gtk_clipboard_wait_for_text is simple enough to be done by the script
> if it loads a library with access to GTK+ (like LuaGnomehttp://lua-gtk.luaforge.net/en/index.html).
>
gtk_clipboard_wait_for_text using a library ;)
> There are some problems with the patch. There's some dead code that
> looks exploratory like looping on
> gtk_clipboard_wait_is_text_available.
should not be needed (I guess), if _wait_for_text is being used; I was
just getting some strange behavior (to do eventually with array
bounds), so I thought maybe I better "double" wait for the text :) I
left it there, more less because I wanted to post the patch as soon as
it started working somewhat (else I'd forget about it, and not post it
all).
> Even in the active code there is
> a second call to gtk_clipboard_wait_for_text if the first returns NULL
> - maybe this is really needed but if so, it at least deserves a
> comment. The string returned is supposed to be freed with g_free but
> its handed back to the platform-independent code in Editor which isn't
> freeing it and doesn't know about g_free since that is only on GTK+.
> Returning a std::string would be better.
>
>
I noticed g_free too, but I didn't instantly think of a good place
where to use it.. And since in my initial use, I haven't experienced
any crashes (though I haven't really checked for memory leaks using
say valgrind), I just left it like that.
In any case, I think the following things may be worth doing:
* Coming up with 'append clipboard' Lua script, that uses CopyText and
a LuaGnome access to _wait_for_text
* Working on a proper, cross-platform 'GetClipboard'
Since things work for me so far, it may take a while for that Lua
script - and since I switched to Linux some year ago, it will take
even longer for a proper suggestion for a GetClipboard :) But in any
case, I'll try to post my results here as they become available...
Cheers!
steve donovan
>> if it loads a library with access to GTK+ (like LuaGnomehttp://lua-gtk.luaforge.net/en/index.html).
>>
> Thanks for this - I wasn't even aware of Lua being able to call
> gtk_clipboard_wait_for_text using a library ;)
I've used lua-gnome with GTK SciTE and it works well for putting up
custom GUI widgets as well.
Generally the approach should be:
- is there an external Lua library that could do the job? (like lua-gnome)
- can we write a Lua extension to do the job? (like the
spawner-ex.dll I use for scite-debug)
- otherwise, last resort, patch SciTE.
steve d.
sdaau
> Generally the approach should be:
> - is there an external Lua library that could do the job? (like lua-gnome)
> - can we write a Lua extension to do the job? (like the
> spawner-ex.dll I use for scite-debug)
> - otherwise, last resort, patch SciTE.
>
Steve - thanks for your comments; a good checklist to have in mind!
Btw - I just thought I'd revisit this thread, because:...
* I wanted get/set clipboard because I wanted to be able to append to
clipboard
* I wanted append to clipboard, because I want to copy non-contiguous
pieces of text
... and I just discovered *now* that Scite has a multiple selection
facility - which in this respect, does the same thing for me! And even
more - since the 'additional' selection can be styled to be of
different color than the normal - so now I have an indication of what
is in the 'queue' :)
However, the 'append to clipboard' script can still be useful to me -
since I have it done to spit out the clipboard contents to output
window whenever 'append' action is performed; which can be useful to
keep track of the copying operation in view (especially if the 'non-
contiguous pieces of text' are far away, and are not in the same
view).
Well, just wanted to leave this here - sorry to bump an old thread,
Cheers!