From: B Goodr <bgoodr@gmail.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 6668@debbugs.gnu.org
Subject: bug#6668: 23.1.90; desktop-read and/or hack-local-variables fails to load local variables from DOS formatted files
Date: Tue, 8 Dec 2020 13:22:19 -0800 [thread overview]
Message-ID: <CAJj=8EFYNU=ZYOhMxBCGQ_w_CmdKGWgDLDY__cdBWLm64kctfg@mail.gmail.com> (raw)
In-Reply-To: <87360gdwpg.fsf@gnus.org>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
Hi Lars,
I withdraw this request:
I have stopped using Microsoft Windows as my primary development platform,
and thus have stopped using Emacs on that platform. It would be very
difficult for me to reify an Emacs setup on that platform at this point.
This test case is very convoluted indeed. I doubt that you or anyone else
has the willingness to try to unravel it at this late date.
thanks,
Brent
On Tue, Dec 8, 2020, 09:38 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Brent Goodrick <bgoodr@gmail.com> writes:
>
> > The desktop-read function (actually hack-local-variables) gives a
> > false error when the local variables in a buffer that is being read
> > have CR codes as a part of the line terminators.
>
> (This bug report unfortunately got no response at the time.)
>
> > The error stack trace on the latter command is (control codes squashed
> > into literal escape sequences for the email report):
> >
> > Debugger entered--Lisp error: (error "Local variables entry is missing
> the suffix")
> > signal(error ("Local variables entry is missing the suffix"))
> > error("Local variables entry is missing the suffix")
> > hack-local-variables()
> > normal-mode(t)
> > after-find-file(nil t)
> > find-file-noselect-1(#<buffer perltest.pm> "~/perltest.pm" nil nil
> "/mnt/sdb1/home/brentg/perltest.pm" (32524636 2065))
> > find-file-noselect("/home/brentg/perltest.pm")
> > desktop-restore-file-buffer("/home/brentg/perltest.pm" "perltest.pm"
> nil)
>
> Are you still seeing this issue in more recent Emacs versions?
>
> The recipe for reproduction here was kinda convoluted, so I didn't try
> it. If the bug is still present, is loading the perltest.pm file
> sufficient to reproduce the bug, or does desktop have to be involved,
> somehow?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
>
[-- Attachment #2: Type: text/html, Size: 3484 bytes --]
next prev parent reply other threads:[~2020-12-08 21:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-19 15:40 bug#6668: 23.1.90; desktop-read and/or hack-local-variables fails to load local variables from DOS formatted files Brent Goodrick
2020-12-08 17:38 ` Lars Ingebrigtsen
2020-12-08 21:22 ` B Goodr [this message]
2020-12-08 21:42 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJj=8EFYNU=ZYOhMxBCGQ_w_CmdKGWgDLDY__cdBWLm64kctfg@mail.gmail.com' \
--to=bgoodr@gmail.com \
--cc=6668@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.