unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#15303: 24.3; [diff-mode] diff-hunk-kill doesn't update numbers in subsequent hunks
@ 2013-09-07 20:01 Matěj Cepl
  2013-09-09 18:18 ` Stefan Monnier
  0 siblings, 1 reply; 5+ messages in thread
From: Matěj Cepl @ 2013-09-07 20:01 UTC (permalink / raw)
  To: 15303

1) Start Emacs
2) Open a patch file, it will open in a diff-mode
3) kill a hunk (Alt-K)

Example:

Let's have a patch with two subsequent hunks:

 curves = [
@@ -108,6 +117,9 @@ Hunk #2, a/tests/test_ec_curves.py curves = [
 #    ('ipsec4', 185),
 #]
 
+
+@unittest.skipUnless(EC_Module_Available,
+                     'Requires EC modules compiled into OpenSSL')
 class ECCurveTests(unittest.TestCase):
     #data = sha.sha('Kilroy was here!').digest()     # 160 bits
     data = "digest"     # keep short (48 bits) so lesser curves 
@@ -153,7 +165,8 @@ Hunk #3, a/tests/test_ec_curves.py def suite():
 
[end of example] 

When I am on line with @unittest.skipUnless and press Alt-K the result
is:

 curves = [
@@ -153,7 +165,8 @@ Hunk #3, a/tests/test_ec_curves.py def suite():

[end of example] 

That's actually wrong. The original hunk added three lines to the new
file, so when it is killed, the new line number in the hunk header
should be decreased by three, so the line should be

@@ -153,7 +162,8 @@

Best,

Matěj Cepl


In GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2)
 of 2013-07-22 on x86-019.build.eng.bos.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.11402000
System Description:	Red Hat Enterprise Linux Workstation release 7.0 Beta (Maipo)

Configured using:
 `configure '--build=x86_64-redhat-linux-gnu'
 '--host=x86_64-redhat-linux-gnu' '--program-prefix='
 '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
 '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
 '--datadir=/usr/share' '--includedir=/usr/include'
 '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
 '--localstatedir=/var' '--sharedstatedir=/var/lib'
 '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
 '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
 '--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
 'build_alias=x86_64-redhat-linux-gnu'
 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
 --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
 'LDFLAGS=-Wl,-z,relro ''

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Diff

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x 5 2 <switch-frame> <help-echo> M-x <up> r e p o 
r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading vc-git...done
user-error: Beginning of history; no preceding item

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils vc-git diff-mode easymenu easy-mmode time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)





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

* bug#15303: 24.3; [diff-mode] diff-hunk-kill doesn't update numbers in subsequent hunks
  2013-09-07 20:01 bug#15303: 24.3; [diff-mode] diff-hunk-kill doesn't update numbers in subsequent hunks Matěj Cepl
@ 2013-09-09 18:18 ` Stefan Monnier
  2013-09-09 18:26   ` Matěj Cepl
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2013-09-09 18:18 UTC (permalink / raw)
  To: Matěj Cepl; +Cc: 15303

> That's actually wrong.  The original hunk added three lines to the new
> file, so when it is killed, the new line number in the hunk header
> should be decreased by three, so the line should be

Indeed, currently, diff-mode does not try very hard (if at all) to keep
the line numbers correct, and instead presumes that the hunks will be
applied "fuzzily".

I might accept a patch which fixes this issue, but doing it right
(e.g. handle all the different kinds of hunks we support, disregard
subsequent hunks that apply to other files, ...) might prove too complex
for the benefit.

The problem also is that this presumes a particular use case (you get
a diff for file FOO, then you remove some of the hunks to extract
a sub-diff that will apply to the same file).

But there are other uses cases where the current behavior is "right".
E.g. I mainly use M-k in .rej files after I applied the corresponding
hunk by hand, in which case the subsequent hunks shouldn't be updated.
Admittedly, for a .rej file, the exact line numbers are often not quite
right, so it wouldn't make things worse to update subsequent hunks.


        Stefan





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

