From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dan Hitt Newsgroups: gmane.emacs.bugs Subject: bug#46507: 26.1; bold attribute copied into enriched-mode text is not saved Date: Sun, 7 Mar 2021 08:51:26 -0800 Message-ID: References: <87mtvf3zdz.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006e6cad05bcf521f6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20033"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46507@debbugs.gnu.org To: Tomas Nordin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 07 18:10:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lIwuw-00059N-OI for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Mar 2021 18:10:10 +0100 Original-Received: from localhost ([::1]:38268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIwuv-00063a-PV for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Mar 2021 12:10:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55106) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIwup-00061K-4R for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 12:10:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57950) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIwuo-0001Mm-JF for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 12:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lIwuo-0002ym-Cg for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 12:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dan Hitt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Mar 2021 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46507 X-GNU-PR-Package: emacs Original-Received: via spool by 46507-submit@debbugs.gnu.org id=B46507.161513699811439 (code B ref 46507); Sun, 07 Mar 2021 17:10:02 +0000 Original-Received: (at 46507) by debbugs.gnu.org; 7 Mar 2021 17:09:58 +0000 Original-Received: from localhost ([127.0.0.1]:41263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIwui-0002yO-4y for submit@debbugs.gnu.org; Sun, 07 Mar 2021 12:09:58 -0500 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:36855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIwd5-0002Y2-FJ for 46507@debbugs.gnu.org; Sun, 07 Mar 2021 11:51:44 -0500 Original-Received: by mail-wm1-f51.google.com with SMTP id r15-20020a05600c35cfb029010e639ca09eso2362366wmq.1 for <46507@debbugs.gnu.org>; Sun, 07 Mar 2021 08:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5fYdJpw4LmuSXf+PdwfyeqTy1WU17/7dc+xZs3qgGsU=; b=SVUXg4C23SwF98a6Vx3+Bv9X9nwGKLoEE8/h0x/kbNDRSiAVPGvghLormYY3XBqCXV tra3gxklbRgfXDljBHvKp4LiMVbVKRJ2GGpN+hIQ58/5XFmfBc3rMHp3wG903vufcWmh uLXVM7FOf1kzw1MgAYB2F+xkkHEC41ZtXAp0BElE2tYhxif+EAEyEHwJZeYXTrG0YAw+ Z8tiwEDX3kWBwuIDPuVzZpUK/P4v872NUnOHqxYG4CLV9H8Z0pTSe5Jav2iTWrbSHFO0 JU8WDwV+D2UHqLOGEQdUEU/uvkBXVJTxLsD/CyD18opHCcshrxsO7uQZr50AeTzfUdO3 jnyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5fYdJpw4LmuSXf+PdwfyeqTy1WU17/7dc+xZs3qgGsU=; b=hB60fOVKfSia0GPTURDm7PI4414W0WbP5z4Omeh+8yYgJA9S4PojQzkGJCF06vtpJT 4f2dzcAaKXKdVG7ZDe0/V6VmCkgA6g5mjBvd1/qm21D4bvNAYNFMWljoV9HicjxeCGtO 1VvgKstqe10f5otAzqOj7vvriwkwAGHudRBGeIx06obf499jPLaUcq54aWM+1TUb+5ZT UxUcl+PiWkfcjhHOdgbX48npRg+0fo9zQ67xhWVrq5UD/SMkgxb468C1mz2YVL/VrSCu cib2LY53ES12VCxqfVTkbBouyfeQFikWpt8vD7NubWGItdh5AVjNt3sp2H45TCkXTo+7 NVsw== X-Gm-Message-State: AOAM530ECu79v0RvjjUsD61e9vDEj/rC2px4O/Z472fCRNf8izeecj49 7pnOIxQnmi6CK32ihpbyQCZihdOKTUdHta1X1oA= X-Google-Smtp-Source: ABdhPJxlzkjAJ0uroG1TXUasbSMumUJi9QjdNdSrJ3us92Dsc+vJ/FYhtgH5FhtuwqeGq494ttdYEpEzt4PyP8IDwtU= X-Received: by 2002:a05:600c:409:: with SMTP id q9mr18736754wmb.105.1615135897446; Sun, 07 Mar 2021 08:51:37 -0800 (PST) In-Reply-To: <87mtvf3zdz.fsf@posteo.net> X-Mailman-Approved-At: Sun, 07 Mar 2021 12:09:55 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201748 Archived-At: --0000000000006e6cad05bcf521f6 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 7, 2021 at 4:46 AM Tomas Nordin wrote: > Hello Dan > > Dan Hitt writes: > > > I am using emacs 26.1 on debian 10.3. > > > > The bug is that when you copy bolded-colored text from an eshell buffer > > into an enriched-text buffer, the bold shows after the copy --- but if > you > > then close the enriched-text file, and re-open it, the bolding is gone. > > I have no experience with Enriched mode but I read this from [1]: > > Enriched mode is typically used with Text mode (see Text Mode). It > is not compatible with Font Lock mode, which is used by many major > modes, including most programming language modes, for syntax > highlighting (see Font Lock). Unlike Enriched mode, Font Lock mode > assigns text properties automatically, based on the current buffer > contents; those properties are not saved to disk. > > So if the "bolded-colored" text is a font lock thing, it will not be > saved to disc. Could that be it? > > [1] > https://www.gnu.org/software/emacs/manual/html_node/emacs/Enriched-Text.html#Enriched-Text-1 > > -- > Tomas > Thanks Thomas for your mail. I think something like that might explain the behavior: i believe that a command in eshell (or a shell buffer also) gets bolded as a result of fontlock. But when the bolded text is copied to the enriched buffer, it stays bolded, even though there's no font-lock in enriched text. Presumably the bolded state of the text is visible to elisp---it must just be some kind of text property. So, as part of the saving process, enriched-text-mode could certainly traverse the buffer and note all the places where text is bold and save those as well as being bold. It already does something like that because when you manually bold text (via M-o b), that bolded text is remembered. And, as an analogy: when the text changes color in eshell --- for example, the response to a command gets colored orange, that color change is also due to font-lock. When the colored text is copied into an enriched-mode buffer, the text stays orange. And when the enriched buffer is saved, the orange color gets saved with it. So sometimes, at least, enriched saves on a WYSIWYG basis. dan --0000000000006e6cad05bcf521f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 7, 2021 at 4:46 AM Tomas = Nordin <tomasn@posteo.net> w= rote:
Hello Dan<= br>
Dan Hitt <dan.hi= tt@gmail.com> writes:

