feature request

feature request

[Sun Yijiang]

I think if GNU Emacs can take a picture as its background, it will be
very cooooooool. I know XEmacs can do this, and something called
TransparentEmacs also. But TransparentEmacs is a branch and it seems
that under windows it's simply no way. Emacs can display pictures both
under windows and linux, so I think it's not a hard work to make
picture backgounds. I'm looking forward to it……

Re: feature request

[David Kastrup]

Sun Yijiang <sunyijiang@gmail.com> writes:

> I think if GNU Emacs can take a picture as its background, it will
> be very cooooooool.

In my opinion, there are so many usability and ergonomic issues with
Emacs that warrant work on them that it is rather unimportant to
bother with methods to make Emacs less efficient and ergonomic.

Since there is no apparent advantage except "coolness", and since
this involved catering with visibility issues and several displayed
things and X bandwidth and so on at the same time, I'd recommend just
keeping this is a branch for now.

In particular, I expect implementation of this to potentially clash
with implementing antialiased fonts in the buffer.  The latter feature
is far more important for daily work, so it would be my recommendation
to postpone even thinking about background image implementation until
we have antialiased font display, and only then check whether the
display code at _that_ time would permit background pictures.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: feature request

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> In my opinion, there are so many usability and ergonomic issues with
> Emacs that warrant work on them that it is rather unimportant to
> bother with methods to make Emacs less efficient and ergonomic.

Actually as someone who always uses one (in Emacs), I can safely state
that a well-selected background image reduces mental strain quite a bit;
I'd say this makes it `more ergonomic'.

[Going back to a standard build of Emacs is downright painful...]

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: feature request

