MS-Windows、Nextstep、Haiku、Androidのようなウィンドウシステムの選択はXの選択とは異なります。これらのウィンドウシステムは前ノードで説明した“選択コンバーター”メカニズムを採用せずに、それぞれが独自の選択メカニズムを場当たり的な使用しています。一般的にサポートされている選択はPRIMARY、CLIPBOARD、SECONDARYですがドラッグアンドドロップのデータを記録するXdndSelection選択はNextstepとHaikuでも利用できます。
GTKはxの選択システムをエミュレートする道わ模索していますがそのエミュレーションは完全に信頼の置けるものではなく、GDKバックエンドが使用される問題それぞれの全体的な品質に依存します。したがってPGTKとともにビルドしたEmacsでは、XとともにビルドしたEmacsと同じインターフェイスが提供されますが、選択ターゲットの多くは役に立たないでしょう。
たとえクリップボードはあっても、MS-Windowsというオペレーティングシステムにはプライマリーやセカンダリーという選択の概念がありません。このシステムでは要求に応じてクリップボードへの保存や取得を行う際に、Emacsがプライマリー選択とセカンダリー選択の存在をシミュレートしています。
プライマリー選択とセカンダリー選択のシミュレーションは、gui-set-selectionに与えられた選択との関連を指定するシンボルのx-selectionsプロパティ(すなわちgui-get-selectionのtype引数)の値を保存するすることによって行われます。その後のgui-get-selection呼び出しごとにその値がリターンされますが、その値はさらなる検査(型チェックなど)の対象ではありません。このような状況下では、data-type引数は通常は無視されます(ただしTARGETSに関する条件については以下参照)。
クリップボード選択を考慮しなければならない場合(typeがCLIPBOARDなら常時)には、gui-set-selectionは提供された値が文字列であることを検証して、selection-coding-systemで構成されたコーディングシステムでエンコードした後にシステムのクリップボードに保存します。gui-get-selectionの呼び出し側はdata-typeをSTRINGかTARGETSのいずれかにセットすることを要求されます。
gui-get-selectionの呼び出しにおいてdata-typeにTARGETSがセットされている場合には、選択データが存在すればXでの場合と同じようにシンボルのベクターがリターンされます。前提条件となるデータ変換ルーチンが存在しないので、STRING以外のフォーマットでクリップボードのデータを要求することは不可能です。selection-coding-systemによってエンコードしてクリップボードに文字列を保存する場合と同じように、同じコーディングシステムによりデコードされた文字列が読み取られます選択データを保存する際に問題が生じた場合には、この変数、および同類のnext-selection-coding-systemは特に吟味する価値があるでしょう。
Xにおける標準であるこれら3つの選択はNextstepにも存在しますが、Emacsに唯一可能なのはこれらの選択への文字列の保存だけです。selection-coding-systemの値に関わらずテキストはutf-8-unixとして一律にエンコードされるとはいえ、gui-set-selectionの呼び出しにはMS-Windowsの場合と同様の制限が課せられます。gui-get-selectionはより寛大なので、以下の選択ターゲットにたいしてリクエストを受け付けます:
NextstepではXdndSelection選択も、gui-set-selectionに提供された値を記録するレポジトリという形式で存在します。これの唯一の目的は、基本的なドラッグアンドドロップ関数であるx-begin-dragにたいする値を保存することにあります(ドラッグアンドドロップを参照)。他の何らかのによって読み取った値については何の保証もありません。
Haikuシステムにおける選択はXにおいて慣例的な3つの選択すべて、およびドラッグアンドドロップデータを記録するXdndSelectionから構成されています。
前者の3つの選択にたいしてgui-set-selectionが呼び出されると、提供されたデータは選択エンコーダー(selection
encoder)という関数のリストによりウィンドウサーバーの“メッセージ”へと変換されて、ウィンドウサーバーに送信されます。
選択エンコーダー関数のリスト。gui-set-selectionが呼び出されると、そのselectionとvalueの引数により、このリスト内の関数がそれぞれ順に呼び出される。これらの関数が非nilをリターンする場合には、リターン値は(key type value)という形式のリストでなければならない。このリストにおいてkeyは転送されるデータの名前(一般的にはたとえば‘"text/plain"’のようにそのデータのMIMEタイプ)、typeはデータのタイプを指定するシンボルか数値(これらによりvalueの解釈も管理される)。以下のリストに有効なデータタイプ、およびそれらによってvalueがどのように解釈されることになるかを示す。
stringユニバイト文字列。この文字列はメッセージ内に配置された後にNULL終端される。
refファイル名。ファイルを特定してそのファイルを識別するinodeをメッセージ内に配置する。
short16ビット整数値。
long32ビット整数値。
llong64ビット整数値。
bytechar0から255の符号なしバイト。
size_t0から1までの数値から、Emacs実行中のコンピューターのワードサイズの2乗を減じた値。
ssize_tCのssize_t型に適合する数値。
pointスクリーン上の座標を指定する2つの浮動小数点数のコンス。
floatdoubleフォーマット未指定の単精度または倍精度の浮動小数点数。
(haiku-numeric-enum MIME)特定のMIMEタイプのデータを含んだユニバイト文字列。
gui-get-selectionの呼び出しにより通常だと選択メッセージ内にdata-typeという名前のデータがリターンされますが、代替えの名前によってdata-typeを置き換える場合には、以下のX選択ターゲットのいずれかが用いられます:
STRINGこれはXにおいてLatin-1テキストを表す: “text/plain;charset=iso-8859-1”
UTF8_STRINGUTF-8テキストを表す: “text/plain”
data-typeがSTRINGのようなテキストタイプ、あるいはパターン‘`text/*’にマッチするMIMEタイプの場合には、文字列データはリターンされる前に適切なコーディングシステムによってデコードされます。
さらにTIMESTAMPとTARGETSの2つのデータタイプは特別に取り扱われます。前者にたいしてリターンされる値はシステムの起動以降に選択が変更された回数(タイムスタンプではない)、後者については他の場合と同じように任意の選択データタイプのベクターです。
MS-Windowsと同じようにAndroidはクリップボードを提供しますがプライマリー選択とセカンダリー選択はありません。gui-set-selectionはgui-get-selection呼び出し後にリターンされる値を変数に保存することでプライマリー選択とセカンダリー選択をシミュレートします。
gui-get-selectionにはクリップボードからタイプSTRINGのUTF-8文字列データ、TAREGTSデータタイプ、イメージデータや任意のMIMEタイプのアプリケーションデータをリターンする能力があります。gui-set-selectionはたとえデータがselection-coding-systemの値に影響を受けなくても、MS-Windowsの場合と同じように文字列データだけをセットできます。これとは対照的にプライマリー選択およびセカンダリー選択との間で保存と読み取りができるのは文字列データだけです。ただしこのデータがEmacs以外のプログラムとやり取りされることはないので、何らかのコーディングシステムによるエンコーディングやデコーディングの対象ではありません。