file centric ecb layout?

Hello,

I was just thinking about if there exists some file centric layout for
ECB? I tried looking around the documentation and didnt find this.

Here is what im thinking about:

- The layout would look something like "midnight commander" but would
be emacs specific and support dired.
There would be a left and right pane, and there would be a dired in
each view.

- there would be an ecb command to quickly change layout from
  code-specific to file-specific, using the normal ecb commands for
  this. 

- change between dired and tree view in a pane

- switch left and right panes

- move files from left pane to right pane

There are several midnight/norton commander clones for emacs, but they
either dont work, or they do not use dired. Also, they try to emulate
too closely the "commander" idea, withouth bringing the power of the
emacs paradigm to the table.

Dired is very nice, because there is wdired for editing names, and
many other nice things.

AW: file centric ecb layout?

AW: nice ascii trees with asci symbols

Re: AW: file centric ecb layout?

<klaus.berndl <at> sdm.de> writes:

> first of all please excuse my late answer - i'm quite bussy...

Shure! We all are, so I understand completely.

> Could you please provide an ascii-screenshot what you have in mind
> exactly? You could use the following as starting-point.... 
>

Well, Ok 

    --------------------------+----------------------------
    |                         |                           |
    |  Dired                  | Dired                     |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    |                         |                           |
    --------------------------+----------------------------

I havent thought so much about how this can be made to work nicely
with ecb:s other facilities. The main point is that this view is
completely file oriented, and you want max screen estate for that. 

Then, maybe, one could have other "frames" for shells or stuff. 
>
> The main-purpose of ECB is browsing code therefore the name
> Emacs Code Browser  For this ECB offers some "basic" directory and
> files browsing features but mostly but all driven by the sake of browsing
> code... ECB will not include these features you mentioned in a native
> way, i.e. ECB will not implement this by itself.

That is understood, and a good decision.

