Bug 248766 - commenting out and static word wrap should be in right order
Summary: commenting out and static word wrap should be in right order
Status: RESOLVED DUPLICATE of bug 105373
Alias: None
Product: kile
Classification: Applications
Component: editor (show other bugs)
Version: 2.0.85
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Michel Ludwig
Depends on:
Reported: 2010-08-23 09:19 UTC by Moritz Augustin
Modified: 2010-08-27 17:38 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Augustin 2010-08-23 09:19:59 UTC
Version:           2.0.85 (using KDE 4.4.5) 
OS:                Linux

when writing a latex document and doing a multiline comment out with ctrl+d there happens the following:

if some lines of latex code are longer (maybe from a loaded document) than the static word wrap border then first they get a '%' comment sign in front but afterwards get wrapped so there remain all long lines which were wrapped automatically 


having a static word wrap of 10 and the following doc:


after marking all and pressing ctrl+d the result ist:

% 12345678
% abc
% 12345678
% def

so the mistake (from my point of view) is the lines beginning with 901.. should also have a % sign in front of them

Reproducible: Always

Steps to Reproduce:
open latex doc with lines longer than static word wrap setting
commenting out some lines containing long lines

Actual Results:  
the lines get commented out and THEN wrapped

Expected Results:  
comment out, wrap, comment remaining lines, repeat until everything is commented out (it might be that the uncommented line gets with the "% " again wrapped...)

OS: Linux (x86_64) release 2.6.35-ARCH
Compiler: gcc
Comment 1 Moritz Augustin 2010-08-23 09:54:00 UTC
same issue in copying long comment lines (longer than static word wrap length)
so my rough idea is doing a possible fix in the static wrap code
Comment 2 Michel Ludwig 2010-08-27 17:38:01 UTC

*** This bug has been marked as a duplicate of bug 105373 ***