all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Makefile mode comment color didn't notice backslash continuation
@ 2003-02-01 20:38 Dan Jacobson
  0 siblings, 0 replies; 8+ messages in thread
From: Dan Jacobson @ 2003-02-01 20:38 UTC (permalink / raw)


Gentlenerds, Makefile mode has blown it by making comment_B appear in
command color when in fact it is a comment just like comment_A:
$ cat Makefile
a:
	echo hello # comment_A \
	comment_B
I bet it was thinking 'shell script'.
-- 
http://jidanni.org/ Taiwan(04)25854780

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Makefile mode comment color didn't notice backslash continuation
       [not found] <mailman.1311.1044140204.21513.bug-gnu-emacs@gnu.org>
@ 2003-02-03 20:48 ` Paul D. Smith
  2003-02-04  1:00   ` Dan Jacobson
                     ` (2 more replies)
       [not found] ` <mailman.1355.1044305370.21513.bug-gnu-emacs@gnu.org>
  1 sibling, 3 replies; 8+ messages in thread
From: Paul D. Smith @ 2003-02-03 20:48 UTC (permalink / raw)


%% Dan Jacobson <jidanni@dman.ddts.net> writes:

  dj> Gentlenerds, Makefile mode has blown it by making comment_B appear in
  dj> command color when in fact it is a comment just like comment_A:
  dj> $ cat Makefile

  dj> a:
  dj> 	echo hello # comment_A \
  dj> 	comment_B

Personally I believe this is wrong as well, but suggest a different
solution: none of this text should be colorized as a comment.

In makefile mode, makefile comments should be colored as comments and
other text which is not makefile comments should not be.

