headers
Paul Lamb | 7 Mar 2008 15:15
Picon
Picon
Favicon

Autosaved file is not being created (sometimes)

Using jed-0.99.16-6 on RHEL5.1 
   if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
   if I edit a file 1.tmp, an autosaved version 1.tmp~ is created.

Using jed-0.99.18-5 on RHEL5.1 
   if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
   if I edit a file 1.tmp, an autosaved file version is NOT created.

The ~/.jedrc are identical.

Any suggestions would be appreciated.

Paul Lamb

------------------------------------------------------------------------
Dr Paul Lamb, Head of Computing
Mullard Space Science Laboratory
University College London
Holmbury St. Mary
Dorking
Surrey
RH5 6NT
UK

Email: pal <at> mssl.ucl.ac.uk
Tel:   +44 (0) 1483 204 136
Fax:   +44 (0) 1483 278 312
Permalink | Reply | 3 comments |
headers
Jörg Sommer | 7 Mar 2008 16:54
Picon

Re: Autosaved file is not being created (sometimes)

Hallo Paul,

Paul Lamb <pal <at> mssl.ucl.ac.uk> wrote:
> Using jed-0.99.16-6 on RHEL5.1 
>    if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
>    if I edit a file 1.tmp, an autosaved version 1.tmp~ is created.
>
> Using jed-0.99.18-5 on RHEL5.1 
>    if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
>    if I edit a file 1.tmp, an autosaved file version is NOT created.
>
> The ~/.jedrc are identical.
>
> Any suggestions would be appreciated.

Did the system configuration changed? What's the value of No_Backups? Use
^Hv to view it?

Bye, Jörg.
--

-- 
Wir leben zwar unter dem gleichen Himmel,
müssen aber nicht zwangsläufig den gleichen Horizont haben.
Permalink | Reply | 0 comments |
headers
Paul Lamb | 7 Mar 2008 21:18
Picon
Picon
Favicon

Re: Autosaved file is not being created (sometimes)

>From:	SMTP%"joerg <at> alea.gnuu.de"  7-MAR-2008 17:34:02.79
>
>Hallo Paul,
>
>Paul Lamb <pal <at> mssl.ucl.ac.uk> wrote:
>> Using jed-0.99.16-6 on RHEL5.1=20
>>    if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
>>    if I edit a file 1.tmp, an autosaved version 1.tmp~ is created.
>>
>> Using jed-0.99.18-5 on RHEL5.1=20
>>    if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
>>    if I edit a file 1.tmp, an autosaved file version is NOT created.
>>
>> The ~/.jedrc are identical.
>>
>> Any suggestions would be appreciated.
>
>Did the system configuration changed? What's the value of No_Backups? Use
>^Hv to view it?
>
>Bye, Joerg

Hi Joerg,

In each case:-
	Integer_Type No_Backups: value = 0
	No_Backups: Undocumented  and unknown

Paul
(Continue reading)

Permalink | Reply | 0 comments |
headers
John E. Davis | 7 Mar 2008 22:33
Picon
Favicon

Re: Autosaved file is not being created (sometimes)

Paul Lamb <pal <at> mssl.ucl.ac.uk> wrote:
> Using jed-0.99.16-6 on RHEL5.1 
>    if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
>    if I edit a file 1.tmp, an autosaved version 1.tmp~ is created.
>
> Using jed-0.99.18-5 on RHEL5.1 
>    if I edit a file 1.qqq, an autosaved version 1.qqq~ is created.
>    if I edit a file 1.tmp, an autosaved file version is NOT created.

In version 0.99-18, files of the form /tmp/foo and /whatever/bar.tmp are
regarded as temporary files and not backed up.  You can put

define make_backup_filename(dir, file)
{
   return strcat (dir, file, "~");
}

in your .jedrc file if you do not like this behavior.

Thanks,
--John
Permalink | Reply | 1 comment |
headers
Tom Culliton | 10 Mar 2008 21:04
Picon

Re: Making compile mode smarter?

Here is another one, along the same lines...

I've set up external builds using scons, but because of the way they work
all of the compiler messages are for paths under the build output
directory rather than my revision control client directory.  It seems like
mapping the one to the other should be fairly trivial and possibly even
common.  Anyone done something like this with jed before?
Permalink | Reply | 1 comment |
headers
G. Milde | 11 Mar 2008 09:26
Picon

Re: Making compile mode smarter?

On 10.03.08, Tom Culliton wrote:

> I've set up external builds using scons, but because of the way they work
> all of the compiler messages are for paths under the build output
> directory rather than my revision control client directory.  It seems like
> mapping the one to the other should be fairly trivial and possibly even
> common.  Anyone done something like this with jed before?

You might have a look at Paul Boekholts ffap (find file at point) under
http://jedmodes.sf.net/mode/ffap and            
http://jedmodes.sf.net/mode/ffap/ffap.sl

GM
Permalink | Reply | 0 comments |
headers
s78199mpf15f05 | 17 Mar 2008 21:12
Picon

tab as ^I

Hello Folks, 

Is there a way to let tabs display as control codes? 

Thanks for any suggestion. 

Frank
Permalink | Reply | 2 comments |
headers
G. Milde | 18 Mar 2008 09:03
Picon

Re: tab as ^I

On 17.03.08, s78199mpf15f05 <at> eca.co.za wrote:
> Hello Folks, 

> Is there a way to let tabs display as control codes? 

> Thanks for any suggestion. 

Set TAB to 0, e.g. by M-X  TAB = 0;

TAB is buffer-local, to get this for all new created buffers use TAB_DEFAULT.
    See Help>Describe Variable TAB 
(and ... TAB_DEFAULT) for details.

If you want this all the time, set TAB_DEFAULT in your jed.rc.
If you want it for some modes, use a mode hook to set TAB.

Guenter
Permalink | Reply | 0 comments |
headers
Jörg Sommer | 17 Mar 2008 23:07
Picon

Re: tab as ^I

s78199mpf15f05 <at> eca.co.za <s78199mpf15f05 <at> eca.co.za> wrote:
> Hello Folks, 
>
> Is there a way to let tabs display as control codes? 

Set TAB=0.

Schöne Grüße, Jörg.
--

-- 
< Mr X.> jo: contact an admin to mount it for you
< jo> The admin is not, well how should I say it, he isn't very familiar with
      the system. What should I tell my admin, what he should do?
< Mr X.> taking a sun solaris administration course.
Permalink | Reply | 0 comments |
headers
s78199mpf15f05 | 20 Mar 2008 19:18
Picon

set_color ("tab", color_fg, color_bg)


Hello Folks, 

Although 

  set_color ("tab", color_fg, color_bg); 

is accepted in the colour settings for the text console,
it is not executed. 

For instance it should be 

   black/brightcyan  for  default1.sl
   yellow/black      for  black1.sl 

but it simply doesn't work in no_mode and text_mode. Even
old syntax c_mode fails despite repeating the set_color
command in c_mode.sl. 

There are traces of this problem in past mailings, actually
rather for trailing whitespace. They wouldn't help in this
case. 

Am I overlooking something? 

Thanks! 

Frank
(Continue reading)

Permalink | Reply | 1 comment |

Gmane