> I am using emacs 26.1 on debian 10.3.
>
> The bug is that when you copy bolded-colored text from an eshell buffe= r
> into an enriched-text buffer, the bold shows after the copy --- but if= you
> then close the enriched-text file, and re-open it, the bolding is gone= .

I have no experience with Enriched mode but I read this from [1]:

=C2=A0 =C2=A0 Enriched mode is typically used with Text mode (see Text Mode= ). It
=C2=A0 =C2=A0 is not compatible with Font Lock mode, which is used by many = major
=C2=A0 =C2=A0 modes, including most programming language modes, for syntax<= br> =C2=A0 =C2=A0 highlighting (see Font Lock). Unlike Enriched mode, Font Lock= mode
=C2=A0 =C2=A0 assigns text properties automatically, based on the current b= uffer
=C2=A0 =C2=A0 contents; those properties are not saved to disk.

So if the "bolded-colored" text is a font lock thing, it will not= be
saved to disc. Could that be it?

[1] http= s://www.gnu.org/software/emacs/manual/html_node/emacs/Enriched-Text.html#En= riched-Text-1

--
Tomas

Thanks Thomas for your mail.

I think something like that might explain the behavior= : i believe that a command in eshell (or a shell buffer also) gets bolded a= s a result of fontlock.

But when the bolded text i= s copied to the enriched buffer, it stays bolded,=C2=A0even though there= 9;s no font-lock in enriched text.

Presumably the = bolded=C2=A0state of the text is visible to elisp---it must just be some ki= nd of text property.

So, as part of the saving pro= cess, enriched-text-mode could certainly traverse the buffer and note all t= he places where text is bold and save those as well as being bold.

It already does something like that because when you manua= lly bold text (via M-o b), that bolded text is remembered.=C2=A0
=
And, as an analogy: when the text changes color in eshell --= - for example, the response to a command gets colored orange, that color ch= ange is also due to font-lock.

When the colored te= xt is copied into an enriched-mode buffer, the text stays orange.=C2=A0 And= when the enriched buffer is saved, the orange color gets saved with it.

So sometimes, at least, enriched saves on a WYSIWYG = basis.

dan
--0000000000006e6cad05bcf521f6--