Newsgroup: it.comp.java
Titolo: Editor per progetto java in Linux

Vorrei sapere se, per Linux, esiste qualche buon EDITOR (non un
compilatore, quello preferisco farlo con degli script "a mano") per
java (tipo ConTEXT, che però esiste solo per Windows).
Preciso subito che quello che mi interessa è la possibilità di
definire un unico progetto, formato da più file, che possano anche
essere aperti contemporaneamente in modo da passare rapidamente, quando
serve, da un file all'altro, e soprattutto avendo la possibilità di
fare un "find &replace" in tutto il progetto, senza dover ripetere
l'operazione in (magari) 50 files. Ovviamente, che vengano visualizzati
con diversi colori commenti, parole chiave, ecc.
Tutti gli editor consigliati in rete che ho provato supportavano
l'apertura di un file per volta; al momento ho scartato anche programmi
tipo Eclipse e simili indirizzati anche alla compilazione, per una
serie di ragioni che non sto qui a spiegare.



Io ti consiglierei vivamente NetBeans, ma visto che non vuoi un IDE troppo
impegnativo e indirizzato alla compilazione, potresti provare con Anjuta!
-- 
      ______________
(*)--[::::::::::::::]--(*)
(*)--[>::d1s4st3r::<]--(*)
(*)--[::::::::::::::]--(*)
(*)--[::wonder'ing::]--(*)
(*)--[::what's::::::]--(*)
(*)--[::^happening::]--(*)
(*)--[::|^::::::::::]--(*)
(*)--[__||__________]--(*)
 |......................|
http://xoomer.virgilio.it/
 +------> mental_insomnia/
(*) <-------------------+

c'è anche jedit
http://www.jedit.org/
saluti

Vi ringrazio dei suggerimenti. Dei due programmi indicati, quello che
si avvicina di più alle mie esigenze è anjuta, che però sembra pù
indirizzato al C/C++, con il risultato che nessuno dei file aperti
compare nella colonna "Progetto"; in questo modo non è del tutto
agevole passare da un file all'altro. Inoltre mi ero abituato, con
ConTEXT, a tenere aperti solo i file che usavo più spesso, senza che
gli altri venissero eliminati dal progetto. In questo modo basta
cliccare sul nome del file nella lista per aprirlo o chiuderlo.
Lo so, sono incontentabile...

Guarda bene JEdit... è altamente configurabile e modulare con una
grande quantità di plugin installabili. Lo puoi configurare in modo
che si comporti come preferisci: dal semplice editor di testo fino a
farlo divenire un IDE di tutto rispetto. Per la gestione di progetti
esiste il plugin ProjectViewer.
S

Nessuno ti obbliga ad usare Eclipse o Jdeveloper o IntellijIdea o
simili per compilare. Puoi usare ant o maven o (ba)sh o qquello che ti
pare sia dentro che fuori dall' ambiente Eclipse e limitarti ad usare
eclipse come "editor".
Ciao
Renato

Ciao, non ho da consigliarti alcun ide, ma sono curioso di capire, se
hai tempo e voglia, perché preferisci non usare editor molto evoluti.
ciao

 writes:
M> Vorrei sapere se, per Linux, esiste qualche buon EDITOR (non un
M> compilatore, quello preferisco farlo con degli script "a mano") per
M> java (tipo ConTEXT, che però esiste solo per Windows).
M> Preciso subito che quello che mi interessa è la possibilità di
M> definire un unico progetto, formato da più file, che possano anche
M> essere aperti contemporaneamente in modo da passare rapidamente,
M> quando serve, da un file all'altro, e soprattutto avendo la
M> possibilità di fare un "find &replace" in tutto il progetto, senza
M> dover ripetere l'operazione in (magari) 50 files. Ovviamente, che
M> vengano visualizzati con diversi colori commenti, parole chiave,
M> ecc.
M> Tutti gli editor consigliati in rete che ho provato supportavano
M> l'apertura di un file per volta; al momento ho scartato anche
M> programmi tipo Eclipse e simili indirizzati anche alla
M> compilazione, per una serie di ragioni che non sto qui a spiegare.
Emacs + J2EE.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 writes:
M> Tutti gli editor consigliati in rete che ho provato supportavano
M> l'apertura di un file per volta; al momento ho scartato anche
M> programmi tipo Eclipse e simili indirizzati anche alla
M> compilazione, per una serie di ragioni che non sto qui a spiegare.
GUL> Emacs + J2EE.
Correzione,   sbagliato  a   digitare,  è   JDEE   (Java  Developement
Environment for Emacs).


 l'operazione in (magari) 50 files. Ovviamente, che vengano visualizzati
ah... allora netbeans non va bene.
sono un sostenitore di netbeans ma leggetevi un po' questo bug, se avete
tempo per intero... fa veramente ridere (per non piangere):
http://www.netbeans.org/issues/show_bug.cgi?id=18237

 writes:
as> Ciao, non ho da consigliarti alcun ide, ma sono curioso di capire,
as> se hai tempo e voglia, perché preferisci non usare editor molto
as> evoluti.
La _mia_ risposta alla tua domanda:
Le  IDE hanno  editor  primordiali, troppo  tempo programmatore  viene
speso per  tutto ciò che non  è editor e  quest'ultimo rimane limitato
(nonostante  campanelle  e  fischietti)  Quando mi  trovo  davanti  un
progetto che i  colleghi gestiscono con Eclipse io  Eclipse lo uso per
il debugger e per preparare i war/ear.
Per il resto uso un editor che  ha passato la trentina e che, dato che
è programmabile,  non mi fa mancare  nulla degli editor  delle IDE. Ma
che come editor è anni luce avanti.


> visualizzati
m> ah... allora netbeans non va bene.
Più che altro, netbeans è in grado di fare tutto questo su file che non
siano Java ?


 siano Java ?
il find se lo fai nella "finestrella" file lo fa su tutti i file di
progetto come ci si aspetterebbe... il problema e' il replace che proprio
non lo fa... e che problema! una roba epica, mai affrontata prima da
nessuno... siamo gia' a 4 anni di analisi ed e' ancora arduo vedere la
fine. mica roba da ridere....
le altre funzioni richieste mi sembra ci siano tutte... sempre che non si
debba forzare l'encoding di lettura di un file ovviamente.
ma son dettagli, fastidiosi, ma dettagli.

> non siano Java ?
m> il find se lo fai nella "finestrella" file lo fa su tutti i file di
m> progetto come ci si aspetterebbe... 
Quindi  devi mettere  i  file in  un  progetto anche  se con  netbeans
c'entrano come i cavoli a merenda ?
m> il problema e' il replace che
m> proprio non lo fa... e che problema! una roba epica, mai affrontata
m> prima da nessuno... siamo gia' a 4 anni di analisi ed e' ancora
m> arduo vedere la fine. mica roba da ridere....
Mica roba da ridere ?
Magari andarsi a riguardare etags...
(Nota, anche senza indicizzare i sorgenti con etags, cosa che è utile
 a livello di progetto, Unix e sopratutto GNU mettono a disposizione
 tool che fanno cose veramente toste, da una trentina di anni...)


 Magari andarsi a riguardare etags...
che c'entra etags con uno stupido find/replace su file che nessuno ha
voglia d'implementare?

Ciao,
forse non ho capito, scrivi di ritenere che l'editor di un prodotto
come eclipse sia primordiale?
S.

> Magari andarsi a riguardare etags...
m> che c'entra etags con uno stupido find/replace su file che nessuno
m> ha voglia d'implementare?
Che ci  sono editor che lo usano  e per fare in  modo efficente questa
cosa.  Forse  nessuno a  voglia  di  implementare quella  funzionalità
perché, sopratutto sotto Unix e quindi GNU/(whatever) è fatica buttata
via per reimplementare in modo _poco_flessibile_ quello che già esiste
ed è flessibile...


 writes:
S> Ciao, forse non ho capito, scrivi di ritenere che l'editor di un
S> prodotto come eclipse sia primordiale?
L'editor di un prodotto come  eclipse *è* primordiale, le sue capacità
di  editing sono *molto*  limitate. E  gli automatismi  che dovrebbero
semplificarti  la vita te  la complicano  in quanto  si attivano  e ti
disturbano quando vogliono loro e non quando a te serva che lavorino.
Non so,  forse ad uno che  usa la tastiera  con i soli indici  e molta
calma la  cosa non infastidisce, ma  ad uno che oramai  ha imparato ad
usare più  dita della  mano un  editor che si  ferma perché  deve fare
uscire una finestrella è una vera iattura.


 cosa.  Forse  nessuno a  voglia  di  implementare quella  funzionalità
scomodare etags/ctags per fare un find/replace di una stringa in piu' file
e' flessibilita'? *tags lavorano su file contenti codice... non vedo come
possa migliorare l'efficienza nel caso suddetto visto che si parla di file
generici....??? mi son perso qualcosa?

> cosa.  Forse nessuno a voglia di implementare quella funzionalità
m> scomodare etags/ctags per fare un find/replace di una stringa in
m> piu' file e' flessibilita'? *tags lavorano su file contenti
m> codice... non vedo come possa migliorare l'efficienza nel caso
m> suddetto visto che si parla di file generici....??? mi son perso
m> qualcosa?
ETAGS è utile per migliorare l'efficenza con una serie di tipi di file
e  serviva  al search  &  replace  con questi  tipi  di  file in  modo
efficiente (usa un indice). Ha  il vantaggio che può essere utilizzato
direttamente dall'editor.  Lo usai  anni fa ed  era molto  comodo, non
tanto per il  semplice search & replace quanto  per inseguire l'uso di
un certo simbolo.
Negli  altri casi  (di search  and replace  su più  file)  si rinuncia
all'efficienza e si ricorre a quanto la shell mette a disposizione.
Personalmente non uso  sed, preferisco usare un editor  a caso :) come
server (visto che permette di  farlo) in quanto posso fare qualcosa di
più (o più probabilmente qualcosa che non ho imparato a fare in sed).


 uscire una finestrella è una vera iattura.
Niente di tutto questo, si direbbe che tu eclipse non lo conosca.
S.

 uscire una finestrella è una vera iattura.
è anche giusto che un programmatore abbia una macchina decente su cui
lavorare.
in tal caso, la comparsa del tooltip di autocompletamento è istantanea.
e se sei veramente così veloce, il tooltip non compare neanche.
quindi tu *non* scrivi veramente veloce :)))
ciao
gl

 all'efficienza e si ricorre a quanto la shell mette a disposizione.