In the above example _none_ of that text is a makefile comment, because
the entirety of any line beginning with a TAB is considered a command
script, and make does not do any comment processing on command script
lines (it can't, actually).

It may or may not be interpreted as a shell comment, once make invokes
the shell (assuming you don't set SHELL to something else)... neither
make nor makefile-mode in Emacs can know that.


In short (too late...) the font-locking in makefile mode should ignore
everything except make variables for colorization in a line that begins
with a TAB (that's what make does, after all...)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Makefile mode comment color didn't notice backslash continuation
  2003-02-03 20:48 ` Paul D. Smith
@ 2003-02-04  1:00   ` Dan Jacobson
       [not found]   ` <mailman.1370.1044327576.21513.bug-gnu-emacs@gnu.org>
  2003-02-04  7:36   ` Eli Zaretskii
  2 siblings, 0 replies; 8+ messages in thread
From: Dan Jacobson @ 2003-02-04  1:00 UTC (permalink / raw)


P> Personally I believe this is wrong as well, but suggest a different
P> solution: none of this text should be colorized as a comment.

hmm, indeed, this is Makefile mode, not shell-script mode.  On the
other hand, one could say that me making a fuss about this ended up in
'emacs taking its toys and going home', leaving me with less colors
than i started. however it is probably better. however maybe there
should still be a makefile-show-shell-comments-too variable one could
turn on so I won't run out of things to find bugs in :-)

P> In the above example _none_ of that text is a makefile comment, because
P> the entirety of any line beginning with a TAB is considered a command
P> script, and make does not do any comment processing on command script
P> lines (it can't, actually).

P.S. if there is no TAB on the last line, it is indeed not colored, as
to your specs...

P> In short (too late...) the font-locking in makefile mode should ignore
P> everything except make variables for colorization in a line that begins
P> with a TAB (that's what make does, after all...)

I think you mean makefile mode need not bother itself with any detail
of lines beginning with tab, i.e. the only comment color in
$ cat Makefile
e=z #ppp
z:
	echo $e
	f=g date
would be #ppp
-- 
http://jidanni.org/ Taiwan(04)25854780

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Makefile mode comment color didn't notice backslash continuation
       [not found]   ` <mailman.1370.1044327576.21513.bug-gnu-emacs@gnu.org>
@ 2003-02-04  4:16     ` Paul D. Smith
  2003-02-04 16:14       ` Dan Jacobson
  0 siblings, 1 reply; 8+ messages in thread
From: Paul D. Smith @ 2003-02-04  4:16 UTC (permalink / raw)


%% Dan Jacobson <jidanni@dman.ddts.net> writes:

  P> In short (too late...) the font-locking in makefile mode should
  P> ignore everything except make variables for colorization in a line
  P> that begins with a TAB (that's what make does, after all...)

  dj> I think you mean makefile mode need not bother itself with any detail
  dj> of lines beginning with tab, i.e. the only comment color in

  dj> $ cat Makefile
  dj> e=z #ppp
  dj> z:
  dj> 	echo $e
  dj> 	f=g date
  dj> would be #ppp

Nope.  In fact I meant exactly what I said.

Yes, the only comment color would be "#ppp", but makefile-mode also
colorizes make variable references.

In the above, the $e is interpreted by make and expanded to the value of
the make variable "e".  Since this value is interpreted by make, it
should be colorized as a make variable reference by makefile-mode.

If you'd written:

  e=z #ppp
  z:
        echo $$e
        f=g date

then I would agree with your statement.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Makefile mode comment color didn't notice backslash continuation
  2003-02-03 20:48 ` Paul D. Smith
  2003-02-04  1:00   ` Dan Jacobson
       [not found]   ` <mailman.1370.1044327576.21513.bug-gnu-emacs@gnu.org>
@ 2003-02-04  7:36   ` Eli Zaretskii
  2 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2003-02-04  7:36 UTC (permalink / raw)
  Cc: gnu-emacs-bug


On 3 Feb 2003, Paul D. Smith wrote:

> In short (too late...) the font-locking in makefile mode should ignore
> everything except make variables for colorization in a line that begins
> with a TAB (that's what make does, after all...)

I agree.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Makefile mode comment color didn't notice backslash continuation
  2003-02-04  4:16     ` Paul D. Smith
@ 2003-02-04 16:14       ` Dan Jacobson
  2003-02-06  5:24         ` Dan Jacobson
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Jacobson @ 2003-02-04 16:14 UTC (permalink / raw)


Oh yes of course, the old double $ trick, as Maxwell Smart would
say. Forgot about that.  OK, hmm, but you must be using the Deluxe
Edition, because my
        echo $$e $e
both look the same color. Indeed, whole line same color.
Maybe it will brighten up when I go to town to get my apt-zip CD
$ apt-cache policy emacs21
  Installed: 21.2-1
  Candidate: 21.2-5
Oh and BTW how about
xy=zw
(no TAB) what say you guys colorize those while you are at it, eh. 
-- 
http://jidanni.org/ Taiwan(04)25854780

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Makefile mode comment color didn't notice backslash continuation
  2003-02-04 16:14       ` Dan Jacobson
@ 2003-02-06  5:24         ` Dan Jacobson
  0 siblings, 0 replies; 8+ messages in thread
From: Dan Jacobson @ 2003-02-06  5:24 UTC (permalink / raw)


I have discovered that, in Makefile mode, $(bla_bla) gets the
colorization, however $B doesn't. I bet the developer didn't remember
that single letter variables are still Makefile variables and not
shell variables.
-- 
http://jidanni.org/ Taiwan(04)25854780

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Makefile mode comment color didn't notice backslash continuation
       [not found] ` <mailman.1355.1044305370.21513.bug-gnu-emacs@gnu.org>
@ 2003-02-13 19:46   ` Alexander Pohoyda
  0 siblings, 0 replies; 8+ messages in thread
From: Alexander Pohoyda @ 2003-02-13 19:46 UTC (permalink / raw)


> In short (too late...) the font-locking in makefile mode should ignore
> everything except make variables for colorization in a line that begins
> with a TAB (that's what make does, after all...)

OK, but what about a makefile like this:

MYVAR = 1  # comment \
             same comment continues

According to info, GNU make treats the second line as a comment:

   * `#' in a line of a makefile starts a "comment".  It and the rest of
     the line are ignored, except that a trailing backslash not escaped
     by another backslash will continue the comment across multiple
     lines.

So it should be colored as a comment.


-- 
Alexander Pohoyda
<alexander.pohoyda@gmx.net>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2003-02-13 19:46 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-01 20:38 Makefile mode comment color didn't notice backslash continuation Dan Jacobson
     [not found] <mailman.1311.1044140204.21513.bug-gnu-emacs@gnu.org>
2003-02-03 20:48 ` Paul D. Smith
2003-02-04  1:00   ` Dan Jacobson
     [not found]   ` <mailman.1370.1044327576.21513.bug-gnu-emacs@gnu.org>
2003-02-04  4:16     ` Paul D. Smith
2003-02-04 16:14       ` Dan Jacobson
2003-02-06  5:24         ` Dan Jacobson
2003-02-04  7:36   ` Eli Zaretskii
     [not found] ` <mailman.1355.1044305370.21513.bug-gnu-emacs@gnu.org>
2003-02-13 19:46   ` Alexander Pohoyda

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.