regexp NOT matching an extension

regexp NOT matching an extension

[Leo]

hi there

in dired-omit-files i need a regexp matching all files without the extension
'.pem'.

i tried
    [^.][^p][^e][^m]$
but it doesn't work. however a one-char-negation like
    [^m]$
works.

any idea?

thanks, leo

Re: regexp NOT matching an extension

[Oliver Scholz]

"Leo" <leo.broska@NOSPAM.isys.com.au> writes:

> hi there
>
> in dired-omit-files i need a regexp matching all files without the extension
> '.pem'.
>
> i tried
>     [^.][^p][^e][^m]$
> but it doesn't work. however a one-char-negation like
>     [^m]$
> works.
>
> any idea?
>
> thanks, leo

"\\(?:[^.]...\\|\\.[^p]..\\|\\.p[^e].\\|\\.pe[^m]\\)$"


[as an aside note to a recent related thread: I think this is still
not what Perl users would expect according to
<84isogutgt.fsf@slowfox.is.informatik.uni-duisburg.de>, since it
simply matches any four character sequence not identical to
".pem". However, I start to wonder whether x\\(!:top\\)y is actually
still a _regular_ and not rather a _context free_ expression.]

    Oliver
-- 
30 Fructidor an 211 de la Révolution
Liberté, Egalité, Fraternité!

rendering a string as a new line?

[Janusz S. Bień]

I will have to work systematically with Unicode files which happen to
use some strange tags to represent new line. Is there a way to render
the tags as newlines without explicitly adding the new line
characters?

A solution requiring a CVS version of Emacs is also OK for me.

Best regards

Janusz

-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl
http://www.mimuw.edu.pl/~jsbien/

Re: regexp NOT matching an extension

[Gareth Rees]

Leo wrote:
> In dired-omit-files I need a regexp matching all files without the
> extension '.pem'.

You need this regexp:

    [^m]$\|[^e]m$\|[^p]em$\|[^.]pem$

Your regexp [^m]$ appears to work because it's the first alternative
that catches most of the files you want to exclude: only files ending in
'm' go on to be considered by the other three cases.

-- 
Gareth Rees

Re: rendering a string as a new line?

[Stefan Monnier]

> I will have to work systematically with Unicode files which happen to
> use some strange tags to represent new line. Is there a way to render
> the tags as newlines without explicitly adding the new line
> characters?

You can put a string "\n" as a `display' property on those tags.

You might also be able to get your way using `compose-region'
... ah no, you'd get the 10th glyph of your ascii font (which might
display some kind of LF).

As for how to put that `display' property, well you could use font-lock.

But all in all, I'd say it's probably better to write up a coding-system
that maps those tags to/from \n.  Ask a coding-system guru how to do that.


        Stefan

Re: rendering a string as a new line?

[Janusz S. Bień]

On Tue, 16 Sep 2003  "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:


[...]

> As for how to put that `display' property, well you could use font-lock.
> 
> But all in all, I'd say it's probably better to write up a coding-system
> that maps those tags to/from \n.  Ask a coding-system guru how to do that.

Thanks for the hints.

The coding-system approach seems too difficult for me, I will try
font-lock first.

Best regards

Janusz

-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl
http://www.mimuw.edu.pl/~jsbien/

Re: rendering a string as a new line?

[Janusz S. Bień]

On Tue, 16 Sep 2003  Kevin Rodgers <ihs_4664@yahoo.com> wrote:

> If the tag is more than 1 character (e.g. an XML tag),

That's the case.

> you could put an overlay on it that specifies
> a before-string or after-string property with a newline.

Thanks.

I guess it is what Stefan actually had in mind:

On Tue, 16 Sep 2003  "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:

[...]

> You can put a string "\n" as a `display' property on those tags.

as, if I understand the documentation correctly, "\n" is not a legal
value for `display' property.

Regards

Janusz

-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl
http://www.mimuw.edu.pl/~jsbien/

Re: rendering a string as a new line?

[David Kastrup]

jsbien@mimuw.edu.pl (Janusz S. Bień) writes:

> On Tue, 16 Sep 2003  Kevin Rodgers <ihs_4664@yahoo.com> wrote:
> 
> > If the tag is more than 1 character (e.g. an XML tag),
> 
> That's the case.
> 
> > you could put an overlay on it that specifies
> > a before-string or after-string property with a newline.
> 
> Thanks.
> 
> I guess it is what Stefan actually had in mind:
> 
> On Tue, 16 Sep 2003  "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
> 
> [...]
> 
> > You can put a string "\n" as a `display' property on those tags.
> 
> as, if I understand the documentation correctly, "\n" is not a legal
> value for `display' property.