> But if you (or anybody else  know or write a package which offers
> two different dired-windows side by side which are smartly linked
> together (e.g. which allow such midhight-
> commander-tasks like coping files from one side to the other etc...) then
> i will make ECB to run these package in a smooth and homogen way from
> within ECB - so for example activating this package could automatically
> hide the tree-buffers of ECB to offer max. space for the two dired
> windows or other senseful intergration-goodies.
> So in general ECB will do all necessary stuff to run other package well
> and smooth within the ECB-frame but it will no implement a special
> midnight-commander or special dired-gui.
>
> What do you think about this approach?

Yes, quite alright.

Guess I have some ECB documentation studying to do if I want to
achieve this!

I guess I need to find functions to:
- create a layout ecb-layout-define
- make a dired go in the "left" and "right" pane
- function to find buffer associated with "left" and "right" pane
- function to change which buffer to see in a pane

That would basically be it, no?

> Ciao,
> Klaus
>

--
Joakim Verona
www.verona.se

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: AW: file centric ecb layout?

>> first of all please excuse my late answer - i'm quite bussy...
> 
> Shure! We all are, so I understand completely.

Well, glad to hear that i'm not the only poor boy who must wasting its
time with business 

>     --------------------------+----------------------------
>     |                         |                           |
>     |  Dired                  | Dired                     |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     |                         |                           |
>     --------------------------+----------------------------
> 
> 
> I havent thought so much about how this can be made to work nicely
> with ecb:s other facilities. The main point is that this view is
> completely file oriented, and you want max screen estate for that.
> Guess I have some ECB documentation studying to do if I want to
> achieve this!
> 
> I guess I need to find functions to:
> - create a layout ecb-layout-define
> - make a dired go in the "left" and "right" pane
> - function to find buffer associated with "left" and "right" pane

What do you means here?

> - function to change which buffer to see in a pane
> 
> That would basically be it, no?

Hmm, refering to your "screenshot" above (well, nicely drawn , i think the
main-problem with your project is, that current layout-engine and related API
needs an edit-area, means an area which can be used for arbitrary not-special
windows - all special windows in an ecb-layout have to be dedicated windows
(dedicated to buffers)!...so there arte two approaches:

1. You want to define the left and right pane as "special" in this sense of ECB
   which then follows the need for the two windows of being dedicated to the
   dired-buffers - but then: where is the edit-area which is needed currently
   by the layout-engine of ECB (at least one editing window must exists)

2. You use the current editing-area of ECB for your tool, means split the
   editing area into two windows side by side, put a dired within etc...
   For this the special-tree-buffer-pane of ECB has to be temporally hidden
   what is already possible (see `ecb-hide-ecb-windows'). These windows must
   NOT being dedicated to their dired-buffers.

What would you prefer (assumed we can enhance ECB's layout engine so no
edit-window is needed, also 1. should be possible)?
BTW: Your suggestion drives me to check how many effort it would be to
allow layouts without an edit-area - which could be really useful.....
I will try to investigate in the next days....................

Klaus

> 
> 
> 
>> Ciao,
>> Klaus

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

Re: AW: file centric ecb layout?

<klaus.berndl <at> sdm.de> writes:

> Well, glad to hear that i'm not the only poor boy who must wasting its
> time with business 

No, I also share this horrid fate 

>>
>> I guess I need to find functions to:
>> - create a layout ecb-layout-define
>> - make a dired go in the "left" and "right" pane
>> - function to find buffer associated with "left" and "right" pane
>
> What do you means here?
>
>> - function to change which buffer to see in a pane
>>
>> That would basically be it, no?
>
> Hmm, refering to your "screenshot" above (well, nicely drawn , i think the

 I got to use Artist-mode so it was effort well spent!

> main-problem with your project is, that current layout-engine and related API
> needs an edit-area, means an area which can be used for arbitrary not-special
> windows - all special windows in an ecb-layout have to be dedicated windows
> (dedicated to buffers)!...so there arte two approaches:
>
> 1. You want to define the left and right pane as "special" in this sense of ECB
>    which then follows the need for the two windows of being dedicated to the
>    dired-buffers - but then: where is the edit-area which is needed currently
>    by the layout-engine of ECB (at least one editing window must exists)

Well, maybe that would be useful.

+-----------------------------------------+
|                                         |
|                                         |
|          Edit area                      |
|                                         |
|                                         |
+--------------------+--------------------+
|                    |                    |
|                    |                    |
|   Left dired       |   Right dired      |
|                    |                    |
|                    |                    |
|                    |                    |
|                    |                    |
+--------------------+--------------------+

When you enter the dired/ecb view, the edit area is preserved, and the
left pane could be set to the workdir defined by the edit area, like
the standard ecb filepanes work today. That would be useful.

Ill start this way, and then take advantage of your new
edit-window-less layout possibility if/when it is available.

> 2. You use the current editing-area of ECB for your tool, means split the
>    editing area into two windows side by side, put a dired within etc...
>    For this the special-tree-buffer-pane of ECB has to be temporally hidden
>    what is already possible (see `ecb-hide-ecb-windows'). These windows must
>    NOT being dedicated to their dired-buffers.

Hmm this aproach doesnt feel right, because the convenience of the
Commander paradigm relies on the panes having special meaning, which
they wont with this aproach.

> What would you prefer (assumed we can enhance ECB's layout engine so no
> edit-window is needed, also 1. should be possible)?
> BTW: Your suggestion drives me to check how many effort it would be to
> allow layouts without an edit-area - which could be really useful.....
> I will try to investigate in the next days....................
>
> Klaus
>
>>
>>
>>
>>> Ciao,
>>> Klaus

--
Joakim Verona
www.verona.se

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

ecb bug

Hello,

I have reported this bug previously.
I have now made tiny progress in localizing the bug.

The error occurs in the condition-case in ecb that ends like this:
            "Errors during the layout setup of ECB."
This is around line 1805-1852.

The error reported is "Wrong type argument: stringp, nil"
which matches this error in *messages*:
tramp-tramp-file-p: Wrong type argument: stringp, nil

When I get this error, ecb-activate fails, and ecb-deactivate doesnt
help.

If I comment out the condition-case, ECB starts, that is, displays its
layout. all windows look ok, except the file window, which seems
consistent with the tramp error.

Regards,
--

-- 
Joakim Verona
www.verona.se

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

ecb-error

Hello, 
I was facing errors when using ecb with my xemacs (SuSE 9.2, 21.4.15) using 
ecb (2.11). As already reported to this list some time ago, my xemacs becomes 
awfully slow and ecb doesnot list correctly members. 

Sorry for this longer mail. 

I have found some reasons/behaviours of ecb:

using std:: templates such as vector<string> 
 1. awfully slow down ecb 
 2. somehow disturbs the method buffer. 
e.g. for a file
----
namespace A{
	vector<string> a;
	void foo()
	{
	}
}
---
A::foo() and A::a would not be shown.  (I supect it's the use of '<' and '>').
also if A consists of e.g. 2000 lines after definition of "vector<string> a" 
ecb takes 10 sek. to reparse the method buffer after saving and does not show 
any function of the namespace. 

In the following nothing is shown in the mehtods' buffer (here it's the return 
value of foo1)
------
namespace A{

	vector<string> foo1()
	{
        }

	void foo()
	{
	}
}
----

In the following A:foo1 () is shown in the mehtods' buffer, but nothing more:
------
namespace A{
	void foo1()
	{
         };
	vector<string> a;
	void foo()
	{
	}
}
-----

In the following nothing is shown in the mehtods' buffer
------
namespace A{
	void foo1();
	vector<string> a;
	void foo()
	{
	}
}
-----

Is this behaviour intended? Or can I make use of a different ecb-option? I 
also tried the latest cygwin distro of xemacs under windows. it's the same. 

Thanks for your hints!
Michael 

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: ecb-error

Hello,

first of all: ECB 2.11 is fully outdated, current is ECB 2.31 -
see http://ecb.sf.net. Then is the question which semantic-version
you are using?

In general i can only recommend upgrading ECB and probably also semantic -
for the latter one you should use latest cedet-suite - see http://cedet.sf.net.

Ciao,
Klaus

Michael Schuster wrote:
> Hello,
> I was facing errors when using ecb with my xemacs (SuSE 9.2, 21.4.15)
> using ecb (2.11). As already reported to this list some time ago, my
> xemacs becomes awfully slow and ecb doesnot list correctly members.
> 
> Sorry for this longer mail.
> 
> I have found some reasons/behaviours of ecb:
> 
> using std:: templates such as vector<string>
>  1. awfully slow down ecb
>  2. somehow disturbs the method buffer.
> e.g. for a file
> ----
> namespace A{
> 	vector<string> a;
> 	void foo()
> 	{
> 	}
> }
> ---
> A::foo() and A::a would not be shown.  (I supect it's the use of '<'
> and '>'). also if A consists of e.g. 2000 lines after definition of
> "vector<string> a" ecb takes 10 sek. to reparse the method buffer
> after saving and does not show any function of the namespace.
> 
> In the following nothing is shown in the mehtods' buffer (here it's
> the return value of foo1)
> ------
> namespace A{
> 
> 	vector<string> foo1()
> 	{
>         }
> 
> 	void foo()
> 	{
> 	}
> }
> ----
> 
> In the following A:foo1 () is shown in the mehtods' buffer, but
> nothing more: ------
> namespace A{
> 	void foo1()
> 	{
>          };
> 	vector<string> a;
> 	void foo()
> 	{
> 	}
> }
> -----
> 
> In the following nothing is shown in the mehtods' buffer
> ------
> namespace A{
> 	void foo1();
> 	vector<string> a;
> 	void foo()
> 	{
> 	}
> }
> -----
> 
> 
> Is this behaviour intended? Or can I make use of a different
> ecb-option? I also tried the latest cygwin distro of xemacs under
> windows. it's the same. 
> 
> Thanks for your hints!
> Michael
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users. Discover which products truly live up to the hype. Start
> reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Ecb-list mailing list
> Ecb-list <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecb-list

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

RE: AW: ecb-error

Michael Schuster wrote:
> Am Dienstag, 22. Februar 2005 14:03 schrieb klaus.berndl <at> sdm.de:
>>>> In general i can only recommend upgrading ECB and probably also
>>>> semantic - for the latter one you should use latest cedet-suite -
>>>> see http://cedet.sf.net.
>>> 
>>> this one doesn't work with my xemacs.
>> 
>> which version of XEmacs you use??
> I use 21.4.15 (coming with suse).
> I use 21.4.15 (coming with cygwin).

with this versions of XEmacs ECB should work well....

> Anyway, do you have any Idea, why xemacs isn't working as it should
> with the linux distro?

no, but if you have performance-issues with ECB/semantic/cedet should
also write a report to the cedet-mailing list - often some default-
setting of semantic/cedet can slow down XEmacs/Emacs dramatically...

> 
>> ECB works with GNU Emacs even better as with XEmacs - or lets say
>> with other words: ECB works well with both XEmacs and Emacs but it
>> is developed in an GNU Emacs-environment ... 
> I'll try. Is there a howto somewhere (to install?)

cedet or ECB? For the latter one see the http://ecb.sf.net and section
"Installation" - if you find some instruction not clear or misunderstandable
then please report - and i will try to enhance the instructions!

Klaus

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click