| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Obviamente que um IDE é centenas de vezes melhor que o velhinho vi (yuck :). O problema é arranjar um IDE jeitoso. Em linux, a coisa mais parecida que já vi é o xemacs, tem lá o botãozinho para fazer make,tem corzinhas e as mariquices todas que precisamos para escrever código. (também existe o codewarrior, mas nunca testei) De qualquer forma, IDE's a sério só mesmo aqueles cujo nome começa por 'microsoft' :) Trabalhar em windows permite aumentar bastante a produtividade, porque se poupar 18 teclas entre 2 edições do ficheiro, certamente que poder arrastar qq coisa do desktop para cima do IDE abrir automaticamente ou ferramentas para construir apliações gráficas decentemente (visual basic vs glade..prefiro o vb :) rendem muito mais. De qualquer forma, isto é um falso argumento :) não se fazem aplicações a pensar em qual o melhor IDE's, mas sim no sistema operativo onde a queremos correr. Para mim, em linux, o melhor 'editor' é o xemacs, embora também goste bastante de trabalhar na consola, com o velhinho pico ou joe.. :))))
|
| | | | | | Não sei porque ("religião" talvez) não gosto de Emacs e praticamente uso mais vi/pico/make (calma... não vamos começar uma guerra :)) ... eu sei das vantagens do Emacs).
E que tal o KDevelop. Apesar do K não implica necessariamente que se tenha de programar em KDE. Já o utilizei várias vezes e acho que esta bastante bom para programação em C/C++ ... e cada vez gosto mais dele :).
Features: - Project Management
- Dialog Editor (KDE)
- Class Parser / Class Tools
- Integrated Debugger
- Graphical Class Viewer
- Application Wizard
- Documentation (html)
- Project TreeViews
- Integrated Unix-tools (automake, ...)
- Integrated Editor (of course)
- Integrated Documentation browser
- Class Generator
- CVS Integration
- etc...
Vejam alguns screenshots: 1 , 2 , 3
Eu sei que já existem muitos IDEs, mais antigos até (e para além de IDE :) ), que fazem isto e muito mais. Mas para o caso que se colocou acho que seria a solução perfeita.
Caso prefiram um IDE mais "a la consola" também têm o RHIDE. Olhando para os screenshots os Borland-Inprise-Turbo-Vision-Turbo-Pascal-ou-C++ sentem-se logo em casa. Trata-se de uma adaptação de um excelente! IDE (para o seu tempo e para o seu objectivo).
|
| | | | O que eu vou dizer pode parecer ofensivo, mas não é essa a intenção: vale a pena aprender a usar o vi de forma profissional. O "vi" faz milhares de coisas que nem imaginam, (aliás, se calhar eu também nem imagino) e é muito superior a qualquer outro editor que eu já vi em qq sistema operativo, excepto talvez o emacs (mas tenho dúvidas). O problema do vi é que demora imenso tempo a aprender e 90% das pessoas que usam o vi não conhecem nem 10% da sua funcionalidade. Já vi várias pessoas dizerem mal do vi, mas depois de eu fazer algumas demonstrações com regular expressions, pipes para comandos externos, multi-buffers, redefenição de teclas, macros, repetição de comandos anteriores, etc, ficaram fascinadas... Vale mesmo a pena aprender a usar o vi: depois de aprender fica-se com uma imagem completamente diferente do editor. O facto de ter vários modos não é uma desvantagem: antes pelo contrário. Claro que isto é apenas a minha opinião e também já vi o emacs fazer coisas fantásticas.
|
| | | | Considero-me um leigo em vi (sou das tais 90% das pessoas que falas) e apesar de já ter (de cabeça ou lendo o manual) experimentado fazer tudo o que foi descrito continuo sem ficar fascinado pelo vi (apesar de utilizar expressões regulares (fanático de perl :) ), repetição de comandos, pipes, etc... no dia-a-dia). A primeira versão (embora exista polémica acerca disso), segundo me lembro de ter lido, foi feita numa noite de insónia. Depois das primeiras versões os autores começaram a adicionar funcionalidades porque era interessante ter aquilo, era bom fazer aquilo, precisa disto, etc... Tenho sempre a impressão de que estou a usar um editor que foi feito e extendido "sobre o joelho" sem realmente se ter pensado muito acerca do assunto (ao contrário do EMacs). Apesar de tudo é o que eu uso mais em máquinas unix "não-minhas". E já uso mais vim que vi puro (ao ponto de tentar usar vim em coisas "estranhas" como AIX). Continuo a espera de aprender, um dia quem sabe, os tais 90% de funcionalidade que desconheço completamente para ficar "fascinado" :).
(que estou a fazer eu ... a meter-me na guerra santa :) )
|
| | | FPTED (Pontos:2, Informativo) |
| | Ok, ok, cada pessoa tem gostos diferentes...
Há cerca de 8 ou 9 anos, escrevi um editor fácil de usar para UNIX: chama-se fpted e pode ser descarregado de http://mc.microcaos.pt/freeware
Ocupa cerca de 49k e por isso descarrega-se num instante.
É fácil de usar, porque tem um menu e help online, tem imensas funcionalidades para programadores: autoindent, word completion, parentesis match, multi-buffer, undo, macros, redefenição de teclas, dezenas de movimentos, copy&paste entre vários ficheiros, etc. etc.
Se não gostas do vi, muito provavelmente vais gostar do "fpted".
É usado por milhares de pessoas e há quase 5 anos que já não recebo bug-reports.
su-
PS: apesar de ter escrito o fpted, continuo a ser viciado no vi/vim...
|
| | | | :) O problema é que o fpted não deve estar disponível em tudo o que é "sabor" unix que existe no mundo (como parte do sistema), não deve fazer parte do standard POSIX 1003.2 e não deve ter uma larga comunidade de suporte que produza bug-reports e tome acções para um vasto leque de plataformas (Windows, Mac, VAX, OS2, Amiga, VMS, Unix, ...) e não deve ser o editor unix com mais documentação disponível no planeta ... certo ? :)
Posso ter um gosto mas sou forçado a aceitar o standard.
Quase que aposto que até este site onde estamos deve ser mantido através de vi/vim ? *grin*
|
| | | | Está disponível em source (C) e só usa o curses: por isso compila em quase tudo o que é unix e até em vms. Quando o fiz (nas horas vagas) estava no Inesc e testei-o em ultrix, sun-os, hp-ux, aix, linux, dg-ux, irix, etc. Depois disso, tive reports de muitas outras pessoas que o usam noutros sistemas. Nota: parece que o site hoje está em baixo.
|
| | | | Dica:
Redefinir a tecla "TAB" para fazer word completion (o equivalente ao TAB na shell).
Desta forma, o vi completa automaticamente o nome das variáveis com nomes compridos, nomes de tipos de dados e classes, nomes de funções e métodos, etc.
Por exemplo, se temos uma variavel chamada dia_da_semana , basta escrever dia«TAB» para que o vi complete o resto.
Caso existam várias variáveis começadas pelas letras "dia", basta carregar várias vezes em TAB.
Para isso, basta inserir a seguinte linha no ".exrc":
map ^V ^P
Para fazer esta linha, é necessário carregar nas seguintes teclas:
map ^V^VTAB ^V^P
em que ^V significa control-v.
O vi é tão inteligente, que abre automaticamente todos os ficheiros "#include" para fazer uma tabela de símbolos.
Agora digam-me que o vi é um editor atrasado ...
Nota final: depois de definir o TAB desta forma, é necessário usar Control-V antes do TAB, para escrever um TAB normalmente.
Felizmente, nunca se deve usar o TAB dentro do vi, porque no vi as teclas usadas para fazer a identação são o Control-T (Increase indent level) e o Control-D (Decrease Indent level). O número de caracteres do indent é definido pela variavel "sw".
Essas variáveis podem ser definidas pela seguinte linha do ~/.exrc:
set sw=4 hardtabs=8 report=2 redraw magic ai autowrite mouse=a
sw = 4 - indentação de 4 caracteres
ai - autoindent
mouse = a , usar o rato dentro do vi,
etc, etc.
|
| | | | Será que devemos esperar que o próximo artigo do su- seja sobre o vi? :] (hint,hint) :]
"I explicitly give people the freedom not to use Perl as God gives people the freedom to go to the devil if they so choose." - L. Wall |
| | | | Parece que nunca acerto à primeira:
Neste exemplo, onde estam map deveria estar map!,
ou seja:
map! ^V^VTAB ^V^P
O "map" serve para definir teclas no modo de comandos, enquanto o "map!" define o significado das teclas no modo de insersão.
|
| | | | Nas discussões entre vi e IDEs, uma das razões por que as pessoas costumam dizer que preferem os IDEs, é por causa do syntax-highlight, em que o editor mostra o texto com cores diferentes, conforme se tratam de constantes, variáveis, palavras chave, comentários, etc.
Acontece que o "vim" não só tem syntax hightlight, como detecta automáticamente cerca de 200 linguagens diferentes: C/C++/Java, Pascal, HTML, SQL, perl, shell, etc. etc. etc.
Para activar o syntax-highlight, basta usar o comando:
:syntax on
ou entao inserir uma linha com
syntax on
no ficheiro ~/.exrc
Nota: para que isto funcione, é necessário usar um terminal que suporte cores (as versões antigas do xterm não dão).
|
| | | | Lembro-me de uma vez tentar programar em PERL utilizando o vim com a dita possibilidade das "corzinhas" e depressa desisti. Ou eu estava a fazer algo incorrectamente, ou o "parsing" daquilo é muito mau.
Hoje em dia utilizo regularmente o joe quando em ambiente UN*X e um tal de PHPed, quando em ambiente windows ( que tem hilight para PERL , PHP , SQL , etc ... além uma agradavel interface. ).
Acerca desta discussão, creio que é bastante boa como troca de ideias e formas de pensar. No entanto não deve servir para se tentar escolher o _melhor_ editor para programação. Este genero de discussão é semelhante a tentar chegar à conclusão de qual seria a melhor posição sexual...
|
| | | | Podes sempre alterar o ficheiro "/usr/share/vim/vim56/syntax/perl.vim" e alterar/definir as próprias regras de parsing da syntaxe do perl...
|
| | | | Eu por mim estou bastante bem impressionado com o gIDE... limpo, eficiente, estável e muito lindo :)))))
O look and fell não é o do visual C ++ mas para mim isso é uma grande vantagem :))
Claro que ainda não tem algumas das coisas mais exóticas que vêm com o kdevelop e isso mas também devem-se contar pelos dedos aqueles que precisam de facto de tudo isso...
http://gide.pn.org/
|
| | | | Como se pode ver ainda é um IDE que esta na fase de "crescimento". Reparando no roadmap e nas faqs pode-se ver que as tais coisas mais exóticas que existem no kdevelop e que supostamente seriam desvantagens do kdevelop estam planeadas para ser implementadas no gIDE ... um dia! (se é suposto ser diferente porque querer também ter??). Parece-me só mais um capítulo na guerra "santa" entre gnome e kde (eu tenho gnome office/eu tenho koffice... eu tenho kdevelop/eu tenho gIDE.... eu tenho gtk/eu tenho qt ... etc.). Em cada caso há sempre um lado (gnome ou kde) que está mais adiantado que o outro.
|
| | | | Eu não quero entrar nessa guerra santa... limitei-me a apontar uma ferramenta que serve as minhas necessidades assim como está hoje... sem falar de futuras evoluções. É uma contribuição para o debate.
|
| | | | Em primeiro lugar, no meu ficheiro .exrc tenho isto:
map F9 :make ^M
map F10 :cnext ^M
E depois para compilar, carrego simplesmente em F9.
Quando acabar de compilar, o cursor fica na linha onde aparecer o primeiro erro.
Depois uso o F10 para saltar para o próximo erro.
Conclusão: O vi é o melhor IDE do mundo...
(PS: o gvim ainda é melhor...)
su-
|
| | | | | | map :make ^M
map :cnext ^M
e é claro, depois uso o F9 e o F10 sem sair do vi...
|
| | | | Bolas para o HTML:
map «F9» :make ^M
map «F10» :cnext ^M
onde está « e » é um menor/maior...
|
| | | | E é claro, para iserir o Control-M ^M no ~/.exrc, é necessário carregar em Control-V/Control-M :-)
|
| | | | You press the keys with no effect,
Your mode is not correct.
The screen blurs, your fingers shake;
You forgot to press escape.
Can't insert, can't delete,
Cursor keys won't repeat.
You try to quit, but can't leave,
An extra "bang" is all you need.
You think it's neat to type an "a" or an "i"--
Oh yeah?
You won't look at emacs, no you'd just rather die
You know you're gonna have to face it;
You're addicted to vi!
You edit files one at a time;
That doesn't seem too out of line?
You don't think of keys to bind--
A meta key would blow your mind.
H, J, K, L? You're not annoyed?
Expressions must be a Joy!
Just press "f", or is it "t"?
Maybe "n", or just "g"?
Oh--You think it's neat to type an "a" or an "i"--
Oh yeah?
You won't look at emacs, no you'd just rather die
You know you're gonna have to face it;
You're addicted to vi!
Might as well face it,
You're addicted to vi!
You press the keys without effect,
Your life is now a wreck.
What a waste! Such a shame!
And all you have is vi to blame.
Oh--You think it's neat to type an "a" or an "i"--
Oh yeah?
You won't look at emacs, no you'd just rather die
You know you're gonna have to face it;
You're addicted to vi!
Might as well face it,
You're addicted to vi!
You have new mail.
|
| | | | | Isto é de facto desconhecimento do poder do vi. Em primeiro lugar há que utilizar o vi certo. O vi que vem com os BSD's (nvi) por exemplo é bastante limitado, nao tem multiwindow, make, etc...
Pessoalmente uso o vim, que me parece o mais completo. Existem ainda outros bons vi-like como o vile. Mas o vim é bastante completo. Quanto ao problema em rubrica, o vim suporta o comando make, portanto estes passos: vi x.c
[alteracoes]
:w ENTER
^Z
make ENTER
fg ENTER Passam a: vi x.c
[alteracoes]
:make É possível depois percorrer os erros do compilador linha a linha com: :cn (proximo erro)
:cp (erro anterior) Outra dica util é a utilizacao de varias janelas de edição.
Supondo que o programa é composto por vários sourcefiles: :split divide a janela corrente em duas
Ctrl-W Ctrl-W salta entre janelas
:e x.c carrega o ficheiro x.c na janela corrente Outra feature que vejo muitos utilizadores a nao utilizarem é a primorosa syntax highlighting oferecida pelo vim, e a indentação automatica de c ao gosto do programador.
Pessoalmente uso no .vimrc: set tabstop=2
set shiftwidth=2
set incsearch
set nocp
set cindent
set cinoptions=:0,p0,t0
set cinwords=if,else,while,do,for,switch,case
syntax on
|
| | | | | O artigo inicial parece vir de alguém que está limitado a aceder ao Linux por um terminal série, ou uma daquelas pessoas que maximizam um único xterm e trabalham nele como se fossse DOS. Também parece usar um shell que não permite aceder aos comandos anteriores com as tecla das setas Vejamos o meu ciclo típico de compilação e execução.. Começo por abrir dois xterms, um para compilar, outro para editar (é claro que tenho que escrever uma vez "vi fich.c" e "make" mas isto é inicialização e não o ciclo). Ciclo edit, save, compile - edit: número de teclas necessárias à modificação
- save: ":w" ( 3 teclas )
- compile (2 teclas)
Assim o ciclo consiste em 5 teclas e dois movimentos de rato o que é um pouco diferente das 30 ou 12 teclas indicadas no artigo. Com isto não quero dizer mal dos IDEs, mas é para comparar temos que recorrer a utilizadores com um grau mínimo de eficácia em cada plataforma. Por exemplo os utilizadores dos IDEs que não aprendam as hotkeys mas recorram exclusivamente ao rato e aos menus estão a prejudicar-se, mas isso não deve ser usado como argumento contra os IDEs.
|
| | | | | | | No way Rosé! Bom, confesso: enganaste-te em cheio :) Neste momento em particular, tenho o fvwm2 a correr, com 6 screens virtuais, 5 deles com 2 xterms cada, e o outro com 10 janelas de netscape. Quanto às teclas do cursor, nao as especifiquei para nao complicar: "x.c" é suficientemente pequeno para se escrever directamente. Mas mais, até tens razao num ponto: eu raramente uso as teclas de cursor. Uso, na tcsh, uma coisa que e' o alt-p (previous), ou alt-n (next), que procura na historia de comandos, aqueles que comecam por uma dada sequencia. ASsim: ". ALT-P" gera "./a.out -p foo -b 23 xpto...", etc... Com duas teclas, evitas estar a percorrer a historia até encontrares o que queres. Finalmente, em relacao ao "pequeno" pormenor dos "dois movimentos de rato": é exactamente isso que eu evito -- enquanto se levam as maos ao rato, escrevo eu um texto inteiro :) Alias, de facto eu até evito tirar as maos do teclado principal. No keypad e nas teclas INS-DEL-HOME(...), nunca toco, e nas do cursor é raro. Por isso é que gosto do vi, deixa-me fazer tudo do teclado principal: os meus dedos podem ser rapidos, mas as maos sao certamente preguiçosas! De facto, a forma mais produtiva de trabalhar que eu tenho, é a que indiquei, e duvido muito que haja alguem que escreva/desenvolva mais rapido (mas admito empates :)
-- carlos |
| | | | | Not so fast, young programmers! :) Vi muitas features descritas, que sao exclusivas do vim, e nao do vi original, i.e. do vi standard. O vi que eu uso, o nvi, é um vi original, com duas ou tres features extra que eu considero no limite entre o util, e a criacao de um monstro lento com o vim. (e sim, ao contrario do que foi dito, o nvi suporta multiwindow!) O vim de facto possui megas e megas de features. Eu diria que é quase um emacs no reino dos VIs. Infelizmente, os VIs que se encontram por default em todos os unixes, excepto linux, nao têm essas facilidades, embora, em abono da verdade, passe-se bem sem muitas delas :) Algumas, com uma certa inteligencia, e algum hackerismo, até se conseguem arranjar. Nomeadamente a do TAB, que é built-in no VIM, mas precisa de ser "fabricada" no vi original: vejam complete macro (ja la vao tres anos! argh!), ou, para terem um cheirinho da complicacao da coisa: map! ^[^V^I ^[mjo^[0i?\<_^V^V^M^[h"lyl0"jy$dd`j:map! ^V^V^[^V^V^V^V^V^V^I .^V^V^[bmi"kyt.o^V^V^[0"jp3lD"kpA^V^V^V^V^V^V^V^V^V^V^V^V^V^V^V^M^V^V^[0"md$"lpA.^V^V^[$"k po"mpA^V^V^[k:.g/^\([^.]*\)\.\1$/+s/.*/"jpAn/^V^V^Mdd"id$@i^V^V^[0"jd$dd`i@j"lye`icf.^V^V^ ["lpea^Ma^[^I
-- carlos
|
| | | | | | Vim = vi++
Como o vim está em source, é só recompilar
e pronto: pode ser usado em qq os.
Quanto ao facto de ser pesado, nunca notei nada...
su-
|
| | | | | experimenta fazer: 50a1 2 3 4 5 ESC em vim e em nvi, e ve a diferenca de tempos de resposta. e se usas de facto macros que façam automatismos, experimenta executa-las num e noutro editor... no meu site, na parte vi-lib, existem muitas dessas macros: vê por exemplo o rot13 ou fmt
-- carlos
|
| |
|