io il search/replace lo voglio nell'ide perche' ritengo sia una cosa che un
ide deve fare. se andiamo a scomodare la shell allora non parliamo piu' di
ide pero'...
che un find/sed/awk/tr/grep/.... offrano una gamma di opzioni maggiore di
un search/replace implementato in un ide non c'e' dubbio ma io non cerco
questo genere di "flessibilita'", io cerco un buon compromesso tra
flessibilita' e usabilita' e per fare uno straccio di replace la shell non
e' il massimo.

> all'efficienza e si ricorre a quanto la shell mette a disposizione.
m> io il search/replace lo voglio nell'ide perche' ritengo sia una
m> cosa che un ide deve fare. se andiamo a scomodare la shell allora
m> non parliamo piu' di ide pero'...
Sai che titolo diedero al loro libro su Unix Kernighan e Pike:
The Unix development environment.
Il sistema  stesso è una  potente IDE a  saperlo usare bene, ed  con i
tool di  GNU ancora meglio.   Dirai che c'è  molto da fare  per imple-
mentare gli automatismi di una  ide. Verissimo, meno male che lo hanno
già fatto.
m> compromesso tra flessibilita' e usabilita' e per fare uno straccio
m> di replace la shell non e' il massimo.
Uno straccio no, uno massivo  si. Dipende molto dalla abitudine che ci
si è fatti, io certe pipe le scrivo in automatico. E l'usabilità non è
un  termine assoluto ed  oggettivo, è  un termine  soggettivo, dipende
moltissimo dalle abitudini di una persona. 
Vantano per Mac OS X  una delle interfaccie più usabili, indubbiamente
è bella  ma _per_me_ è  scomoda, allo stesso  modo un utente Mac  OS X
esperto apprezza il modo di  fare di Aquaemacs (particolare building e
configurazione  di Emacs  22 da  CVS) e  trova meno  usabile  Emacs 22
prelevato  dal   CVS  perché  Aquaemacs   si  comporta  di   più  come
un'applicazione Mac.
Una IDE che  ti rimpiazza una stringa in un  progetto può essere molto
comoda.  Se  hai però  solo quella ed  ad un  certo punto ti  trovi un
problema che la IDE non è in grado di affrontare...