* bug#15303: 24.3; [diff-mode] diff-hunk-kill doesn't update numbers in subsequent hunks
  2013-09-09 18:18 ` Stefan Monnier
@ 2013-09-09 18:26   ` Matěj Cepl
  2013-09-09 23:08     ` Stefan Monnier
  0 siblings, 1 reply; 5+ messages in thread
From: Matěj Cepl @ 2013-09-09 18:26 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15303

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On 09/09/2013 08:18 PM, Stefan Monnier wrote:
> I might accept a patch which fixes this issue, but doing it right
> (e.g. handle all the different kinds of hunks we support, disregard
> subsequent hunks that apply to other files, ...) might prove too complex
> for the benefit.

I am afraid, I have no clue about Lisp at all (SICP is still lying on my
bed table, but I am afraid it is used mostly as sleeping pills ;)). I
have come to this problem while writing my own module for vim
(http://gitorious.org/vim-diff_navigator/).

> The problem also is that this presumes a particular use case (you get
> a diff for file FOO, then you remove some of the hunks to extract
> a sub-diff that will apply to the same file).

While working with Fedora (and RHEL) packages I work a lot with patches,
and it is often much more easy to actually edit patches (which are of
course correct ones) than to apply all patches and regenerate patches.
And quilt doesn't help everytime completely.

And of course, we have --fuzz=0 everywhere in Fedora (and RHEL).

So, yes, I understand where you are coming from, but I have a bit
different use case.

> But there are other uses cases where the current behavior is "right".
> E.g. I mainly use M-k in .rej files after I applied the corresponding
> hunk by hand, in which case the subsequent hunks shouldn't be updated.
> Admittedly, for a .rej file, the exact line numbers are often not quite
> right, so it wouldn't make things worse to update subsequent hunks.

OTOH, my script in the worst case doesn't make things worse.

Best,

Matěj
-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Our lives are spectacles of powerlessness.
    -- Richard Rohr


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

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

* bug#15303: 24.3; [diff-mode] diff-hunk-kill doesn't update numbers in subsequent hunks
  2013-09-09 18:26   ` Matěj Cepl
@ 2013-09-09 23:08     ` Stefan Monnier
  2013-09-09 23:11       ` Matěj Cepl
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2013-09-09 23:08 UTC (permalink / raw)
  To: Matěj Cepl; +Cc: 15303

severity 15303 wishlist
thanks

> I am afraid, I have no clue about Lisp at all (SICP is still lying on my
> bed table, but I am afraid it is used mostly as sleeping pills ;)).
> I have come to this problem while writing my own module for vim
> (http://gitorious.org/vim-diff_navigator/).

Sounds like the perfect opportunity to get up to speed on Lisp.

> While working with Fedora (and RHEL) packages I work a lot with patches,
> and it is often much more easy to actually edit patches (which are of
> course correct ones) than to apply all patches and regenerate patches.
> And quilt doesn't help everytime completely.
> And of course, we have --fuzz=0 everywhere in Fedora (and RHEL).
> So, yes, I understand where you are coming from, but I have a bit
> different use case.

I agree it would be generally good to update the numbers like you
request, but it's not a high-enough priority.


        Stefan





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

* bug#15303: 24.3; [diff-mode] diff-hunk-kill doesn't update numbers in subsequent hunks
  2013-09-09 23:08     ` Stefan Monnier
@ 2013-09-09 23:11       ` Matěj Cepl
  0 siblings, 0 replies; 5+ messages in thread
From: Matěj Cepl @ 2013-09-09 23:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15303

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

On 09/10/2013 01:08 AM, Stefan Monnier wrote:
> Sounds like the perfect opportunity to get up to speed on Lisp.

I was nice and I haven't said my thoughts about Emacs and Lisp, right? ;)

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

God is not worried about my financial situation.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

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

end of thread, other threads:[~2013-09-09 23:11 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-07 20:01 bug#15303: 24.3; [diff-mode] diff-hunk-kill doesn't update numbers in subsequent hunks Matěj Cepl
2013-09-09 18:18 ` Stefan Monnier
2013-09-09 18:26   ` Matěj Cepl
2013-09-09 23:08     ` Stefan Monnier
2013-09-09 23:11       ` Matěj Cepl

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).