Re: longish Local Variables in Files

Re: longish Local Variables in Files

[Kevin Rodgers]

Dan Jacobson wrote:
 > In Info:
 >    Here is an example of a local variables list:
 >
 >      ;;; Local Variables: ***
 >      ;;; mode:lisp ***...
 >
 > Yes, right. But what about when you want to use a longish one and
 > want to break the line?

Then you are out of luck: file local variables must be specified on a
single line.  What's wrong with having a really long compile-command
line in your script?

-- 
Kevin Rodgers

Re: longish Local Variables in Files

[Dan Jacobson]

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.

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.

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.  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:

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"

By the way, the documentation, both of local variables and compile,
could also say compile-command is a great local variable to set.
E.g., my .crontab file has

# Local Variables:
# compile-command: "crontab .crontab"
# End:

great local variables examples

[Dan Jacobson]

Continuing "great examples of the use of local variables, in particular
regarding the compile command" for addition to the documentation, here is

! Local Variables:
! compile-command: "xrdb .Xresources"
! End:

However having to hardwire the filename into the file is dumb.
One would want to use something like

! compile-command: (concat "xrdb " buffer-file-name)

But 1. the user is then asked a question upon find-file, and
2. Wrong type argument: stringp, concat.

Re: longish Local Variables in Files

[Kevin Rodgers]

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

Re: longish Local Variables in Files

[Dan Jacobson]

K> We can't recommend the use of backquote-newline-backquote in a shell
K> command.

K> The # hack is unnecessary and potentially confusing.

But we often need the #'s to hide from what is scanning the file. OK?
So there should be examples given for when you need #, and when you
don't.

Let's see, also there's long lines for .el's where we use ";" to hide,
"!" is used in .Xresources, etc. etc.  I suppose all these would hide
behind a ... `#
;`...

or

 ....`#
!`...

Untested. Ok, document all this. Perhaps test first.

K> that should be explained in the Emacs Lisp manual, not the Emacs manual.

anyways, my collection of hacks are intended for a small cookbook
section in the Emacs manual.

Document is soon as this topic is about to get boring.

Re: longish Local Variables in Files

[Kevin Rodgers]

Dan Jacobson wrote:
 > K> We can't recommend the use of backquote-newline-backquote in a shell
 > K> command.
 >
 > K> The # hack is unnecessary and potentially confusing.
 >
 > But we often need the #'s to hide from what is scanning the file. OK?
 > So there should be examples given for when you need #, and when you
 > don't.

Ah, right.  I think the local variable prefix comment string is needed
for successive lines when they can't be continued via a trailing
backslash on the preceding line.  One example where comments can be
continued across line breaks that comes to mind is Tcl/Tk:

# This is obviously a comment \
   and this is a comment as well, but not so obviously.

 > Let's see, also there's long lines for .el's where we use ";" to hide,
 > "!" is used in .Xresources, etc. etc.  I suppose all these would hide
 > behind a ... `#
 > ;`...
 >
 > or
 >
 >  ....`#
 > !`...

It depends completely on the format of the file.  If it's a program,
it depends both on the syntax of the programming language at both the
lexical and grammatical levels; if it's a text file, it depends on the
syntax of the markup language at both levels.  It is far too
idiosyncratic to generalize, but it might be worthwhile to include
shell and lisp programming language examples.

 > Untested. Ok, document all this. Perhaps test first.

Perhaps?

 > K> that should be explained in the Emacs Lisp manual, not the Emacs manual.
 >
 > anyways, my collection of hacks are intended for a small cookbook
 > section in the Emacs manual.
 >
 > Document is soon as this topic is about to get boring.

It may be boring, but it's still not solved.

The alternative implementation I'd like to propose is that the local
variable prefix and suffix be ignored, by copying the local variables
section (minus the "Local variables:" header and "End:" footer lines)
to a temporary buffer and deleting the the prefix and suffix from each
line before parsing the "variable: value" pairs.  Then your original
example would be simply:

# Local variables:
# compile-command: "invoke-rc.d chrony restart && sleep 2 && \
# grep chrony /var/log/syslog|tail -19"
# End:

The temporary buffer would contain just:

compile-command: "invoke-rc.d chrony restart && sleep 2 && \
grep chrony /var/log/syslog|tail -19"

and the backslashed newline in the string value would be discarded by
Emacs' read function.

-- 
Kevin Rodgers

Re: longish Local Variables in Files

[Dan Jacobson]

Here's perhaps another example for the Local Variables examples,
which you can put on the info Node "Locals",
which by the way should be renamed "Local Variables",
;Local Variables:
;compile-command: "emacs -batch -l .emacs -f batch-byte-compile .emacs"
;End:
(No I don't know how to use current-buffer instead of hardwiring ".emacs".)
Now even the beginner can get into the obsessive-compulsive habit of
byte-compiling his .emacs.
Wait.  Wrap this around your .emacs instead:
(let ((el (expand-file-name "~/.emacs"))
      (elc (expand-file-name "~/.gnus.elc")))
  (if (file-newer-than-file-p el elc)
      (progn
	(message "%s is not up to date, byte-compiling %s..." el elc)
	(sit-for 1)
	(byte-compile-file el)
	(load elc nil t t))
;ELSE: to the end of the file!
;;guts of .emacs go here
))
I wanted to not hardwire the file names in but they are needed in
during byte-compile apparently,  buffer-file-name can't be used.