[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX-devel] Re: Cleaning functionality

From: Ralf Angeli
Subject: Re: [AUCTeX-devel] Re: Cleaning functionality
Date: Mon, 06 Feb 2006 13:01:02 +0100

* Reiner Steib (2006-02-06) writes:

> On Mon, Feb 06 2006, Ralf Angeli wrote:
>> * Reiner Steib (2006-02-05) writes:
>>> A compromise might be to use a list of regexps.
>> Hm, not a bad option.  My concerns are that you will have to write a
>> lot of "\."'s for the extension delimiters and "\'"'s for matching
>> their ends.  And if you fail to do that correctly, mismatches will
>> happen which would be rather fatal when it comes to deleting files.
> We could prepend «\.» and append «\'» automatically unless the entry
> starts with «\.» (and «-» or «_» for ConTeXt or texinfo).  It might
> sound like too much DWIM, but if it's explicitly documented and the
> user already can see examples, it should be okay.

Appending "\'" would be okay, I guess.  At least it still seems to
work if somebody had the idea to specify it herself:

ELISP> (string-match "foo\\'\\'" "foo")

I am not really fond of prepending stuff.  What if some crazy tool
used a different separator we did not think of behorehand?

>> In any case I am thinking about optionally opening a window which
>> displays the files to be deleted so that the user can check if there
>> is anything she wants to keep.
> Maybe a variable `TeX-confirm-clean' with values like nil (don't ask),
> t (ask for every file)

This would annoy the hell out of me. (c:  Do you think that anybody
would actually use this option?  In my opinion such a behavior would
only be asked for in very special situations which means it's probably
not worth the hassle implementing it.

> and 'once (ask only once for each call of
> TeX-clean; maybe combined a listing of the files) should be added.


>>> Or use `custom-split-regexp-maybe' (like in `gnus-visible-headers').
>> But this will only work for very simple regexps without grouping.
> Yes, but it would be possible to rewrite the regexp in a way that it
> works.  :-)

But then the advantage of having to write less code in a manually
crafted regexp is lost.  It's even easier to write `"foo" "bar"'
instead of `"foo\\|bar"'.  And if you as a user wanted to remove some
elements without customizing the variable this would be easier with a
list as well.  So the only advantage I see is that you don't have to
jump through the (mapconcat 'identity ...) hoop as soon as you want to
use the regexps in the code.

>> ELISP> (custom-split-regexp-maybe "\\.\\(foo\\|bar\\)")
>> ("\\.\\(foo" "bar\\)")
> Probably `custom-split-regexp-maybe' should better signal an error in
> such a case.

Well, the doc string does not make a promise to handle such a case.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]