¿Cómo se duplica una línea de código en Delphi con método abreviado del teclado?
 

En Notepad++ esto se hace con Ctrl+D pero en Delphi por más que busco no encuentro el método abreviado del teclado para eso.

CTRL+C y CTRL+V.
Si lo haces rápido, casi parece una única pulsación... :D:D:D

No en serio, que yo sepa el IDE no la trae, pero si tienes, por ejemplo los CnWizards, puedes hacerlo con CTRL+ALT+D.

Usa Vim. :D

Vim es para tipos duros ^\||/
Por eso yo no lo uso :p

Digo yo, ¿Y tan falta hace una funcionalidad como esa en un IDE? ¿Que tanto tiempo glorioso e importante se va a perder o pretender ganar aplicando una combinación de teclas por sobre otra como el tan rápido e igualmente efectivo Copy & Paste? ¿Realmente supone un beneficio esos 3 míseros segundos ganados?

Por momentos pienso que las nuevas cosas (como las de este estilo) que le van poniendo a los IDEs son para hacer desarrolladores cada vez más vagos.

Saludos,

Sirve para ejercitar la memoria ;)

Sí, sí hace falta, aunque, desde luego, no es imprescindible. Ya lo dijo Casimiro, si eres un tipo duro, usa VIM, o NotePad, si se trata de no ser vago.

Por otra parte, duplicar un línea no es equivalente a un copy&paste que, además, requiere primero seleccionar la línea y luego mover el cursor para no pegar sobre lo seleccionado.

Son pequeñas cosas, cada una prescindible, pero que, en conjunto, hacen que un editor sea algo agradable de usar y agilizan la edición.

LineComment Saludos

:confused: Explícate. ¡Estoy en modo Sheldon Cooper!

Obviamente que para duplicar la línea con la función de Copy & Paste hay que seleccionar, copiar, movernos a la línea y pegar. Moverse y seleccionar la línea correspondiente e ir a la línea destino es algo que se puede hacer con mucha rapidez si se sabe usar bien las flechas direccionales y el Ctrl.
Y si es un proceso equivalente, puesto que se llega al mismo resultado.

Mi punto es, ¿Cuanto más rápido y que beneficio real y hiper productivo es disponer de esa funcionalidad que la llaman tan útil? Quiero saber ya que me fascina la idea de aprovechar esos segundos ganados y dormir un poquito más cada día.
Si la jusitificación de la funcionalidad de copiar o duplicar una línea la quisieran enfocar hacia el hecho de que es una molestia el Copy & Paste o que hubiera que estar haciendo lo mismo varias veces el problema de fondo es otro. Porque si se va a estar duplicando muchas veces una (o más incluso) línea, es que estás haciendo un mal código.
Si es cierto que en ocasiones es inevitable, y habrá duplicidad.
Ahora si lo haces cada 2 x 3... insito: ¡Algo mal estás haciendo!

Saludos,

Precisamente en Vim muchas de estas necesidades "nuevas" desaparecen casi solas. Como digo, basta con pulsar la secuencia "yyp" para duplicar la línea. Así de rápido. Y no es porque alguien lo haya programado exprofeso. En realidad son tres comandos diferentes en secuencia:

1. y - copia
2. y - línea
3. p - pega a continuación

De hecho, para duplicar una palabra se usaría "ywp":

1. y - copia
2. w - palabra
3. p - pega a continuación

O copiar una línea tres veces "yy3p":

1. y - copia
2. y - línea
3. 3 - Repetir tres veces el siguiente comando
4. p - pega a continuación

Duplicar tres líneas es algo más complicado, pero también es bastante rápido puesto que sería "y3ykp":

1. y - copia
2. 3 - Repetir tres veces el siguiente comando
3. y - linea
4. k - Subir el cursor (de lo contrario copiaría a continuación de la primera línea).
5. p - pega a continuación

Esta es una de las razones por las que me gusta tanto Vim.

Duplicar línea (editor básico):

• Seleccionar línea
• Copiar seleccion
• Mover cursor
• Insertar línea en blanco o mover cursor al principio de la línea
• Pegar línea

Duplicar línea (editor avanzado)

• Duplicar línea

Yo creo que esto responde las dudas.

Ahora; el porqué alguien quiera o requiera usar muchas veces este comando es algo que no puedo juzgar y, mucho menos, determinar que esté haciendo algo mal. Para el caso, cualquier comando de edición que no sea escribir caracteres sería un indicador de que algo estuvo mal.

Por otra parte -enfatizando lo dicho anteriormente, cada editor provee un conjunto de shortcuts que en conjunto dan una funcionalidad que los destaca de otros. Cada atajo puede ser prescindible, pero en conjunto, todos ellos nos hacen la vida un poco más fácil. Desde luego podemos prescindir -como lo hemos hecho muchos años- de una funcionalidad específica, no se nos va la vida en ello. Pero si agregan funciones que facilitan, aunque sea en pequeña medida, la escritura de código, pues, bienvenidas.

