Tramp with GUD broken on trunk?

Tramp with GUD broken on trunk?

[Nick Roberts]

I think the last set of changes to tramp has broken use with GUD.  At least
doing:

Run gdb (like this): gdb --annotate=3 /ssh:localhost:/home/nickrob/myprog

with EMACS_22_BASE I get:

  Current directory is /ssh:localhost:/home/nickrob/
    GNU gdb 6.6-debian
  Copyright (C) 2006 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "i486-linux-gnu"...
  /ssh:localhost:/home/nickrob/myprog: No such file or directory.
  (gdb) 

which has a file not found error but this is recoverable.
However with the trunk I get:

  Current directory is /ssh:localhost:/home/nickrob/

  Debugger exited abnormally with code 2

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> I think the last set of changes to tramp has broken use with GUD.

Yes. The idea is to adapt existing packages to the new features with
Tramp 2.1, in order to let them run even on remote hosts. I did it
already with compile.el and rcompile.el; other packages will
follow. grep.el and gud.el are on my top priority.

There is a workaround for these packages in Tramp 2.1.9 which uses
defadvices heavily. It is not desirable to introduce these workarounds
into the Emacs trunk. That's why tramp-util.el and tramp-vc.el have
not been kept there.

For the time being, I believe it is tolerable that these packages
don't work when default-directory is remote. They didn't work before
either under these circumstances.

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Nick Roberts]

 > For the time being, I believe it is tolerable that these packages
 > don't work when default-directory is remote. They didn't work before
 > either under these circumstances.

Sure, I was just reporting a regression that I thought might not have been
noticed.  I don't understand the workings of TRAMP but if you can express what
changes are needed to gud.el, I might be able to help

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> Sure, I was just reporting a regression that I thought might not have been
> noticed.  I don't understand the workings of TRAMP but if you can express what
> changes are needed to gud.el, I might be able to help

First of all, call-process and/or start-process must be replaced by
process-file and start-file-process, respectively.

Then I needed to adapt gud-find-file, gud-%s-find-file and
gud-%s-massage-args. I don't remember the details (I wrote it in
November 2005); you might check the code at
<http://cvs.savannah.gnu.org/viewvc/tramp/lisp/tramp-util.el?revision=2.44&root=tramp&view=markup>.

I fear the change is not trivial, although it might be simpler to
change inside the concerned gud functions. If you could apply a patch
I'ld really appreciate it because my todo list is rather long.

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Nick Roberts]

 > First of all, call-process and/or start-process must be replaced by
 > process-file and start-file-process, respectively.

GUD uses make-comint which uses start-process i.e. it's asynchronous so
it doesn't use call-process.

 > Then I needed to adapt gud-find-file, gud-%s-find-file and
 > gud-%s-massage-args. I don't remember the details (I wrote it in
 > November 2005); you might check the code at
 > <http://cvs.savannah.gnu.org/viewvc/tramp/lisp/tramp-util.el?revision=2.44&root=tramp&view=markup>.

I don't see why gud-%s-massage-args should change.  In any case
gud-gdb-massage-args has been deleted.  There only seems to be one
variation of gud-find-file now (gud-sdb-find-file) but these are
basically find-file which appears to be fundamental to TRAMP.  I would
guess it just needs fiddling with arguments.

I'll check out your link.

 > I fear the change is not trivial, although it might be simpler to
 > change inside the concerned gud functions. If you could apply a patch
 > I'ld really appreciate it because my todo list is rather long.

I'll dig out an ethernet cable.  Using localhost is too confusing because
I'm not sure if things are happening locally or through TRAMP.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > First of all, call-process and/or start-process must be replaced by
>  > process-file and start-file-process, respectively.
>
> GUD uses make-comint which uses start-process i.e. it's asynchronous so
> it doesn't use call-process.

Yep. You need to wrap the make-comint call with some code to use
start-file-process instead of start-process. Maybe similar to the code
I've applied in compilation-start.

Or shall we extend comint to make this an option?

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Stefan Monnier]

>> > First of all, call-process and/or start-process must be replaced by
>> > process-file and start-file-process, respectively.
>> 
>> GUD uses make-comint which uses start-process i.e. it's asynchronous so
>> it doesn't use call-process.

> Yep. You need to wrap the make-comint call with some code to use
> start-file-process instead of start-process. Maybe similar to the code
> I've applied in compilation-start.

> Or shall we extend comint to make this an option?

Or change comint to always use start-file-process.


        Stefan

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

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

> Or change comint to always use start-file-process.

That would be the most simple approach. But it must be ensured that
all callers of comint appreciate this behaviour. There might be cases
they insist in starting processes on the local host, even if
default-directory is remote. Examples might be browse-url, ediff,
gnus, ispell, jka-compr, ... I haven't checked whether one of them
uses comint, but you see the point.

>         Stefan

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Stefan Monnier]

>> Or change comint to always use start-file-process.
> That would be the most simple approach.  But it must be ensured that
> all callers of comint appreciate this behaviour.  There might be cases
> they insist in starting processes on the local host, even if
> default-directory is remote.  Examples might be browse-url, ediff,
> gnus, ispell, jka-compr, ... I haven't checked whether one of them
> uses comint, but you see the point.

A quick run of

  egrep -l 'make-comint|comint-(run|exec)' **/*.el

seems to indicate this is not a problem.  Furthermore, there's already
a flag to turn off the "remote process" feature: "setq default-directory".      


        Stefan

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

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

> A quick run of
>
>   egrep -l 'make-comint|comint-(run|exec)' **/*.el
>
> seems to indicate this is not a problem.  Furthermore, there's already
> a flag to turn off the "remote process" feature: "setq default-directory".      
rlogin.el? telnet.el? net-utils.el?

However, I believe your approach is more robust. Shall I change
comint.el this way, adapt these packages, and revert my patch from
compile.el?

>         Stefan

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Stefan Monnier]

