unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* A true challenge for Emac and Elisp hackers - at Least I think so
@ 2005-10-12 11:48 Sune
  2005-10-12 12:49 ` Gian Uberto Lauri
                   ` (5 more replies)
  0 siblings, 6 replies; 17+ messages in thread
From: Sune @ 2005-10-12 11:48 UTC (permalink / raw)


Hi all!

After having had dozens of null pointer exceptions thrown at me, I
decided to give up on the much hyped Eclipse CDT 3.0 and switch to
Emacs. Emacs seems to be configurable down to its atoms and I don't
have to wait for the screen to update while I type (which is eh...
nice). Basically, Emacs makes me more productive.

After starting to write some C-programs I quickly realized what I
wanted Emacs to do for me and added Elisp code into .emacs until I was
closed to being satisfied.

This is how far I've come:

Editor
- GNU coding guidelines enforced
- keyboard shortcuts to almost anything including features listed below
- nice functions like untabify-and-reindent, kill buffer of choice,
keyboard macros
etc etc

CVS
- Integrated in menu system to a satisfactory level + keyboard
shortcuts

Make
- Completely intergrated in menu system + keyboard shortcuts +
integrated with error look up in files
etc etc

But now the shit hits the fan! I want the following, but I have no clue
as to how I should even start:

The whole idea is this: I want to add debug trace with as little effort
as possible into my source.