I don't know what the documentation has to say about that, but it
_is_ a valid display property according to my experience.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: rendering a string as a new line?

[Oliver Scholz]

jsbien@mimuw.edu.pl (Janusz S. Bień) writes:

> On Tue, 16 Sep 2003  Kevin Rodgers <ihs_4664@yahoo.com> wrote:
>
>> If the tag is more than 1 character (e.g. an XML tag),
>
> That's the case.

That would probably rule out a coding system as a more efficient
alternative to font-lock. But you might want to consider using either
format.el or `after-insert-file-functions' and
`write-region-annotate-functions', instead.

[...]
> On Tue, 16 Sep 2003  "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
>
> [...]
>
>> You can put a string "\n" as a `display' property on those tags.
>
> as, if I understand the documentation correctly, "\n" is not a legal
> value for `display' property.
[...]

It is not documented (so one could indeed argue, that it is not
legal), but it is valid.  

Both valid and documented is '((margin nil) "\n").

    Oliver
-- 
Jour du Génie de l'Année 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: rendering a string as a new line?

[Kevin Rodgers]

Oliver Scholz wrote:

> jsbien@mimuw.edu.pl (Janusz S. Bień) writes:
>>On Tue, 16 Sep 2003  "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
>>>You can put a string "\n" as a `display' property on those tags.
>>>
>>as, if I understand the documentation correctly, "\n" is not a legal
>>value for `display' property.
>>
> [...]
> 
> It is not documented (so one could indeed argue, that it is not
> legal), but it is valid.  
> 
> Both valid and documented is '((margin nil) "\n").

The "Other Display Specs" node of the Emacs Lisp manual says:

| `((margin nil) STRING)'
| `STRING'
|      A display specification of this form means to display STRING
|      instead of the text that has the display specification, at the same
|      position as that text.  This is a special case of marginal display
|      (*note Display Margins::).

Note the simple STRING alternative.

-- 
Kevin Rodgers

Re: rendering a string as a new line?

[Oliver Scholz]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Oliver Scholz wrote:
[...]
>> It is not documented 
[...]

> The "Other Display Specs" node of the Emacs Lisp manual says:
>
> | `((margin nil) STRING)'
> | `STRING'
[...]
>
> Note the simple STRING alternative.
[...]

Thanks for the correction.  Obviously I have always overlooked the
second line.


    Oliver
-- 
Jour du Génie de l'Année 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: rendering a string as a new line?

[Janusz S. Bień]

On Thu, 18 Sep 2003  Kevin Rodgers <ihs_4664@yahoo.com> wrote:


[...]

> The "Other Display Specs" node of the Emacs Lisp manual says:
> 
> | `((margin nil) STRING)'
> | `STRING'
> |      A display specification of this form means to display STRING
> |      instead of the text that has the display specification, at the same
> |      position as that text.  This is a special case of marginal display
> |      (*note Display Margins::).
> 
> Note the simple STRING alternative.

I've missed this because I've been confused by the statement

        This is a special case of marginal display

and judged the passage as irrelevant.

To say the truth, I still don't understand it. :-(


On Fri, 19 Sep 2003  Oliver Scholz <alkibiades@gmx.de> wrote:


[...]

> This is all very hypothetical. Now I am curious how those tags
> actually look like and what the file format in question is.