> uscire una finestrella è una vera iattura.
S> Niente di tutto questo, si direbbe che tu eclipse non lo conosca.
Impressione sbagliata, lo ho usato  e ancora quando capita lo uso come
gestore  del progetto quando  il resto  del team  di lavoro  cui vengo
mandato in supporto lo usa.
Come gestore di progetto è comodo, come debugger è comodo.
Lo uso  per gli EJB, perché  ha gli strumenti per  tenere allineate le
varie classi implicate.
Come  _editor_ è  primitivo, nonostante  tutti gli  automatismi "auto-
sense".
Nel  momento in  cui gli  automatismi (quando  non rompono  le toe...)
cessano l'editor è rudimentale, tutta apparenza e niente sostanza.
Vero che io sono abituato da passa un decennio ad un editor che espone
in modo immediato  il linguaggio con cui è  implementato (linguaggio a
cui Java e molti altri linguaggi di oggi devono molto) e quindi per me
una operazione  lunga ripetitiva e noiosa si  trasforma nel divertente
giochetto  "scrivere  la  manciata   di  istruzioni  che  fa  la  cosa
automaticamente ed in fretta"...
E  si, ha gli  automatismi che  offre eclipse,  solo che  partono solo
quando io chiedo che partano. E usualmente sono più lesti...