>> A quick run of
>> 
>> egrep -l 'make-comint|comint-(run|exec)' **/*.el
>> 
>> seems to indicate this is not a problem.  Furthermore, there's already
>> a flag to turn off the "remote process" feature: "setq default-directory".      
> rlogin.el? telnet.el? net-utils.el?

As far as I can tell, these are all designed for interactive use, so it
seems OK: if the user wants to run nslookup|telnet|rlogin on a remote host,
she can do so.

> However, I believe your approach is more robust.  Shall I change
> comint.el this way, adapt these packages, and revert my patch from
> compile.el?

Sounds good to me,


        Stefan

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

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

>> However, I believe your approach is more robust.  Shall I change
>> comint.el this way, adapt these packages, and revert my patch from
>> compile.el?
>
> Sounds good to me,

Done.

Nick, if you like you could check what's left to do for gud.

>         Stefan

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Nick Roberts]

 > Done.
 > 
 > Nick, if you like you could check what's left to do for gud.

OK, I'm playing catch up at the moment.  I made the same change to
comint-exec-1 that you had made to compilation-start (below).  That meant that
if I started with a remote default-directory, M-x gdb would execute remotely
but GUD wouldn't put the source in a buffer when execution stopped, as
gud-find-file only used the local filename.

-- 
Nick                                           http://www.inet.net.nz/~nickrob



*** comint.el	03 Apr 2007 02:01:02 +1200	1.361
--- comint.el	11 Jul 2007 01:17:50 +1200	
*************** buffer.  The hook `comint-exec-hook' is 
*** 780,788 ****
      (let ((exec-path (if (file-name-directory command)
  			 ;; If the command has slashes, make sure we
  			 ;; first look relative to the current directory.
! 			 (cons default-directory exec-path) exec-path)))
!       (setq proc (apply 'start-process name buffer command switches)))
!     (let ((coding-systems (process-coding-system proc)))
        (setq decoding (car coding-systems)
  	    encoding (cdr coding-systems)))
      ;; If start-process decided to use some coding system for decoding
--- 780,801 ----
      (let ((exec-path (if (file-name-directory command)
  			 ;; If the command has slashes, make sure we
  			 ;; first look relative to the current directory.
! 			 (cons default-directory exec-path) exec-path))
! 	  (start-process (symbol-function 'start-process)))
!       ;; Redefine temporarily `start-process' in order to handle
!       ;; remote processes.
!       (fset 'start-process
! 	    (lambda (name buffer program &rest program-args)
! 	      (apply
! 	       (if (file-remote-p default-directory)
! 		   'start-file-process
! 		 start-process)
! 	       name buffer program program-args)))
!       (unwind-protect
! 	  (setq proc (apply 'start-process name buffer command switches))
! 	;; Unwindform: Reset original definition of `start-process'
! 	(fset 'start-process start-process)))
!      (let ((coding-systems (process-coding-system proc)))
        (setq decoding (car coding-systems)
  	    encoding (cdr coding-systems)))
      ;; If start-process decided to use some coding system for decoding

Re: Tramp with GUD broken on trunk?

[Nick Roberts]

 > >> However, I believe your approach is more robust.  Shall I change
 > >> comint.el this way, adapt these packages, and revert my patch from
 > >> compile.el?
 > >
 > > Sounds good to me,

Reverting compile.el doesn't make sense to me as it doesn't necessarily use
comint.

 > Done.

 > Nick, if you like you could check what's left to do for gud.

This last change has the same effect as my earlier one, i.e., gud-find-file has
to be adapted to find remote files.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> Reverting compile.el doesn't make sense to me as it doesn't necessarily use
> comint.

Hmm, you're right. Wrapping start-process-shell-command in
compilation-start seems still to be necessary.

I'll commit it tonight.

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Nick Roberts]

 > Nick, if you like you could check what's left to do for gud.

The patch below works for me, both with an initial local default-directory
with, e.g.:

gdb --annotate=3 /ssh:192.168.1.5:/home/nickrob/myprog

and an initial remote directory (/ssh:192.168.1.5:/home/nickrob/) with:

gdb --annotate=3 myprog

It may be a bit of a hack but you may be able to generalise it.

Incidentally, I think something should display in the mode-line to say that
the default-directory is remote.  Quite often there are similar files on
both machines and it's easy to forget which one you're looking at.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** gud.el	11 Jul 2007 10:28:18 +1200	1.132
--- gud.el	11 Jul 2007 18:53:19 +1200	
*************** Used to grey out relevant toolbar icons.
*** 292,297 ****
--- 292,301 ----
  (defun gud-file-name (f)
    "Transform a relative file name to an absolute file name.
  Uses `gud-<MINOR-MODE>-directories' to find the source files."
+   (let ((remote (file-remote-p default-directory)))
+     (when remote
+       (string-match "\\(.*:\\).*$" remote)
+       (setq f (concat (match-string 1 remote) f))))
    (if (file-exists-p f) (expand-file-name f)
      (let ((directories (gud-val 'directories))
  	  (result nil))
*************** comint mode, which see."
*** 2510,2516 ****
        (while (and w (not (eq (car w) t)))
  	(setq w (cdr w)))
        (if w
! 	  (setcar w file)))
      (apply 'make-comint (concat "gud" filepart) program nil
  	   (if massage-args (funcall massage-args file args) args))
      ;; Since comint clobbered the mode, we don't set it until now.
--- 2514,2523 ----
        (while (and w (not (eq (car w) t)))
  	(setq w (cdr w)))
        (if w
! 	  (setcar w
! 		  (if (file-remote-p default-directory)
! 		      (setq file (file-name-nondirectory file))
! 		    file))))
      (apply 'make-comint (concat "gud" filepart) program nil
  	   (if massage-args (funcall massage-args file args) args))
      ;; Since comint clobbered the mode, we don't set it until now.

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> It may be a bit of a hack but you may be able to generalise it.

I'll check tonight.

> Incidentally, I think something should display in the mode-line to say that
> the default-directory is remote.  Quite often there are similar files on
> both machines and it's easy to forget which one you're looking at.

>From the Tramp FAQ:

   * I'ld like to see a host indication in the mode line when I'm
     remote

     The following code has been tested with GNU Emacs 22.  You
     should put it into your `~/.emacs':

          (defconst my-mode-line-buffer-identification
            (list
             '(:eval
               (let ((host-name
          	    (if (file-remote-p default-directory)
          		(tramp-file-name-host
          		 (tramp-dissect-file-name default-directory))
          	      (system-name))))
                 (if (string-match "^[^0-9][^.]*\\(\\..*\\)" host-name)
          	   (substring host-name 0 (match-beginning 1))
          	 host-name)))
             ": %12b"))

          (setq-default
           mode-line-buffer-identification
           my-mode-line-buffer-identification)

          (add-hook
           'dired-mode-hook
           '(lambda ()
              (setq
               mode-line-buffer-identification
               my-mode-line-buffer-identification)))

Maybe it shall be enabled by default?

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> The patch below works for me, both with an initial local default-directory
> with, e.g.:
>
> gdb --annotate=3 /ssh:192.168.1.5:/home/nickrob/myprog
>
> and an initial remote directory (/ssh:192.168.1.5:/home/nickrob/) with:
>
> gdb --annotate=3 myprog
>
> It may be a bit of a hack but you may be able to generalise it.

I've committed a slightly modified version of your patch.

Best regards, Michael,

Re: Tramp with GUD broken on trunk?

[Nick Roberts]

 > I've committed a slightly modified version of your patch.

This looks good.  Initially, it wasn't obvious to me how you could use GUD
with TRAMP.  Are you going to document this kind of use in the Tramp
manual?  Then I could link to it from the GUD node in the Emacs manual.

> > Incidentally, I think something should display in the mode-line to say that
> > the default-directory is remote.  Quite often there are similar files on
> > both machines and it's easy to forget which one you're looking at.

> From the Tramp FAQ:

>    * I'ld like to see a host indication in the mode line when I'm
>      remote

This isn't exactly what I meant.  I don't really want the hostname displaying
in all buffers including those for the local machine.  I was just thinking of
something like the character 'R', possibly with a different face/background
colour, for remote buffers similar to the single character flags at the start
of the mode-line.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> This looks good.  Initially, it wasn't obvious to me how you could use GUD
> with TRAMP.  Are you going to document this kind of use in the Tramp
> manual?  Then I could link to it from the GUD node in the Emacs manual.

Yes, I will do this. But just now I'm debugging gud in order to
stabilize the patch. I'm running into problems with perldb; the change
in gud-common-init doesn't seem to be sufficient.

> This isn't exactly what I meant.  I don't really want the hostname displaying
> in all buffers including those for the local machine.  I was just thinking of
> something like the character 'R', possibly with a different face/background
> colour, for remote buffers similar to the single character flags at the start
> of the mode-line.

There might be different requirements. I, for example, work on dozens
of remote machines in parallel (all machines from our test floor). A
simple "R" indication in the mode line wouldn't help in my use
case. Likely it is sufficient just to document possible approaches.

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> Nick Roberts <nickrob@snap.net.nz> writes:
>
>> This looks good.  Initially, it wasn't obvious to me how you could use GUD
>> with TRAMP.  Are you going to document this kind of use in the Tramp
>> manual?  Then I could link to it from the GUD node in the Emacs manual.
>
> Yes, I will do this. But just now I'm debugging gud in order to
> stabilize the patch. I'm running into problems with perldb; the change
> in gud-common-init doesn't seem to be sufficient.

Forget this, it was a home-made problem.

I've added in the Tramp manual some few words about remote debugging;
see "(tramp)Remote processes". 

Best regards, Michael.

Re: Tramp with GUD broken on trunk?

[Nick Roberts]

 > I've added in the Tramp manual some few words about remote debugging;
 > see "(tramp)Remote processes". 

Thanks.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

mode-line with Tramp [was: Re: Tramp with GUD broken on trunk?]

[Nick Roberts]

 > > This isn't exactly what I meant.  I don't really want the hostname
 > > displaying in all buffers including those for the local machine.  I was
 > > just thinking of something like the character 'R', possibly with a
 > > different face/background colour, for remote buffers similar to the single
 > > character flags at the start of the mode-line.
 > 
 > There might be different requirements. I, for example, work on dozens
 > of remote machines in parallel (all machines from our test floor). A
 > simple "R" indication in the mode line wouldn't help in my use
 > case. Likely it is sufficient just to document possible approaches.

I don't know what typical use is but I was thinking about the occasional user
who connects to just one other machine.  Perhap there could be a variable like
"tramp-mode-line" with values 'none, 'minimal, and 'full to give differing
levels of detail, where the default would be minimal.  This would alert new
users to remote buffers.  Those using dozens of remote machines in parallel
would surely know about such a veriable to change it's value.



-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> I don't know what typical use is but I was thinking about the occasional user
> who connects to just one other machine.  Perhap there could be a variable like
> "tramp-mode-line" with values 'none, 'minimal, and 'full to give differing
> levels of detail, where the default would be minimal.  This would alert new
> users to remote buffers.  Those using dozens of remote machines in parallel
> would surely know about such a veriable to change it's value.

What about this:

(defvar tramp-minor-mode-map (make-sparse-keymap)
  "Keymap for Tramp minor mode.")

(define-minor-mode tramp-minor-mode "Tramp minor mode."
  :group 'tramp
  :global nil
  :init-value nil
  :lighter " Tramp"
  :keymap tramp-minor-mode-map
  (setq tramp-minor-mode
	(and tramp-minor-mode (tramp-tramp-file-p default-directory))))

(add-hook 'find-file-hooks 'tramp-minor-mode t)

Best regards, Michael.

Re: mode-line with Tramp

[Nick Roberts]

 > What about this:
 > 
 > (defvar tramp-minor-mode-map (make-sparse-keymap)
 >   "Keymap for Tramp minor mode.")
 > 
 > (define-minor-mode tramp-minor-mode "Tramp minor mode."
 >   :group 'tramp
 >   :global nil
 >   :init-value nil
 >   :lighter " Tramp"
 >   :keymap tramp-minor-mode-map
 >   (setq tramp-minor-mode
 > 	(and tramp-minor-mode (tramp-tramp-file-p default-directory))))
 > 
 > (add-hook 'find-file-hooks 'tramp-minor-mode t)

It's a bit misleading because tramp-minor-mode doesn't have any keybindings
so it's not a real minor-mode.  Also for dired, GUD buffer etc. this shows
nothing.

I think conditioning on (file-remote-p default-directory) was the right idea.

How about something like this for binding.el:

(defvar mode-line-remote-p
  (list (propertize
	 "%1R"
	 'help-echo (purecopy (lambda (window object point)
 				(format "%s"
					(save-selected-window
					  (select-window window)
					  (if (file-remote-p default-directory)
					      (concat "Remote: "
						      default-directory)
					    "")))))))
  "Mode-line flag to show if current buffer is for a remote machine.")

(make-variable-buffer-local 'mode-line-remote-p)

where mode-line-remote-p is added to the value of mode-line-format:

("%e"
 #("-" 0 1
   (help-echo "mouse-1: select (drag to resize), mouse-2 = C-x 1, mouse-3 = C-x 0"))
 mode-line-mule-info mode-line-modified mode-line-remote-p mode-line-frame-identification mode-line-buffer-identification...


And %R (not implemented yet) works a bit like %*: print R or hyphen depending
on whether (file-remote-p default-directory) is true or not.



-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > (add-hook 'find-file-hooks 'tramp-minor-mode t)
>
> It's a bit misleading because tramp-minor-mode doesn't have any keybindings
> so it's not a real minor-mode.  Also for dired, GUD buffer etc. this shows
> nothing.

Oh, it was just code I've taken from Tramp 2.0. There was a "real"
Tramp minor mode, including key bindings, because it offered
alternative implementations for `compile' etc.

> I think conditioning on (file-remote-p default-directory) was the right idea.
>
> How about something like this for binding.el:

[...]

> And %R (not implemented yet) works a bit like %*: print R or hyphen depending
> on whether (file-remote-p default-directory) is true or not.

I don't know whether it is OK to call pure Lisp functions in
decode_mode_spec. Besides of this, it looks natural to me.

And one could also think about a host indication %h, which is a
candidate for frame-title-format or header-line-format.

However, I'm rather chary with changes in xdisp.c, bindings.el etc,
because I don't know whether they are accepted by the majority.

Best regards, Michael.

Re: mode-line with Tramp

[Nick Roberts]

 > > And %R (not implemented yet) works a bit like %*: print R or hyphen
 > > depending on whether (file-remote-p default-directory) is true or not.
 > 
 > I don't know whether it is OK to call pure Lisp functions in
 > decode_mode_spec. Besides of this, it looks natural to me.
                     (Apart from this?)

Using call1 seems to work. The function file-remote-p is in file.el which gets
built into Emacs through loadup.el, so I guess it's OK.

 > And one could also think about a host indication %h, which is a
 > candidate for frame-title-format or header-line-format.
 > 
 > However, I'm rather chary with changes in xdisp.c, bindings.el etc,
 > because I don't know whether they are accepted by the majority.

It's just one character on the mode-line.  Here's a patch that they can try.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


Index: src/xdisp.c
===================================================================
RCS file: /sources/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1156
diff -p -r1.1156 xdisp.c
*** src/xdisp.c	17 Jun 2007 01:45:46 -0000	1.1156
--- src/xdisp.c	18 Jul 2007 08:38:44 -0000
*************** decode_mode_spec (w, c, field_width, pre
*** 17994,17999 ****
--- 17994,18009 ----
  #endif
        break;
  
+     case 'R':
+       {
+ 	Lisp_Object val;
+ 	val = call1 (intern ("file-remote-p"), current_buffer->directory);
+ 	if (NILP (val))
+ 	  return "-";
+ 	else
+ 	  return "R";
+       }
+ 
      case 't':			/* indicate TEXT or BINARY */
  #ifdef MODE_LINE_BINARY_TEXT
        return MODE_LINE_BINARY_TEXT (b);
