Feasibility suggestions

[beef9999]

Type of feature request

Misc

Misc

No response

Summary Description

1. The source panel: Source file and line number shouldn't be collapsed. We all have wide screens nowadays. For example, source:/root/rocksdb/b[...].h+435.
2. The trace panel: Source file and line number should be able to configure to display. Otherwise we have to use frame to see the actual source code step by step.

Implementation idea/suggestion

.

Existing alternatives?

No response

Additional information

No response

[Grazfather]

We need to collapse it if it is too long to fit on one line, but I agree that we shouldn't collapse it unless we need to. We can probably have the title function do the collapsing, though it would not know how to collapse it nicely. Maybe context_source should use self.tty_columns instead of hardcoding 20 as the max fn length.

[beef9999]

Notify me if you have fixed it.

[hugsy]

Notify me if you have fixed it.

This is a low priority for us. If you want to see this feature happening, we welcome a PR.

[beef9999]

You didn't even realize this is a major reason new users say good bye to your tool :-)

Once again, source:/root/rocksdb/b[...].h+435. Tell me which file I was looking at?

[theguy147]

@beef9999 This is an open source project where everyone chips in on their free time. If this is an issue you absolutely want to see in GEF than you're always welcome to create a PR with your changes instead of demanding other people to fix it even when they deem that the issue doesn't have a high priority for them.

While I agree that this issue doesn't qualify for high priority (for my use cases), we could actually prioritize the final part of the path instead of the beginning with something as simple as this change...

    def context_source(self) -> None:
        # ... snipped ...
        if len(fn) > 20:
-            fn = f"{fn[:15]}[...]{os.path.splitext(fn)[1]}"
+            fn = fn[-20:]
        # ... snipped ...

Allthough with really long filenames this could make things more confusing. A more (and maybe unnecessarily) complex approach would split the path into dirname and basename and start by shortening the dirname in the front and if that doesn't suffice then continue to shorten the basename at the end...

Additionally, in the long run we could introduce a setting context.line_length (or similar) instead of all the hardcoded values in the codebase. This could be done by somebody who currently has enough free time at their hand and really wants this to be implemented...

EDIT:

I'm definitely not proud of this code snippet, but this would do the job of shortening a path to a maximum length n with the above mentioned strategy:

def shorten_path(path: str, n: int) -> str:
    if len(path) <= n:
        return path
    
    _dir, base = os.path.split(path)
    n -= 4

    b_len = len(base)
    if b_len < (n-1):
        n -= (b_len + 1)
        return f"[..]{os.path.join(_dir[-n:], base)}"
    elif b_len == (n-1):
        return f"[..]/{base}"
    elif b_len == n:
        return f"[..]{base}"

    base, ext = os.path.splitext(base)
    n -= (len(ext) + 4)
    return f"[..]{base[:n]}[..]{ext}"

And here are the results of some long path with filenames of increasing length (using a de-bruijn sequence for the filename itself):

/this/is/some/long/path/a.py
[..]/is/some/long/path/aa.py
[..]is/some/long/path/aaa.py
[..]s/some/long/path/aaaa.py
[..]/some/long/path/aaaab.py
[..]some/long/path/aaaaba.py
[..]ome/long/path/aaaabaa.py
[..]me/long/path/aaaabaaa.py
[..]e/long/path/aaaabaaac.py
[..]/long/path/aaaabaaaca.py
[..]long/path/aaaabaaacaa.py
[..]ong/path/aaaabaaacaaa.py
[..]ng/path/aaaabaaacaaad.py
[..]g/path/aaaabaaacaaada.py
[..]/path/aaaabaaacaaadaa.py
[..]path/aaaabaaacaaadaaa.py
[..]ath/aaaabaaacaaadaaae.py
[..]th/aaaabaaacaaadaaaea.py
[..]h/aaaabaaacaaadaaaeaa.py
[..]/aaaabaaacaaadaaaeaaa.py
[..]aaaabaaacaaadaaaeaaaf.py
[..]aaaabaaacaaadaaae[..].py

[beef9999]

I think a common problem among engineers is to equate priority with difficulty or functional complexity, while ignoring the basic fact that many users only use 30% of a product's basic functionality. For example, as a C++ application developer, I basically don't watch registers and assembly. The reason why I don't like gdb is that it doesn't have a color display like gef, and it can't print local variables conveniently. Maybe you would think these are simple usages that gef has been supported for a long time, but if it is not good enough or even flawed, most ordinary users will still go back to gdb.

[Grazfather]

I suggest you use gdb-dashboard instead of GEF.