Finalmente, por fortuna hay, actualmente, un motón de editores para que cada cual escoja el que le apetezca y le acomode. Nadie está obligado a usar x o z característica o x o z editor. Pero lo que sí me cuesta trabajo entender, es el porqué tildar de vagos a quienes usan una de esas x o z caracteristicas. ¿Soy un mejor programador si uso vim o notepad? ¿Soy malo programando si uso sublime, atom, brackets, small editor o cualquier otro de tantos?

LineComment Saludos

A mí me gustan las macros, configurar distintas opciones complejas para hacerlas automáticamente con la pulsación de un par de teclas. Soy muy vago :rolleyes:

Pretender comparar un editor de texto, con más o menos monerías, con el editor de un código de un IDE no tiene sentido.
En un editor de texto (Notepad++ aún con sus tantas cosas no deja de ser uno) vas a brindar herramientas variadas para facilitar la edición de texto de forma rápida.
En un IDE lo que se espera es que el "texto" tenga un sentido, es un código. Si, que Notepad++ te resalta la sintaxis, si... pero al fin y a cabo para él es texto. Texto que ni le importa un carajo si está en la línea 5 o en la 6. Simplemente toma texto.
Para un IDE ese texto tiene un fin, un propósito, tiene significado. Y como tal, obecede y sigue reglas estrictas de semántica y sintáctica. Algunas, muchas (y por no decir todas), de esas reglas tienen condiciones de orden. Es natural entonces que su editor se centre más en ofrecer caracteristicas apropiadas y diseñadas para facilitar esas reglas en primer lugar, y ya en aspecto secundario algunos detalles para la entrada de código.

En un editor de texto es esperable un caso como el que se discute en el hilo. En un IDE no necesariamente y el gran error de damianccs es pretender que Delphi tenga lo mismo que un Notepad++.

¿Porqué no tiene mayor sentido esta característica de duplicación? Como he dicho: en un buen código se evita tender a la duplicación de sentencias. Si es cierto que en ciertas ocasiones tendremos que hacer tipo de cosas como ésta:

Código Delphi [-]
MiQuery.ParamByName('Campo1').AsInteger := blabla;
MiQuery.ParamByName('Campo2').AsInteger := blabla;
MiQuery.ParamByName('Campo3').AsInteger := blabla;
....

En estos casos duplicar la línea puede ayudar. Pero también hay ciertas ocasiones que son más o menos evitable:

Código Delphi [-]
for i := 1 to 3 do
begin
  MiCampo := 'Campo' + IntToStr(i)
  MiQuery.ParamByName(MiCampo).AsInteger := blablabla;
end;

O con su alternativa mediante su propiedad vectorial igualmente válida.

Encontrarse con casos en que debamos estar duplicando líneas de código quizá no sea evitable. Ahora, estos casos deben ser dispersos y mantenerse lo más bajos posibles.
Razón suficiente como para justificar la NO necesidad de que exista una macro o atajo de teclado. No al menos por la "vía oficial". Los expertos como GExpert y cnWizards extienden y brindan más cosas interesantes obviamente.

El IDE tratará de mantener tu "productividad" al momento de acelerar la entrada de código basada en las reglas. Copiar una línea y ponerla consecutiva no es una de ellas. Para lo demás, estan los expertos si tan preocupado estás.

Pero esto no invalida un gran punto, y es otro motivo por el cual no se busca fomentar la copia extensiva por atajo en el IDE de Delphi: si en tu código terminas haciendo demasiado copy & paste, piensa dos veces. Notepad++ no te va a regañar... ¡Notepad ama cualquier texto que le pongas, cuanto más mejor! :D

El punto es que damianccs se sorprende o extraña demasiado por el hecho de que Delphi no cuente con esa "util" característica.

Casimiro, las macros ya son otro cantar. En principio su concepto no es propio a edición de código (lo que se está discutiendo en este hilo al fin y a cabo) sino para tareas más complejas que puede involucrar acciones "fuera" como configurar, hacer un merge, etc.

Saludos,

Ha habido épocas en las que he usado editplus y similares en lugar del ide de delphi (en viejos ordenadores con poquita memoria que manejaban mejor editplus que delphi) y no echaba en falta nada en uno u otro. Eran muy similares.

Delphi tiene macros configurables.

Yo uso las macros muy, muy a menudo, facilitan mucho el trabajo para cosas repetitivas.

Delphius: El tiempo que te ahorra es lo de menos. La comodidad se traduce en productividad. Más pulsos neuronales invertidos en el objetivo del proyecto en curso; menos en realizar tareas rutinarias. :)