> uscire una finestrella è una vera iattura.
gi> è anche giusto che un programmatore abbia una macchina decente su
gi> cui lavorare.
Sarebbe. E  poi ho  notato che purtroppo  su alcuni  sistemi operativi
Java è un pelino più svelto che su altri...
gi>  in tal caso, la comparsa del tooltip di
gi> autocompletamento è istantanea.
Continuo a preferire  un tool che fa tutte queste  cose (e anche molte
altre), non  mi obbliga ad usare  un sistema operativo  che trovo poco
usabile, e che con la macchina  "non decente" (appena un giga di RAM e
un PIII) risponde egualmente bene.
gi> e se sei veramente così veloce, il tooltip non compare neanche.
gi> quindi tu *non* scrivi veramente veloce :)))
Con Eclipse non scrivo veloce.
Non lo uso per scrivere il codice, come ho già detto l'editor lo trovo
scarsino.
Lo uso per correggere gli  errori di compilazione quando il progetto è
gestito con Eclipse.


> Sono curioso di capire perché preferisci non usare editor molto evoluti.
Io uso da più di un anno ConText (
http://www.context.cx/
). E mi sono 
abituato a fare cose a cui non vorrei rinunciare:
1) creare un progetto con l'elenco di tutti i file relativi, 
indipendentemente da quali siano quelli aperti al momento;
2) poter aprire e chiudere tutti i file del progetto con un unico click;
3) poter tenere nella colonna sinistra l'elenco dei files del progetto, 
anche ordinati uno per uno da me (
p.es
, sposto in alto quelli che uso di più 
al momento);
4) poter fare un cerca e sostituisci su tutti i files aperti del progetto 
con un unica operazione;
5) ovviamente, colori per evidenziare parole chiave, commenti, ecc., nonchè 
i numeri di riga visualizati;
6) menù tutti in italiano;
7) la possibilità di passare da un file all'altro cliccando sull'apposita 
linguetta con il nome.
Non so quali sono gli editor evoluti a cui fai riferimento; io ho provato 
Eclipse e Netbeans, ma così di primo acchitto non mi sono piaciuti.
Può essere che sia solo un problema di poca familiarità del pogramma da 
parte mia, ma quando mi sono trovato una finestrella minuscola per il file, 
una cartella creata in mezzo ai miei sorgenti, per non parlare della classe 
principale che si chiamava Main, anzichè con il nome che avevo scelto io... 
ho depennato i programmi dalla lista.
Non parliamo del fatto che Fedora ha, per default, un suo java proprietario 
che, a differenza di quello di Sun, mi genera errori ed eccezioni strani 
(tipo: una classe che estende Button, con un disegno al posto della 
scritta), e quando ho visto il titolo "Fedora [non ricordo se fosse Eclipse 
o Netbeans]"... altro punto a sfavore.
Al momento il programma che più si avvicina alle mie esigenze (ovvero, 
quello che per me deve essere un editor evoluto) e jedit con il plugin 
ProjectViewer, ma mi sembra che abbia alcuni difetti:
1) la lista dei file del progetto (non posso spostare i nomi in alto e in 
basso, purtroppo; in compenso c'è una struttura ad albero che permette di 
muoversi più facilmente nella lista) non è aperta per default quando apro 
jedit, quindi devo ogni volta seguire il menù per aprirlo;
2) non ho ancora capito se e come si possa fare un cerca e sostituisci su 
tutti i files aperti (ESSENZIALE);
3) non sono presenti le linguette dei files aperti, per cui il passaggio da 
un file all'altro non lo trovo proprio comodissimo (poco importante);
4) l'opzione che aggiorna i plugin non funziona, va sempre in errore, per 
cui ho dovuto scaricare e spostare nell'apposita cartella tutti i plugin che 
mi interessavano; non ho capito se aver inserito i jar è sufficiente, o se 
dovevo fare anche altro (avevo letto che i plugin di sistema richiedono 
anche il make; ma quali sono quelli di sistema?).
Insomma, non è che mi faccia schifo un editor avanzato, anzi; è che lo 
vorrei standard rispetto alla procedura java di JUN (intendo i comandi javac 
java, jar...), oppure che facesso solo l'editor. Ma con le caratteristiche 
che ho detto (+ o -).

 il plugin ProjectViewer
