Sam Steingold | 31 Oct 19:23 2014
Picon

vc-dir mode: marking modified files after pull

Hi,

ISTR that when I updated in CVS, the files which were modified by the
update were marked as such in the vc-dir buffer.

Is there a way to do that with git and hg?

With git the answer seems to be
$ git diff --name-status ORIG_HEAD..
(http://stackoverflow.com/questions/6535150/git-pull-change-log)

With hg it appears that the information has to be extracted before update:
$ hg status --rev .:tip
(http://stackoverflow.com/questions/3277334/what-files-will-be-changed-vs-added-when-i-do-an-hg-pull-and-hg-update)

So the information is available.
The question is, what has to be changed in vc-dir.el?

Thanks.

--

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1343
http://www.childpsy.net/ http://openvotingconsortium.org http://ffii.org
http://iris.org.il http://islamexposedonline.com http://jihadwatch.org
Save time: send elected officials to jail directly, bypassing the office.

Oleh Krehel | 31 Oct 17:15 2014
Picon

prin1-to-string noescape parameter

Hi all,

I'm trying to write some code that formats/restructures Elisp source
files (a la Paredit).  But instead of using text manipulation,
I want to read the object in, manipulate it and print it
out.

One issue that I'm facing is:

    (prin1-to-string (read "(foo.bar baz?)"))
    => "(foo\\.bar baz\\?)"

I tried to overcome this with:

    (prin1-to-string (read "(foo.bar baz?)") t)
    => "(foo.bar baz?)"

But another problem resurfaces instead:

    (prin1-to-string (read "(foo \"bar\")") t)
    => "(foo bar)"

Even worse:

     (prin1-to-string (read "(foo \";bar\")") t)
     => "(foo ;bar)"

I think a fix to the issue would be to split the `escapeflag'
parameter of the `print_object' C function into two parts. Currently a
single bool flag decides if to escape strings or not, and if to escape
(Continue reading)

Eric S. Raymond | 30 Oct 18:54 2014
Picon

The bzr revision map

It is not reflected in the review7 repository, but I have just updated the
conversion machinery to check a map of bzr revisions to committer/date
stamps into /etc on each full conversion.

This will support Emacs Lisp code (not yet written) to find a bzr
revision number around point and check out the corresponding git
revision.

This data file will be in review8.  The code is on my to-do list.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The right of the citizens to keep and bear arms has justly been considered as
the palladium of the liberties of a republic; since it offers a strong moral
check against usurpation and arbitrary power of rulers; and will generally,
even if these are successful in the first instance, enable the people to resist
and triumph over them."
        -- Supreme Court Justice Joseph Story of the John Marshall Court

Trey Jackson | 30 Oct 17:26 2014
Picon

Emacs 24.4 and advice

All,

I just downloaded Emacs 24.4 and found that the function 'ad-start-advice was no longer defined.

I looked at the NEWS - no mention of the function being deprecated.
I looked at the "documentation" (comment section in advice.el) and all references to start/stop had been removed.
I looked through the past year and a half of the devel mailing list - and the only subject line that contained advice was the request to not remove advice documentation.

I'm not reporting this as a bug, because I can just update my code to work around this, but I do think that the changes made to this package could have been handled more gracefully.


Whatever you think of people (over)using 'advice, the 'ad-start-advice and 'ad-stop-advice were a part of the tutorial and documentation in 24.3.


TJ

ps. This is my default signature, I didn't customize it for the purpose of this post.

--
Trey Jackson
bigfaceworm <at> gmail.com

"Like any truly useful program, `hello' contains a built-in mail reader."
-- GNU's Bulletin, July 1996

Eric S. Raymond | 30 Oct 17:25 2014
Picon

New review conversion of Emacs repository

Next review version of the repository conversion is here:

	git://gitorious.org/emacs-transition/review7.git

This one is current to complete to 2014-10-30 05:23:43 -0400 and includes the transition patch.
It has been repacked.

Cloning this may appear at first sight to fetch only the master branch,
but do "git branch -a" to list the other remote branches.  You can
easily create local tracking branches for those you are interested in.

The conversion machinery, including the lift script, can be cloned from

	git://gitorious.org/emacs-transition/emacs-transition.git

How you can help:

1. Examine the transition  patch (last commit) for errors and problems.

2. Use gitk or git log to spot CVS cliques consisting of uncoalesced
single-file changes and their ChangeLog entry commits; report them so
I can squash them into proper changesets. 

3. Investigate the old-branches and other-branches groups and determine
which branches, if any, should be discarded.

4. (Advanced) Identify the actual deletion points of as many of the
=-prefixed attic files as possible.  Look for the string "ATTIC
FILES" in emacs.lift and try to turn 'attic' calls into 'deattic'
calls. (I've already done this, but it's a difficult and finicky process;
I might have missed some.)

5. (Advanced) Learn the reposurgeon DSL.  Use this knowledge to audit
emacs.lift for correctness.

Barring any glitches found by people (other than me) doing these
auditing steps, the conversion procedure is pretty much ready to go.
I rerun it occasionally to catch new bzr references in the logs and
comments.  Note that a full conversion takes about ten hours of
compute time; this constraint needs to be planned around in the 
conversion-day schedule.

Phillip Lord | 30 Oct 11:22 2014
Picon
Picon

Comment conventions, adding an explicit Header.


Currently, emacs uses comments of the form ";;; Commentary;" to
effectively indicate section headers in the buffer.

However, the header of the file has no section indicator -- so, the
copyright, the ";; Author:" metadata and so on.

I was wondering how many things (if any) would break, if this were
changed. So:

;;; blah.el --- Dull file

;; This file is not part of Emacs

;; Author: Phillip Lord <phillip.lord <at> newcastle.ac.uk>

Would become:

;;; blah.el --- Dull file

;;; Header:

;; This file is not part of Emacs

;; Author: Phillip Lord <phillip.lord <at> newcastle.ac.uk>

Putting the header on the third or second line is deliberate; various
parts of emacs use the first line semantics, including  -*-
lexical-binding: t -*-.

Why do I ask?

I have written a mode which transforms an Emacs-Lisp file into an
org-mode file. So you can view (and edit) your comments in org-mode,
while maintaining a normal elisp file (i.e. it doesn't require tangling
as an org-mode babel file would). In this process ";;; Commentary:"
lines get transformed into Org mode section one headers. This works
nicely, but the lack of a ";;; Header:" line, means that the metadata
and copyright is outside of the org-mode structure. Adding a ";;;
Header:" is a simple way of circumventing this.

Phil

Artur Malabarba | 29 Oct 22:40 2014
Picon

Merging nth, aref, and elt.

On 29 Oct 2014 16:35, "Stefan Monnier" <monnier <at> iro.umontreal.ca> wrote:
> But yes, Elisp's "core" functions suffer from lots of irregularities,
> and getting rid of them would be an improvement.  E.g.: [...]
> - Merge nth, aref, and elt.

I wouldn't mind giving this a try.
I take it this should be a C function?

Nicolas Petton | 29 Oct 08:25 2014
Picon

Including some functions from dash.el in Emacs?

Hi,

When manipulating lists I often needs some basic list functions provided
by dash.el[1] and missing from builtin Elisp functions. Some are
implemented one way or another in cl-lib, some are just missing, but I
think it would be great if Elisp had them builtin, like `flatten`,
`filter` or `reduce`.

Would it make sense to include some of the dash.el functions into Emacs?
It wouldn't have to be all of them, but including some basic ones would
IMO be a big plus.

Cheers,
Nico
--

-- 
Nicolas Petton
http://nicolas-petton.fr

Alan Mackenzie | 28 Oct 23:33 2014
Picon

Referring to revisions in the git future.

Hello, Emacs.

We are switching to git, soon.

git doesn't have revision numbers.  Instead it uses cryptic identifiers,
which are not very useful in day to day conversation.  A bit like in
George Orwell's "Newspeak", where lingusists constantly removed words and
meanings so as to render certain notions literally inexpressible, we seem
to be faced with the same situation.

On this list, one quite often sees statements such as:

    "That was fixed in revision 118147, have you updated since then?"

or

    "The bug seems to have been introduced between 118230 and 118477.
    Maybe you could do a bisect to track it down.".

Is it going to be possible to express such ideas in our git world, in any
meaningful way?  If so, how?  Does git have a useable way of mapping its
cryptic revision identifiers to monotonically increasing natural numbers,
or some other useable scheme?

I have bad feelings about this.

--

-- 
Alan Mackenzie (Nuremberg, Germany).

Ulf Jasper | 28 Oct 21:36 2014
Picon

Drop toplevel XML-comments in libxml-parse-(xml|html)-region?

Hi,

parse_region from xml.c, which is called by `libxml-parse-xml-region'
and `libxml-parse-html-region', makes some effort to retain top-level
comments in xml documents.  If necessary it adds an artificial node at
the top of the parse tree.  As a consequence one has to check whether
the result contains the "top" node or not (see below for an example).
This behaviour is different from that of `xml-parse-region' (from
xml.el), which just discards the toplevel comments.

Can we make `libxml-parse-(xml|html)-region' consistent with
`xml-parse-region', i.e. can we drop the toplevel xml comments (and
simply call xmlDocGetRootElement)?

Ulf

----------------------------------------------------------------------
Example: Calling (libxml-parse-xml-region (point-min) (point-max)) on

Attachment: text/xml, 71 bytes

results in

    (top nil (foo nil "bar") (comment nil "ignore me"))

while for

Attachment: text/xml, 54 bytes

one gets

    (foo nil "bar")

without the artificial node "top".

David Reitter | 28 Oct 20:06 2014
Picon

Hang after toolbar use - easy to reproduce

Hi,

I have this hang that a bunch of users are complaining to me about.  I’m trying to diagnose this, but I’m
not sure where else to look.

It’s easy to reproduce (on a Mac, anyway):  Emacs -Q, then double-click any available icon in the toolbar. 
The bug occurs for individual clicks as well, just not as reliably for me - but the hang is a major issue for
some users, as it seems.  Emacs stops reacting to input or redrawing the screen.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18848

Any pointers would be appreciated.

D


Gmane