no-wrap mode?

[Andrew Athan]

I looked around but didn't find a way to turn off line wrapping in iTerm2. What I did find was this old discussion:

https://groups.google.com/g/iterm2-discuss/c/4PTptVLYrNQ

Does this feature exist?

[Richard Mitchell]

I'm assuming piping the output to (a variant of) less doesn't work for your workflow ?

[Adrian Bool]

Hi Andrew,

I've had a look at a few ways of achieving this within the current iTerm2.

Richard's suggestion of less works well — the argument -S turns off wrapping within less and allows you to use the left/right cursor keys to move to data that is off screen.  By default, moving over to content to the side in less is performed in quite large jumps.  This can be controlled using the # parameter.  You can set the environment variable LESS="-S # 10" such that LESS doesn't wrap by default and jumps left/right in blocks of 10 chars.  Works pretty well.

There is also a tool "most" (available on Homebrew) for which non-wrapping of content is the default and left/right scrolling character-by-character.  That seemed perfect for when you do need to process long lines in this manner; however I tried using it a little and found it wasn't really as polished as less.  e.g. I intended to pipe some grep output into most but forgot the input filename to grep - the terminal was frozen awaiting input from stdin that would never come. I couldn't break out of this so had to close that tab and loosing that shell.  Repeating this with less, Ctrl-C allowed me to break out and correct my stupidity within the same shell.  It turned out that I didn't have read rights to the file to be grepped and when piping through "most" I just saw an empty file; whereas with less it showed the error message by presenting stderr instead.  All in all, less seems to be the far better pager.

Neither of the above seem to allow horizontal control by the trackpad as mentioned in the Google Groups discussion.

To get trackpad control seems to be a bit of a faff.  I found that using tmux (again in Homebrew) and issuing the command Ctrl-B ":resize-window -x 1000" would present a really wide terminal to programs within the session; causing them effectively not to wrap.  With the iTerm settings "Allow two finger swipe between tabs" disabled (in Advanced) and "Enable mouse reporting" enabled (within the Profile->Terminal config) - I could kind of use the trackpad to scroll around.  But, similar to less's defaults, the move was in big jumps and it didn't feel reliable at all.  Too annoying to use in my opinion.

I'd just keep to "less -S". ;-)

One issue I did find was that my personal default less environment variable is LESS="-Xr" - the X instructs less not to clear the content on exit and the "r" allows raw control chars to be displayed (which helps when viewing output from Terraform).  My use of -r caused -S not to work, but using -R (a softened version of -r) did not cause this issue.  So, in my case LESS="-XRS #10" seems to be the best environment variable for this long-line behaviour.

I feel it is worth mentioning another "less" feature of which I wasn't aware for the longest time - when viewing a file using less; entering F (i.e. shift-f) instructs less to move to the bottom of the file and follow updates to a file as one would normally do with "tail -f".  I could well imagine this could be a useful parameter in this use case if the data is coming in live...

Cheers

aid

--
You received this message because you are subscribed to the Google Groups "iterm2-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iterm2-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iterm2-discuss/66f90ea5-640b-47b7-8775-fa746f54408bn%40googlegroups.com.

[George Nachman]

In the current beta you can turn off line wrapping for a limited section of history. 

1. Select the text you wish not to wrap
2. Choose the menu item Edit > Render Selection
3. Click the Wide button at the top and select the proper syntax highlighting, if desired.

The end result looks like this:

--

You received this message because you are subscribed to the Google Groups "iterm2-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iterm2-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/iterm2-discuss/eb6df1e1-6a2c-4d66-b185-2c464e273091n%40googlegroups.com.

[Andrew Athan]

Thanks for the replies:

piping through less & other means of encapsulating the content in a viewer that manages its display is simply a different animal than what I asked about. There are at least two reasons that kind of solution may not work for people: (1) it assumes that the output pipeline is running in an environment that can provide the necessary resources and (2) it requires that you've set up that pipeline a-priori, unless you save the terminal buffer and re-pipe it in order to achieve the no-wrap rendering.

George ... good to know, I'll check it out next opportunity.

I've come to this discussion group and/or to the iterm2 issues tracker over the last couple of years over search & formatting features/bugs/etc all of which stem from cases where iterm2 is displaying (sometimes voluminous, sometimes colorized, sometimes formatted) logging output. Log analysis is "a thing" and it occurs to me I should explore purpose built tooling for that task. However, terminals are frequently where devs interact with logs ...

A.

[George Nachman]

Yeah, a native log analysis tool has been in the back of my mind for a long time. It’d be useful to build a list of desired features for such a thing.

To view this discussion on the web visit https://groups.google.com/d/msgid/iterm2-discuss/1f7efafc-a0dc-46f2-a5d8-af98fdfb1279n%40googlegroups.com.