Menu
▾
▴
#120 Copy copies also font info
Alpha (in contrast to AlphaX) copies text WITH formatting,
instead of just copying the text as a sequence of chars.
I think this is wrong, since the formatting is not an attribute
of the text copied but only an artefact of how the text editor
presents the text on screen.
(In practical terms, when from time to time I have to edit a Word
document, I always found it useful to do as much as possible of
the editing in AlphaX, before pasting it into Word, where it
will be inserted free of formatting. I hope this use of AlphaX
can be inherited by Alpha.)
If for some reason the new behaviour is deemed useful, perhaps
this is not a bug report but a feature request: could we then have
a prefs flag for controlling this, please?
In order to fix Ticket #79: Paste upon rectangular copy inserts spaces instead of \n I have delegated Copy/Paste entirely to Cocoa (no more intervention from Alpha). This ensures that multiple selections as well as rectangular selections are now handled correctly. When a chunk of text is copied in Alpha, many different flavours are stored in the pasteboard. Actually, with a simple Copy, I see
The flavour you mention is
public.utf8-plain-text. But now the target application (say Word) may decide to use any of the flavours contained in the pasteboard and we have no control on this. It is possible it picks thepublic.rtfwhich may contain font information.Or is it the other way round you are concerned with (pasting in Alpha something coming from an other application)?
Pasting in Alpha works as expeced: even text copied from Word or from a web browser is pasted into Alpha without formatting. In other words, Alpha takes from the pasteboard only the information that befits a text editor, namely the plain text. The problem is the other way around, that Copy in Alpha places formatting info in the pasteboard. The logical thing would be that since it only takes text, it should also only put text there (since anyway the formatting does not really belong to the text chunk but rather to the user interface). But if this is complicated to achieve, never mind. It is of course much more important that rectangular copy and paste works correctly.
I have no control over what another application decides to use. Each application looks for the different flavours present in the pasteboard and then is free to choose any one it is interested in. Probably Word uses the
public.rtf(or possiblyNeXT Rich Text Format v1.0 pasteboard type) flavour rather than thepublic.utf8-plain-textone.The only thing I can think of would be to erase the
public.rtftype just after copying in Alpha so that Word has no other choice than pickingpublic.utf8-plain-text. I'll experiment with this idea: I hope it won't break copies from Alpha to itself!I don't know how to inspect the pasteboard, but I think the best would be to see what AlphaX does, which different formats it leaves there on Copy. Since by experience pasteboard content from AlphaX does not have any formatting, I guess this means that there is no Rich Text or similar. I think it is a good idea in AlphaCocoa to remove this Rich Text manually after each Copy operation, and I don't see how it could break internal Copy-and Paste, since in any case it appears that when Alpha pastes, it does not use any of the Rich Text formats.
To inspect the pasteboard you can use Alpha's core command pasteboard. In particular, you can obtain the lsit of flavours present in the pasteboard with the following instruction:
Unfortunately, after a lot of experiments, it seems that there is no way of removing the rich data flavours from the pasteboard. There is no obvious API to remove a data type from the pasteboard anyway. I tried the hard way: after a copy instruction, I stored a copy of all the data types in a dictionary, then cleared the entire pasteboard (there is a command for this), then reconstructed the pasteboard items filtering out the rich text types. No matter what, the "public.rtf" item is back again.
Also as soon as I switch to another application, the contents of the pasteboard change and much more types are present, including other rich text types. Maybe it is a question of data providers (promised data as opposed to actual data).
I can't think of any other solution and I give up.
let me make some advertisement for the utility popclip, which allows many manipulations of text clipboard. In particular it offers the possibility of pasting raw text (unicode, I guess). It has also many other extensions.
https://pilotmoon.com/popclip/ https://pilotmoon.com/popclip/
François
Related
Tickets:
#120I notice that the Alpha command
pasteboard write
produces good clean text.
You said that in order to handle rectangular
copy and multiple selection copy, it was necessary
to use native cocoa pasteboard API, not the Alpha
command.
Would it be possible to make copy conditional:
if the selection is simple, use the Alpha command,
and if it is not simple, use cocoa API.
Maybe it is not feasible, or maybe it would be
too complicated --- in that case sorry for the
noise.
As an experiment, I have installed a new global preference called Copy Restricted which by-passes cocoa's default behavior and stores only the UTF8 text flavour into the pasteboard. This is like using
pasteboard writeand achieves what you want. But doing so we loose the nice copy/paste of rectangular selections. I'll see if I can make Alpha more clever to retrieve the flavour that Cocoa would store in case of a rectangular selection and to install it in the pasteboard. My previous attempts at filtering the copies provided by cocoa have been unsuccesfull so far.Eureka! I found the solution. It is in fact sooooo easy and soooo elegant !
Finally I have installed a new preference called Copy Includes Font Info in the General panel of the Global Preferences dialog (with value 0 by default). This preserves both multiple selections and rectangular selections. The trick was to subclass the writablePasteboardTypes method in class AlphaTextPane.
Changes committed to the repository (rev. 1325). The core must be rebuilt.
Last edit: Bernard Desgraupes 2017-04-21
Fantastic! Thank you so much for the effort, Bernard.
I have just rebuilt and tested. Works perfectly.