Index: src/buffer.c
===================================================================
RCS file: /sources/emacs/emacs/src/buffer.c,v
retrieving revision 1.528
diff -p -r1.528 buffer.c
*** src/buffer.c	27 Jun 2007 11:33:29 -0000	1.528
--- src/buffer.c	18 Jul 2007 08:38:51 -0000
*************** A string is printed verbatim in the mode
*** 5501,5506 ****
--- 5501,5508 ----
    %P -- print percent of buffer above bottom of window, perhaps plus Top,
          or print Bottom or All.
    %n -- print Narrow if appropriate.
+   %R -- print R or hyphen.  R means that default-directory is on a
+         remote machine.
    %t -- visited file is text or binary (if OS supports this distinction).
    %z -- print mnemonics of keyboard, terminal, and buffer coding systems.
    %Z -- like %z, but including the end-of-line format.
Index: lisp/bindings.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.178
diff -p -r1.178 bindings.el
*** lisp/bindings.el	11 Feb 2007 22:11:48 -0000	1.178
--- lisp/bindings.el	18 Jul 2007 08:38:53 -0000
*************** Normally nil in most modes, since there 
*** 248,253 ****
--- 248,270 ----
  
  (make-variable-buffer-local 'mode-line-modified)
  
+ (defvar mode-line-remote
+   (list (propertize
+ 	 "%1R"
+ 	 'help-echo (purecopy (lambda (window object point)
+  				(format "%s"
+ 					(save-selected-window
+ 					  (select-window window)
+ 					  (concat 
+ 					  (if (file-remote-p default-directory)
+ 					      "Remote: "
+ 					    "Local: ")
+ 					  default-directory)))))))
+   "Mode-line flag to show if default-directory for the current buffer
+ is on a remote machine.")
+ 
+ (make-variable-buffer-local 'mode-line-remote)
+ 
  ;; Actual initialization is below.
  (defvar mode-line-position nil
    "Mode-line control for displaying the position in the buffer.
*************** Keymap to display on minor modes.")
*** 287,292 ****
--- 304,310 ----
  	 (propertize "-" 'help-echo help-echo)
  	 'mode-line-mule-info
  	 'mode-line-modified
+ 	 'mode-line-remote
  	 'mode-line-frame-identification
  	 'mode-line-buffer-identification
  	 (propertize "   " 'help-echo help-echo)
Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.912
diff -p -r1.912 files.el
*** lisp/files.el	17 Jul 2007 21:07:49 -0000	1.912
--- lisp/files.el	18 Jul 2007 08:39:02 -0000
*************** asking you for confirmation."
*** 2464,2469 ****
--- 2464,2470 ----
  	mode-line-mule-info
  	mode-line-position
  	mode-line-process
+ 	mode-line-remote
  	mode-name
  	outline-level
  	overriding-local-map

Re: mode-line with Tramp

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> It's just one character on the mode-line.  Here's a patch that they can try.

Your patch looks reasonable to me. However, I don't feel comfortable
to decide whether we shall install such a change in the modeline.

Richard?

Best regards, Michael.

Re: mode-line with Tramp

[Richard Stallman]

    Your patch looks reasonable to me. However, I don't feel comfortable
    to decide whether we shall install such a change in the modeline.

The code looks clean enough, and the feature could be useful.  We can
spare one character.  Before deciding on it, I'd like to see reports
from some users about whether they find it useful.

I wonder whether "R" could sometimes get confused with the frame
identification.  Usually the frame name won't start with R, but it
can.  Maybe this indicator should appear in a different place in the
mode line.

Before we install this, the changes to the manuals should be written
so they can be installed at the same time.

Re: mode-line with Tramp

[Nick Roberts]

 >     Your patch looks reasonable to me. However, I don't feel comfortable
 >     to decide whether we shall install such a change in the modeline.
 > 
 > The code looks clean enough, and the feature could be useful.  We can
 > spare one character.  Before deciding on it, I'd like to see reports
 > from some users about whether they find it useful.

Like Juri, I think the reality is that very few will test it.  This might
not be the best solution but something needs to be done.  Committing such
changes to the trunk ensures that they _are_ tested and if people don't
like them they generally report to the mailing list, e.g., "scratch buffer
annoyances".  I try out very few changes that aren't committed to the
repository but often comment on those that are.  I think many others on this
list do the same.

 > I wonder whether "R" could sometimes get confused with the frame
 > identification.  Usually the frame name won't start with R, but it
 > can.  Maybe this indicator should appear in a different place in the
 > mode line.
 > 
 > Before we install this, the changes to the manuals should be written
 > so they can be installed at the same time.

I always try to document changes that I make to Emacs but generally prefer
to do this once the change has been finalised.  Other projects, e.g GDB,
make documentation a requirement for patch approval.  Emacs seems to be
quite inconsistent, however, with each contributor providing different levels
of documentation, e.g., there have been many changes to VC recently but I
see nothing in the manual to reflect this, e.g, the manual says 
vc-handled-backends  is `(RCS CVS SVN SCCS Arch MCVS)', Emacs tells me it's
(RCS CVS SVN SCCS BZR HG Arch MCVS)

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Richard Stallman]

      Emacs seems to be
    quite inconsistent, however, with each contributor providing different levels
    of documentation, e.g., there have been many changes to VC recently but I

I think ESR went ahead and installed his rewrite of VC without the
discussion that should have happened first.  This is not the way
things are supposed to be done.  We should discuss such change
before installation.

Could you please look at this point?

     > I wonder whether "R" could sometimes get confused with the frame
     > identification.  Usually the frame name won't start with R, but it
     > can.  Maybe this indicator should appear in a different place in the
     > mode line.

Re: mode-line with Tramp

[Nick Roberts]

 >     quite inconsistent, however, with each contributor providing different
 >     levels of documentation, e.g., there have been many changes to VC
 >     recently but I
 > 
 > I think ESR went ahead and installed his rewrite of VC without the
 > discussion that should have happened first.  This is not the way
 > things are supposed to be done.  We should discuss such change
 > before installation.

I don't think he was responsible for the example that I gave.

 > Could you please look at this point?
 > 
 >      > I wonder whether "R" could sometimes get confused with the frame
 >      > identification.  Usually the frame name won't start with R, but it
 >      > can.  Maybe this indicator should appear in a different place in the
 >      > mode line.

All I know is that the mode-line shows -F1 on a tty, and -F2 on the rare
occasions that I use C-x 5 2 there.  I've never seen the frame-name changed
explicitly on a tty and since it is preceded by a hyphen, it would have to
start with R- for to be an ambiguity.  All the single character flags are on
the left and I can't think of a better place for it (that doesn't mean there
isn't a better one, of course).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 21 Jul 2007 21:07:12 +1200
> Cc: michael.albinus@gmx.de, emacs-devel@gnu.org
> 
> All I know is that the mode-line shows -F1 on a tty, and -F2 on the rare
> occasions that I use C-x 5 2 there.  I've never seen the frame-name changed
> explicitly on a tty

You can do that with "M-x set-frame-name RET".  You can later switch
to a named frame with "M-x select-frame-by-name RET".  This comes in
very handy when I need to work on a tty for a long time: I can
organize my frames by subject (one frame for email, another for
working on a program, yet another for reading Info docs, etc.) and
switch to the one I need in one go, instead of using long series of
"C-x 5 o" or using tmm-menubar and guessing whether the frame I need
is F3 or F5.

Re: mode-line with Tramp

[Richard Stallman]

    All I know is that the mode-line shows -F1 on a tty, and -F2 on the rare
    occasions that I use C-x 5 2 there.  I've never seen the frame-name changed
    explicitly on a tty and since it is preceded by a hyphen, it would have to
    start with R- for to be an ambiguity.

Aha, mode-line-frame-identification starts with a dash before the
frame name.  So you are right that there is no problem of confusion.

If a few other people say they would like this, please install it.

Re: mode-line with Tramp

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Fri, 20 Jul 2007 11:28:54 +1200
> Cc: Michael Albinus <michael.albinus@gmx.de>, emacs-devel@gnu.org
> 
> there have been many changes to VC recently but I
> see nothing in the manual to reflect this

That is okay, as long as the respective entries in etc/NEWS aren't
marked with either +++ or ---.  The idea is that shortly before the
release, we should go through NEWS and make sure every change that
needs to be documented is documented.

> e.g, the manual says 
> vc-handled-backends  is `(RCS CVS SVN SCCS Arch MCVS)', Emacs tells me it's
> (RCS CVS SVN SCCS BZR HG Arch MCVS)

Thanks, I fixed that.

Re: mode-line with Tramp

[Nick Roberts]

 > > there have been many changes to VC recently but I
 > > see nothing in the manual to reflect this
 > 
 > That is okay, as long as the respective entries in etc/NEWS aren't
 > marked with either +++ or ---.  The idea is that shortly before the
 > release, we should go through NEWS and make sure every change that
 > needs to be documented is documented.

Yes, but I get mixed messages because Richard has just said:

  Before we install this, the changes to the manuals should be written
  so they can be installed at the same time.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Richard Stallman]

     > That is okay, as long as the respective entries in etc/NEWS aren't
     > marked with either +++ or ---.  The idea is that shortly before the
     > release, we should go through NEWS and make sure every change that
     > needs to be documented is documented.

    Yes, but I get mixed messages because Richard has just said:

      Before we install this, the changes to the manuals should be written
      so they can be installed at the same time.

We don't always insist on changing the manual when a feature is
installed, but sometimes I think it is important to do so.
It never hurts, of course.

Re: mode-line with Tramp

[Juri Linkov]

> Like Juri, I think the reality is that very few will test it.  This might
> not be the best solution but something needs to be done.  Committing such
> changes to the trunk ensures that they _are_ tested and if people don't
> like them they generally report to the mailing list, e.g., "scratch buffer
> annoyances".  I try out very few changes that aren't committed to the
> repository but often comment on those that are.  I think many others on this
> list do the same.

I rarely try out not installed changed too, but now I tried out your patch
and generally I like it.

First I want to note that adding R for Remote doesn't make the mode line
more confusing than it can be already in some extreme cases. For instance,
after renaming the current frame to "R" and using the KOI8-R language
environment (with "R" indication in three slots) we get:

-RRR:%%--R

When the directory is remote then we get:

-RRR:%%R-R

Maybe it would be better to use "@" instead of "R" to indicate the remote
directory?

-RRR:%%@-R

"@" is less likely as the frame name, and "@" has good mnemonic as
a symbol often used in addresses of remote directories.

Also another question: is it possible not to show useless placeholder "-"
when the directory is not remote?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: mode-line with Tramp

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> Maybe it would be better to use "@" instead of "R" to indicate the remote
> directory?
>
> -RRR:%%@-R

Great.  4 rust monsters and a lizard attacking.  At least there is
plenty of food.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: mode-line with Tramp

[Nick Roberts]

 > Maybe it would be better to use "@" instead of "R" to indicate the remote
 > directory?
 > 
 > -RRR:%%@-R

Yes "R" is only meaningful to an English speaker, "@" is more international.

 > "@" is less likely as the frame name, and "@" has good mnemonic as
 > a symbol often used in addresses of remote directories.
 > 
 > Also another question: is it possible not to show useless placeholder "-"
 > when the directory is not remote?

When the directory is not remote, placing the pointer over the hyphen displays
the value of the default-directory.  It does look a bit distracting but perhaps
that's because I'm not used to it.  If people prefer, I could remove it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Richard Stallman]

    When the directory is not remote, placing the pointer over the hyphen displays
    the value of the default-directory.  It does look a bit distracting but perhaps
    that's because I'm not used to it.  If people prefer, I could remove it.

Why not provide the same tooltip when it IS remote?
It doesn't require access to the remote host, does it?

Re: mode-line with Tramp

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> Why not provide the same tooltip when it IS remote?

Nick's patch does this.

> It doesn't require access to the remote host, does it?

Yep.

Best regards, Michael.

Re: mode-line with Tramp

[Nick Roberts]

 >     When the directory is not remote, placing the pointer over the hyphen
 >     displays the value of the default-directory.  It does look a bit
 >     distracting but perhaps that's because I'm not used to it.  If people
 >     prefer, I could remove it.
 > 
 > Why not provide the same tooltip when it IS remote?

It already does this.  I've probably been ambiguous: I mean't remove the hyphen,
not the tooltip.

 > It doesn't require access to the remote host, does it?

? The buffer does, when remote, but the mode-line information doesn't.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Juri Linkov]

>  > Maybe it would be better to use "@" instead of "R" to indicate the remote
>  > directory?
>  > 
>  > -RRR:%%@-R
>
> Yes "R" is only meaningful to an English speaker, "@" is more international.
>
>  > "@" is less likely as the frame name, and "@" has good mnemonic as
>  > a symbol often used in addresses of remote directories.
>  > 
>  > Also another question: is it possible not to show useless placeholder "-"
>  > when the directory is not remote?
>
> When the directory is not remote, placing the pointer over the hyphen displays
> the value of the default-directory.  It does look a bit distracting but perhaps
> that's because I'm not used to it.  If people prefer, I could remove it.

Hmm, I sometimes access remote directories using Emacs on a terminal
where placing the mouse pointer over the hyphen doesn't work, so I can't
see the host name which is even more important to know than default-directory.

Maybe a better variant would be to display a string "@hostname.tld" on the
mode line?  For instance, to display it after the buffer file name like
"filename.txt@hostname.tld"?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: mode-line with Tramp

[Nick Roberts]

 > > When the directory is not remote, placing the pointer over the hyphen
 > > displays the value of the default-directory.  It does look a bit
 > > distracting but perhaps that's because I'm not used to it.  If people
 > > prefer, I could remove it.
 > 
 > Hmm, I sometimes access remote directories using Emacs on a terminal where
 > placing the mouse pointer over the hyphen doesn't work, so I can't see the
 > host name which is even more important to know than default-directory.

If you mean a text terminal, tooltips don't currently work there on the
mode-line.  I only committed a change (to the trunk) to get them to work in the
text area after 22.1 was released.  Extending them to the mode-line should be a
routine but time consuming task.

 > Maybe a better variant would be to display a string "@hostname.tld" on the
 > mode line?  For instance, to display it after the buffer file name like
 > "filename.txt@hostname.tld"?

I think this would take up too much space and push more important information
out of view.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Richard Stallman]

    Maybe it would be better to use "@" instead of "R" to indicate the remote
    directory?

    -RRR:%%@-R

I prefer @.

Re: mode-line with Tramp

[Nick Roberts]

 >     Maybe it would be better to use "@" instead of "R" to indicate the remote
 >     directory?
 > 
 >     -RRR:%%@-R
 > 
 > I prefer @.

OK I've committed a patch with "@".  Michael might like to choose how to
document this in the Tramp/Emacs manuals.  If not, I will add something
to the "Mode Line" node.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

> Michael might like to choose how to document this in the Tramp/Emacs
> manuals.  If not, I will add something to the "Mode Line" node.

Please do. I'll refer to this from the Tramp manual then.

Best regards, Michael.

Re: mode-line with Tramp

[Nick Roberts]

 > > Michael might like to choose how to document this in the Tramp/Emacs
 > > manuals.  If not, I will add something to the "Mode Line" node.
 > 
 > Please do. I'll refer to this from the Tramp manual then.

OK, I've added a few lines to the Emacs manual.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Richard Stallman]

    OK I've committed a patch with "@".

There is nothing in etc/NEWS about this.  Please don't ever
install a patch that changes user-level features without documenting
it in etc/NEWS.

Please describe this in etc/NEWS now, and ack.

Re: mode-line with Tramp

[Nick Roberts]

 >     OK I've committed a patch with "@".
 > 
 > There is nothing in etc/NEWS about this.  Please don't ever
 > install a patch that changes user-level features without documenting
 > it in etc/NEWS.

My change was made late at night and your e-mail was sent six hours after it.

 > Please describe this in etc/NEWS now, and ack.

Done.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Juri Linkov]

