| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is largely based upon Justin's patch, I just moved the
reset_ansi() parts out otherwise you get strange colour reset
behaviours.
Original patch message:
I used the --no-linewrap (-w) option for the first time today, watching
some wide output that didn't quite fit in my tmux pane. Quickly I
noticed a problem: while --no-linewrap did indeed eliminate the
spillover of lines too long for the terminal "window" width, it *also*
resulted in a bunch of lines from the program output being hidden
entirely.
After some fiddling around, the exact problematic behavior appears to be
as follows:
1. Lines which would have wrapped (more than $COLUMNS chars long) are
handled correctly.
2. Lines which would *not* have wrapped (shorter than $COLUMNS) are
printed; but then the next line is *not* printed! For long sequences
of non-wrap-length lines, you get an every-other-line-is-visible
sort of effect.
The logic underlying the problem seems to be this: in the run_command
loop, if the x loop goes all the way to completion (meaning we've
reached the right-side edge of the window area), there's a small block
of code for --no-linewrap whose main purpose is to call find_eol, which
eats input until it hits a newline (or EOF). Clearly this is intended to
be done for lines that are too long, so that the excess characters are
discarded and the input pointer is ready to go for the subsequent line.
However, this code isn't in any way conditional on the value of eolseen!
Short/wouldn't-wrap lines will have encountered a newline character
before exhausting the entire x loop, and therefore eolseen will be true.
Long/would-wrap lines will not have encountered a newline when the x
loop is exhausted, and so eolseen will be false.
Nevertheless, find_eol is called in *both* cases. For long lines, it
does what it's meant to do. For short lines, *the newline has already
been encountered and dealt with*, and so the actual effect of find_eol
is to eat the entirety of the next line, all the way through to its
newline, such that it isn't printed at all.
References:
procps-ng/procps!157
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
|
|
|
|
| |
If you have the watched program doing some other thing every time its
run and you resize the window, you might get unexpected results. The
-r option lets you run only when the interval has expired.
References:
procps-ng/procps!125
procps-ng/procps#190
|
| |
|
|
|
|
|
|
| |
Based upon merge request 104, closes #174
References:
procps-ng/procps!104
procps-ng/procps#174
|
| |
|
|
|
| |
References:
procps-ng/procps#230
|
| |
|
|
|
|
|
|
|
|
| |
Updated the definition of total, because its not *all* of
the installed memory but close to it.
References:
procps-ng/procps#247
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
| |
References:
procps-ng/procps#263
|
| |
|
|
|
| |
References:
procps-ng/procps!156
|
| |
|
|
|
|
| |
References:
commit 5baf1e6226f9aa051b5570b655ed49b73ae10061
procps-ng/procps!159
|
| | |
|
| |
|
|
|
|
| |
References:
commit 866abacf8805a74fb7c59cae1f64963e0a540b14
procps-ng/procps!165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In production we've had several incidents over the years where a process
has a signal handler registered for SIGHUP or one of the SIGUSR signals
which can be used to signal a request to reload configs, rotate log
files, and the like. While this may seem harmless enough, what we've
seen happen repeatedly is something like the following:
1. A process is using SIGHUP/SIGUSR[12] to request some
application-handled state change -- reloading configs, rotating a log
file, etc;
2. This kind of request is deprecated and removed, so the signal handler
is removed. However, a site where the signal might be sent from is
missed (often logrotate or a service manager);
3. Because the default disposition of these signals is terminal, sooner
or later these applications are going to be sent SIGHUP or similar
and end up unexpectedly killed.
I know for a fact that we're not the only organisation experiencing
this: in general, signal use is pretty tricky to reason about and safely
remove because of the fairly aggressive SIG_DFL behaviour for some
common signals, especially for SIGHUP which has a particularly ambiguous
meaning. Especially in a large, highly interconnected codebase,
reasoning about signal interactions between system configuration and
applications can be highly complex, and it's inevitable that on occasion
a callsite will be missed.
In some cases the right call to avoid this will be to migrate services
towards other forms of IPC for this purpose, but inevitably there will
be some services which must continue using signals, so we need a safe
way to support them.
This patch adds support for the -H/--require-handler flag, which matches
on processes with a userspace handler present for the signal being sent.
With this flag we can enforce that all SIGHUP reload cases and SIGUSR
equivalents use --require-handler. This effectively mitigates the case
we've seen time and time again where SIGHUP is used to rotate log files
or reload configs, but the sending site is mistakenly left present after
the removal of signal handler, resulting in unintended termination of
the process.
Signed-off-by: Chris Down <chris@chrisdown.name>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the p/e-cores support (via the '5' key) was added
in the patch referenced below, I intentionally omitted
that key from the top primary help screen. This seemed
appropriate since it only applied to select Intel cpus
and, besides, that screen was getting kind of crowded.
[ it remains an objective to fit on a 80x24 terminal ]
Upon reflection, I found a way to squeeze it into that
help screen and have decided to included it. Hopefully
its presence will encourage use of top's new provision
on any Intel platforms that distinguish between cores.
Reference(s):
Sep, 2022 - exploit p/e-cores provision
commit 00f5c74b1bc583d37315fa094c6f50cef7961c0c
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the commits referenced below special code was added
to make the bottom window sticky and fix the bug after
'Cap_nl_clreos' was traded for the 'Cap_clr_eol' loop.
However, there's always major overhead associated with
interacting with a terminal. So we'll only abandon the
single 'Cap_nl_clreos' putp in favor of repeated calls
with 'Cap_clr_eol' when a bottom window isn't present.
Reference(s):
. May, 2022 - bottom window batch bug fix
commit 793f3e85aeb41788e359c2f6f387812c328ac097
. May, 2022 - bottom window made sticky
commit 0f2a755b0b2754fca79545984e25ec52f4ae4444
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
| |
Please, do not look at the actual changes made by this
commit. Trust me they will vastly improve performance.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
| |
vmstat <n> would update most fields, but the memory statistics
were only fetched the first time.
References:
https://bugs.debian.org/1027963
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
procps 3.3.17 the c option changed the command/args field
to cmd but this got removed as part of newlib
Functionality is back in with a test case.
References:
https://bugs.debian.org/1026326
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
| |
The man page said it cannot show changes to comm, such as when you
use prctl(). In fact, ps can see this. The args field may not change
because its due to the path of the executable but comm can.
|
| |
|
|
|
|
|
|
| |
The field comm no longer shows defunct for zombie processes, use the
state field for this as it could be obscured if not the last
column anyhow.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
When the skill program was ported to the new API the code to filter
on PID, used by the -p option, was missed. It is now restored.
References:
https://bugs.debian.org/1025915
|
| |
|
|
|
|
|
| |
Fix the building of the man pages instead of installing the same
english ones twice.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |
|
|
|
|
|
|
|
|
|
| |
While ps used the correct type for PIDS_VM_RSS the test
did not. For some reason this only appeared to be an issue
for s390x
References:
https://bugs.debian.org/1025495
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| |\
| |
| |
| |
| |
| | |
[ with the histories of both branches also preserved ]
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
244f2b33
______________________________ original newlib message
----------------------------------- ( minus git hash )
When long command line options were introduced, in the
patch shown below, the string associated with the enum
'WRONG_switch_fmt' became obsolete. However, that enum
and its string were never removed. Well, now they are.
Reference(s):
. Sep, 2021 - getopt and long cmdline options
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3e5016c2
______________________________ original newlib message
----------------------------------- ( minus git hash )
When that 'Bottom' window was being finalized, an enum
of BREAK_screen was added to the Frames_signal values.
This was done so some full screen replacement function
could flag the need for that bottom window to go away.
Around that same time, top was made more responsive to
keyboard input so that residual portions of a previous
bottom window would not linger until the next refresh.
This happened if going from a larger (^N, environment)
bottom window to some smaller window (^P, namespaces).
The combined effect of these changes was to create the
potential race condition this commit addresses. If the
user encountered a SIGWINCH while on any of those full
screen replacement displays (help, fields mgmt, etc.),
endless redraws would occur. A ^C was the only option.
Henceforth we will protect against any redraw loops by
clearing Frames_signal each time a redraw is required.
[ along the way, we'll make the 'q' key work on that ]
t secondary 'windows' help screen as it should, even ]
[ though it is not documented on that screen itself. ]
Reference(s):
. May, 2022 - more responsive to keyboard input
commit ........................................
. May, 2022 - maybe force the bottom window off
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5f9185e0
______________________________ original newlib message
----------------------------------- ( minus git hash )
Darn, after testing on some older, out of date distros
I was embarrassed to find some awful code I created in
the commit shown below. I was rewarded with some 'nan'
floating point values and 'inf' computational results.
Reference(s);
. a missed opportunity to repent
commit ........................................
. true source of my original sin
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
124f26a4
The 'unrelated' note reflected in the original message
doesn't apply since we already used that correct name.
______________________________ original newlib message
If one per line display of Mem/Swap data was forced by
this #define, screen width was not fully exploited for
graph mode. Rather, those graphs were scaled just like
they would be if aligned with a nonexistent separator.
With this commit, those graphs will expand to fill the
screen width (or be limited by the maximum of '100' ).
[ and in unrelated news a variable used in do_memory ]
[ was changed for consistency. it doesn't affect the ]
[ the results since a part1 of swap was always zero. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
602146a6
______________________________ original newlib message
This patch introduces a new #define TOG4_MEM_FIX which
serves to turn off the new feature it also implements.
The feature, on by default, provides a flexible memory
graph approach which strives to always keep its visual
separator in alignment with cpu separators seen above.
Below is a summary of the algorithm implementing this:
1) First, ascertain the widest graph which corresponds
to the largest number of cpu graphs but doesn't exceed
maximum allowable graph width (i.e. GRAPH_length_max).
2) Next, apply that to the graphed 'Mem' portion which
is likely to remain entirely visible. However, it will
grow or shrink depending on total adjacent cpu graphs.
3) Last, the same width is used for the 'Swap' portion
but that graph is considered sacrificial and very well
could be truncated depending on the width of a screen.
[ along the way, when the cpu graphs revert to their ]
[ abbreviated form, the memory graphs will also show ]
[ an abbreviated prefix. in this way the widths will ]
[ also be maximized, reducing potential distortions. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
bf916fdf
______________________________ original newlib message
This commit will change some comments, adjust a little
whitespace but mostly rename some #define identifiers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
96153c0f
______________________________ original newlib message
When displaying detailed memory statistics two abreast
data for the lines are less than those for cpus. So we
can exploit such a difference to provide a distinctive
separator. This may help separating cpu & memory data.
[ in truth, this happened before this patch. what we ]
[ are doing now is polishing that accidental feature ]
[ and placing it under the control of a conditional. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
e5386f1f
______________________________ original newlib message
When displaying detailed cpu statistics, as opposed to
those scalable graphs, only two per line can be shown.
Therefore, if we are showing a detail version, our '4'
toggle must prematurely revert to single mode display.
Conversely, the 't' toggle must also turn off that '4'
toggle rather than try to print more than 2 abreast if
we're currently executing in detailed statistics mode.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5c5bff39
______________________________ original newlib message
When more than two cpus are displayed per summary area
line in graph form, those memory graphs were scaled to
that same width for consistency & aesthetics. However,
they probably shouldn't have been reduced to less than
terminal width due to a resulting loss of information.
[ after all, detailed memory stats are never reduced ]
So now, supporting logic was refactored to behave just
as it did before the 4 toggle was expanded beyond '1'.
[ the changes impact the 2 memory graphs exclusively ]
Reference(s):
https://www.freelists.org/post/procps/top-enhancements-2-bugs-swatted,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3543172d
______________________________ original newlib message
This patch just supplements the previous series with a
few minor tweaks representing some diverse objectives:
. a recent date for man page (which i always overlook)
. improved length calculations to maximize graph width
. a proper response to platforms with less than 8 cpus
. more consistency and readability with one blank line
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
fd529e96
______________________________ original newlib message
--------------------------------------------- ( none )
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
248efdf1
______________________________ original newlib message
Well, here it is. This is what the preceding series of
commits was leading to: an ability to show up to eight
cpus per Summary Area line. In reality, a self imposed
limit of four cpus on such lines seems more realistic.
In any case, the new capability could also be employed
along with that '!' toggle which consolidates adjacent
cpus into a solitary graph. When used together the '4'
and '!' toggles should accommodate any number of cpus.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1c802890
______________________________ original newlib message
I guess the cat's out of the bag with the prior commit
message. It mentioned the objective of displaying more
than the current two cpu graphs on summary area lines.
On the way to that objective, this patch just prepares
our battlefield for the actual implementation in which
up to 8 individual cpu graphs will be shown on 1 line.
[ no logic has been impacted with this commit. we're ]
[ just adding one manifest constant, trading several ]
[ identifiers and updating some comments so the next ]
[ commit might be just a little bit more manageable. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
8c69e66a
______________________________ original newlib message
This program has always been sensitive to the width of
a terminal/console. The detailed cpu/memory statistics
plus all of those full screen replacement windows were
designed to fit within some 80 column, 24 row display.
When a user narrowed a gui terminal to less than those
dimensions, top would simply truncate the data to fit.
However, when displaying cpu/mem graphs instead of the
detailed statistics such truncation was not justified.
After all, such graphs were already scaled to 80 cols.
Henceforth, when in graph mode, truncation won't occur
until the graphs will no longer fit within 10 columns.
[ can you keep a secret? this change is really being ]
[ made in anticipation of showing more than just two ]
[ cpu graphs in the summary area on each screen row! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2d5b51d1
______________________________ original newlib message
The logic (illogic?) in the sum_tics() and do_memory()
functions has grown to become almost unfathomable over
time. Additionally, though perhaps not apparent in the
code, many steps are duplicated within those routines.
So, this patch refactors all the summary graph support
to consolidate duplicated code and (hopefully) make it
more understandable with an eye to future maintenance.
[ additionally, that show_special guy's workload has ]
[ been reduced by eliminating any special directives ]
[ previously embedded in some cpu graphs even though ]
[ a cpu may have been idle during the last interval. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
08d0f377
______________________________ original newlib message
----------------------------------- ( minus git hash )
When 2 abreast cpu display was introduced, the minimum
screen width was 160 columns so as to avoid (minimize)
truncation. Later that was reduced to 80 columns while
keeping the original minimum as a compile conditional.
In preparation for (virtually) eliminating these width
restrictions in a future patch this #define's history.
Reference(s):
. May, 2020 - introduced #define TOG4_NOTRUNC
commit ........................................
. May, 2020 - introduce 2 abreast display
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
d9c45988
______________________________ original newlib message
----------------------------------- ( minus git hash )
When two abreast display was introduce, in that commit
shown below, this #define provision was also added. It
actually was an artifact left from program development
and never made much sense in a real world application.
If activated it would make the '4' toggle appear to be
broken since it would only take affect if a user first
activated individual cpu display (the '1' toggle off).
And there was no error message offered to those users.
So, this questionable #define is now being eliminated.
Reference(s):
. May, 2020 - introduce 2 abreast display
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
9d999370
______________________________ original newlib message
----------------------------------- ( minus git hash )
When top was made more responsive to keyboard input in
that commit referenced below, his previous response to
a SIGWINCH was upset. Formerly, that display integrity
was restored with the next refresh cycle. But, without
this patch, one must strike some key to accomplish it.
[ in truth, this patch vastly improves that sigwinch ]
[ response. whereas before, although integrity would ]
[ be restored automatically, it did not happen until ]
[ the next regular refresh. now it is instantaneous! ]
Reference(s):
. May, 2022 - made more responsive to kdb input
commit ........................................
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
80e2a7a6
______________________________ original newlib message
----------------------------------- ( minus git hash )
In that issue cited below, Tyson Nottingham identified
a potential abend which was associated with 'alternate
display mode' plus that troublesome 'mkVIZrow1' macro.
He also offered a perfectly adequate fix for that bug.
I refer to that macro as troublesome since it's now so
widely used and sometimes (by design) causes 'begtask'
to go negative (invalid). And now I found yet one more
place where it should have been used but wasn't ('f').
It's also troublesome as evidenced by some git history
listed below. Heck, there was even a commit addressing
the same symptoms (alternate display mode abend) which
Tyson suffered. Clearly, the current design is flawed.
So, with those two issues in mind, I've refactored the
approach to maintaining a visible task in the 1st row.
Henceforth, a 'mkVIZrow1' macro will be issued in only
two places: once at startup and after most keystrokes.
Such an approach likely results in additional calls to
the 'window_hlp' routine that aren't really necessary.
But, it provides a cleaner design less prone to errors
in the future. Besides, such additional overhead would
only be incurred when interacting with the user. Thus,
new costs are of no concern and will never be noticed.
Reference(s):
. Tyson Nottingham reported problem
https://gitlab.com/procps-ng/procps/-/issues/245
. Jun, 2018 - visible row 1 tasks first addressed
commit ........................................
. Jun, 2018 - adressed edge case, new bugs created
commit ........................................
. Sep, 2018 - additional edge case addressed
commit ........................................
. May, 2021 - some abends fixed, new error created
commit ........................................
. Jun, 2021 - try to prorect against future errors
commit ........................................
. Sep, 2021 - integrate mkVIZ & 'focused' tasks
commit ........................................
Discovered by: Tyson Nottingham
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The change occurred under the newlib branch in a patch
that couldn't be ported dealing with MEMINFO_MEM_USED.
That required a library change whereas this is frozen.
Reference(s):
. Jun, 2022 - newlib branch change
commit 047d16ccfda6638eda78f56b67def196a2002b6f
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
b0adacf1
______________________________ original newlib message
If we're deleting a character or operating in overtype
mode, we must account for the potential of 'invisible'
characters. When one follows any character about to be
deleted or replaced both multi-byte sequences must go.
Without this change, there exists the possibility that
top might report some error where no error is apparent
to the user. For example, with 'other filtering' (o/O)
the user could see "unrecognized field name 'COMMAND'"
where the quoted column name appears perfectly normal.
Or maybe a sequences like the 'combining acute accent'
gets applied to an existing character instead of being
deleted as one expects when its parent was eliminated.
So, henceforth whenever any character is being deleted
we will now check for a following 'invisible' sequence
then eliminate it along with that preceding character.
[ admittedly, these scenarios are very rare yet they ]
[ may occur, especially when recalling some previous ]
[ multi-byte strings for editing. and, since we will ]
[ be interacting with a user, performance won't be a ]
[ factor so extra checks for a zero wcwidth is fine. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
89200784
______________________________ original newlib message
--------------------------------------------- ( none )
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
757a3452
______________________________ original newlib message
This commit just provides the final protection against
possible screen corruption when processing line input.
[ such corruption was limited to the input line only ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3c7f8199
______________________________ original newlib message
Some kdeinit tasks have a large environment consisting
mostly of nulls which were then followed by one or two
printable characters. Such strange environments should
not be shown with that 'not applicable' (n/a) notation
even though that first string vector is equal to '\0'.
I thought I had covered such a contingency but, due to
a misplaced right parenthesis, that '^N' bottom window
could see 'n/a' + a bunch of spaces + printable stuff.
Well, that won't happen anymore with this tiny change.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
daaf634e
______________________________ original newlib message
--------------------------------------------- ( none )
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
2282c74c
______________________________ original newlib message
--------------------------------------------- ( none )
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