[Kai Grossjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> David Kastrup <dak@gnu.org> writes:
>> In my opinion, there are so many usability and ergonomic issues with
>> Emacs that warrant work on them that it is rather unimportant to
>> bother with methods to make Emacs less efficient and ergonomic.
>
> Actually as someone who always uses one (in Emacs), I can safely state
> that a well-selected background image reduces mental strain quite a bit;
> I'd say this makes it `more ergonomic'.

Can you post a (URL of a) screenshot?  I wonder what that image might
look like...

Kai

Re: feature request

[Miles Bader]

On Sat, Jul 17, 2004 at 04:49:18PM +0200, Kai Grossjohann wrote:
> > Actually as someone who always uses one (in Emacs), I can safely state
> > that a well-selected background image reduces mental strain quite a bit;
> > I'd say this makes it `more ergonomic'.
> 
> Can you post a (URL of a) screenshot?  I wonder what that image might
> look like...

I can but it's not magic -- I just take some background image I like, one
that's not too wild, and reduce the brightness/contrast a bunch.  The result
is something that's not black, but sort of darkish; I find that it feels far
more "open" than a pure-color background of any color.

[BTW, what looks good seems to _strongly_ depend on your monitor -- I can't
use the same one at work and home, even when I was using a CRT in both
cases.]

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: feature request

[Miles Bader]

> Can you post a (URL of a) screenshot?  I wonder what that image might
> look like...

Try 

   http://sourcecontrol.net/~miles/emacs-screen-20040718.png

[my home monitor is rather dark, so it might look annoyingly bright for some
people.]

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: feature request

[Kai Grossjohann]

Thanks for the URL.  It is really amazing.  I can see the huge
difference the image makes.

Kai

Re: feature request

[Michael Olson]

If this change goes into the main branch, a variable to control the
shading/transparency of the background might be nice, kind of like
what GNOME Terminal does.  That way, you wouldn't need to open up the
Gimp to manually make the background darker or lighter.

On Sat, 17 Jul 2004 22:24:02 +0200, Kai Grossjohann wrote:

> Thanks for the URL.  It is really amazing.  I can see the huge
> difference the image makes.
>
> Kai

Re: feature request

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
> Try 
>
>    http://sourcecontrol.net/~miles/emacs-screen-20040718.png
>
> [my home monitor is rather dark, so it might look annoyingly bright for some
> people.]

BTW here's what I use at work, which is somewhat more subdued:

   http://sourcecontrol.net/~miles/emacs-screen-20040720.png

[warning, it's a big file...]

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Feature request

[Matzi Kratzi]

I really like ediff and almost always prefer it.

There is however one feature that I really would like it to gain (or
really would like to know how it can already be done):
One of the for-money-competitors gives the user the possibility to
help the tool by pointing to sync lines in the buffers. That way the
diff can become much better.

Is this possible already?

Kind regards
Mats

Re: Feature request

[Stefan Monnier]

> I really like ediff and almost always prefer it.
> There is however one feature that I really would like it to gain (or
> really would like to know how it can already be done):
> One of the for-money-competitors gives the user the possibility to
> help the tool by pointing to sync lines in the buffers.
> That way the diff can become much better.

> Is this possible already?

I don't think Ediff currently supports it.  It shouldn't be terribly
hard to add support for it (basically a sync line would split the region
such that the text before and the text after are passed to separate
invocations of `diff').


        Stefan

Re: Feature request

[Matzi Kratzi]

The Other SW that I tested gave the user the possibility to set
several pairs of sync lines.

/Mats

On Thu, Nov 7, 2013 at 9:05 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I really like ediff and almost always prefer it.
>> There is however one feature that I really would like it to gain (or
>> really would like to know how it can already be done):
>> One of the for-money-competitors gives the user the possibility to
>> help the tool by pointing to sync lines in the buffers.
>> That way the diff can become much better.
>
>> Is this possible already?
>
> I don't think Ediff currently supports it.  It shouldn't be terribly
> hard to add support for it (basically a sync line would split the region
> such that the text before and the text after are passed to separate
> invocations of `diff').
>
>
>         Stefan

Re: Feature request

[John Yates]

[-- Attachment #1.1: Type: text/plain, Size: 416 bytes --]

What you are describing is a poor-man's form of patience diff.  Google it
if unfamiliar.

Attached is a just slightly tweaked version I stole from bzr.  I have my
emacs ediff-compare-program set to ~/bin/pdiff.

Being a python script it potentially may be a bit slow (though I have never
had a problem).  An alternative I saw on stackoverlow would be to use git:

$ git diff --no-index --patience file1 file2

/john

[-- Attachment #1.2: Type: text/html, Size: 496 bytes --]

[-- Attachment #2: pdiff --]
[-- Type: application/octet-stream, Size: 5994 bytes --]

#!/usr/bin/env python
# Copyright (C) 2005, 2006, 2007 Canonical Ltd
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

from __future__ import absolute_import

from bzrlib.lazy_import import lazy_import
lazy_import(globals(), """
import os
import sys
import time
import difflib
""")


__all__ = ['PatienceSequenceMatcher', 'unified_diff', 'unified_diff_files']


# This is a version of unified_diff which only adds a factory parameter
# so that you can override the default SequenceMatcher
# this has been submitted as a patch to python
def unified_diff(a, b, fromfile='', tofile='', fromfiledate='',
                 tofiledate='', n=3, lineterm='\n',
                 sequencematcher=None):
    r"""
    Compare two sequences of lines; generate the delta as a unified diff.

    Unified diffs are a compact way of showing line changes and a few
    lines of context.  The number of context lines is set by 'n' which
    defaults to three.

    By default, the diff control lines (those with ---, +++, or @@) are
    created with a trailing newline.  This is helpful so that inputs
    created from file.readlines() result in diffs that are suitable for
    file.writelines() since both the inputs and outputs have trailing
    newlines.

    For inputs that do not have trailing newlines, set the lineterm
    argument to "" so that the output will be uniformly newline free.

    The unidiff format normally has a header for filenames and modification
    times.  Any or all of these may be specified using strings for
    'fromfile', 'tofile', 'fromfiledate', and 'tofiledate'.  The modification
    times are normally expressed in the format returned by time.ctime().

    Example:

    >>> for line in unified_diff('one two three four'.split(),
    ...             'zero one tree four'.split(), 'Original', 'Current',
    ...             'Sat Jan 26 23:30:50 1991', 'Fri Jun 06 10:20:52 2003',
    ...             lineterm=''):
    ...     print line
    --- Original Sat Jan 26 23:30:50 1991
    +++ Current Fri Jun 06 10:20:52 2003
    @@ -1,4 +1,4 @@
    +zero
     one
    -two
    -three
    +tree
     four
    """
    if sequencematcher is None:
        sequencematcher = difflib.SequenceMatcher

    if fromfiledate:
        fromfiledate = '\t' + str(fromfiledate)
    if tofiledate:
        tofiledate = '\t' + str(tofiledate)

    started = False
    for group in sequencematcher(None,a,b).get_grouped_opcodes(n):
        if not started:
            yield '--- %s%s%s' % (fromfile, fromfiledate, lineterm)
            yield '+++ %s%s%s' % (tofile, tofiledate, lineterm)
            started = True
        i1, i2, j1, j2 = group[0][1], group[-1][2], group[0][3], group[-1][4]
        yield "@@ -%d,%d +%d,%d @@%s" % (i1+1, i2-i1, j1+1, j2-j1, lineterm)
        for tag, i1, i2, j1, j2 in group:
            if tag == 'equal':
                for line in a[i1:i2]:
                    yield ' ' + line
                continue
            if tag == 'replace' or tag == 'delete':
                for line in a[i1:i2]:
                    yield '-' + line
            if tag == 'replace' or tag == 'insert':
                for line in b[j1:j2]:
                    yield '+' + line


def unified_diff_files(a, b, sequencematcher=None):
    """Generate the diff for two files.
    """
    # Should this actually be an error?
    if a == b:
        return []
    if a == '-':
        file_a = sys.stdin
        time_a = time.time()
    else:
        file_a = open(a, 'rb')
        time_a = os.stat(a).st_mtime

    if b == '-':
        file_b = sys.stdin
        time_b = time.time()
    else:
        file_b = open(b, 'rb')
        time_b = os.stat(b).st_mtime

    # TODO: Include fromfiledate and tofiledate
    return unified_diff(file_a.readlines(), file_b.readlines(),
                        fromfile=a, tofile=b,
                        sequencematcher=sequencematcher)


try:
    from bzrlib._patiencediff_c import (
        unique_lcs_c as unique_lcs,
        recurse_matches_c as recurse_matches,
        PatienceSequenceMatcher_c as PatienceSequenceMatcher
        )
except ImportError:
    from bzrlib._patiencediff_py import (
        unique_lcs_py as unique_lcs,
        recurse_matches_py as recurse_matches,
        PatienceSequenceMatcher_py as PatienceSequenceMatcher
        )


def main(args):
    import optparse
    p = optparse.OptionParser(usage='%prog [options] file_a file_b'
                                    '\nFiles can be "-" to read from stdin')
    # p.add_option('--patience', dest='matcher', action='store_const', const='patience',
    #              default='patience', help='Use the patience difference algorithm')
    # p.add_option('--difflib', dest='matcher', action='store_const', const='difflib',
    #              default='patience', help='Use python\'s difflib algorithm')

    # algorithms = {'patience':PatienceSequenceMatcher, 'difflib':difflib.SequenceMatcher}

    (opts, args) = p.parse_args(args)
    # matcher = algorithms[opts.matcher]

    if len(args) != 2:
        print 'You must supply 2 filenames to diff'
        return -1

    status = 0
    for line in unified_diff_files(args[0], args[1], sequencematcher=PatienceSequenceMatcher):
        status = 1
        sys.stdout.write(line)

    return status


if __name__ == '__main__':
    sys.exit(main(sys.argv[1:]))

Re: Feature request

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 1654 bytes --]