Eso me recuerda las macros que hice en mis tiempos para el Turbo C/C++. Escribías un nombre y con pulsar dos teclas ¡Patapum! tenía hecha la estructura básica de una función o una clase con comentarios básicos y todo. En teoría eso se puede hacer con Lazarus, pero cada vez que me meto a leer cómo personalizarlo me dan los siete males. ¿Por qué tiene que ser tan complicado? Creo que debería retomar este proyecto y avanzar un poquito más...

El 99% de los desarrolladores, y de la gente en común y la percepción general dice que menor tiempo se traduce en productividad.

Para mi la productividad se mide en muchas cosas, y entre ellas la cantidad de defectos y errores que detecto. Como yo vengo de una escuela en la que prioriza el análisis y el diseño, al momento de escribir código raramente tengo que estar copiando y pegando y pensar en que debo hacer después. No divago en esta etapa... justamente para eviar lo más posible los bloqueos de quedarme en el monitor sobre que es lo que me falta, o en que parte meti tal cosa, etc. El "código a lo espaguetti, y no planeado" es para mi un sacrilegio.
Al momento de sentarme con el IDE ya tengo planeado que, donde, como. Los errores se reducen mucho porque además llevo mis diseños pensando en que tipos de pruebas deben superarse. Lo que ayuda un montón a mostrar los errores. Es más el objetivo del diseño dirigido por las pruebas (una de las buenas prácticas que comparte Scrum como y el modelo USDP/UP/RUP) es que si hay un error este resalte y se haga evidente.
Por ejemplo: de vez en cuando me sale un defecto como confundir filas y columnas cuando estoy aplicando muchas operaciones algebraicas y termino mostrando matrices traspuestas :p y se me mezclan las matrices y vectores, y otras estructuras con las que suelo enfrentarme.
O el de olvidarme de haber puesto un Sqr por rapidez.

Son errores tontos que suelo detectar temprano ya que el código ha sido pensando en que antes se ha definido una serie de pruebas bien planeadas y detalladas que ayudan a detectarlos.

Hay mucha gente que se lanza de una a tirar código, y después pretende organizarlo y probarlo. Por lo general eso lleva a tirar más errores hacia adelante, y detectarlos más tarde. En estas situaciones es muy habitual el copiado y pegado a lo bruto.

Volviendo al punto...
Yo entiendo a lo que apuntas amigo. No es que venga de malo, nomás estoy exponiendo lo absurdo y ridículo que puede ser pedir tantos atajos. Al final tenes que tener más memoria y gastar esos pulsos neuronales que tu dices pero para recordar 50 atajos y te puedo asegurar que apenas vas a terminar usando no más que 10. Es real. Nos pasa a todos.

No voy a negar que de vez en cuando yo aplico alguna combinación de atajos como el autocompletado de clase, o el forb + ctrl + j para que te arme la estructura for. Ayudan.
Pero si prestan atención estos atajos están pensados para formar código, estructura.
¿Hay alguno pensado para hacer Copy & Paste por líneas? NO. ¡Ya tenes el Ctrl + V y el Ctrl + C, ¡Para que reinventar la rueda! Y además, el código redundante no es deseable. Ahí tienes otro motivo más para desistir de la posibilidad.
¿Tiene Notepad++ el autocompletado que tiene Delphi? NO. Entonces no confundan los tantos ni le pidan peras al olmo. Una cosa es editor de textos y otra el editor para un código.

Hay una cosa que me molesta del autocompletado que tiene Lazarus/CodeTyphon... ¡No me respeta los espacios/sangrado que le coloco! Para mi es muy molesto. A mi me gusta el "ifeb" así:

Código Delphi [-]
if $Param(Conditional)
   then begin
          |
        end
   else begin
        end;

Es decir el then y el else en a la misma "altura". Pero al momento de usarlo te queda así:

Código Delphi [-]
  if Conditional
    then begin
      
    end
  else begin
    end;

Y cosas similares me molesta como el "begin end". Cuando pones "begin" y presionas enter te pone el end "fuera de lugar" a un sangrado al que no estoy acostumbrado y al que yo espero. No le he encontrado la vuelta de como corregir esto.

Saludos,

Precisamente, con cnwizards y similares :)

Que yo sepa, no hay CnPack ni GExpert para Lazarus/CodeTyphon. Aunque, al menos con CodeTyphon (desconozco si será originarias de Lazarus) hay cosillas que están inspiradas en algunas herramientas y funcionalidades de estos expertos.

En Delphi tenía mis plantillas y funcionaban. Usaba tanto GExpert como CnPack. Al pasar a CodeTyphon las cosas son diferentes.

Saludos,