font faces across a copy and paste

font faces across a copy and paste

[Luca Ferrari]

Hi,
this is just a curiosity: I noted that if I'm editing a text buffer
and a code buffer, let's say C/Java, and I copy and paste the code
from the code buffer into the text one than the pasted text maintains
the faces (e.g., colors). I was thinking that faces were applied at a
buffer level, and therefore the code should become faced as a text
chunk, but apparently Emacs stores faces somewhere in memory related
to the text chunk itself. Is this correct? There is something I'm
missing?

Thanks,
Luca

Re: font faces across a copy and paste

[Peter Dyballa]

Am 30.07.2013 um 08:30 schrieb Luca Ferrari:

> There is something I'm missing?

I think since GNU Emacs 24.2 copy&paste also handles text attributes. When one is compiling a line from a series of snippets this line is not one, i.e., C-a, C-e, C-k, or a RET in *shell* buffer does not affect the whole line but only a piece.

I want to find a solution for this behaviour but have not found yet one in the documentation. Guess I would just need to find the proper key word…

--
Greetings

  Pete

To most people solutions mean finding the answers. But to chemists solutions
are things that are still all mixed up.

Re: font faces across a copy and paste

[Jambunathan K]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> I think since GNU Emacs 24.2 copy&paste also handles text
> attributes. 

Does

    C-h d yank properties 

help?

> When one is compiling a line from a series of snippets
> this line is not one, i.e., C-a, C-e, C-k, or a RET in *shell* buffer
> does not affect the whole line but only a piece.

I have difficulty parsing the above sentence and make sense out of it.
Could you re-phrase what you are saying here?

Re: font faces across a copy and paste

[Peter Dyballa]

Am 30.07.2013 um 13:29 schrieb Jambunathan K:

>    C-h d yank properties

Ahh! This sound promising!
> 
>> When one is compiling a line from a series of snippets
>> this line is not one, i.e., C-a, C-e, C-k, or a RET in *shell* buffer
>> does not affect the whole line but only a piece.
> 
> I have difficulty parsing the above sentence and make sense out of it.
> Could you re-phrase what you are saying here?

When I try to "write" in *shell* buffer a command and re-use one and have to insert some addition text I just copy&yank, then

• C-a does not put the cursor to the beginning of the command, just right of the prompt
• C-e does not put the cursor to the end of the command line
• C-k does not kill to the end of the command line
• and RET does not send the whole command but only the portion between the prompt and the cursor.

C-a, C-e, C-k stop working at boundaries of different text properties.

--
Greetings

  Pete

Clovis' Consideration of an Atmospheric Anomaly:
        The perversity of nature is nowhere better demonstrated than by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft

Re: font faces across a copy and paste

[Jambunathan K]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> When I try to "write" in *shell* buffer a command and re-use one and
> have to insert some addition text I just copy&yank, then
>
> • C-a does not put the cursor to the beginning of the command, just right of the prompt
> • C-e does not put the cursor to the end of the command line
> • C-k does not kill to the end of the command line
> • and RET does not send the whole command but only the portion between the prompt and the cursor.
>
> C-a, C-e, C-k stop working at boundaries of different text properties.

A cursory look suggests that the following snippet will do the trick

    (setq inhibit-field-text-motion t)

Consult

    (info "(elisp) Word Motion")

Ofcourse, you could cook up a defadvice that let binds the above
variable to t so that point movement happens in an "un-constrained"
manner.

----------------------------------------------------------------

Notes to self:

1. M-x shell
2. M-h, C-w
3. C-x b *scratch* 
4. M-x font-lock-mode  (Disable font-lock-mode)
5. C-y
6. C-a
7. C-u C-x =

   The help buffer shows following text properties.

   There are text properties here:
     face                 font-lock-string-face
     front-sticky         (field inhibit-line-move-field-capture)
     inhibit-line-move-field-capture t
     rear-nonsticky       t

8. A simple source code search for `inhibit-line-move-field-capture'
   yields hits in - simple.el, ielm.el and comint.el - which in turn
   hint at

      C-h f constrain-to-field

   which makes mention of

     C-h v inhibit-field-text-motion

Re: font faces across a copy and paste

[Peter Dyballa]

Am 30.07.2013 um 13:29 schrieb Jambunathan K:

>    C-h d yank properties 

Setting yank-handled-properties to nil might be the proper and easy means.

--
Greetings

  Pete

There's no place like ~
			– (UNIX Guru)

Re: font faces across a copy and paste

[Jambunathan K]

Luca Ferrari <fluca1978@infinito.it> writes:

> Hi,
> this is just a curiosity: I noted that if I'm editing a text buffer
> and a code buffer, let's say C/Java, and I copy and paste the code
> from the code buffer into the text one than the pasted text maintains
> the faces (e.g., colors). I was thinking that faces were applied at a
> buffer level, and therefore the code should become faced as a text
> chunk, but apparently Emacs stores faces somewhere in memory related
> to the text chunk itself. Is this correct? There is something I'm
> missing?

When you move the text, the text properties (face is one of the
properties) also move with it.

    1. Put your cursor on a piece of text.
    2. C-u C-x =
    3. Go to the end of the resulting buffer.
    4. You will see text properties (usually fontified t, and a
       font-lock-face-*), overlay etc.

But when you copy the pasted text in to buffer that has font-lock-mode
on, the copied text will usually change colors.  This "changing of
colors", (I believe) happens very fast that it is barely noticeable.

>
> Thanks,
> Luca

Re: font faces across a copy and paste

[Sebastien Vauban]

Hi Luca,

Luca Ferrari wrote:
> this is just a curiosity: I noted that if I'm editing a text buffer
> and a code buffer, let's say C/Java, and I copy and paste the code
> from the code buffer into the text one than the pasted text maintains
> the faces (e.g., colors). I was thinking that faces were applied at a
> buffer level, and therefore the code should become faced as a text
> chunk, but apparently Emacs stores faces somewhere in memory related
> to the text chunk itself. Is this correct? There is something I'm
> missing?

AFAIK, fontification can be obtained through either "overlays" or "text
properties".

When overlays, it is in the buffer itself, and not copied across other
buffers.

When text properties, it is a property (face) "attached" to the text, and thus
copied across other buffers.

So, it comes down to how fontification is made in the particular mode or
situation you face.

Best regards,
  Seb

-- 
Sebastien Vauban