>  >     Maybe it would be better to use "@" instead of "R" to indicate the remote
>  >     directory?
>  > 
>  >     -RRR:%%@-R
>  > 
>  > I prefer @.
>
> OK I've committed a patch with "@".

Not a big deal, but wouldn't it be better to use %@ format instead of %R
for consistency with its display in the mode line?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: mode-line with Tramp

[Nick Roberts]

 > >  >     Maybe it would be better to use "@" instead of "R" to indicate the remote
 > >  >     directory?
 > >  > 
 > >  >     -RRR:%%@-R
 > >  > 
 > >  > I prefer @.
 > >
 > > OK I've committed a patch with "@".
 > 
 > Not a big deal, but wouldn't it be better to use %@ format instead of %R
 > for consistency with its display in the mode line?

Well, %R isn't a user level change (mode-line-format is described in the
Elisp manual, not the Emacs manual).  I had thought there might be a clash
but there isn't, so I could do this as there is no cost.

Currently the double-end arrow pointer shape that indicates the mode-line
can be dragged obscures the character underneath.  How about the change
below?  I realise that Richard thinks that mixing the mouse and keyboard is
bad UI (although Emacs already does this from the menu-bar and, now with
vc-mode, from the mode-line with some VC commands) but it changes the
pointer shape to a hand and gives functionality consistent with the bindings
for the two previous characters on the mode line (mode-line-toggle-read-only
and mode-line-toggle-modified) which I think is good UI.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** bindings.el	23 Jul 2007 11:01:09 +1200	1.179
--- bindings.el	24 Jul 2007 10:24:57 +1200	
*************** corresponding to the mode line clicked."
*** 74,79 ****
--- 74,90 ----
      (force-mode-line-update)))
  
  