The file format is a proprietary format of a little known KOMBI
typesetting system (http://www.3n.com.pl/kombi6.htm) which happens to
be used for the dictionary of 16th century Polish. The system
historically is a WYSIWYG one, but moves gradually toward a markup
system. I am investigating whether useful information about the entry
contents and structures can be extracted from the dictionary files in
this format.

When asking a question, I made an oversimplification. Actually there
is no new line tag at all, the new line is just implied by some
SGML-like tags. For example, the tag used to change the content of the
running head implies the end of the current entry and the beginning of
a new one, so one or even several new lines should be displayed.

Thanks to all of you for your interest and help.

Regards

Janusz

-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW
Prof. Janusz S. Bien, Warsaw Uniwersity
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl
http://www.mimuw.edu.pl/~jsbien/

Re: rendering a string as a new line?

[Stefan Monnier]

>>> If the tag is more than 1 character (e.g. an XML tag),
>> That's the case.
> That would probably rule out a coding system as a more efficient
> alternative to font-lock.

What makes you think so ?


        Stefan

Re: rendering a string as a new line?

[Oliver Scholz]

"Stefan Monnier" <monnier@iro.umontreal.ca> writes:

>>>> If the tag is more than 1 character (e.g. an XML tag),

>>> That's the case.

>> That would probably rule out a coding system as a more efficient
>> alternative to font-lock.
>
> What makes you think so ?
[...]

It's more or less a guess. It depends on the actual tag. If it is
indeed an XML tag among other XML tags, then it could be hairy to
write a CCL program. I believe that you could always--as a last
resort--implement a state machine to decode arbitrary tags, using the
`branch' statement from CCL, but it would still be hairy. As I said,
depending on the actual tag.

Hmmm, for example if the newline-tag is <p/>:

(define-ccl-program egoge-test
  '(1 ((r0 = 0)
	(loop 
	 (read r1)
	 (branch r0
		 (if (r1 == ?<)
		     (r0 = 1)
		   (write r1))
		 (if (r1 == ?p)
		     (r0 = 2)
		   ((write ?<)
		    (write r1)
		    (r0 = 0)))
		 (if (r1 == ?/)
		     (r0 = 3)
		   ((write ?<)
		    (write ?p)
		    (write r1)
		    (r0 = 0)))
		 (if (r1 == ?>)
		     ((r0 = 0)
		      (write ?\n))
		   ((write ?<)
		    (write ?p)
		    (write ?/)
		    (write r1)
		    (r0 = 0))))
	 (repeat)))))

;; Testing
(let ((str "<other-tag>lirum</other-tag><p/>larum")
      (vect (make-vector 9 nil)))
  (ccl-execute-on-string 'egoge-test vect str))


The question is, where you draw the line between character encoding
and formatting markup. If those “tags” are rather formatting markup,
then I think it is better to use the functionality already provided by
Emacs for this purpose: either `after-insert-file-functions' and
`write-file-functions' respectively or the functionality provided by
format.el. This has also the benefit that you could put a text
property on the converted newlines to distinguish them from regular
newlines (if there are any) so that there is no ambiguity, when
encoding the buffer again.

This is all very hypothetical. Now I am curious how those tags
actually look like and what the file format in question is.

    Oliver
-- 
Jour du Génie de l'Année 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: rendering a string as a new line?

[Stefan Monnier]

> It's more or less a guess. It depends on the actual tag. If it is
> indeed an XML tag among other XML tags, then it could be hairy to
> write a CCL program. I believe that you could always--as a last
> resort--implement a state machine to decode arbitrary tags, using the
> `branch' statement from CCL, but it would still be hairy. As I said,
> depending on the actual tag.

You can always use post-conversion functions to use regexps.

> This is all very hypothetical. Now I am curious how those tags
> actually look like and what the file format in question is.

Given what he said, I'd say that a few good font-lock patterns
adding a display property should do the trick.


        Stefan

Re: rendering a string as a new line?

[Oliver Scholz]

"Stefan Monnier" <monnier@iro.umontreal.ca> writes:

>> It's more or less a guess. It depends on the actual tag. If it is
>> indeed an XML tag among other XML tags, then it could be hairy to
>> write a CCL program. I believe that you could always--as a last
>> resort--implement a state machine to decode arbitrary tags, using the
>> `branch' statement from CCL, but it would still be hairy. As I said,
>> depending on the actual tag.
>
> You can always use post-conversion functions to use regexps.

Sure, but then why bother to use a coding-system at all?

>> This is all very hypothetical. Now I am curious how those tags
>> actually look like and what the file format in question is.
>
> Given what he said, I'd say that a few good font-lock patterns
> adding a display property should do the trick.
[...]

I agree.

    Oliver
-- 
Jour de la Raison de l'Année 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: rendering a string as a new line?

[Kevin Rodgers]

Janusz S. Bien' wrote:

> I will have to work systematically with Unicode files which happen to
> use some strange tags to represent new line. Is there a way to render
> the tags as newlines without explicitly adding the new line
> characters?

If the tag is a single character, you could set up a display table that

has a newline in that character's glyph.  If the tag is more than 1
character (e.g. an XML tag), you could put an overlay on it that specifies
a before-string or after-string property with a newline.

-- 
Kevin Rodgers