OOPS, è jedit
Un altro (per me grave) difetto di jedit: dopo aver smanettato per un po' 
dentro Linux, ritornato in Windows [ah, sono io che ho aperto il post] ho 
scoperto mio malgrado che erano stati inseriti una serie di segni di 
tabulazione al posto degli spazi; e siccome avevo settato a 1 il numero di 
spazi per tab (voglio un'indentazione "lieve", per evitare che al quarto 
livello si esca dallo schermo), tutte le modifiche mi sono sparite dallo 
schermo ora che ho riaperto con Context il progetto. Siccome ho una 
sincronia file in un portatile dove continuerò, quando non sono a casa, a 
lavorare in Windows, ho bisogno di una compatibilità assoluta. 

 gestito con Eclipse.
Allora č questione di gusti e abitudini.
Io trovo l'editor di Eclipse molto buono, e le funzioni di refactoring
eccellenti.
ciao
gl

> è gestito con Eclipse.
gi> e le funzioni di refactoring eccellenti.
Non sono  funzioni dell'editor, non ci  sono lì quando  premi i tasti.
Anche a  me piacciono  le funzioni di  refactoring di Eclipse  e anche
dell'IDE di Oracle. Ma non  mi pare che avrebbero coperto alcune delle
situazioni di refactoring in cui mi sono trovato.


 writes:
M> Non parliamo del fatto che Fedora ha, per default, un suo java
M> proprietario 
??????????
Sun distribuisce la sua implementazione  mirata su RH (se vi domandate
perché Fedora  si chiama cosě, giocate  a nethack o falcon  eye :) )se
non  ricordo   male.  Vero  che   senza  accordi  con  SUN   non  puoi
ridistribuirla...


 problema che la IDE non č in grado di affrontare...
lo risolvero' in altro modo. l'ide mica deve fare il cappuccino ne' deve
essere predisposto perche' io possa customizzarlo per farlo...