+ (defun mode-line-cd (event)
+   "Make DIR become the current buffer's default directory.
+ See `cd'."
+   (interactive "e")
+   (save-selected-window
+     (select-window (posn-window (event-start event)))
+     (let ((arg (read-from-minibuffer "Change default directory: ")))
+       (cd arg))
+     (force-mode-line-update)))
+ 
+ 
  (defun mode-line-widen (event)
    "Widen a buffer from the mode-line."
    (interactive "e")
*************** Normally nil in most modes, since there 
*** 250,265 ****
  
  (defvar mode-line-remote
    (list (propertize
! 	 "%1R"
  	 'help-echo (purecopy (lambda (window object point)
   				(format "%s"
  					(save-selected-window
  					  (select-window window)
  					  (concat 
! 					  (if (file-remote-p default-directory)
! 					      "Remote: "
! 					    "Local: ")
! 					  default-directory)))))))
    "Mode-line flag to show if default-directory for current buffer is remote.")
  
  (make-variable-buffer-local 'mode-line-remote)
--- 261,277 ----
  
  (defvar mode-line-remote
    (list (propertize
! 	 "%1@"
  	 'help-echo (purecopy (lambda (window object point)
   				(format "%s"
  					(save-selected-window
  					  (select-window window)
  					  (concat 
! 					  default-directory
! 					  ": mouse-1 changes")))))
! 	 'local-map (purecopy (make-mode-line-mouse-map
! 			       'mouse-1 #'mode-line-cd))
! 	 'mouse-face 'mode-line-highlight))
    "Mode-line flag to show if default-directory for current buffer is remote.")
  
  (make-variable-buffer-local 'mode-line-remote)

Re: mode-line with Tramp

[Nick Roberts]

 > Currently the double-end arrow pointer shape that indicates the mode-line
 > can be dragged obscures the character underneath.  How about the change
 > below?  I realise that Richard thinks that mixing the mouse and keyboard is
 > bad UI (although Emacs already does this from the menu-bar and, now with
 > vc-mode, from the mode-line with some VC commands) but it changes the
 > pointer shape to a hand and gives functionality consistent with the bindings
 > for the two previous characters on the mode line (mode-line-toggle-read-only
 > and mode-line-toggle-modified) which I think is good UI.

This drew no response.  The patch assigned mouse-1 over the mode-line flag for
default-directory to "cd", i.e., to change default-directory.  Assuming it was
unfavourable because it mixed the mouse and keyboard, how about extending
use-file-dialog, which applies to commands from menus and tool bar buttons, to
commands from the mode-line also?  That way default-directory could be changed
with the mouse alone.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Juri Linkov]

>  > Currently the double-end arrow pointer shape that indicates the mode-line
>  > can be dragged obscures the character underneath.  How about the change
>  > below?  I realise that Richard thinks that mixing the mouse and keyboard is
>  > bad UI (although Emacs already does this from the menu-bar and, now with
>  > vc-mode, from the mode-line with some VC commands) but it changes the
>  > pointer shape to a hand and gives functionality consistent with the bindings
>  > for the two previous characters on the mode line (mode-line-toggle-read-only
>  > and mode-line-toggle-modified) which I think is good UI.
>
> This drew no response.  The patch assigned mouse-1 over the mode-line flag for
> default-directory to "cd", i.e., to change default-directory.  Assuming it was
> unfavourable because it mixed the mouse and keyboard, how about extending
> use-file-dialog, which applies to commands from menus and tool bar buttons, to
> commands from the mode-line also?  That way default-directory could be changed
> with the mouse alone.

Maybe this should depend on the value of tooltip-mode?  When tooltip-mode
is on, then display the directory selection dialog.  When tooltip-mode is off,
then read the directory from the minibuffer.  The reason is that the user
sets it to off when the user prefers to use the minibuffer and echo area
(where tooltips are displayed when tooltip-mode is off).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: mode-line with Tramp

[Richard Stallman]

    This drew no response.  The patch assigned mouse-1 over the mode-line flag for
    default-directory to "cd", i.e., to change default-directory.  Assuming it was
    unfavourable because it mixed the mouse and keyboard, how about extending
    use-file-dialog, which applies to commands from menus and tool bar buttons, to
    commands from the mode-line also?  That way default-directory could be changed
    with the mouse alone.

I think it is not worth the trouble to implement it.  If we have some
specific reason to think this will help a lot of beginners, then let's
do it.  Otherwise, let's forget it.

Re: mode-line with Tramp

[Johan Bockgård]

Nick Roberts <nickrob@snap.net.nz> writes:

> OK I've committed a patch with "@".

The doc string needs a fix.


2007-07-27  Johan Bockgård  <bojohan@dd.chalmers.se>

	* buffer.c (syms_of_buffer) <mode-line-format>: Doc fix.



--- buffer.c	28 Jul 2007 00:47:36 +0200	1.530
+++ buffer.c	28 Jul 2007 00:45:59 +0200	
@@ -5501,7 +5514,7 @@
   %P -- print percent of buffer above bottom of window, perhaps plus Top,
         or print Bottom or All.
   %n -- print Narrow if appropriate.
-  %R -- print R or hyphen.  R means that default-directory is on a
+  %R -- print @ or hyphen.  @ means that default-directory is on a
         remote machine.
   %t -- visited file is text or binary (if OS supports this distinction).
   %z -- print mnemonics of keyboard, terminal, and buffer coding systems.


-- 
Johan Bockgård

Re: mode-line with Tramp

[Nick Roberts]

 > > OK I've committed a patch with "@".
 > 
 > The doc string needs a fix.

Thanks, I was waiting to see if there was support for my latest patch which
also fixes this.  As there wasn't, I'll just follow Juri's suggestion and use
%@.

 > 2007-07-27  Johan Bockgård  <bojohan@dd.chalmers.se>
 > 
 > 	* buffer.c (syms_of_buffer) <mode-line-format>: Doc fix.
 > 
 > 
 > 
 > --- buffer.c	28 Jul 2007 00:47:36 +0200	1.530
 > +++ buffer.c	28 Jul 2007 00:45:59 +0200	
 > @@ -5501,7 +5514,7 @@
 >    %P -- print percent of buffer above bottom of window, perhaps plus Top,
 >          or print Bottom or All.
 >    %n -- print Narrow if appropriate.
 > -  %R -- print R or hyphen.  R means that default-directory is on a
 > +  %R -- print @ or hyphen.  @ means that default-directory is on a
 >          remote machine.
 >    %t -- visited file is text or binary (if OS supports this distinction).
 >    %z -- print mnemonics of keyboard, terminal, and buffer coding systems.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line with Tramp

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> The code looks clean enough, and the feature could be useful.  We can
> spare one character.  Before deciding on it, I'd like to see reports
> from some users about whether they find it useful.

Do I count as user? I've tested it, and I find it useful.

Best regards, Michael.

Re: mode-line with Tramp

[Richard Stallman]

    Do I count as user? I've tested it, and I find it useful.

Of course you count.
But I'd like to hear from several users.