Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

modification in the way we get the displayed path #72

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

jaesivsm commented Sep 16, 2012

  • refactor of _lp_shorten_path
  • if bash is used and bash's version is 4 or greater we'll use the
    PROMPT_DIRTRIM var which is a builtin way to shorten path

(redoing #71 which was quite messy and got mixed up with unrelated change)

@jaesivsm jaesivsm modification in the way we get the displayed path
* refactor of _lp_shorten_path
* if bash is used and bash's version is 4 or greater we'll use the
PROMPT_DIRTRIM var which is a builtin way to shorten path
5f128e3
Owner

nojhan commented Sep 23, 2012

Before merging that interesting patch, I would like to know if it is possible to configure the substitution characters used by dirtrim (seems to be "..." by default, I would have wanted the unicode's "…")?

Additionaly, the expected behavior linked to LP_PATH_KEEP seems to be broken:

[nojhan:~] $ cd /tmp/11111/22222/33333/44444/55555/66666/7777/88888/99999
[nojhan:.../33333/44444/55555/66666/77777/88888/99999] $

With LP_PATH_KEEP=2, it should have been something like:

nojhan:/tmp/11111/.../55555/66666/77777/88888/99999] $
Collaborator

dolmen commented Sep 24, 2012

It looks like the behavior seems to be quite different.
So I think it would be better to let the user choose: if we are under bash and PROMPT_DIRTRIM is set, then just use \w. Else use _lp_shorten_path. This check must be done just once, at load time (not every time we show the prompt).

Contributor

jaesivsm commented Sep 25, 2012

Indeed, for bash shell, the behavior change in two ways:

  • LP_PATH_KEEP isn't actually used anymore. The built-in PROMPT_DIRTRIM functionality doesn't take this kind of parameter in account. Only the ~ is kept when we're in an tree originating from HOME. We could actually prefix the path with some parts of the original path, but we'd lost the perks of using built-in the functionality.
  • The mark isn't customizable anymore.

I didn't see in the bash documentation a way to configure those two things.

As said by @dolmen, if we keep \w and the user disables LP_ENABLE_SHORTEN_PATH, he will still be able to define a custom PROMPT_DIRTRIM.

The advantage brought by _lp_get_dirtrim is to provide a dynamic value for PROMPT_DIRTRIM, and so to keep a behavior as close as possible be from the original one with built-in tools. Triggering the use of this function by detecting if PROMPT_DIRTRIM or another configuration variable is set is also doable. I'll commit something in that sense.

Owner

nojhan commented Jan 4, 2013

I would prefer to have this feature as an additional feature rather than loosing the custom mark feature.
Having the automated choice using PROMPT_DIRTRIM would be a good point.

jaesivsm added some commits Jan 4, 2013

@jaesivsm jaesivsm change in the way we decide to use PROMPT_DITRIM or not
we now check for an existing PROMPT_DIRTRIM variable to enable the use
of _lp_get_dirtrim

the check for the bash minimal version (4) has been suppressed as it was
redundant with the one for the PROMPT_DIRTRIM variable
ef0fdfc
@jaesivsm jaesivsm adding documentation 38adca6
@jaesivsm jaesivsm Bugfix: ${#max_len} != $max_len a093ed7
@jaesivsm jaesivsm precedent commit introduced a bug in the path composition aed53f6

@jaesivsm jaesivsm closed this Jan 9, 2013

Contributor

jaesivsm commented Jan 10, 2013

Sorry about the late notice about the closing of this pull request. After running some test I realized my way of shorting path was actually way slower that the one originally implemented. As the PR was globally bloated with unnecessary chamges, I closed it and opened a new one : #89

@dolmen dolmen added the duplicate label Jan 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment