all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Kevin Rodgers <ihs_4664@yahoo.com>
Subject: Re: longish Local Variables in Files
Date: Mon, 30 Aug 2004 12:21:43 -0600	[thread overview]
Message-ID: <41337037.5030802@yahoo.com> (raw)
In-Reply-To: mailman.534.1093712643.1998.bug-gnu-emacs@gnu.org

Dan Jacobson wrote:
 > K> Then you are out of luck: file local variables must be specified on a
 > K> single line.
 >
 > Make sure this is documented. Wait, I demonstrated that it could be
 > done on two lines.

OK, I see now why that works: hack-local-variables reads the value as
a Lisp expression, not as a line.  So Lisp objects whose readable
syntax can span multiple lines (strings, lists, and vectors -- are
there any others?) can be specified with embedded newlines as values
for file local variables.

The key thing to remember is that the newlines, local variable prefix,
and local variable suffix are not ignored or discarded by the (read
(current-buffer)) function call when the occur within "...".  So in
your compile-command example, they are all present in the variable's
value.

Within a list or vector value, though, the prefix and suffix may be
significant.

 > K> What's wrong with having a really long compile-command
 > K> line in your script?
 >
 > I don't want lines to wrap etc. on my terminal or printer. Call me old
 > fashioned.

I agree readability is a good thing, I just wanted to make sure it
wasn't a functional requirement.

 > rms> # compile-command: "invoke-rc.d chrony restart && sleep 2`\
 > rms> #` && grep chrony /var/log/syslog|tail -19"
 >
 > Indeed that works, no need for /bin/sh's ":", and one can even remove
 > the backslash.

That's because the backslash occurs within "..." and is interpreted
the same as within any string: the following newline is ignored.

 >  One can go on and on:
 >
 > # Local Variables:
 > # compile-command: "p=$PWD && cd /tmp && procmail -m LOGABSTRACT=all `
 > #` VERBOSE=on $p/.procmailrc.local.post </dev/null `
 > #` bla bla"
 > # End:

We can't recommend the use of backquote-newline-backquote in a shell
command.  RMS' example above (backquote-backslash-newline-pound
sign-backquote) is even worse.

 > OK, remember to document this `#` hack.  As this always is sent to sh,
 > this should always work.  And document simpler ways for those who
 > don't need to hide local variables in comments, e.g.,
 >
 > rms> # compile-command: "invoke-rc.d chrony restart && sleep 2 \
 > rms> && grep chrony /var/log/syslog|tail -19"

The # hack is unnecessary and potentially confusing.  RMS' example
clearly demonstrates the right way to do this.  I think it might be
worthwhile explaining that string etc. values for file local variables
may span multiple lines and that the local variable prefix can
interfere with the intended value; but that should be explained in the
Emacs Lisp manual, not the Emacs manual.

-- 
Kevin Rodgers

  parent reply	other threads:[~2004-08-30 18:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.2243.1093147432.2011.bug-gnu-emacs@gnu.org>
2004-08-23 20:58 ` longish Local Variables in Files Kevin Rodgers
2004-08-27  1:13   ` Dan Jacobson
2004-08-29  0:17     ` great local variables examples Dan Jacobson
     [not found]   ` <mailman.534.1093712643.1998.bug-gnu-emacs@gnu.org>
2004-08-30 18:21     ` Kevin Rodgers [this message]
2004-08-31 17:23       ` longish Local Variables in Files Dan Jacobson
     [not found]       ` <mailman.888.1093976111.1998.bug-gnu-emacs@gnu.org>
2004-08-31 20:27         ` Kevin Rodgers
2004-09-09 21:19       ` Dan Jacobson
     [not found] <E1C5pOU-0007hf-Ut@fencepost.gnu.org>
2004-09-10 23:24 ` Dan Jacobson
2004-08-21 22:52 Dan Jacobson
     [not found] ` <E1Bz1w0-00035G-KQ@fencepost.gnu.org>
2004-08-23 17:45   ` Dan Jacobson
2004-08-24 21:02     ` Richard Stallman

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=41337037.5030802@yahoo.com \
    --to=ihs_4664@yahoo.com \
    /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.