Fri 04 Jan 2013 11:36:32 AM UTC, comment #10:
Now the back-tick character (` ascii 0x60) in a text document is always pasted as a left quote in texmacs which in turn is pasted back as a back-tick character in the text document. This is true whether I paste normally or paste as verbatim, and whether into a top level document or into a code, verbatim or mode=prog.
However if I verbatim-copy this back-tick character from a texmacs document and paste to a text editor it renders as ‘ which is unicode 0x2018. I am not certain that this is desirable. (However see comment marked *** below)
Cut-n-paste from a code/verbatim block into a text mode document is likely to need to happen as verbatim-copy, and it is in this case that preserving the common meaning is very important. Current behaviour will not preserve meaning: e.g.
` paste-verbatim unto the document will produce the ascii 0x60 symbol looking like a left-quote. copy-verbatim back to the text document will produce the unicode 0x2018 symbol which is not valid in scripting or source code and not what originated.
I would prefer the other behaviour, that for copy-verbatim the character emitted by the back-tick key and represented by ascii 0x60 within the .tm document should also be represented by ascii 0x60 in the clipboard.
In normal non-verbatim copy mode it may make sense to copy as unicide 0x2018 as normal copy mode would be used when copying from a document body and so we choose the symbol with the right appearance. Although in such a case I guess the ' character rendered as right quote should be converted to 0x2019 as well. But I note than I cannot enter a literal apostrophe using S-F5 ' in the same way that S-F5 " will enter an ascii quote (ascii 34)
Also, I no longer know how to enter the grave accent character that renders with the symbol printed on the key cap of the key on my keyboard. If I edit the tm document with a text editor and insert \0 then I can enter the character, likewise I can paste the character sequence \0 from a text editor to obtain the grace accent character.
This grave character may be cut-n-pasted all over the document and keeps its represented form as the grave accent.
****
If I copy from texmacs and paste into a text editor it pastes \0, if I copy-verbatim it appears in a text editor as ` which I would be fine as it COULD mean that the proper symbol as shown in a console would be verbatim-paste into a text editor; but there is NO WAY to paste the symbol back from the text editor, it appears as the left quote instead of the grave accent; and further there is no way I know to enter that symbol from the keyboard into a verbatim/code block.
Finally, if I copy the character from http://www.unicodemap.org/details/0x2018/index.html it appears in a text editor as ‘ but if I paste into texmacs it is rendered as a ?, even with paste-from verbatim. Pasting other charcaters after that causes the ? to turn upside down.
So I think there are few problems.
1. there needs to be a way to type the grave character 0x60 (I note that within .tm, 0x60 means the left-quote 0x2019, and \0 means the grave character).
Maybe a keymap can cause the ` key to insert the right symbol in code/verbatim/mode=prog but this is a small matter.
2. if (1) is done, at least in verbatim export and verbatim-copy we should map \0 -> 0x60 and 0x60 -> 0x2019 (and reverse for verbatim import, verbatim-paste)
3. if (1) is NOT done (current) and ascii 0x60 is to be used (instead of \0) in code/verbatim/mode=prog to represent the symbol emitted by the back-tick key (grave symbol) then:
a. MAYBE it could be rendered as the grave symbol in those environments
b. it should certainly remain as 0x60 when cut-n-paste in verbatim mode and only mapped to 0x2018 0x2019 for non-verbatim cut-n-paste.
and perhaps any ` -> 0x2018 mapping should be joined with comparable mapping for ' -> 0x2019 but that would also need a different representation for a true apostrophe which is actually 0x27 which I think cannot be currently represented in a .tm document separately from the right quote.
This is confusing and I think the confusion comes from trying to represent the meaning a human attaches to the key-cap characters within the document while preserving the ascii symbols the keys generate; combined with a history of character wilful substitution due to font shortcomings as well as taking advantage of homoglyphs oferred by some specific fonts.
I think we should identify .tm representations for double quote (ascii 34) apostrophe (ascii 0x60) and left-single-quote, right-single-quote.
We should then specify how those characters should be input in the different modes, and how they should be converted in the different cut-paste modes.
I prefer that in code/verbatim/mode=prog that whatever symbols are inserted should have the same appearance as in a traditional coding environment; and that when cut-n-paste verbatim they should also have the traditional ascii codes that are generated by the same keys. When left,right quote are inserted into these modes cut-n-paste-verbatim should use the proper unicode representation. This permits cut-n-paste to preserve meaning in a text editor for scripts and source code as well as supporting those symbols in unicode strings (if the compiler supports it).
Finally; while I have talked about mapping according to if copy and paste mode is verbatim mode or not, maybe it should be according to whether or not a section is a verbatim/code/mode=prog section. But that is talk for another day
|