This is a test. It is only test. If this had been a real emergency, you would have been given unreliable information by the duly constituted authorities. As it is, there is no emergency, not, at any rate on the happenin' jed users list. -- -- Bob Bernstein
G. Milde schrieb: > The new version of svn.sl at http://jedmodes.sf.net/mode/svn/ is out and > brings: > > % 2007-12-11 * Key_Ins selects and moves down one line > % * vc_list_dir() did open a buffer even if dir not under vc > % * basic support for SVK (http://svk.bestpractical.com/) > % * edit log-message in a dedicated buffer > % * after commit, update all buffers that changed on disk When using the svn.sl from cvs, I have the following errors: 1. the directory list is opened in a read-only buffer, so no files can be marked. 2. when trying to commit a buffer, I get: Unable to typecast Array_Type to String_Type -- -- Gruß Joachim
I found the reason for this:
diff mode/svn/svn.sl svn.sl
1332c1332
< definekey("close_buffer", Key_Esc, log_mode);
---
> definekey_reserved("close_buffer", Key_Esc, log_mode);
in line 1333 of svn.sl
Joachim Schmitz schrieb:
> G. Milde schrieb:
>> The new version of svn.sl at http://jedmodes.sf.net/mode/svn/ is out and
>> brings:
>>
>> % 2007-12-11 * Key_Ins selects and moves down one line
>> % * vc_list_dir() did open a buffer even if dir not under vc
>> % * basic support for SVK (http://svk.bestpractical.com/)
>> % * edit log-message in a dedicated buffer
>> % * after commit, update all buffers that changed on disk
> When using the svn.sl from cvs, I have the following errors:
>
> 1. the directory list is opened in a read-only buffer, so no files can
> be marked.
>
> 2. when trying to commit a buffer, I get:
>
> Unable to typecast Array_Type to String_Type
>
--
--
Gruß Joachim
(Continue reading)
Dear Joachim, dear Jed users,
I wish you all a happy new year.
On 3.01.08, Joachim Schmitz wrote:
> I found the reason for this:
> diff mode/svn/svn.sl svn.sl
> 1332c1332
> < definekey("close_buffer", Key_Esc, log_mode);
> ---
> > definekey_reserved("close_buffer", Key_Esc, log_mode);
Actually, while this might prevent the error from occuring, it does not go
to the core of the problem.
> Joachim Schmitz schrieb:
>> G. Milde schrieb:
>>> The new version of svn.sl at http://jedmodes.sf.net/mode/svn/ is out and
>>> brings:
>>> % 2007-12-11 * Key_Ins selects and moves down one line
>>> % * vc_list_dir() did open a buffer even if dir not under vc
>>> % * basic support for SVK (http://svk.bestpractical.com/)
>>> % * edit log-message in a dedicated buffer
>>> % * after commit, update all buffers that changed on disk
A bugfix release is out (with some enhancements as well):
% 2007-12-18 * New functions: vc_subtract_selected(), vc_delete_selected,
% vc_commit_dir()
(Continue reading)
On 3.01.08, G. Milde wrote: > >> 2. when trying to commit a buffer, I get: > >> Unable to typecast Array_Type to String_Type > This is fixed in the current release. I proved myself wrong. Commiting a buffer did not only suffer from the bug fixed in % 2007-12-18 * remove spurious arg in vc_commit_finish() but also another one, fixed only today: % 2008-01-03 * bugfix: swapped arguments in vc_commit_buffer() Sorry for any inconvenience. GM
G. Milde schrieb:
> On 3.01.08, G. Milde wrote:
>
>>>> 2. when trying to commit a buffer, I get:
>>>> Unable to typecast Array_Type to String_Type
>
>> This is fixed in the current release.
>
> I proved myself wrong. Commiting a buffer did not only suffer from
> the bug fixed in
>
> % 2007-12-18 * remove spurious arg in vc_commit_finish()
>
> but also another one, fixed only today:
>
> % 2008-01-03 * bugfix: swapped arguments in vc_commit_buffer()
>
> Sorry for any inconvenience.
Thank You for the good work.
On my system this modification is still necessary:
diff mode/svn/svn.sl svn.sl
1333c1333
< definekey("close_buffer", Key_Esc, log_mode);
---
> definekey_reserved("close_buffer", Key_Esc, log_mode);
Also I notice the following inconvenience:
(Continue reading)
On 3.01.08, Joachim Schmitz wrote:
> On my system this modification is still necessary:
> diff mode/svn/svn.sl svn.sl
> 1333c1333
> < definekey("close_buffer", Key_Esc, log_mode);
> ---
> > definekey_reserved("close_buffer", Key_Esc, log_mode);
I could trace this down to a bug in x-keydefs.sl
Either use version 1.7 of x-keydefs.sl or set in your jed.rc::
variable Key_Esc = "\e\e\e";
(this is the default in cua emulation and therefore I missed to detect
the bug).
> Also I notice the following inconvenience:
> after committing a file the buffers are now reloaded, if they change on
> disk, which is always the case, if one uses the $id$ tag. this is good but
> it should do this, without asking everytime.
What does it ask?
> Also the result of the commit is not shown,
This is intended - if the commit is successfull.
(Continue reading)
G. Milde schrieb:
> On 3.01.08, Joachim Schmitz wrote:
>
>> On my system this modification is still necessary:
>
>> diff mode/svn/svn.sl svn.sl
>> 1333c1333
>> < definekey("close_buffer", Key_Esc, log_mode);
>> ---
>>> definekey_reserved("close_buffer", Key_Esc, log_mode);
>
> I could trace this down to a bug in x-keydefs.sl
>
> Either use version 1.7 of x-keydefs.sl or set in your jed.rc::
>
> variable Key_Esc = "\e\e\e";
>
> (this is the default in cua emulation and therefore I missed to detect
> the bug).
>
This is fixed now.
>
>> Also I notice the following inconvenience:
>
>> after committing a file the buffers are now reloaded, if they change on
>> disk, which is always the case, if one uses the $id$ tag. this is good but
>> it should do this, without asking everytime.
>
> What does it ask?
File changed on disk, reload (yes/no)
(Continue reading)
On a remote machine I edited with jed a text-file (IDS.txt) when the link went down. No problem, I tought, I can use recover_file() within jed. But when I logged in again and called jed with that file I saw no message: "Autosave file is newer. Use ESC-X recover_file. (IDS.txt)" as expected. The problem is: I edited the file via a symbolic link! lanldap1:~: l IDS.txt lRWX - 06-07-05 18:11 IDS.txt -> /opt/doc/IDS/IDS.txt lanldap1:~: jed IDS.txt In this case jed does not offer the recover-function. Only when I call jed with the direct file name: lanldap1:~: l /opt/doc/IDS/*IDS* -(Continue reading)RW- 16,086 08-01-04 17:21 /opt/doc/IDS/#IDS.txt# -RW- 15,331 08-01-02 17:12 /opt/doc/IDS/IDS.txt -RW- 14,917 08-01-02 16:25 /opt/doc/IDS/IDS.txt~ lanldap1:~: jed /opt/doc/IDS/IDS.txt then I get: "Autosave file is newer. Use ESC-X recover_file. (IDS.txt)"
Ulli Horlacher <framstag <at> rus.uni-stuttgart.de> wrote: > The problem is: I edited the file via a symbolic link! [...] > In this case jed does not offer the recover-function. [...] > Is this a bug? Yes. I am testing a patch now and if it works out, I will check-in the change this weekend. Thanks, --John
RSS Feed6 | |
|---|---|
27 | |
6 | |
2 | |
1 | |
30 | |
18 | |
18 | |
6 | |
15 | |
10 | |
3 | |
7 | |
19 | |
6 | |
7 | |
22 | |
34 | |
20 | |
34 | |
19 | |
4 | |
7 | |
42 | |
41 | |
5 | |
8 | |
1 | |
9 | |
4 | |
11 | |
3 | |
25 | |
21 | |
10 | |
5 | |
11 | |
33 | |
14 | |
10 | |
3 | |
20 | |
19 | |
15 | |
24 | |
15 | |
32 | |
24 | |
20 | |
3 | |
10 | |
31 | |
11 | |
11 | |
7 | |
10 | |
20 | |
28 | |
30 | |
19 | |
31 | |
10 | |
51 | |
90 | |
102 | |
23 | |
6 | |
19 | |
6 | |
28 | |
17 | |
48 | |
50 | |
44 | |
59 | |
74 | |
68 | |
82 | |
52 | |
155 | |
16 | |
35 | |
80 | |
55 | |
44 | |
37 | |
30 | |
52 | |
58 | |
83 | |
57 | |
14 | |
37 | |
14 |
