* diff-mode misinterprets empty lines. @ 2007-11-29 1:03 Richard Stallman 2007-11-29 9:26 ` David Kastrup 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2007-11-29 1:03 UTC (permalink / raw) To: emacs-devel This is important to fix. Would someone please fix it in Emacs 22, then ack? X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.1.0 To: bug-gnu-emacs@gnu.org From: Sergei Organov <osv@javad.com> Date: Tue, 27 Nov 2007 21:04:17 +0300 Message-ID: <8763zno99a.fsf@osv.gnss.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: diff-mode misinterprets empty lines. Hello, In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20). GNU diff since version 2.8.7 outputs empty lines in the unified diff format for empty context lines that don't change (instead of single space followed by newline). See, e.g., the thread starting here: <http://lists.gnu.org/archive/html/bug-gnu-utils/2006-09/msg00005.html> Emacs diff-mode interprets empty lines as patch hunk separators, in particular leading to wrong calculation of the length put into hunk header. Another symptom is "C-c C-n" (diff-restrict-view) wrongly restricts hunks with empty line(s). Here is a patch hunk to test on: @@ -1,7 +1,7 @@ l1 l3 - abc + cba l5 l6 l7 -- Sergei Organov. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-11-29 1:03 diff-mode misinterprets empty lines Richard Stallman @ 2007-11-29 9:26 ` David Kastrup 2007-11-29 16:09 ` Stefan Monnier 2007-11-29 22:31 ` Richard Stallman 0 siblings, 2 replies; 56+ messages in thread From: David Kastrup @ 2007-11-29 9:26 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > This is important to fix. Would someone please fix it in Emacs 22, > then ack? [...] > GNU diff since version 2.8.7 outputs empty lines in the unified diff > format for empty context lines that don't change (instead of single > space followed by newline). See, e.g., the thread starting here: > > <http://lists.gnu.org/archive/html/bug-gnu-utils/2006-09/msg00005.html> I have to agree with those thinking it is a terrible idea to prune trailing spaces that are part of the _diff_ format. When people don't want trailing whitespace warnings to trigger in their editor, they should obviously amend diff-mode for that. But changing the diff format instead is insane. And that patch happens to have tolerance code intended to deal with utterly broken mailers is no excuse for that. There are lots of other tools working with diffs and applying patches. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-11-29 9:26 ` David Kastrup @ 2007-11-29 16:09 ` Stefan Monnier 2007-12-05 7:35 ` Paul Eggert 2007-11-29 22:31 ` Richard Stallman 1 sibling, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2007-11-29 16:09 UTC (permalink / raw) To: bug-gnu-utils; +Cc: rms, emacs-devel >> GNU diff since version 2.8.7 outputs empty lines in the unified diff >> format for empty context lines that don't change (instead of single >> space followed by newline). See, e.g., the thread starting here: >> >> <http://lists.gnu.org/archive/html/bug-gnu-utils/2006-09/msg00005.html> > I have to agree with those thinking it is a terrible idea to prune > trailing spaces that are part of the _diff_ format. Agreed as well, this is a terrible idea. Making tools somewhat robust in the face of lost trailing whitespace is good (diff-mode does that), but actively removing them is bad. What's the benefit, really? The original post said "This doesn't really matter..." and I agree with this part. So breaking every/most program that parses diffs just because "when the only trailing blanks in a diff are those in context headers, it's a little annoying" seems gratuitous. Could you please revert this change? Stefan "Author of Emacs's diff-mode" ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-11-29 16:09 ` Stefan Monnier @ 2007-12-05 7:35 ` Paul Eggert 2007-12-05 10:17 ` Jim Meyering 0 siblings, 1 reply; 56+ messages in thread From: Paul Eggert @ 2007-12-05 7:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: jim, bug-gnu-utils, rms, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Could you please revert this change? I did so, by installing the following patch into diffutils. The old behavior (with trailing blanks) is now the default, and the new behavior (without them) is enabled only if the new --suppress-blank-empty option is given. However, the next POSIX version specifies a "diff -u" format in which those trailing blanks are optional, and apparently some "diff" implementations in the wild omit them even though no official or test version of GNU diff ever did. So, as a practical matter, programs that parse "diff" output should not assume the trailing blanks are present, regardless of what GNU diff does. 2007-12-04 Paul Eggert <eggert@cs.ucla.edu> * NEWS: New diff option --suppress-blank-empty (no longer -u default). * doc/diff.texi (Detailed Unified): Trailing spaces are no longer omitted. (Trailing Blanks): New section. (diff Options) Mention new option. * src/diff.h (suppress_blank_entry): New decl. * src/context.c (pr_unidiff_hunk): Support --suppress-blank-empty. * src/util.c (print_1_line): Likewise. * src/diff.c (longopts, main, option_help_msgid): Likewise. (SUPPRESS_BLANK_EMPTY_OPTION): New constant. Index: NEWS =================================================================== RCS file: /cvsroot/diffutils/diffutils/NEWS,v retrieving revision 1.27 diff -u -p -r1.27 NEWS --- NEWS 19 Jul 2007 17:45:26 -0000 1.27 +++ NEWS 5 Dec 2007 07:24:10 -0000 @@ -1,7 +1,6 @@ User-visible changes since 2.8.7 (in "version" 2.8.7-cvs): -* When reporting an unchanged empty line, diff -u now outputs an - empty line instead of a line consisting of a single space character. +* New diff option --suppress-blank-empty. * Bring back support for `diff -NUM', where NUM is a number, even when conforming to POSIX 1003.1-2001. This change reverts to Index: doc/diff.texi =================================================================== RCS file: /cvsroot/diffutils/diffutils/doc/diff.texi,v retrieving revision 1.33 diff -u -p -r1.33 diff.texi --- doc/diff.texi 15 Aug 2007 19:33:36 -0000 1.33 +++ doc/diff.texi 5 Dec 2007 07:24:11 -0000 @@ -842,8 +842,7 @@ line numbers look like @samp{@var{start} its end line number appears. An empty hunk is considered to end at the line that precedes the hunk. -Lines common to both files begin with a space character, except that -the space is omitted if its line is empty. Lines +The lines common to both files begin with a space character. The lines that actually differ between the two files have one of the following indicator characters in the left print column: @@ -1854,8 +1853,9 @@ specified patterns. These adjustments can be applied to any output format. @menu -* Tabs:: Preserving the alignment of tab stops. -* Pagination:: Page numbering and time-stamping @command{diff} output. +* Tabs:: Preserving the alignment of tab stops. +* Trailing Blanks:: Suppressing blanks before empty output lines. +* Pagination:: Page numbering and time-stamping @command{diff} output. @end menu @node Tabs @@ -1890,6 +1890,29 @@ output format, which does not have a spa type indicator character. Select this method with the @option{-T} or @option{--initial-tab} option. +@node Trailing Blanks +@section Omitting trailing blanks +@cindex trailing blanks +When outputting lines in normal or context format, or outputting an +unchanged line in unified format, @command{diff} normally outputs a +blank just before each line. If the line is empty, the output of +@command{diff} therefore contains trailing blanks even though the +input does not contain them. For example, when outputting an +unchanged empty line in context format, @command{diff} normally +outputs a line with two leading spaces. + +Some text editors and email agents routinely delete trailing blanks, +so it can be a problem to deal with diff output files that contain +them. You can avoid this problem with the +@option{--suppress-blank-empty} option. It causes @command{diff} to +omit trailing blanks at the end of output lines in normal, context, +and unified format, unless the trailing blanks were already present in +the input. This changes the output format slightly, so that output +lines are guaranteed to never end in a blank unless an input line ends +in a blank. This format is less likely to be munged by text editors +or by transmission via email. It is accepted by @acronym{GNU} +@command{patch} as well. + @node Pagination @section Paginating @command{diff} Output @cindex paginating @command{diff} output @@ -3878,6 +3901,11 @@ normal. @xref{Tabs}. Assume that tab stops are set every @var{columns} (default 8) print columns. @xref{Tabs}. +@item --suppress-blank-empty +Suppress any blanks before newlines when printing the representation +of an empty line, when outputting normal, context, or unified format. +@xref{Trailing Blanks}. + @item --to-file=@var{file} Compare each operand to @var{file}; @var{file} may be a directory. Index: src/diff.h =================================================================== RCS file: /cvsroot/diffutils/diffutils/src/diff.h,v retrieving revision 1.28 diff -u -p -r1.28 diff.h --- src/diff.h 19 Jul 2007 17:45:29 -0000 1.28 +++ src/diff.h 5 Dec 2007 07:24:11 -0000 @@ -150,6 +150,9 @@ XTERN size_t tabsize; without changing the characters in it (-T). */ XTERN bool initial_tab; +/* Do not output an initial space or tab before the text of an empty line. */ +XTERN bool suppress_blank_empty; + /* Remove trailing carriage returns from input. */ XTERN bool strip_trailing_cr; Index: src/context.c =================================================================== RCS file: /cvsroot/diffutils/diffutils/src/context.c,v retrieving revision 1.23 diff -u -p -r1.23 context.c --- src/context.c 19 Jul 2007 17:45:28 -0000 1.23 +++ src/context.c 5 Dec 2007 07:24:11 -0000 @@ -350,7 +350,7 @@ pr_unidiff_hunk (struct change *hunk) if (!next || i < next->line0) { char const *const *line = &files[0].linbuf[i++]; - if (**line != '\n') + if (! (suppress_blank_empty && **line == '\n')) putc (initial_tab ? '\t' : ' ', out); print_1_line (NULL, line); j++; @@ -362,10 +362,11 @@ pr_unidiff_hunk (struct change *hunk) k = next->deleted; while (k--) { + char const * const *line = &files[0].linbuf[i++]; putc ('-', out); - if (initial_tab) + if (initial_tab && ! (suppress_blank_empty && **line == '\n')) putc ('\t', out); - print_1_line (NULL, &files[0].linbuf[i++]); + print_1_line (NULL, line); } /* Then output the inserted part. */ @@ -373,10 +374,11 @@ pr_unidiff_hunk (struct change *hunk) k = next->inserted; while (k--) { + char const * const *line = &files[1].linbuf[j++]; putc ('+', out); - if (initial_tab) + if (initial_tab && ! (suppress_blank_empty && **line == '\n')) putc ('\t', out); - print_1_line (NULL, &files[1].linbuf[j++]); + print_1_line (NULL, line); } /* We're done with this hunk, so on to the next! */ Index: src/util.c =================================================================== RCS file: /cvsroot/diffutils/diffutils/src/util.c,v retrieving revision 1.37 diff -u -p -r1.37 util.c --- src/util.c 15 Aug 2007 19:32:22 -0000 1.37 +++ src/util.c 5 Dec 2007 07:24:11 -0000 @@ -506,7 +506,8 @@ print_script (struct change *script, \f /* Print the text of a single line LINE, flagging it with the characters in LINE_FLAG (which say whether - the line is inserted, deleted, changed, etc.). */ + the line is inserted, deleted, changed, etc.). LINE_FLAG must not + end in a blank, unless it is a single blank. */ void print_1_line (char const *line_flag, char const *const *line) @@ -517,12 +518,25 @@ print_1_line (char const *line_flag, cha /* If -T was specified, use a Tab between the line-flag and the text. Otherwise use a Space (as Unix diff does). - Print neither space nor tab if line-flags are empty. */ + Print neither space nor tab if line-flags are empty. + But omit trailing blanks if requested. */ if (line_flag && *line_flag) { - flag_format = initial_tab ? "%s\t" : "%s "; - fprintf (out, flag_format, line_flag); + char const *flag_format_1 = flag_format = initial_tab ? "%s\t" : "%s "; + char const *line_flag_1 = line_flag; + + if (suppress_blank_empty && **line == '\n') + { + flag_format_1 = "%s"; + + /* This hack to omit trailing blanks takes advantage of the + fact that the only way that LINE_FLAG can end in a blank + is when LINE_FLAG consists of a single blank. */ + line_flag_1 += *line_flag_1 == ' '; + } + + fprintf (out, flag_format_1, line_flag_1); } output_1_line (base, limit, flag_format, line_flag); Index: src/diff.c =================================================================== RCS file: /cvsroot/diffutils/diffutils/src/diff.c,v retrieving revision 1.46 diff -u -p -r1.46 diff.c --- src/diff.c 15 Aug 2007 19:32:22 -0000 1.46 +++ src/diff.c 5 Dec 2007 07:24:11 -0000 @@ -110,6 +110,7 @@ enum NORMAL_OPTION, SDIFF_MERGE_ASSIST_OPTION, STRIP_TRAILING_CR_OPTION, + SUPPRESS_BLANK_EMPTY_OPTION, SUPPRESS_COMMON_LINES_OPTION, TABSIZE_OPTION, TO_FILE_OPTION, @@ -187,6 +188,7 @@ static struct option const longopts[] = {"speed-large-files", 0, 0, 'H'}, {"starting-file", 1, 0, 'S'}, {"strip-trailing-cr", 0, 0, STRIP_TRAILING_CR_OPTION}, + {"suppress-blank-empty", 0, 0, SUPPRESS_BLANK_EMPTY_OPTION}, {"suppress-common-lines", 0, 0, SUPPRESS_COMMON_LINES_OPTION}, {"tabsize", 1, 0, TABSIZE_OPTION}, {"text", 0, 0, 'a'}, @@ -565,6 +567,10 @@ main (int argc, char **argv) strip_trailing_cr = true; break; + case SUPPRESS_BLANK_EMPTY_OPTION: + suppress_blank_empty = true; + break; + case SUPPRESS_COMMON_LINES_OPTION: suppress_common_lines = true; break; @@ -886,6 +892,7 @@ static char const * const option_help_ms N_("-t --expand-tabs Expand tabs to spaces in output."), N_("-T --initial-tab Make tabs line up by prepending a tab."), N_("--tabsize=NUM Tab stops are every NUM (default 8) print columns."), + N_("--suppress-blank-empty Suppress space or tab before empty output lines."), "", N_("-r --recursive Recursively compare any subdirectories found."), N_("-N --new-file Treat absent files as empty."), ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 7:35 ` Paul Eggert @ 2007-12-05 10:17 ` Jim Meyering 2007-12-05 10:58 ` David Kastrup 2007-12-05 17:48 ` Paul Eggert 0 siblings, 2 replies; 56+ messages in thread From: Jim Meyering @ 2007-12-05 10:17 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel, bug-gnu-utils, Stefan Monnier, rms Paul Eggert <eggert@CS.UCLA.EDU> wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> Could you please revert this change? > > I did so, by installing the following patch into diffutils. The old > behavior (with trailing blanks) is now the default, and the new > behavior (without them) is enabled only if the new > --suppress-blank-empty option is given. > > However, the next POSIX version specifies a "diff -u" format in which > those trailing blanks are optional, and apparently some "diff" > implementations in the wild omit them even though no official or test > version of GNU diff ever did. So, as a practical matter, programs > that parse "diff" output should not assume the trailing blanks are > present, regardless of what GNU diff does. > > 2007-12-04 Paul Eggert <eggert@cs.ucla.edu> > > * NEWS: New diff option --suppress-blank-empty (no longer -u default). > * doc/diff.texi (Detailed Unified): Trailing spaces are no longer > omitted. > (Trailing Blanks): New section. > (diff Options) Mention new option. > * src/diff.h (suppress_blank_entry): New decl. > * src/context.c (pr_unidiff_hunk): Support --suppress-blank-empty. > * src/util.c (print_1_line): Likewise. > * src/diff.c (longopts, main, option_help_msgid): Likewise. > (SUPPRESS_BLANK_EMPTY_OPTION): New constant. Hi Paul, That looks fine. Since I was thinking of using that new option always, I considered changing the source to make the default in my private binary be to enable the new option. Since I'd rather not have to make private changes, what do you think about having a compile-time option to change the default? Not even a configure-time flag. Since Emacs may eventually change to accept the new format, it may make sense to change the default and to provide a --no-suppress-blank-empty option. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 10:17 ` Jim Meyering @ 2007-12-05 10:58 ` David Kastrup 2007-12-05 11:27 ` Jim Meyering 2007-12-05 17:48 ` Paul Eggert 1 sibling, 1 reply; 56+ messages in thread From: David Kastrup @ 2007-12-05 10:58 UTC (permalink / raw) To: Jim Meyering; +Cc: Paul Eggert, bug-gnu-utils, Stefan Monnier, rms, emacs-devel Jim Meyering <jim@meyering.net> writes: > Since I was thinking of using that new option always, I considered > changing the source to make the default in my private binary be to > enable the new option. Since I'd rather not have to make private > changes, what do you think about having a compile-time option to > change the default? Not even a configure-time flag. > > Since Emacs may eventually change to accept the new format, it may > make sense to change the default and to provide a > --no-suppress-blank-empty option. No, it does not make sense to change the default. Emacs is just one of many tools processing diff output. I remember gratuitous breakage of git, too. There are far too many tools relying on the _documented_ diff output formats (please read (info "(diff) Context") for a detailed explanation of the diff formats) that it makes sense breaking things all around for no tangible benefit. I don't understand why this change was made in the first place, and I don't understand why people would want to gratuitously make the format less reliable to parse by tools, when the main usage _is_ the application by independent tools. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 10:58 ` David Kastrup @ 2007-12-05 11:27 ` Jim Meyering 2007-12-05 12:33 ` Andreas Schwab 2007-12-05 14:59 ` David Kastrup 0 siblings, 2 replies; 56+ messages in thread From: Jim Meyering @ 2007-12-05 11:27 UTC (permalink / raw) To: David Kastrup Cc: Paul Eggert, bug-gnu-utils, Stefan Monnier, rms, emacs-devel David Kastrup <dak@gnu.org> wrote: > Jim Meyering <jim@meyering.net> writes: > >> Since I was thinking of using that new option always, I considered >> changing the source to make the default in my private binary be to >> enable the new option. Since I'd rather not have to make private >> changes, what do you think about having a compile-time option to >> change the default? Not even a configure-time flag. >> >> Since Emacs may eventually change to accept the new format, it may >> make sense to change the default and to provide a >> --no-suppress-blank-empty option. > > No, it does not make sense to change the default. Emacs is just one of > many tools processing diff output. I remember gratuitous breakage of > git, too. There are far too many tools relying on the _documented_ diff > output formats (please read > (info "(diff) Context") Hi David, My sole interest is in the change to the *unidiff* format. And that was not documented, back then. > for a detailed explanation of the diff formats) that it makes sense > breaking things all around for no tangible benefit. The benefit was tangible enough to me to propose the change, and to Paul to allow and extend it. I'm sure you know that git tools have been accepting the trailing-blank-free format for over a year, so they too saw some benefit in accepting the new format. Too many tools these days can automatically remove trailing blanks. If I keep my code free of trailing blanks (and I do), those tools should have no affect on my code. I want the same benefit for diffs of my code. IMHO, it's an improvement at least to allow a trailing-blank-free diff format. > I don't understand why this change was made in the first place, and I > don't understand why people would want to gratuitously make the format > less reliable to parse by tools, when the main usage _is_ the > application by independent tools. You seem to underestimate Paul's concern for portability. Git was young at the time, and the format they cared about was unidiff, so it wasn't *that* big a deal to fix it. If we had known about the incompatibility with diff-mode back then, I'm sure the new behavior would never have been made the default. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 11:27 ` Jim Meyering @ 2007-12-05 12:33 ` Andreas Schwab 2007-12-05 12:39 ` Jim Meyering 2007-12-05 14:59 ` David Kastrup 1 sibling, 1 reply; 56+ messages in thread From: Andreas Schwab @ 2007-12-05 12:33 UTC (permalink / raw) To: Jim Meyering Cc: Paul Eggert, rms, bug-gnu-utils, emacs-devel, David Kastrup, Stefan Monnier Jim Meyering <jim@meyering.net> writes: > My sole interest is in the change to the *unidiff* format. > And that was not documented, back then. (diff)Detailed Unified: The lines common to both files begin with a space character. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 12:33 ` Andreas Schwab @ 2007-12-05 12:39 ` Jim Meyering 0 siblings, 0 replies; 56+ messages in thread From: Jim Meyering @ 2007-12-05 12:39 UTC (permalink / raw) To: Andreas Schwab Cc: Paul Eggert, rms, bug-gnu-utils, emacs-devel, David Kastrup, Stefan Monnier Andreas Schwab <schwab@suse.de> wrote: > Jim Meyering <jim@meyering.net> writes: > >> My sole interest is in the change to the *unidiff* format. >> And that was not documented, back then. > > (diff)Detailed Unified: > > The lines common to both files begin with a space character. Oh. So it did. I suppose I was remembering that aspect was not specified by POSIX, but now it is. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 11:27 ` Jim Meyering 2007-12-05 12:33 ` Andreas Schwab @ 2007-12-05 14:59 ` David Kastrup 2007-12-05 17:45 ` Paul Eggert 2007-12-06 2:11 ` Richard Stallman 1 sibling, 2 replies; 56+ messages in thread From: David Kastrup @ 2007-12-05 14:59 UTC (permalink / raw) To: Jim Meyering; +Cc: Paul Eggert, bug-gnu-utils, Stefan Monnier, rms, emacs-devel Jim Meyering <jim@meyering.net> writes: > David Kastrup <dak@gnu.org> wrote: > >> No, it does not make sense to change the default. Emacs is just one of >> many tools processing diff output. I remember gratuitous breakage of >> git, too. There are far too many tools relying on the _documented_ diff >> output formats (please read >> (info "(diff) Context") > > My sole interest is in the change to the *unidiff* format. > And that was not documented, back then. Huh? What makes you say that? >> for a detailed explanation of the diff formats) that it makes sense >> breaking things all around for no tangible benefit. > > The benefit was tangible enough to me to propose the change, and to > Paul to allow and extend it. I'm sure you know that git tools have > been accepting the trailing-blank-free format for over a year, so they > too saw some benefit in accepting the new format. Huh? What tangible benefit is "does not break in newer versions but only gets less reliable"? > Too many tools these days can automatically remove trailing blanks. Why would you apply them to a _diff_? > If I keep my code free of trailing blanks (and I do), those tools > should have no affect on my code. But your code is written as _diffs_. diffs are _output_ formats, not input formats. > I want the same benefit for diffs of my code. What benefit? > IMHO, it's an improvement at least to allow a trailing-blank-free diff > format. We are not talking about whether it makes sense for Emacs diff to be able to work around the output of broken file transfers. We are talking about whether it makes sense to break the output in the first place. And a "trailing-blank-free diff format" gained in this manner is an illusion, anyway, since diff must be able to represent lines differing in trailing space. >> I don't understand why this change was made in the first place, and I >> don't understand why people would want to gratuitously make the >> format less reliable to parse by tools, when the main usage _is_ the >> application by independent tools. > > You seem to underestimate Paul's concern for portability. Huh? How does one gain portability by breaking output formats? > Git was young at the time, and the format they cared about was > unidiff, so it wasn't *that* big a deal to fix it. Huh? What do you mean by "fix it"? > If we had known about the incompatibility with diff-mode back then, > I'm sure the new behavior would never have been made the default. We are not talking about an "incompatibility with diff-mode". We are talking about breaking the format specification. That concerns _any_ tool reading the output of diff, not just diff-mode. So again: where is the tangible benefit of breaking diff output in the first place? Because broken communication channels might break it, too? What kind of benefit is it to prebreak it? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 14:59 ` David Kastrup @ 2007-12-05 17:45 ` Paul Eggert 2007-12-05 18:12 ` David Kastrup 2007-12-05 21:04 ` Juanma Barranquero 2007-12-06 2:11 ` Richard Stallman 1 sibling, 2 replies; 56+ messages in thread From: Paul Eggert @ 2007-12-05 17:45 UTC (permalink / raw) To: David Kastrup Cc: rms, bug-gnu-utils, Jim Meyering, Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: >> Too many tools these days can automatically remove trailing blanks. > > Why would you apply them to a _diff_? We're beating a dead horse here, since the default behavior has been changed back, but since you're interested in doing an autopsy.... I regularly apply many tools to a diff. I use Emacs, and other text editors. I send diffs via email, and I store them as part of other text files. The most recent email I sent to this forum contained a diff, for example. In environments that use diffs a lot, trailing white space can cause problems. Here's one example. Emacs has a way of highlighting trailing white space. This feature is a nice thing to have in general, since it highlights white space that in some applications can cause harm (C source code, makefiles, etc.) and that the user normally cannot see. But if 'diff' output contains unnecessary trailing white space, the highlighted white space turns into false alarms on your screen. In general, a false alarm is a bad thing: either it causes you to turn off the alarm mechanism, or it causes you to ignore similar alarms in the future. So that is at least one good motivation for suppressing unnecessary trailing white space. I'm not saying that it is always the right thing to suppress trailing blanks; I'm only saying that there are good reasons to do so in some cases. By the way, the diff that I sent in my previous email <http://lists.gnu.org/archive/html/bug-gnu-utils/2007-12/msg00026.html> suppressed the trailing white space in question. Did you notice? I've used this format for many months now, for patches that I send via email. No problems have been reported with these patches. And I send out my fair share of patches. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 17:45 ` Paul Eggert @ 2007-12-05 18:12 ` David Kastrup 2007-12-06 0:54 ` Paul Eggert 2007-12-05 21:04 ` Juanma Barranquero 1 sibling, 1 reply; 56+ messages in thread From: David Kastrup @ 2007-12-05 18:12 UTC (permalink / raw) To: Paul Eggert; +Cc: rms, bug-gnu-utils, Jim Meyering, Stefan Monnier, emacs-devel Paul Eggert <eggert@CS.UCLA.EDU> writes: > David Kastrup <dak@gnu.org> writes: > >>> Too many tools these days can automatically remove trailing blanks. >> >> Why would you apply them to a _diff_? > > We're beating a dead horse here, since the default behavior has been > changed back, but since you're interested in doing an autopsy.... > > I regularly apply many tools to a diff. I use Emacs, and other text > editors. I send diffs via email, and I store them as part of other > text files. The most recent email I sent to this forum contained a > diff, for example. > > In environments that use diffs a lot, trailing white space can cause > problems. No. In environments that use diffs, trailing white space needs to be preserved. Otherwise you could, for example, never have a diff that removes trailing white space. What _you_ mean is that in environments that _don't_ use diffs but rather interpret them as naked text, inconveniences might occur. But those will occur with any patch dealing with trailing white space in any manner, anyhow. > Here's one example. Emacs has a way of highlighting trailing white > space. This feature is a nice thing to have in general, since it > highlights white space that in some applications can cause harm (C > source code, makefiles, etc.) and that the user normally cannot see. > But if 'diff' output contains unnecessary trailing white space, the > highlighted white space turns into false alarms on your screen. Which only means that it is is wrong to interpret diff output with an unmodified trailing whitespace detection mode. Because diff files are not merely text. They carry a meaning. > So that is at least one good motivation for suppressing unnecessary > trailing white space. The trailing white space is not unnecessary since it is part of the format. > I'm not saying that it is always the right thing to suppress trailing > blanks; I'm only saying that there are good reasons to do so in some > cases. diff-mode clearly is not such a one. > By the way, the diff that I sent in my previous email > <http://lists.gnu.org/archive/html/bug-gnu-utils/2007-12/msg00026.html> > suppressed the trailing white space in question. Did you notice? I happen not to be a program. If I had used Emacs for actually dealing with the diff, I would have noticed. Isn't it quite nonsensical to ask this question? Would you be bothering messing with trailing whitespace in the first place if it was human-visible normally? > I've used this format for many months now, for patches that I send via > email. No problems have been reported with these patches. You mean, the mailing list thread on the Emacs developer list (which the request to change this back originated on) is just a figment of my imagination? No problem report triggered it? > And I send out my fair share of patches. The "patch" program deals with this format violation. Not everything else does, and people often repair patches instead of reporting them. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 18:12 ` David Kastrup @ 2007-12-06 0:54 ` Paul Eggert 2007-12-06 10:11 ` Andreas Schwab 0 siblings, 1 reply; 56+ messages in thread From: Paul Eggert @ 2007-12-06 0:54 UTC (permalink / raw) To: David Kastrup Cc: rms, bug-gnu-utils, Jim Meyering, Stefan Monnier, emacs-devel David Kastrup <dak@gnu.org> writes: > In environments that use diffs, trailing white space needs to be > preserved. Otherwise you could, for example, never have a diff that > removes trailing white space. Yes, of course, but the trailing white space you're talking about is unaffected by the change, so this is not the issue here. We are talking only about trailing white space generated by the diff format itself, not about trailing white space in the data. > it is is wrong to interpret diff output with an > unmodified trailing whitespace detection mode. Not if --suppress-blank-empty is used. With that option, all the trailing white space will be about changes to data, which is normally something I want to see. It's much easier to see changings that affect only trailing white space that way. That is an advantage of suppressing the blanks in question. If Emacs could be improved to mark only important trailing white space; then --suppress-blank-empty would be less useful (at least, less useful to Emacs users). But I don't see how to do that in general, when diffs are mixed in with other text. > The trailing white space is not unnecessary since it is part of the > format. Not necessarily. diff outputs several formats. The definition of the format is up to us, and depends on utility; it is not carved in stone. Unless you count draft POSIX as the "stone"; in that case, the trailing blanks of diff -u format are indeed unnecessary. > Would you be bothering > messing with trailing whitespace in the first place if it was > human-visible normally? Yes. Human-visible trailing white space was one of the motivations for this change. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-06 0:54 ` Paul Eggert @ 2007-12-06 10:11 ` Andreas Schwab 0 siblings, 0 replies; 56+ messages in thread From: Andreas Schwab @ 2007-12-06 10:11 UTC (permalink / raw) To: Paul Eggert Cc: David Kastrup, rms, bug-gnu-utils, Jim Meyering, emacs-devel, Stefan Monnier Paul Eggert <eggert@CS.UCLA.EDU> writes: > Not necessarily. diff outputs several formats. The definition of the > format is up to us, and depends on utility; it is not carved in stone. But was defined and documented several years ago. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 17:45 ` Paul Eggert 2007-12-05 18:12 ` David Kastrup @ 2007-12-05 21:04 ` Juanma Barranquero 2007-12-06 15:39 ` Stefan Monnier 1 sibling, 1 reply; 56+ messages in thread From: Juanma Barranquero @ 2007-12-05 21:04 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel On Dec 5, 2007 6:45 PM, Paul Eggert <eggert@cs.ucla.edu> wrote: > But if 'diff' output contains unnecessary trailing white > space, the highlighted white space turns into false alarms on your > screen. In general, a false alarm is a bad thing: either it causes > you to turn off the alarm mechanism, or it causes you to ignore > similar alarms in the future. Or it makes you add (add-hook 'diff-mode-hook (lambda () (setq show-trailing-whitespace nil))) to your .emacs if it really bothers you. This is not "to turn off the alarm mechanism", but rather than having it activated for patches is a mistake, because patches are not text (as David has said). > I've used this format for many months now, for patches that I send via > email. No problems have been reported with these patches. And I send > out my fair share of patches. Again, I agree with David: I've installed quite a few patches, and I've never reported back problems with them if I could trivially fix them. Lack of complains is not a positive proof. Juanma ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 21:04 ` Juanma Barranquero @ 2007-12-06 15:39 ` Stefan Monnier 2008-01-06 0:15 ` Glenn Morris 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2007-12-06 15:39 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Paul Eggert, emacs-devel > Again, I agree with David: I've installed quite a few patches, and > I've never reported back problems with them if I could trivially fix > them. Lack of complains is not a positive proof. Also Emacs's diff-mdoe already has code to try and fix missing trailing whitespace (as well as a few other common problems introduced by brain dead mailers). This support was good enough when only occasional broken patches had those problems. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-06 15:39 ` Stefan Monnier @ 2008-01-06 0:15 ` Glenn Morris 2008-01-06 18:09 ` Richard Stallman 2008-01-14 21:08 ` Stefan Monnier 0 siblings, 2 replies; 56+ messages in thread From: Glenn Morris @ 2008-01-06 0:15 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel In an effort to clear FOR-RELEASE, here is a simple-minded attempt to deal with this. It seems to fix the original problem at least. *** diff-mode.el.~1.122.~ 2007-10-21 13:00:12.000000000 -0700 --- diff-mode.el 2008-01-05 15:58:41.000000000 -0800 *************** *** 403,409 **** (setq style (diff-hunk-style style)) (let ((end (and (re-search-forward (case style ;; A `unified' header is ambiguous. ! (unified (concat "^[^-+# \\]\\|" diff-file-header-re)) (context "^[^-+#! \\]") (normal "^[^<>#\\]") --- 403,409 ---- (setq style (diff-hunk-style style)) (let ((end (and (re-search-forward (case style ;; A `unified' header is ambiguous. ! (unified (concat "^[^-+# \\\n]\\|" diff-file-header-re)) (context "^[^-+#! \\]") (normal "^[^<>#\\]") ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-01-06 0:15 ` Glenn Morris @ 2008-01-06 18:09 ` Richard Stallman 2008-01-14 21:08 ` Stefan Monnier 1 sibling, 0 replies; 56+ messages in thread From: Richard Stallman @ 2008-01-06 18:09 UTC (permalink / raw) To: Glenn Morris; +Cc: monnier, emacs-devel Thank you for working on this. There are just a few bugs in FOR-RELEASE; with a little work we can fix them all. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-01-06 0:15 ` Glenn Morris 2008-01-06 18:09 ` Richard Stallman @ 2008-01-14 21:08 ` Stefan Monnier 2008-01-14 21:38 ` Glenn Morris 2008-01-29 18:37 ` Chong Yidong 1 sibling, 2 replies; 56+ messages in thread From: Stefan Monnier @ 2008-01-14 21:08 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel > In an effort to clear FOR-RELEASE, here is a simple-minded attempt to > deal with this. It seems to fix the original problem at least. It is problematic when you try to apply a hunk via C-c C-a because any empty line following your hunk (e.g. the last hunk in a C-x v =) will be taken as being part of the hunk and C-c C-a will think that the original text was just missing a newline and will add it (as a result of its fuzzy matching feature). Stefan > *** diff-mode.el.~1.122.~ 2007-10-21 13:00:12.000000000 -0700 > --- diff-mode.el 2008-01-05 15:58:41.000000000 -0800 > *************** > *** 403,409 **** > (setq style (diff-hunk-style style)) > (let ((end (and (re-search-forward (case style > ;; A `unified' header is ambiguous. > ! (unified (concat "^[^-+# \\]\\|" > diff-file-header-re)) > (context "^[^-+#! \\]") > (normal "^[^<>#\\]") > --- 403,409 ---- > (setq style (diff-hunk-style style)) > (let ((end (and (re-search-forward (case style > ;; A `unified' header is ambiguous. > ! (unified (concat "^[^-+# \\\n]\\|" > diff-file-header-re)) > (context "^[^-+#! \\]") > (normal "^[^<>#\\]") ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-01-14 21:08 ` Stefan Monnier @ 2008-01-14 21:38 ` Glenn Morris 2008-01-14 22:46 ` Glenn Morris 2008-01-29 18:37 ` Chong Yidong 1 sibling, 1 reply; 56+ messages in thread From: Glenn Morris @ 2008-01-14 21:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier wrote: >> In an effort to clear FOR-RELEASE, here is a simple-minded attempt to >> deal with this. It seems to fix the original problem at least. > > It is problematic when you try to apply a hunk via C-c C-a because any > empty line following your hunk (e.g. the last hunk in a C-x v =) will be > taken as being part of the hunk and C-c C-a will think that the original > text was just missing a newline and will add it (as a result of its > fuzzy matching feature). Oh dear. Would it suffice to back up over empty lines at the end of a unified diff? Ie treat empty-lines as part of a hunk unless they are at the very end of the diff? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-01-14 21:38 ` Glenn Morris @ 2008-01-14 22:46 ` Glenn Morris 2008-01-14 23:35 ` Diffs between %s and %s end here (was: diff-mode misinterprets empty lines.) Reiner Steib 2008-01-15 0:09 ` diff-mode misinterprets empty lines Dan Nicolaescu 0 siblings, 2 replies; 56+ messages in thread From: Glenn Morris @ 2008-01-14 22:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Glenn Morris wrote: > Would it suffice to back up over empty lines at the end of a unified > diff? Ie treat empty-lines as part of a hunk unless they are at the > very end of the diff? Sigh, that won't work in the CVS trunk, where the end of vc-diff output looks like: <last line of diff hunk> <empty line> <empty line> Diffs between working revision and workfile end here. I don't personally like that last line anyway... ^ permalink raw reply [flat|nested] 56+ messages in thread
* Diffs between %s and %s end here (was: diff-mode misinterprets empty lines.) 2008-01-14 22:46 ` Glenn Morris @ 2008-01-14 23:35 ` Reiner Steib 2008-01-15 3:29 ` Diffs between %s and %s end here Miles Bader 2008-01-15 0:09 ` diff-mode misinterprets empty lines Dan Nicolaescu 1 sibling, 1 reply; 56+ messages in thread From: Reiner Steib @ 2008-01-14 23:35 UTC (permalink / raw) To: emacs-devel On Mon, Jan 14 2008, Glenn Morris wrote: > <last line of diff hunk> > <empty line> > <empty line> > Diffs between working revision and workfile end here. > > I don't personally like that last line anyway... Me too. I'm still distracted by it. What is the purpose of this line? Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-01-14 23:35 ` Diffs between %s and %s end here (was: diff-mode misinterprets empty lines.) Reiner Steib @ 2008-01-15 3:29 ` Miles Bader 2008-01-16 8:13 ` Glenn Morris 0 siblings, 1 reply; 56+ messages in thread From: Miles Bader @ 2008-01-15 3:29 UTC (permalink / raw) To: emacs-devel Reiner Steib <reinersteib+gmane@imap.cc> writes: >> <last line of diff hunk> >> <empty line> >> <empty line> >> Diffs between working revision and workfile end here. >> >> I don't personally like that last line anyway... > > Me too. I'm still distracted by it. What is the purpose of this > line? I agree, the extra junk at the end is annoying. Should be nuked. -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-01-15 3:29 ` Diffs between %s and %s end here Miles Bader @ 2008-01-16 8:13 ` Glenn Morris 0 siblings, 0 replies; 56+ messages in thread From: Glenn Morris @ 2008-01-16 8:13 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel Miles Bader wrote: > I agree, the extra junk at the end is annoying. Should be nuked. I'll remove it in a week or so if no-one objects. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-01-14 22:46 ` Glenn Morris 2008-01-14 23:35 ` Diffs between %s and %s end here (was: diff-mode misinterprets empty lines.) Reiner Steib @ 2008-01-15 0:09 ` Dan Nicolaescu 1 sibling, 0 replies; 56+ messages in thread From: Dan Nicolaescu @ 2008-01-15 0:09 UTC (permalink / raw) To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel Glenn Morris <rgm@gnu.org> writes: > Glenn Morris wrote: > > > Would it suffice to back up over empty lines at the end of a unified > > diff? Ie treat empty-lines as part of a hunk unless they are at the > > very end of the diff? > > Sigh, that won't work in the CVS trunk, where the end of vc-diff > output looks like: > > <last line of diff hunk> > <empty line> > <empty line> > Diffs between working revision and workfile end here. > > I don't personally like that last line anyway... I would vote to take out that line and the extra empty lines. They are annoying when you want to save the diff to a file and archive it, or mail it to someone else, etc. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-01-14 21:08 ` Stefan Monnier 2008-01-14 21:38 ` Glenn Morris @ 2008-01-29 18:37 ` Chong Yidong 2008-02-19 16:32 ` Stefan Monnier 1 sibling, 1 reply; 56+ messages in thread From: Chong Yidong @ 2008-01-29 18:37 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> In an effort to clear FOR-RELEASE, here is a simple-minded attempt to >> deal with this. It seems to fix the original problem at least. > > It is problematic when you try to apply a hunk via C-c C-a because any > empty line following your hunk (e.g. the last hunk in a C-x v =) will be > taken as being part of the hunk and C-c C-a will think that the original > text was just missing a newline and will add it (as a result of its > fuzzy matching feature). Is there any progress on this issue, or is help needed? It seems to me that this is the last bug remaining the FOR-RELEASE, although the release process is so opaque and confusing that I have little idea what's going on. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-01-29 18:37 ` Chong Yidong @ 2008-02-19 16:32 ` Stefan Monnier 2008-02-19 20:44 ` Stefan Monnier 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2008-02-19 16:32 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel >>> In an effort to clear FOR-RELEASE, here is a simple-minded attempt to >>> deal with this. It seems to fix the original problem at least. >> >> It is problematic when you try to apply a hunk via C-c C-a because any >> empty line following your hunk (e.g. the last hunk in a C-x v =) will be >> taken as being part of the hunk and C-c C-a will think that the original >> text was just missing a newline and will add it (as a result of its >> fuzzy matching feature). > Is there any progress on this issue, or is help needed? No progress. Help would be welcome. I think it mostly involves trying to use diff-sanity-checks (either the function itself or the ideas) at more places. E.g. diff-end-of-hunk should check that the place it found is consistent with the hunk header's numbers and if not (and if looking at an empty line) keep going further. But be careful also that diff-end-of-hunk (and other functions) is/are used in diff-fixup-modifs where the hunk header is presumed broken. > It seems to me that this is the last bug remaining the FOR-RELEASE, > although the release process is so opaque and confusing that I have > little idea what's going on. It was decided that this bug should not prevent the pretest. I would personally not hold the release for it either, so we already have diff-sanity-checks which takes care of the most serious problems already. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2008-02-19 16:32 ` Stefan Monnier @ 2008-02-19 20:44 ` Stefan Monnier 0 siblings, 0 replies; 56+ messages in thread From: Stefan Monnier @ 2008-02-19 20:44 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > No progress. Help would be welcome. I think it mostly involves trying Actually, as you may have seen, I've found the time to do it today, Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 14:59 ` David Kastrup 2007-12-05 17:45 ` Paul Eggert @ 2007-12-06 2:11 ` Richard Stallman 1 sibling, 0 replies; 56+ messages in thread From: Richard Stallman @ 2007-12-06 2:11 UTC (permalink / raw) To: David Kastrup; +Cc: eggert, bug-gnu-utils, jim, monnier, emacs-devel There is no need to argue. We do need to change Emacs to cope if that space is missing. And GNU diff should output the spaces by default as it did in the past. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 10:17 ` Jim Meyering 2007-12-05 10:58 ` David Kastrup @ 2007-12-05 17:48 ` Paul Eggert 2007-12-05 17:50 ` Jim Meyering 1 sibling, 1 reply; 56+ messages in thread From: Paul Eggert @ 2007-12-05 17:48 UTC (permalink / raw) To: Jim Meyering; +Cc: bug-gnu-utils, emacs-devel Jim Meyering <jim@meyering.net> writes: > Since I was thinking of using that new option always, I considered > changing the source to make the default in my private binary be to enable > the new option. Could you instead use a shell script? #!/bin/sh exec /path/to/actual/diff/program --suppress-blank-empty "$@" ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-12-05 17:48 ` Paul Eggert @ 2007-12-05 17:50 ` Jim Meyering 0 siblings, 0 replies; 56+ messages in thread From: Jim Meyering @ 2007-12-05 17:50 UTC (permalink / raw) To: Paul Eggert; +Cc: bug-gnu-utils, emacs-devel Paul Eggert <eggert@CS.UCLA.EDU> wrote: > Jim Meyering <jim@meyering.net> writes: > >> Since I was thinking of using that new option always, I considered >> changing the source to make the default in my private binary be to enable >> the new option. > > Could you instead use a shell script? > > #!/bin/sh > exec /path/to/actual/diff/program --suppress-blank-empty "$@" Of course :-) Thanks. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-11-29 9:26 ` David Kastrup 2007-11-29 16:09 ` Stefan Monnier @ 2007-11-29 22:31 ` Richard Stallman 2007-11-29 23:12 ` David Kastrup 2007-11-30 2:03 ` Stefan Monnier 1 sibling, 2 replies; 56+ messages in thread From: Richard Stallman @ 2007-11-29 22:31 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel When people don't want trailing whitespace warnings to trigger in their editor, they should obviously amend diff-mode for that. But changing the diff format instead is insane. And that patch happens to have tolerance code intended to deal with utterly broken mailers is no excuse for that. Are you suggesting I should ask the diff maintainers to revert that change? That might be a good idea. But in the mean time let's make Emacs work with the format generated by diff 2.8.7. Even if diff 2.8.8 undoes this change, 2.8.7 won't disappear. Would someone please do that and ack? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-11-29 22:31 ` Richard Stallman @ 2007-11-29 23:12 ` David Kastrup 2007-11-30 2:03 ` Stefan Monnier 1 sibling, 0 replies; 56+ messages in thread From: David Kastrup @ 2007-11-29 23:12 UTC (permalink / raw) To: rms; +Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > When people don't want trailing whitespace warnings to trigger in their > editor, they should obviously amend diff-mode for that. But changing > the diff format instead is insane. And that patch happens to have > tolerance code intended to deal with utterly broken mailers is no excuse > for that. > > Are you suggesting I should ask the diff maintainers to revert that > change? That might be a good idea. Personally, I would consider this a good idea. The "patch" program has apparently been made robust in the presence of mail-mangled patches, cut&paste carnage and other damage. But "patch works with it" is, in my opinion, not a positive definition of the diff format (while "patch fails" is a different issue): patch is not the only program working with diffs, and some version control systems have a diff-based workflow without using "patch" for it. Here is the format definition actually delivered with diff itself for context diffs: <URL:http://www.gnu.org/software/diffutils/manual/html_node/Detailed-Context.html#Detailed%20Context> And here another for unified diffs: <URL:http://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html#Detailed%20Unified> It appears quite definite from the description that no whitespace reduction is intended, neither for content nor for formatting characters. So yes, I would ask the diff maintainers to revert the change. I can't think of a good reason for it at all, but maybe they can, so it would probably be a good idea to keep emacs-devel in the list (after all, Emacs is one of the applications broken by this, for now): that way we might together reach consensus on the best course. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: diff-mode misinterprets empty lines. 2007-11-29 22:31 ` Richard Stallman 2007-11-29 23:12 ` David Kastrup @ 2007-11-30 2:03 ` Stefan Monnier 1 sibling, 0 replies; 56+ messages in thread From: Stefan Monnier @ 2007-11-30 2:03 UTC (permalink / raw) To: rms; +Cc: emacs-devel > When people don't want trailing whitespace warnings to trigger in their > editor, they should obviously amend diff-mode for that. But changing > the diff format instead is insane. And that patch happens to have > tolerance code intended to deal with utterly broken mailers is no excuse > for that. > Are you suggesting I should ask the diff maintainers to revert that > change? That might be a good idea. Yes, please. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* vc-set-mode-line-busy-indicator @ 2008-02-25 12:46 Nick Roberts 2008-02-25 20:25 ` vc-set-mode-line-busy-indicator Nick Roberts 0 siblings, 1 reply; 56+ messages in thread From: Nick Roberts @ 2008-02-25 12:46 UTC (permalink / raw) To: emacs-devel The problem with this message is that it is so long that the bit after ("from filename") doesn't fit in 80 columns. Also a warning-face isn't really needed because it doesn't provide a wake up call: the user has just entered a command, e.g, vc-diff or vc-print-log, so presumably he's already looking for the output buffer. I've used the same style as I've used for the GUD buffer. If text in the mode-line is going to be increasingly fontified, it might be a good idea to have some consistency. -- Nick http://www.inet.net.nz/~nickrob *** vc.el.~1.541.~ 2008-02-24 08:24:18.000000000 +1300 --- vc.el 2008-02-26 01:29:24.000000000 +1300 *************** BUF defaults to \"*vc*\", can be a strin *** 1064,1077 **** (defun vc-set-mode-line-busy-indicator () (setq mode-line-process ! ;; Deliberate overstatement, but power law respected. ! ;; (The message is ephemeral, so we make it loud.) --ttn ! (propertize " (incomplete/in progress)" ! 'face (if (featurep 'compile) ! ;; ttn's preferred loudness ! 'compilation-warning ! ;; suitably available fallback ! font-lock-warning-face) 'help-echo "A VC command is in progress in this buffer"))) --- 1064,1071 ---- (defun vc-set-mode-line-busy-indicator () (setq mode-line-process ! (propertize " [waiting...]" ! 'face 'font-lock-variable-name-face 'help-echo "A VC command is in progress in this buffer"))) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-02-25 12:46 vc-set-mode-line-busy-indicator Nick Roberts @ 2008-02-25 20:25 ` Nick Roberts 2008-02-26 4:11 ` vc-set-mode-line-busy-indicator Glenn Morris 0 siblings, 1 reply; 56+ messages in thread From: Nick Roberts @ 2008-02-25 20:25 UTC (permalink / raw) To: emacs-devel Nick Roberts writes: > > The problem with this message is that it is so long that the bit after > ("from filename") doesn't fit in 80 columns. Also a warning-face isn't > really needed because it doesn't provide a wake up call: the user has just > entered a command, e.g, vc-diff or vc-print-log, so presumably he's already > looking for the output buffer. > > I've used the same style as I've used for the GUD buffer. If text in the > mode-line is going to be increasingly fontified, it might be a good idea to > have some consistency. I forgot to ask: Shall I apply this patch? > -- > Nick http://www.inet.net.nz/~nickrob > > > *** vc.el.~1.541.~ 2008-02-24 08:24:18.000000000 +1300 > --- vc.el 2008-02-26 01:29:24.000000000 +1300 > *************** BUF defaults to \"*vc*\", can be a strin > *** 1064,1077 **** > > (defun vc-set-mode-line-busy-indicator () > (setq mode-line-process > ! ;; Deliberate overstatement, but power law respected. > ! ;; (The message is ephemeral, so we make it loud.) --ttn > ! (propertize " (incomplete/in progress)" > ! 'face (if (featurep 'compile) > ! ;; ttn's preferred loudness > ! 'compilation-warning > ! ;; suitably available fallback > ! font-lock-warning-face) > 'help-echo > "A VC command is in progress in this buffer"))) > > --- 1064,1071 ---- > > (defun vc-set-mode-line-busy-indicator () > (setq mode-line-process > ! (propertize " [waiting...]" > ! 'face 'font-lock-variable-name-face > 'help-echo > "A VC command is in progress in this buffer"))) > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-02-25 20:25 ` vc-set-mode-line-busy-indicator Nick Roberts @ 2008-02-26 4:11 ` Glenn Morris 2008-02-26 7:38 ` vc-set-mode-line-busy-indicator Nick Roberts 0 siblings, 1 reply; 56+ messages in thread From: Glenn Morris @ 2008-02-26 4:11 UTC (permalink / raw) To: Nick Roberts; +Cc: emacs-devel Nick Roberts wrote: > > ! (propertize " [waiting...]" > > ! 'face 'font-lock-variable-name-face I much prefer your wording. With regards to the face, any chance of a new one? I know this is what people always say, and that for some reason creating new faces is sometimes frowned upon. The practical reason is, the mode-line often has a different background colour to the main buffer, so a font-lock face customized to look good in the buffer may look poor on the mode-line. Eg for me, font-lock-warning-face is practically invisible in the mode-line. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-02-26 4:11 ` vc-set-mode-line-busy-indicator Glenn Morris @ 2008-02-26 7:38 ` Nick Roberts 2008-03-01 22:19 ` vc-set-mode-line-busy-indicator Glenn Morris 0 siblings, 1 reply; 56+ messages in thread From: Nick Roberts @ 2008-02-26 7:38 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel > > > ! (propertize " [waiting...]" > > > ! 'face 'font-lock-variable-name-face > > I much prefer your wording. > > With regards to the face, any chance of a new one? I know this is what > people always say, and that for some reason creating new faces is > sometimes frowned upon. The practical reason is, the mode-line often > has a different background colour to the main buffer, so a font-lock > face customized to look good in the buffer may look poor on the > mode-line. Eg for me, font-lock-warning-face is practically invisible > in the mode-line. I don't know enough to suggest a better one. Perhaps someone else can. I just selected a quiet font-lock face, as font-lock faces are always available. On a related note, I think that adding colour to the mode-line of the already psychedelic compilation buffer means ironically that the plain text starts to stand out. Bright colours only draw attention to a part of the screen if they are used in moderation. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-02-26 7:38 ` vc-set-mode-line-busy-indicator Nick Roberts @ 2008-03-01 22:19 ` Glenn Morris 2008-03-01 22:26 ` vc-set-mode-line-busy-indicator Nick Roberts 0 siblings, 1 reply; 56+ messages in thread From: Glenn Morris @ 2008-03-01 22:19 UTC (permalink / raw) To: Nick Roberts; +Cc: emacs-devel Nick Roberts wrote: > > > > ! (propertize " [waiting...]" > > > > ! 'face 'font-lock-variable-name-face Sorry, but now this is installed I see it is totally invisible on my mode-line. Please can I either remove the 'face altogether or create a new face for it. I don't care which. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-01 22:19 ` vc-set-mode-line-busy-indicator Glenn Morris @ 2008-03-01 22:26 ` Nick Roberts 2008-03-01 22:53 ` vc-set-mode-line-busy-indicator Glenn Morris 0 siblings, 1 reply; 56+ messages in thread From: Nick Roberts @ 2008-03-01 22:26 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel > > > > > ! (propertize " [waiting...]" > > > > > ! 'face 'font-lock-variable-name-face > > Sorry, but now this is installed I see it is totally invisible on my > mode-line. > > Please can I either remove the 'face altogether or create a new face > for it. I don't care which. I committed it because that seemed to fit the culture being advocated. If it doesn't work for you then please do change it accordingly. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-01 22:26 ` vc-set-mode-line-busy-indicator Nick Roberts @ 2008-03-01 22:53 ` Glenn Morris 2008-03-02 17:25 ` vc-set-mode-line-busy-indicator Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Glenn Morris @ 2008-03-01 22:53 UTC (permalink / raw) To: Nick Roberts; +Cc: emacs-devel Nick Roberts wrote: > > Sorry, but now this is installed I see it is totally invisible on my > > mode-line. > > > > Please can I either remove the 'face altogether or create a new face > > for it. I don't care which. > > I committed it because that seemed to fit the culture being advocated. If it > doesn't work for you then please do change it accordingly. I don't know nothing' 'bout no culture... I should have tried it out to see how it looked. If people feel the need to emphasize certain mode-line features (and if you did a similar thing for gud, there probably is such a need), then I would say it needs a new face; because the mode-line palette is different to the buffer palette. I suggest a new `mode-line-emphasis' face. The existing `mode-line-highlight' doesn't look right because it is designed for buttons. I made up some defaults; I'm not sure about them. *** faces.el.~1.394.~ 2008-02-23 11:24:00.000000000 -0800 --- faces.el 2008-03-01 14:47:47.000000000 -0800 *************** *** 2388,2398 **** :box (:line-width 2 :color "grey40" :style released-button)) (t :inherit highlight)) ! "Basic mode line face for highlighting." :version "22.1" :group 'mode-line-faces :group 'basic-faces) (defface mode-line-buffer-id '((t (:weight bold))) "Face used for buffer identification parts of the mode line." --- 2388,2409 ---- :box (:line-width 2 :color "grey40" :style released-button)) (t :inherit highlight)) ! "Basic mode line face for highlighting (of buttons, etc)." :version "22.1" :group 'mode-line-faces :group 'basic-faces) + (defface mode-line-emphasis + '((((class color) (min-colors 88)) + :background "grey40") + (t + :inherit highlight)) + "Face used to emphasize certain mode line features. + Use the face `mode-line-highlight' for features that can be selected." + :version "23.1" + :group 'mode-line-faces + :group 'basic-faces) + (defface mode-line-buffer-id '((t (:weight bold))) "Face used for buffer identification parts of the mode line." *** vc.el.~1.545.~ 2008-03-01 11:41:50.000000000 -0800 --- vc.el 2008-03-01 14:43:10.000000000 -0800 *************** *** 1063,1072 **** (defun vc-set-mode-line-busy-indicator () (setq mode-line-process ! (propertize " [waiting...]" ! 'face 'font-lock-variable-name-face 'help-echo ! "A VC command is in progress in this buffer"))) (defun vc-exec-after (code) "Eval CODE when the current buffer's process is done. --- 1063,1072 ---- (defun vc-set-mode-line-busy-indicator () (setq mode-line-process ! (concat " " (propertize "[waiting...]" ! 'face 'mode-line-emphasis 'help-echo ! "A VC command is in progress in this buffer")))) (defun vc-exec-after (code) "Eval CODE when the current buffer's process is done. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-01 22:53 ` vc-set-mode-line-busy-indicator Glenn Morris @ 2008-03-02 17:25 ` Richard Stallman 2008-03-02 18:53 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-02 17:25 UTC (permalink / raw) To: Glenn Morris; +Cc: nickrob, emacs-devel I suggest a new `mode-line-emphasis' face. The existing `mode-line-highlight' doesn't look right because it is designed for buttons. I made up some defaults; I'm not sure about them. Does this proposal mean having two different faces for two different kinds of highlighting in the mode line? What sort of VC commands are asynchronous, other than vc-diff which shouldn't be a problem? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-02 17:25 ` vc-set-mode-line-busy-indicator Richard Stallman @ 2008-03-02 18:53 ` Dan Nicolaescu 2008-03-03 18:27 ` vc-set-mode-line-busy-indicator Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2008-03-02 18:53 UTC (permalink / raw) To: rms; +Cc: Glenn Morris, nickrob, emacs-devel Richard Stallman <rms@gnu.org> writes: > What sort of VC commands are asynchronous, other than vc-diff which > shouldn't be a problem? All non-state changing VC commands should be asynchronous. Currently vc-diff, vc-annotate, vc-log and vc-status are. Not sure what you mean above about vc-diff... vc-diff is essential to be asynchronous, computing diffs can take several minutes (see what Tom Tromey said in another thread about GCC svn). Having an indication in the mode-line that the diff is still active is very good, especially if the user has selected a large number a files for diffing. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-02 18:53 ` vc-set-mode-line-busy-indicator Dan Nicolaescu @ 2008-03-03 18:27 ` Richard Stallman 2008-03-03 18:58 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-03 18:27 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: rgm, nickrob, emacs-devel > What sort of VC commands are asynchronous, other than vc-diff which > shouldn't be a problem? All non-state changing VC commands should be asynchronous. Currently vc-diff, vc-annotate, vc-log and vc-status are. Not sure what you mean above about vc-diff... I see no need to inform people in the mode line that vc-diff is running, or that it has stopped. Likewise vc-log. vc-status must be something new; I don't know what it is. But any asynch vc command whose purpose is to display something need not put anything in the mode line. Better to work like vc-diff: make the output buffer appear, and the user will see when it is complete. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-03 18:27 ` vc-set-mode-line-busy-indicator Richard Stallman @ 2008-03-03 18:58 ` Dan Nicolaescu 2008-03-04 17:38 ` vc-set-mode-line-busy-indicator Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2008-03-03 18:58 UTC (permalink / raw) To: rms; +Cc: rgm, nickrob, emacs-devel Richard Stallman <rms@gnu.org> writes: > > What sort of VC commands are asynchronous, other than vc-diff which > > shouldn't be a problem? > > All non-state changing VC commands should be asynchronous. Currently > vc-diff, vc-annotate, vc-log and vc-status are. > > Not sure what you mean above about vc-diff... > > I see no need to inform people in the mode line that vc-diff is > running, or that it has stopped. > > Likewise vc-log. vc-status must be > something new; I don't know what it is. But any asynch vc command > whose purpose is to display something need not put anything in the > mode line. Better to work like vc-diff: make the output buffer > appear, and the user will see when it is complete. vc-diff was one of the reasons for adding the mode-line notification: the user can't see that the output is complete. vc-diff operations can take a long time. Using CVS with a busy server/slow network tends to have very non-predictable behavior, one can't see when the diff operations has finished. If the user actually wants to use the result of vc-diff, for example to email it to someone else, then he can get incomplete results. The mode-line notification is a very good way to show that the VC command is still in progress. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-03 18:58 ` vc-set-mode-line-busy-indicator Dan Nicolaescu @ 2008-03-04 17:38 ` Richard Stallman 2008-03-04 18:39 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-04 17:38 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: rgm, nickrob, emacs-devel vc-diff was one of the reasons for adding the mode-line notification: the user can't see that the output is complete. It moves point when it completes, so that you can tell. Until then, point remains at the top. If you start moving point before it completes, then maybe you can't tell, unless you move to the end. Are we talking about the mode line of that buffer only? That might be reasonable. I thought people were talking about mode lines of all buffers. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-04 17:38 ` vc-set-mode-line-busy-indicator Richard Stallman @ 2008-03-04 18:39 ` Dan Nicolaescu 2008-03-05 21:33 ` vc-set-mode-line-busy-indicator Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2008-03-04 18:39 UTC (permalink / raw) To: rms; +Cc: rgm, nickrob, emacs-devel Richard Stallman <rms@gnu.org> writes: > vc-diff was one of the reasons for adding the mode-line notification: > the user can't see that the output is complete. > > It moves point when it completes, so that you can tell. > Until then, point remains at the top. > > If you start moving point before it completes, then > maybe you can't tell, unless you move to the end. Even if you move to the end, you can't tell if the command is done > Are we talking about the mode line of that buffer only? We are talking about vc-diff, vc-annotate, vc-log buffers only. > That might be reasonable. I thought people were talking about mode > lines of all buffers. No, it's not for all buffers, just for buffers that VC uses to execute commands that can take a long time. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-04 18:39 ` vc-set-mode-line-busy-indicator Dan Nicolaescu @ 2008-03-05 21:33 ` Richard Stallman 2008-03-05 21:50 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-05 21:33 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: rgm, nickrob, emacs-devel > If you start moving point before it completes, then > maybe you can't tell, unless you move to the end. Even if you move to the end, you can't tell if the command is done Why not? Isn't there some text that appears at the end when the command is finished? If not, let's add some. > That might be reasonable. I thought people were talking about mode > lines of all buffers. No, it's not for all buffers, just for buffers that VC uses to execute commands that can take a long time. I have no objection to that, but adding text at the end when it finishes also seems like a good idea. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-05 21:33 ` vc-set-mode-line-busy-indicator Richard Stallman @ 2008-03-05 21:50 ` Dan Nicolaescu 2008-03-07 3:38 ` vc-set-mode-line-busy-indicator Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2008-03-05 21:50 UTC (permalink / raw) To: rms; +Cc: rgm, nickrob, emacs-devel Richard Stallman <rms@gnu.org> writes: > > If you start moving point before it completes, then > > maybe you can't tell, unless you move to the end. > > Even if you move to the end, you can't tell if the command is done > > Why not? Isn't there some text that appears at the end when the > command is finished? No, there isn't. > If not, let's add some. Please don't, there temporarily was some for a few months, and it was discussed at length on the list and voted out. It is annoying when you have to copy the buffer that there's extra text that is not part of the diff that you have to deal with. > > That might be reasonable. I thought people were talking about mode > > lines of all buffers. > > No, it's not for all buffers, just for buffers that VC uses to execute > commands that can take a long time. > > I have no objection to that, but adding text at the end when it finishes > also seems like a good idea. Please don't, see above. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-05 21:50 ` vc-set-mode-line-busy-indicator Dan Nicolaescu @ 2008-03-07 3:38 ` Richard Stallman 2008-03-07 3:46 ` vc-set-mode-line-busy-indicator Miles Bader 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-07 3:38 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: rgm, nickrob, emacs-devel Please don't, there temporarily was some for a few months, and it was discussed at length on the list and voted out. It is annoying when you have to copy the buffer that there's extra text that is not part of the diff that you have to deal with. Suppose it says "End of diff output". Why is it a problem if you copy that along with the diff? If you copy that, what harm does it do? It won't bother `patch'. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-07 3:38 ` vc-set-mode-line-busy-indicator Richard Stallman @ 2008-03-07 3:46 ` Miles Bader 2008-03-08 17:39 ` vc-set-mode-line-busy-indicator Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Miles Bader @ 2008-03-07 3:46 UTC (permalink / raw) To: rms; +Cc: rgm, nickrob, Dan Nicolaescu, emacs-devel Richard Stallman <rms@gnu.org> writes: > Suppose it says "End of diff output". Why is it a problem if you copy > that along with the diff? If you copy that, what harm does it do? > It won't bother `patch'. I dunno, maybe it's just a personal foible, but emacs the "diff" command used to add this sort of terminator line (haven't noticed recently) sort of terminator string, and I always found it very annoying -- it probably doesn't cause anything to _break_ but it was like an ugly little wart, and I always ended up going to extra effort to delete it when saving the output. I think the highlighted mode-line status indicators used by e.g. compile-mode (running or finished etc) now are really nice and do a great job of quickly making me aware of what's going on. I would love it if asynchronous vc commands used a similar indicator to show their status. -Miles -- "Though they may have different meanings, the cries of 'Yeeeee-haw!' and 'Allahu akbar!' are, in spirit, not actually all that different." ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: vc-set-mode-line-busy-indicator 2008-03-07 3:46 ` vc-set-mode-line-busy-indicator Miles Bader @ 2008-03-08 17:39 ` Richard Stallman 2008-03-08 18:57 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Reiner Steib 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-08 17:39 UTC (permalink / raw) To: Miles Bader; +Cc: rgm, nickrob, dann, emacs-devel I dunno, maybe it's just a personal foible, but emacs the "diff" command used to add this sort of terminator line (haven't noticed recently) sort of terminator string, and I always found it very annoying -- it probably doesn't cause anything to _break_ but it was like an ugly little wart, and I always ended up going to extra effort to delete it when saving the output. I think you're making a mountain out of a molehill. If there is no other reason for its removal, we should put it back in. I think the highlighted mode-line status indicators used by e.g. compile-mode (running or finished etc) now are really nice and do a great job of quickly making me aware of what's going on. Those canbe useful, but inserting text at the end is also useful. For instance, M-x compile does both. When it finishes, it inserts text saying "Compilation finished ...". It forces you to do yet another operation (delete the extra output) every time when copying from the diff buffer to and email message, or some other place. You don't need to delete that extra output. It doesn't cause any harm if you copy it into an email message. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) 2008-03-08 17:39 ` vc-set-mode-line-busy-indicator Richard Stallman @ 2008-03-08 18:57 ` Reiner Steib 2008-03-08 19:29 ` Diffs between %s and %s end here David Kastrup 2008-03-09 20:53 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Richard Stallman 0 siblings, 2 replies; 56+ messages in thread From: Reiner Steib @ 2008-03-08 18:57 UTC (permalink / raw) To: Richard Stallman; +Cc: rgm, nickrob, dann, emacs-devel, Miles Bader On Sat, Mar 08 2008, Richard Stallman wrote: > I dunno, maybe it's just a personal foible, but emacs the "diff" command > used to add this sort of terminator line (haven't noticed recently) sort > of terminator string, and I always found it very annoying -- it probably > doesn't cause anything to _break_ but it was like an ugly little wart, > and I always ended up going to extra effort to delete it when saving the > output. > > I think you're making a mountain out of a molehill. Before "Diffs between %s and %s end here" was removed, several people reported to be distracted or annoyed by it. See the thread on emacs-devel in January[1]. Nobody spoke up in favor of it when Glenn announced to "remove it in a week or so if no-one objects." > If there is no other reason for its removal, we should put it back > in. Please don't (at least provide an option to turn it off). When I produce a diff before committing a change, I often want to make sure the no unintended/other changes crept in. I expect to see exactly the diffs, not some disturbing additional lines. Even after seeing it several weeks (but not using diff very frequently), I still found it distracting.[1] > I think the highlighted mode-line status indicators used by > e.g. compile-mode (running or finished etc) now are really nice and do a > great job of quickly making me aware of what's going on. > > Those canbe useful, but inserting text at the end is also useful. For > instance, M-x compile does both. When it finishes, it inserts text > saying "Compilation finished ...". I almost never want to save compilation output buffers (or include it in a mail message), but I often do for diffs. Additionally, in compilation mode, it is more clear that this line is not part of the output because the bold words are in green or red: | Compilation *exited abnormally* with code ... | Compilation *finished* at ... > It forces you to do yet another operation (delete the extra output) > every time when copying from the diff buffer to and email message, or > some other place. > > You don't need to delete that extra output. It doesn't cause any harm > if you copy it into an email message. Not everyone is so familiar with the patch command to know what is ignored and what not. If even Emacs developers who are quite familiar with patch, remove the extra line, I'm sure that most "ordinary" users will do the extra work as well to be sure. Bye, Reiner. [1] "Diffs between %s and %s end here". See the thread with this subject in January. <http://thread.gmane.org/gmane.emacs.devel/84272/focus=86974> -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 18:57 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Reiner Steib @ 2008-03-08 19:29 ` David Kastrup 2008-03-08 19:35 ` Dan Nicolaescu 2008-03-08 21:33 ` Juri Linkov 2008-03-09 20:53 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Richard Stallman 1 sibling, 2 replies; 56+ messages in thread From: David Kastrup @ 2008-03-08 19:29 UTC (permalink / raw) To: Richard Stallman; +Cc: rgm, nickrob, dann, emacs-devel, Miles Bader Reiner Steib <reinersteib+gmane@imap.cc> writes: > On Sat, Mar 08 2008, Richard Stallman wrote: > >> I dunno, maybe it's just a personal foible, but emacs the "diff" command >> used to add this sort of terminator line (haven't noticed recently) sort >> of terminator string, and I always found it very annoying -- it probably >> doesn't cause anything to _break_ but it was like an ugly little wart, >> and I always ended up going to extra effort to delete it when saving the >> output. >> >> I think you're making a mountain out of a molehill. > > Before "Diffs between %s and %s end here" was removed, several people > reported to be distracted or annoyed by it. See the thread on > emacs-devel in January[1]. Nobody spoke up in favor of it when Glenn > announced to "remove it in a week or so if no-one objects." > >> If there is no other reason for its removal, we should put it back >> in. > > Please don't (at least provide an option to turn it off). > > When I produce a diff before committing a change, I often want to make > sure the no unintended/other changes crept in. I expect to see > exactly the diffs, not some disturbing additional lines. Even after > seeing it several weeks (but not using diff very frequently), I still > found it distracting.[1] Maybe we should put informational messages like that as an (evaporating) afterstring overlay on the final LF character? That way they would not be copied anywhere. >> Those canbe useful, but inserting text at the end is also useful. For >> instance, M-x compile does both. When it finishes, it inserts text >> saying "Compilation finished ...". > > I almost never want to save compilation output buffers (or include it > in a mail message), but I often do for diffs. Additionally, in > compilation mode, it is more clear that this line is not part of the > output because the bold words are in green or red: Same could be done here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 19:29 ` Diffs between %s and %s end here David Kastrup @ 2008-03-08 19:35 ` Dan Nicolaescu 2008-03-08 19:40 ` David Kastrup 2008-03-08 21:33 ` Juri Linkov 1 sibling, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2008-03-08 19:35 UTC (permalink / raw) To: David Kastrup; +Cc: rgm, nickrob, emacs-devel, Richard Stallman, Miles Bader David Kastrup <dak@gnu.org> writes: > Reiner Steib <reinersteib+gmane@imap.cc> writes: > > > On Sat, Mar 08 2008, Richard Stallman wrote: > > > >> I dunno, maybe it's just a personal foible, but emacs the "diff" command > >> used to add this sort of terminator line (haven't noticed recently) sort > >> of terminator string, and I always found it very annoying -- it probably > >> doesn't cause anything to _break_ but it was like an ugly little wart, > >> and I always ended up going to extra effort to delete it when saving the > >> output. > >> > >> I think you're making a mountain out of a molehill. > > > > Before "Diffs between %s and %s end here" was removed, several people > > reported to be distracted or annoyed by it. See the thread on > > emacs-devel in January[1]. Nobody spoke up in favor of it when Glenn > > announced to "remove it in a week or so if no-one objects." > > > >> If there is no other reason for its removal, we should put it back > >> in. > > > > Please don't (at least provide an option to turn it off). > > > > When I produce a diff before committing a change, I often want to make > > sure the no unintended/other changes crept in. I expect to see > > exactly the diffs, not some disturbing additional lines. Even after > > seeing it several weeks (but not using diff very frequently), I still > > found it distracting.[1] > > Maybe we should put informational messages like that as an (evaporating) > afterstring overlay on the final LF character? That way they would not > be copied anywhere. That sounds good, as long as M-w and insert-buffer don't copy that string. But the main question remains: is it worth doing it? We already have the mode-line notification, does adding another type provide a significant benefit for the user? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 19:35 ` Dan Nicolaescu @ 2008-03-08 19:40 ` David Kastrup 0 siblings, 0 replies; 56+ messages in thread From: David Kastrup @ 2008-03-08 19:40 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: rgm, nickrob, emacs-devel, Richard Stallman, Miles Bader Dan Nicolaescu <dann@ics.uci.edu> writes: > David Kastrup <dak@gnu.org> writes: > > > Maybe we should put informational messages like that as an > > (evaporating) afterstring overlay on the final LF character? That > > way they would not be copied anywhere. > > That sounds good, as long as M-w and insert-buffer don't copy that > string. Huh? Overlays are not a part of the buffer text. > But the main question remains: is it worth doing it? We already have > the mode-line notification, does adding another type provide a > significant benefit for the user? Its relevance is after the compilation text, so it is a natural place to look for it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 19:29 ` Diffs between %s and %s end here David Kastrup 2008-03-08 19:35 ` Dan Nicolaescu @ 2008-03-08 21:33 ` Juri Linkov 2008-03-08 21:39 ` Glenn Morris 1 sibling, 1 reply; 56+ messages in thread From: Juri Linkov @ 2008-03-08 21:33 UTC (permalink / raw) To: David Kastrup Cc: rgm, Richard Stallman, nickrob, emacs-devel, dann, Miles Bader >>> If there is no other reason for its removal, we should put it back in. >> >> Please don't (at least provide an option to turn it off). >> >> When I produce a diff before committing a change, I often want to make >> sure the no unintended/other changes crept in. I expect to see >> exactly the diffs, not some disturbing additional lines. Even after >> seeing it several weeks (but not using diff very frequently), I still >> found it distracting.[1] > > Maybe we should put informational messages like that as an (evaporating) > afterstring overlay on the final LF character? That way they would not > be copied anywhere. I think this is a good idea: this footer will be still displayed but not copied or saved. But please don't use such overlays for compilation buffers - they are not like diff output. After saving and later visiting the old compilation output it is useful to see the overall status of the compilation at the end of the saved output file. Also it is useful to see how long the full compilation took time (by subtracting times at the beginning and the end of compilation) to make estimation how long the next compilation will take time. However, nothing like this is necessary for diff output which I think should have no additional text appended in the saved file. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 21:33 ` Juri Linkov @ 2008-03-08 21:39 ` Glenn Morris 2008-03-08 21:59 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Glenn Morris @ 2008-03-08 21:39 UTC (permalink / raw) To: Juri Linkov; +Cc: Richard Stallman, nickrob, emacs-devel, dann, Miles Bader Juri Linkov wrote: >> Maybe we should put informational messages like that as an (evaporating) >> afterstring overlay on the final LF character? That way they would not >> be copied anywhere. > > I think this is a good idea: this footer will be still displayed > but not copied or saved. I don't. I object to the visual appearance of this footer in any form. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 21:39 ` Glenn Morris @ 2008-03-08 21:59 ` Juri Linkov 2008-03-08 23:41 ` Glenn Morris 2008-03-09 16:39 ` Richard Stallman 0 siblings, 2 replies; 56+ messages in thread From: Juri Linkov @ 2008-03-08 21:59 UTC (permalink / raw) To: Glenn Morris; +Cc: Richard Stallman, nickrob, emacs-devel, dann, Miles Bader >>> Maybe we should put informational messages like that as an (evaporating) >>> afterstring overlay on the final LF character? That way they would not >>> be copied anywhere. >> >> I think this is a good idea: this footer will be still displayed >> but not copied or saved. > > I don't. I object to the visual appearance of this footer in any form. My comment was for the case when displaying this footer is unavoidable (though I don't think it is), and provided it will be optional, I will immediately turn it off. Since it seems the discussion currently reached consensus that additional text is necessary only for visual indication, I have a question: isn't visual indication for the current status in the mode line is sufficient with the new face `mode-line-emphasis'? Maybe we should install a change that uses this new face to display the status, and wait for more feedback? Then what about *cvs-diff* and *Diff*? Should they use the same technique? -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 21:59 ` Juri Linkov @ 2008-03-08 23:41 ` Glenn Morris 2008-03-08 23:58 ` David Kastrup 2008-03-09 16:39 ` Richard Stallman 1 sibling, 1 reply; 56+ messages in thread From: Glenn Morris @ 2008-03-08 23:41 UTC (permalink / raw) To: Juri Linkov; +Cc: Richard Stallman, nickrob, emacs-devel, dann, Miles Bader Juri Linkov wrote: > Since it seems the discussion currently reached consensus that > additional text is necessary only for visual indication, I have > a question: isn't visual indication for the current status > in the mode line is sufficient with the new face `mode-line-emphasis'? I (have always) agree(d) with this, but I'm not sure if rms does. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 23:41 ` Glenn Morris @ 2008-03-08 23:58 ` David Kastrup 2008-03-09 0:29 ` Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: David Kastrup @ 2008-03-08 23:58 UTC (permalink / raw) To: Glenn Morris Cc: Richard Stallman, nickrob, emacs-devel, Juri Linkov, dann, Miles Bader Glenn Morris <rgm@gnu.org> writes: > Juri Linkov wrote: > >> Since it seems the discussion currently reached consensus that >> additional text is necessary only for visual indication, I have >> a question: isn't visual indication for the current status >> in the mode line is sufficient with the new face `mode-line-emphasis'? > > I (have always) agree(d) with this, but I'm not sure if rms does. For me, the bottom of the compilation output seems like a natural place to look for that kind of info. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 23:58 ` David Kastrup @ 2008-03-09 0:29 ` Dan Nicolaescu 2008-03-09 10:10 ` David Kastrup 2008-03-09 16:40 ` Richard Stallman 0 siblings, 2 replies; 56+ messages in thread From: Dan Nicolaescu @ 2008-03-09 0:29 UTC (permalink / raw) To: David Kastrup Cc: Glenn Morris, Richard Stallman, nickrob, emacs-devel, Juri Linkov, Miles Bader David Kastrup <dak@gnu.org> writes: > Glenn Morris <rgm@gnu.org> writes: > > > Juri Linkov wrote: > > > >> Since it seems the discussion currently reached consensus that > >> additional text is necessary only for visual indication, I have > >> a question: isn't visual indication for the current status > >> in the mode line is sufficient with the new face `mode-line-emphasis'? > > > > I (have always) agree(d) with this, but I'm not sure if rms does. > > For me, the bottom of the compilation output seems like a natural place > to look for that kind of info. It has never been there, adding it (like adding anything else to emacs) should require a very strong argument, given there are so many counter arguments. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 0:29 ` Dan Nicolaescu @ 2008-03-09 10:10 ` David Kastrup 2008-03-09 15:02 ` Dan Nicolaescu 2008-03-09 16:40 ` Richard Stallman 1 sibling, 1 reply; 56+ messages in thread From: David Kastrup @ 2008-03-09 10:10 UTC (permalink / raw) To: Dan Nicolaescu Cc: Glenn Morris, Richard Stallman, nickrob, emacs-devel, Juri Linkov, Miles Bader [-- Attachment #1: Type: text/plain, Size: 832 bytes --] Dan Nicolaescu <dann@ics.uci.edu> writes: > David Kastrup <dak@gnu.org> writes: > > > Glenn Morris <rgm@gnu.org> writes: > > > > > Juri Linkov wrote: > > > > > >> Since it seems the discussion currently reached consensus that > > >> additional text is necessary only for visual indication, I have > > >> a question: isn't visual indication for the current status > > >> in the mode line is sufficient with the new face `mode-line-emphasis'? > > > > > > I (have always) agree(d) with this, but I'm not sure if rms does. > > > > For me, the bottom of the compilation output seems like a natural place > > to look for that kind of info. > > It has never been there, adding it (like adding anything else to emacs) > should require a very strong argument, given there are so many counter > arguments. Huh? [-- Attachment #2: Type: text/plain, Size: 158 bytes --] -*- mode: compilation; default-directory: "/home/tmp/akt/" -*- Compilation started at Sun Mar 9 11:09:45 echo Compilation finished at Sun Mar 9 11:09:46 [-- Attachment #3: Type: text/plain, Size: 52 bytes --] -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 10:10 ` David Kastrup @ 2008-03-09 15:02 ` Dan Nicolaescu 0 siblings, 0 replies; 56+ messages in thread From: Dan Nicolaescu @ 2008-03-09 15:02 UTC (permalink / raw) To: David Kastrup Cc: Glenn Morris, Richard Stallman, nickrob, emacs-devel, Juri Linkov, Miles Bader David Kastrup <dak@gnu.org> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > David Kastrup <dak@gnu.org> writes: > > > > > Glenn Morris <rgm@gnu.org> writes: > > > > > > > Juri Linkov wrote: > > > > > > > >> Since it seems the discussion currently reached consensus that > > > >> additional text is necessary only for visual indication, I have > > > >> a question: isn't visual indication for the current status > > > >> in the mode line is sufficient with the new face `mode-line-emphasis'? > > > > > > > > I (have always) agree(d) with this, but I'm not sure if rms does. > > > > > > For me, the bottom of the compilation output seems like a natural place > > > to look for that kind of info. > > > > It has never been there, adding it (like adding anything else to emacs) > > should require a very strong argument, given there are so many counter > > arguments. > > Huh? I was talking about diff. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 0:29 ` Dan Nicolaescu 2008-03-09 10:10 ` David Kastrup @ 2008-03-09 16:40 ` Richard Stallman 1 sibling, 0 replies; 56+ messages in thread From: Richard Stallman @ 2008-03-09 16:40 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: rgm, nickrob, emacs-devel, juri, miles > For me, the bottom of the compilation output seems like a natural place > to look for that kind of info. It has never been there, adding it (like adding anything else to emacs) should require a very strong argument, given there are so many counter arguments. In another message I've explained why it is useful. In addition, it is desirable for consistency with M-x diff. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-08 21:59 ` Juri Linkov 2008-03-08 23:41 ` Glenn Morris @ 2008-03-09 16:39 ` Richard Stallman 2008-03-09 17:57 ` Juri Linkov 2008-03-09 19:07 ` Glenn Morris 1 sibling, 2 replies; 56+ messages in thread From: Richard Stallman @ 2008-03-09 16:39 UTC (permalink / raw) To: Juri Linkov; +Cc: rgm, nickrob, emacs-devel, dann, miles Since it seems the discussion currently reached consensus that additional text is necessary only for visual indication, I have a question: isn't visual indication for the current status in the mode line is sufficient with the new face `mode-line-emphasis'? I don't think so. When the process terminates, it is nice to have confirmation that it completed normally. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 16:39 ` Richard Stallman @ 2008-03-09 17:57 ` Juri Linkov 2008-03-10 6:12 ` Richard Stallman 2008-03-09 19:07 ` Glenn Morris 1 sibling, 1 reply; 56+ messages in thread From: Juri Linkov @ 2008-03-09 17:57 UTC (permalink / raw) To: rms; +Cc: rgm, nickrob, emacs-devel, dann, miles > Since it seems the discussion currently reached consensus that > additional text is necessary only for visual indication, I have > a question: isn't visual indication for the current status > in the mode line is sufficient with the new face `mode-line-emphasis'? > > I don't think so. When the process terminates, it is nice to have > confirmation that it completed normally. Then we could use the same non-intrusive solution already implemented for compile: when compilation is successful it displays the successful status in the mode line of the compilation buffer in green. When compilation fails, it displays the error code in the mode line in red. So no additional text is necessary to append to the end of the output that many find too annoying. This modeline indication should be enough for confirmation the process completed normally. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 17:57 ` Juri Linkov @ 2008-03-10 6:12 ` Richard Stallman 2008-03-11 0:20 ` David Kastrup 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-10 6:12 UTC (permalink / raw) To: Juri Linkov; +Cc: rgm, nickrob, emacs-devel, dann, miles Then we could use the same non-intrusive solution already implemented for compile: when compilation is successful it displays the successful status in the mode line of the compilation buffer in green. When compilation fails, it displays the error code in the mode line in red. Using faces that way seems like a good idea. Still, the arguments offered against inserting a "finished" message, like M-x compile and M-x diff, seem to make much ado about very little. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-10 6:12 ` Richard Stallman @ 2008-03-11 0:20 ` David Kastrup 0 siblings, 0 replies; 56+ messages in thread From: David Kastrup @ 2008-03-11 0:20 UTC (permalink / raw) To: rms; +Cc: rgm, nickrob, emacs-devel, Juri Linkov, dann, miles Richard Stallman <rms@gnu.org> writes: > Then we could use the same non-intrusive solution already implemented for > compile: when compilation is successful it displays the successful status > in the mode line of the compilation buffer in green. When compilation > fails, it displays the error code in the mode line in red. > > Using faces that way seems like a good idea. Still, the arguments > offered against inserting a "finished" message, like M-x compile > and M-x diff, seem to make much ado about very little. As long as there is reasonable agreement that a "very little" change is an improvement, I don't see anything wrong in following through. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 16:39 ` Richard Stallman 2008-03-09 17:57 ` Juri Linkov @ 2008-03-09 19:07 ` Glenn Morris 2008-03-10 3:02 ` Stefan Monnier 2008-03-10 6:11 ` Richard Stallman 1 sibling, 2 replies; 56+ messages in thread From: Glenn Morris @ 2008-03-09 19:07 UTC (permalink / raw) To: rms; +Cc: nickrob, emacs-devel, Juri Linkov, dann, miles Richard Stallman wrote: > Since it seems the discussion currently reached consensus that > additional text is necessary only for visual indication, I have > a question: isn't visual indication for the current status > in the mode line is sufficient with the new face `mode-line-emphasis'? > > I don't think so. When the process terminates, it is nice to have > confirmation that it completed normally. It's very frustrating that a discussion about creating a single new face has got sidetracked into this issue. We have already had this discussion. No-one agreed with you. Please read the references Reiner supplied. Meanwhile, vc-set-mode-line-busy-indicator continue to be totally invisible for me. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 19:07 ` Glenn Morris @ 2008-03-10 3:02 ` Stefan Monnier 2008-03-10 6:11 ` Richard Stallman 1 sibling, 0 replies; 56+ messages in thread From: Stefan Monnier @ 2008-03-10 3:02 UTC (permalink / raw) To: Glenn Morris; +Cc: rms, nickrob, emacs-devel, Juri Linkov, dann, miles >> Since it seems the discussion currently reached consensus that >> additional text is necessary only for visual indication, I have >> a question: isn't visual indication for the current status >> in the mode line is sufficient with the new face `mode-line-emphasis'? >> >> I don't think so. When the process terminates, it is nice to have >> confirmation that it completed normally. > It's very frustrating that a discussion about creating a single new > face has got sidetracked into this issue. We have already had this > discussion. No-one agreed with you. Please read the references Reiner > supplied. > Meanwhile, vc-set-mode-line-busy-indicator continue to be totally > invisible for me. Please create a mode-line-emphasis face and use it for vc-set-mode-line-busy-indicator. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 19:07 ` Glenn Morris 2008-03-10 3:02 ` Stefan Monnier @ 2008-03-10 6:11 ` Richard Stallman 2008-03-10 22:07 ` Glenn Morris 1 sibling, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-10 6:11 UTC (permalink / raw) To: Glenn Morris; +Cc: nickrob, emacs-devel, juri, dann, miles It's very frustrating that a discussion about creating a single new face has got sidetracked into this issue. We have already had this discussion. No-one agreed with you. Please read the references Reiner supplied. Due to the rather nasty tone, I do not feel inclined to carry out your demand. Especially when it involves something as inconvenient as looking at a web site. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-10 6:11 ` Richard Stallman @ 2008-03-10 22:07 ` Glenn Morris 2008-03-11 20:24 ` Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Glenn Morris @ 2008-03-10 22:07 UTC (permalink / raw) To: rms; +Cc: nickrob, emacs-devel, juri, dann, miles Richard Stallman wrote: > Due to the rather nasty tone, I do not feel inclined to carry out your > demand. You've accused me of making demands before. I'm not at all put out, but rather than letting it slide this time, let's analyse my mail: It's very frustrating A statement of how I feel about something. In hindsight, the "very" was overkill, but I guess I'm entitled to feel how I like. that a discussion about creating a single new face has got sidetracked into this issue. A statement that I think the discussion has been sidetracked. We have already had this discussion. A statement of fact. No-one agreed with you. A statement of fact. Please read the references Reiner supplied. A request framed in a normal level of politeness. I don't know how you want me to ask you things if you think this is a "demand". > Especially when it involves something as inconvenient as looking at > a web site. Reiner also supplied the name of the thread and the month it took place in. I thought this was how you normally found old mailing list discussions. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-10 22:07 ` Glenn Morris @ 2008-03-11 20:24 ` Richard Stallman 0 siblings, 0 replies; 56+ messages in thread From: Richard Stallman @ 2008-03-11 20:24 UTC (permalink / raw) To: Glenn Morris; +Cc: nickrob, emacs-devel, juri, dann, miles > Due to the rather nasty tone, I do not feel inclined to carry out your > demand. You've accused me of making demands before. I'm not at all put out, but rather than letting it slide this time, let's analyse my mail: Tone isn't found in the questions that you analyzed. For instance, a demand can be made in the words of a polite request. Perhaps you didn't mean it as nasty. Perhaps you didn't mean to say "Go read that link (and shut up)." But that's what it sounds like to me. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) 2008-03-08 18:57 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Reiner Steib 2008-03-08 19:29 ` Diffs between %s and %s end here David Kastrup @ 2008-03-09 20:53 ` Richard Stallman 2008-03-09 22:39 ` Diffs between %s and %s end here Reiner Steib 1 sibling, 1 reply; 56+ messages in thread From: Richard Stallman @ 2008-03-09 20:53 UTC (permalink / raw) To: Reiner Steib; +Cc: rgm, nickrob, dann, emacs-devel, miles When I produce a diff before committing a change, I often want to make sure the no unintended/other changes crept in. I expect to see exactly the diffs, not some disturbing additional lines. How do you check that they are exactly the same diffs? Do you use M-x compare-windows? When that comes to the end of the diffs in both buffers, the fact that one has a note saying "end of diffs" won't make it harder for you to tell that the two are identical. I almost never want to save compilation output buffers (or include it in a mail message), but I often do for diffs. I don't think that end-of-diffs message will do any harm when you save or mail the diffs. In an email there will usually be other text both above and below the diffs, in any case. Adding one line of more text below the diffs won't change the situation much. Additionally, in compilation mode, it is more clear that this line is not part of the output because the bold words are in green or red: We could put colors into the notice in the diff buffer just as we do in compilation mode. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Diffs between %s and %s end here 2008-03-09 20:53 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Richard Stallman @ 2008-03-09 22:39 ` Reiner Steib 0 siblings, 0 replies; 56+ messages in thread From: Reiner Steib @ 2008-03-09 22:39 UTC (permalink / raw) To: Richard Stallman; +Cc: rgm, nickrob, emacs-devel, Juri Linkov, dann, miles On Sun, Mar 09 2008, Richard Stallman wrote: > When I produce a diff before committing a change, I often want to make > sure the no unintended/other changes crept in. I expect to see > exactly the diffs, not some disturbing additional lines. > > How do you check that they are exactly the same diffs? > Do you use M-x compare-windows? No. Usually I just look at it. E.g. when someone sends a mail with a patch for Gnus, I apply it from the mail buffer. Then I do `C-x v =' (or `=' in PCL-CVS) and check if everything is as intended (e.g. that there are no other unrelated uncommitted changes). > When that comes to the end of the diffs in both buffers, the fact > that one has a note saying "end of diffs" won't make it harder for > you to tell that the two are identical. [...] > I don't think that end-of-diffs message will do any harm when you save > or mail the diffs. I can only repeat that even after seeing this note several time, I was still distracted. We already had such a end-of-diff note in CVS (see the subject: "Diffs between %s and %s end here") for some weeks and _nobody_ argued to keep it, but several developers were and still are strongly against it. > Additionally, in > compilation mode, it is more clear that this line is not part of the > output because the bold words are in green or red: > > We could put colors into the notice in the diff buffer just as we do > in compilation mode. I agree with Juri (and others)...; in <87k5kb7pm9.fsf@jurta.org>, Juri wrote: | Then we could use the same non-intrusive solution already implemented for | compile: when compilation is successful it displays the successful status | in the mode line of the compilation buffer in green. When compilation | fails, it displays the error code in the mode line in red. | | So no additional text is necessary to append to the end of the output that | many find too annoying. This modeline indication should be enough for | confirmation the process completed normally. Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2008-03-11 20:24 UTC | newest] Thread overview: 56+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-11-29 1:03 diff-mode misinterprets empty lines Richard Stallman 2007-11-29 9:26 ` David Kastrup 2007-11-29 16:09 ` Stefan Monnier 2007-12-05 7:35 ` Paul Eggert 2007-12-05 10:17 ` Jim Meyering 2007-12-05 10:58 ` David Kastrup 2007-12-05 11:27 ` Jim Meyering 2007-12-05 12:33 ` Andreas Schwab 2007-12-05 12:39 ` Jim Meyering 2007-12-05 14:59 ` David Kastrup 2007-12-05 17:45 ` Paul Eggert 2007-12-05 18:12 ` David Kastrup 2007-12-06 0:54 ` Paul Eggert 2007-12-06 10:11 ` Andreas Schwab 2007-12-05 21:04 ` Juanma Barranquero 2007-12-06 15:39 ` Stefan Monnier 2008-01-06 0:15 ` Glenn Morris 2008-01-06 18:09 ` Richard Stallman 2008-01-14 21:08 ` Stefan Monnier 2008-01-14 21:38 ` Glenn Morris 2008-01-14 22:46 ` Glenn Morris 2008-01-14 23:35 ` Diffs between %s and %s end here (was: diff-mode misinterprets empty lines.) Reiner Steib 2008-01-15 3:29 ` Diffs between %s and %s end here Miles Bader 2008-01-16 8:13 ` Glenn Morris 2008-01-15 0:09 ` diff-mode misinterprets empty lines Dan Nicolaescu 2008-01-29 18:37 ` Chong Yidong 2008-02-19 16:32 ` Stefan Monnier 2008-02-19 20:44 ` Stefan Monnier 2007-12-06 2:11 ` Richard Stallman 2007-12-05 17:48 ` Paul Eggert 2007-12-05 17:50 ` Jim Meyering 2007-11-29 22:31 ` Richard Stallman 2007-11-29 23:12 ` David Kastrup 2007-11-30 2:03 ` Stefan Monnier -- strict thread matches above, loose matches on Subject: below -- 2008-02-25 12:46 vc-set-mode-line-busy-indicator Nick Roberts 2008-02-25 20:25 ` vc-set-mode-line-busy-indicator Nick Roberts 2008-02-26 4:11 ` vc-set-mode-line-busy-indicator Glenn Morris 2008-02-26 7:38 ` vc-set-mode-line-busy-indicator Nick Roberts 2008-03-01 22:19 ` vc-set-mode-line-busy-indicator Glenn Morris 2008-03-01 22:26 ` vc-set-mode-line-busy-indicator Nick Roberts 2008-03-01 22:53 ` vc-set-mode-line-busy-indicator Glenn Morris 2008-03-02 17:25 ` vc-set-mode-line-busy-indicator Richard Stallman 2008-03-02 18:53 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 2008-03-03 18:27 ` vc-set-mode-line-busy-indicator Richard Stallman 2008-03-03 18:58 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 2008-03-04 17:38 ` vc-set-mode-line-busy-indicator Richard Stallman 2008-03-04 18:39 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 2008-03-05 21:33 ` vc-set-mode-line-busy-indicator Richard Stallman 2008-03-05 21:50 ` vc-set-mode-line-busy-indicator Dan Nicolaescu 2008-03-07 3:38 ` vc-set-mode-line-busy-indicator Richard Stallman 2008-03-07 3:46 ` vc-set-mode-line-busy-indicator Miles Bader 2008-03-08 17:39 ` vc-set-mode-line-busy-indicator Richard Stallman 2008-03-08 18:57 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Reiner Steib 2008-03-08 19:29 ` Diffs between %s and %s end here David Kastrup 2008-03-08 19:35 ` Dan Nicolaescu 2008-03-08 19:40 ` David Kastrup 2008-03-08 21:33 ` Juri Linkov 2008-03-08 21:39 ` Glenn Morris 2008-03-08 21:59 ` Juri Linkov 2008-03-08 23:41 ` Glenn Morris 2008-03-08 23:58 ` David Kastrup 2008-03-09 0:29 ` Dan Nicolaescu 2008-03-09 10:10 ` David Kastrup 2008-03-09 15:02 ` Dan Nicolaescu 2008-03-09 16:40 ` Richard Stallman 2008-03-09 16:39 ` Richard Stallman 2008-03-09 17:57 ` Juri Linkov 2008-03-10 6:12 ` Richard Stallman 2008-03-11 0:20 ` David Kastrup 2008-03-09 19:07 ` Glenn Morris 2008-03-10 3:02 ` Stefan Monnier 2008-03-10 6:11 ` Richard Stallman 2008-03-10 22:07 ` Glenn Morris 2008-03-11 20:24 ` Richard Stallman 2008-03-09 20:53 ` Diffs between %s and %s end here (was: vc-set-mode-line-busy-indicator) Richard Stallman 2008-03-09 22:39 ` Diffs between %s and %s end here Reiner Steib
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.