1)
What is listed below is valid for all .c files. Not .h files!
2)
I want RET, the enter key, to trig the following behaviour:

   * If I hit RET with any shift-key being pressed
     simultaneously, RET must behave as any
     normal RET would (basically a normal
     linefeed with possible auto-indentation).
     This may seem backward but I want almost
     every line in my sorce to be traceable.

   * If I hit RET only, and the following applies:

       - It is preceeded by a ';' (semicolon) AND the
         word 'return' is not part of the current
         line or:

       - It is preceeded by a '{' (curly bracket)

     RET adds DBG after the ';' or the '{' with a
     space in between like so:

     ; DBG
     { DBG

     respectively. After that (the same key stroke)
     , RET behaves like a normal RET would (basically
     a normal linefeed with possible auto-indentation).

I have to admit that this is so far out there (at least for me) that I
would need more or less a ready-to-go implementation just to paste into
.emacs.

Do you know a place where something similar has been done which I can
steal and adapt, or are you interested in implementing it? (A place on
my tomb stone is reserved for anyone that succeeds in doing this)

Otherwise I will go back to crap Eclipse, wait for it to stabilize and
implement a plugin - that stuff I know. I just don't want to give up on
Emacs!!

Truckloads of thanks
/Sune

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

* A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 11:48 A true challenge for Emac and Elisp hackers - at Least I think so Sune
@ 2005-10-12 12:49 ` Gian Uberto Lauri
  2005-10-12 13:16 ` Slawomir Nowaczyk
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 17+ messages in thread
From: Gian Uberto Lauri @ 2005-10-12 12:49 UTC (permalink / raw)
  Cc: help-gnu-emacs

>>>>> "S" == Sune  <sune_ahlgren@hotmail.com> writes:

S>    * If I hit RET with any shift-key being pressed simultaneously,
S> RET must behave as any normal RET would (basically a normal
S> linefeed with possible auto-indentation).  This may seem backward
S> but I want almost every line in my sorce to be traceable.

S>    * If I hit RET only, and the following applies:

S>        - It is preceeded by a ';' (semicolon) AND the word 'return'
S> is not part of the current line or:

S>        - It is preceeded by a '{' (curly bracket)

S>      RET adds DBG after the ';' or the '{' with a space in between
S> like so:

S>      ; DBG { DBG


S>      respectively. After that (the same key stroke) , RET behaves
S> like a normal RET would (basically a normal linefeed with possible
S> auto-indentation).

S> I have to admit that this is so far out there (at least for me)
S> that I would need more or less a ready-to-go implementation just to
S> paste into .emacs.

Does this help ?

(defun unusual-return ()
  (interactive)
  (save-excursion)
  (let ((here (point))
	(previous-char (char-before)))
    (beginning-of-line)
    (cond ((string-match "DGB[ \\t]*$"
			 (buffer-substring (point) here))
	   (goto-char here)
	   (newline-and-indent))
	  ((or (char-equal previous-char ?{)
	       (char-equal previous-char ?\;))
	   (goto-char here)
	   (insert " DBG"))
	  (t
	   (goto-char here)
	   (newline-and-indent)))))

You  then add  an  hook to  c-mode  a little  function  that does  the
following:

    tests that the buffer name does  end by .c 

    locally sets RET to the function above (or a better one, this is a
    5 minutes game result)

    locally sets S-RET, C-RET and M-RET to newline-and-indent

-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 11:48 A true challenge for Emac and Elisp hackers - at Least I think so Sune
  2005-10-12 12:49 ` Gian Uberto Lauri
@ 2005-10-12 13:16 ` Slawomir Nowaczyk
       [not found] ` <mailman.11019.1129123023.20277.help-gnu-emacs@gnu.org>
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 17+ messages in thread
From: Slawomir Nowaczyk @ 2005-10-12 13:16 UTC (permalink / raw)


On Wed, 12 Oct 2005 04:48:25 -0700
Sune <sune_ahlgren@hotmail.com> wrote:

#> I have to admit that this is so far out there (at least for me) that I
#> would need more or less a ready-to-go implementation just to paste into
#> .emacs.

I don't think this is too far away for you :) Anyway, I somehow expect
somebody on this list to provide a more-or-less complete solution, but
the thing you should ultimately do is:

1) Learn basics of Lisp (and really, all you need here is the basics)

2) Write a function which does what you want and bind it to RET key
      *) the function should check if buffer name ends with *.c
      *) the function should get current line contents (think of
         functions buffer-substring, point, beginning-of-line, etc.)
      *) compare it with what do you want (string-match maybe?)
      *) either insert "\n" or "; DBG\n"

   And also, try "C-h i C-s elisp RET" :)

3) And that's it :)

No, seriously, after you are done with the above come back with your
solution and somebody will certainly provide you with a lot of
hints... but you will at least understand what is going on :)

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

I'd love to change the world, but they won't give me the source code!

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
       [not found] ` <mailman.11019.1129123023.20277.help-gnu-emacs@gnu.org>
@ 2005-10-12 13:29   ` Matthieu Moy
  2005-10-12 14:04     ` Slawomir Nowaczyk
       [not found]     ` <mailman.11022.1129125880.20277.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 17+ messages in thread
From: Matthieu Moy @ 2005-10-12 13:29 UTC (permalink / raw)


Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:

> 2) Write a function which does what you want and bind it to RET key
>       *) the function should check if buffer name ends with *.c

Better: bind this function only in c-mode and c++-mode. No test needed
in the command itself.

  C-h v c++-mode-map RET
  C-h v c-mode-map RET

>       *) the function should get current line contents (think of
>          functions buffer-substring, point, beginning-of-line, etc.)

and C-h f looking-at RET. You don't even need to get it in a string.

(if (save-excursion
      (beginning-of-line)
      (looking-at ".*return;")) ; adapt ...
  ...
...)

>       *) compare it with what do you want (string-match maybe?)
>       *) either insert "\n" or "; DBG\n"
>
>    And also, try "C-h i C-s elisp RET" :)

C-h i m eli TAB RET ;-).

-- 
Matthieu

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 11:48 A true challenge for Emac and Elisp hackers - at Least I think so Sune
                   ` (2 preceding siblings ...)
       [not found] ` <mailman.11019.1129123023.20277.help-gnu-emacs@gnu.org>
@ 2005-10-12 13:48 ` Pascal Bourguignon
  2005-10-12 15:36 ` Drew Adams
  2005-10-12 23:28 ` Thien-Thi Nguyen
  5 siblings, 0 replies; 17+ messages in thread
From: Pascal Bourguignon @ 2005-10-12 13:48 UTC (permalink / raw)


"Sune" <sune_ahlgren@hotmail.com> writes:
> 1)
> What is listed below is valid for all .c files. Not .h files!
> 2)
> I want RET, the enter key, to trig the following behaviour:
>
>    * If I hit RET with any shift-key being pressed
>      simultaneously, RET must behave as any
>      normal RET would (basically a normal
>      linefeed with possible auto-indentation).
>      This may seem backward but I want almost
>      every line in my sorce to be traceable.
>
>    * If I hit RET only, and the following applies:
>
>        - It is preceeded by a ';' (semicolon) AND the
>          word 'return' is not part of the current
>          line or:
>
>        - It is preceeded by a '{' (curly bracket)
>
>      RET adds DBG after the ';' or the '{' with a
>      space in between like so:
>
>      ; DBG
>      { DBG
>
>      respectively. After that (the same key stroke)
>      , RET behaves like a normal RET would (basically
>      a normal linefeed with possible auto-indentation).
>
> I have to admit that this is so far out there (at least for me) that I
> would need more or less a ready-to-go implementation just to paste into
> .emacs.

This is not a challenge, this is trivial.


(defvar *c-trace-code* " DBG;\n")

(defun c-after (regexp)
  (save-excursion
    (backward-char)
    (while (and (< (point-min) (point)) (looking-at "[\t\n ]"))
      (backward-char))
    (looking-at regexp)))

(defun insert-return-and-trace ()
  (interactive)
    (if (c-after "[{;]")
        (insert *c-trace-code*)
        (insert "\n"))
    (c-indent-command))

(add-hook 'c-mode-hook
          (lambda ()
            (unless (string-match "\\.h$" (buffer-name))
                (local-set-key [return]   (function insert-return-and-trace))
                (local-set-key [S-return] (function newline)))))



> Do you know a place where something similar has been done which I can
> steal and adapt, or are you interested in implementing it? (A place on
> my tomb stone is reserved for anyone that succeeds in doing this)

(info "elisp")


-- 
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 13:29   ` Matthieu Moy
@ 2005-10-12 14:04     ` Slawomir Nowaczyk
       [not found]     ` <mailman.11022.1129125880.20277.help-gnu-emacs@gnu.org>
  1 sibling, 0 replies; 17+ messages in thread
From: Slawomir Nowaczyk @ 2005-10-12 14:04 UTC (permalink / raw)


On Wed, 12 Oct 2005 15:29:54 +0200
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:

#> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
#> 
#> > 2) Write a function which does what you want and bind it to RET key
#> >       *) the function should check if buffer name ends with *.c
#> 
#> Better: bind this function only in c-mode and c++-mode. No test needed
#> in the command itself.

Well, my system reports c++-mode for *.h files as well. Original
poster specifically asked the function to apply to *.c files only.

#> >       *) the function should get current line contents (think of
#> >          functions buffer-substring, point, beginning-of-line, etc.)
#> 
#> and C-h f looking-at RET. You don't even need to get it in a string.

docstring for looking-at suggests it looks at text after point, while
the needed one seems to be before the point. Sure you can move to the
beginning of line first, but then I fail to see the benefit...

#> (if (save-excursion
#>       (beginning-of-line)
#>       (looking-at ".*return;")) ; adapt ...
#>   ...
#> ...)

(if (string-match ".*return;"
        (buffer-substring (line-beginning-position) (point)))
     ...
 ...)

Well, OK, your version is shorter :)

#> >    And also, try "C-h i C-s elisp RET" :)

#> C-h i m eli TAB RET ;-).

Ah, yes, I always forget this one... Thanks :)

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

The greatest enemy of a good plan is the dream of a perfect plan.

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

* RE: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 11:48 A true challenge for Emac and Elisp hackers - at Least I think so Sune
                   ` (3 preceding siblings ...)
  2005-10-12 13:48 ` Pascal Bourguignon
@ 2005-10-12 15:36 ` Drew Adams
  2005-10-12 23:28 ` Thien-Thi Nguyen
  5 siblings, 0 replies; 17+ messages in thread
From: Drew Adams @ 2005-10-12 15:36 UTC (permalink / raw)


    Emacs seems to be configurable down to its atoms

Down to its strings, actually.

No, way beyond that even - far on beyond zebracs, down to its very emarcs,
the fundamental building blocks of all becoming, in the wholly Narrowed
Region that quivers and spits between the transient Mark of being and the
pointless Point of nothingness.

`C-ohm-m-m-m' (an oxymoron, of course)

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
       [not found]     ` <mailman.11022.1129125880.20277.help-gnu-emacs@gnu.org>
@ 2005-10-12 16:13       ` Giorgos Keramidas
  2005-10-12 19:20         ` Chris McMahan
  0 siblings, 1 reply; 17+ messages in thread
From: Giorgos Keramidas @ 2005-10-12 16:13 UTC (permalink / raw)


Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
> On Wed, 12 Oct 2005 15:29:54 +0200
> Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:
> #> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
> #>
> #> > 2) Write a function which does what you want and bind it to RET key
> #> >       *) the function should check if buffer name ends with *.c
> #>
> #> Better: bind this function only in c-mode and c++-mode. No test needed
> #> in the command itself.
>
> Well, my system reports c++-mode for *.h files as well. Original
> poster specifically asked the function to apply to *.c files only.

That was probably a mis-statement of the original poster's intent,
since it's not unheard of to have macros with real C or C++ code in
header files too :)

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 16:13       ` Giorgos Keramidas
@ 2005-10-12 19:20         ` Chris McMahan
  0 siblings, 0 replies; 17+ messages in thread
From: Chris McMahan @ 2005-10-12 19:20 UTC (permalink / raw)


Ahh functional specs... :)

- Chris

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
>> On Wed, 12 Oct 2005 15:29:54 +0200
>> Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:
>> #> Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:
>> #>
>> #> > 2) Write a function which does what you want and bind it to RET key
>> #> >       *) the function should check if buffer name ends with *.c
>> #>
>> #> Better: bind this function only in c-mode and c++-mode. No test needed
>> #> in the command itself.
>>
>> Well, my system reports c++-mode for *.h files as well. Original
>> poster specifically asked the function to apply to *.c files only.
>
> That was probably a mis-statement of the original poster's intent,
> since it's not unheard of to have macros with real C or C++ code in
> header files too :)
>

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 11:48 A true challenge for Emac and Elisp hackers - at Least I think so Sune
                   ` (4 preceding siblings ...)
  2005-10-12 15:36 ` Drew Adams
@ 2005-10-12 23:28 ` Thien-Thi Nguyen
  2005-10-13  9:13   ` Sune
                     ` (3 more replies)
  5 siblings, 4 replies; 17+ messages in thread
From: Thien-Thi Nguyen @ 2005-10-12 23:28 UTC (permalink / raw)


"Sune" <sune_ahlgren@hotmail.com> writes:

> I just don't want to give up
> on Emacs!!

i'm sure emacs won't mind if you "implement a plugin" for it,
although you might want to phrase it a little differently...

thi

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 23:28 ` Thien-Thi Nguyen
@ 2005-10-13  9:13   ` Sune
  2005-10-13 14:33     ` Joe Corneli
  2005-10-13 21:45   ` Sune
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 17+ messages in thread
From: Sune @ 2005-10-13  9:13 UTC (permalink / raw)


Thien-Thi Nguyen skrev:

> "Sune" <sune_ahlgren@hotmail.com> writes:
>
> > I just don't want to give up
> > on Emacs!!
>
> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...
> 
> thi

Yeah, but I don't think a Java plugin will do...

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-13  9:13   ` Sune
@ 2005-10-13 14:33     ` Joe Corneli
  0 siblings, 0 replies; 17+ messages in thread
From: Joe Corneli @ 2005-10-13 14:33 UTC (permalink / raw)



   Thien-Thi Nguyen skrev:

   > "Sune" <sune_ahlgren@hotmail.com> writes:
   >
   > > I just don't want to give up
   > > on Emacs!!
   >
   > i'm sure emacs won't mind if you "implement a plugin" for it,
   > although you might want to phrase it a little differently...
   > 
   > thi

   Yeah, but I don't think a Java plugin will do...


If you feel you need java to do something this easy, maybe you've
already given up.  However, I suppose the (much more complicated)
problem of using java as an extension language for Emacs has been
considered by some people... you could, er, look into it.

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 23:28 ` Thien-Thi Nguyen
  2005-10-13  9:13   ` Sune
@ 2005-10-13 21:45   ` Sune
  2005-10-13 21:49   ` Sune
  2005-10-15 17:57   ` Sune
  3 siblings, 0 replies; 17+ messages in thread
From: Sune @ 2005-10-13 21:45 UTC (permalink / raw)



Thien-Thi Nguyen skrev:

> "Sune" <sune_ahlgren@hotmail.com> writes:
>
> > I just don't want to give up
> > on Emacs!!
>
> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...
> 
> thi

Yeah, but I think emacs would mind a Java plugin...

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 23:28 ` Thien-Thi Nguyen
  2005-10-13  9:13   ` Sune
  2005-10-13 21:45   ` Sune
@ 2005-10-13 21:49   ` Sune
  2005-10-14 13:10     ` Thien-Thi Nguyen
  2005-10-15 17:57   ` Sune
  3 siblings, 1 reply; 17+ messages in thread
From: Sune @ 2005-10-13 21:49 UTC (permalink / raw)


> This is not a challenge, this is trivial.

Well, for you perhaps. Nevertheless I appreciate your effort. I've
tested it and it works fine.

Thanks a lot Pascal!

> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...

Thi, I do emacs would mind a Java plugin regardless of name...

/Sune

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-13 21:49   ` Sune
@ 2005-10-14 13:10     ` Thien-Thi Nguyen
  0 siblings, 0 replies; 17+ messages in thread
From: Thien-Thi Nguyen @ 2005-10-14 13:10 UTC (permalink / raw)


"Sune" <sune_ahlgren@hotmail.com> writes:

> Thi, I do emacs would mind a Java plugin regardless of name...

the name of the thing is not the thing.

thi

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-12 23:28 ` Thien-Thi Nguyen
                     ` (2 preceding siblings ...)
  2005-10-13 21:49   ` Sune
@ 2005-10-15 17:57   ` Sune
  2005-10-15 19:57     ` Thien-Thi Nguyen
  3 siblings, 1 reply; 17+ messages in thread
From: Sune @ 2005-10-15 17:57 UTC (permalink / raw)


Hi!

> This is not a challenge, this is trivial.
Well, for you perhaps  ;)  Anyway, it worked just the way I hoped for.
Thanks Pascal.

> i'm sure emacs won't mind if you "implement a plugin" for it,
> although you might want to phrase it a little differently...
Thanks for the pointless remark thi. I think Emacs would mind a plugin
written in Java...

BRs
Sune

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

* Re: A true challenge for Emac and Elisp hackers - at Least I think so
  2005-10-15 17:57   ` Sune
@ 2005-10-15 19:57     ` Thien-Thi Nguyen
  0 siblings, 0 replies; 17+ messages in thread
From: Thien-Thi Nguyen @ 2005-10-15 19:57 UTC (permalink / raw)


"Sune" <sune_ahlgren@hotmail.com> writes:

> Thanks for the pointless remark thi.

i'm just trying to hint to hackers looking for hacks on a possibly
enjoyable SMOP.  let's hope someone hears this and helps you and me
both, in the long run.  then, we will know the point has been made.

thi

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

end of thread, other threads:[~2005-10-15 19:57 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-12 11:48 A true challenge for Emac and Elisp hackers - at Least I think so Sune
2005-10-12 12:49 ` Gian Uberto Lauri
2005-10-12 13:16 ` Slawomir Nowaczyk
     [not found] ` <mailman.11019.1129123023.20277.help-gnu-emacs@gnu.org>
2005-10-12 13:29   ` Matthieu Moy
2005-10-12 14:04     ` Slawomir Nowaczyk
     [not found]     ` <mailman.11022.1129125880.20277.help-gnu-emacs@gnu.org>
2005-10-12 16:13       ` Giorgos Keramidas
2005-10-12 19:20         ` Chris McMahan
2005-10-12 13:48 ` Pascal Bourguignon
2005-10-12 15:36 ` Drew Adams
2005-10-12 23:28 ` Thien-Thi Nguyen
2005-10-13  9:13   ` Sune
2005-10-13 14:33     ` Joe Corneli
2005-10-13 21:45   ` Sune
2005-10-13 21:49   ` Sune
2005-10-14 13:10     ` Thien-Thi Nguyen
2005-10-15 17:57   ` Sune
2005-10-15 19:57     ` Thien-Thi Nguyen

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).