Cursor positioning vs TABs (vs variable fonts)

[aramazano]

I think character count and cursor position are different things. For instance;

• I look at the "Position" value to assess where I am in a document positionally. I use this value as a rough formatting cue. So I need positional value here.

• In a TAB formatted text documents I use Up/Down keys to move vertically in the document, and when I press [Down] I expect the cursor goes down positionally vertical. So I need positional behavior here. Currently, with Up/Down keys, cursor moves vertically by character count, making zig-zags from line to line. This makes formatted text editing tedious.

I would like to have cursor positioning handled as cursor's logical (geometric) position, rather than its physical (character count) position.

OTOH, I don't know how this affects variable length fonts (Latin) or certain peculiar character sets/alphabets (with huge length variations between characters).

Tried this with mousepad and juffed to see how they behave with variable fonts:

• Mousepad: There is a setting for font selection but it doesn't work. No matter what font you select, it goes on with the same monospace font.

• Juffed: Behaves in an intelligent way - vertical cursor moves are carried out literally positional - that is it keeps pixel positioning of the cursor the same in vertical move.

  • For monospace fonts, this gives the expected behavior of keeping the same cursor position by its logical position (which also coincides with pixel position).
  • For variable fonts, the cursor moves pixel-wise vertically, so that its column position from one line to the next can drastically be different. For instance, I tried two lines, one filled with "i" letters and the other with "m" letters. The cursor is at 180th column in the "i" line, and when I move it up, it goes to 61st column position of the "m" line - this geometrically the closest location to the 180th character of "i" line. I found this behavior ingenious in that, sticking to logical character position is only sensible for monospace text, because ASCII-art formatting is only possible with monospace. OTOH with variable fonts ASCII-art can't be used, so pixel-wise vertical movement makes better sense there. This approach also resolves my earlier self-wonderin about peculiar alphabets with largely varying lenth letters.

As I always work with monospace fonts, it doesn't matter for me whether pixel-position or logical-position is used. Geometrically fixed horizontal positioning just for monospace fits me well. But I feel juffed's approach should be given a consideration as well. I liked it.

[aramazano]

• I look at the "Position" value to assess where I am in a document positionally. I use this value as a rough formatting cue. So I need positional value here.

I forgot to mention that here I talk about the "Position:" value shown at the far right of status bar.

[aramazano]

But I feel juffed's approach should be given a consideration as well. I liked it.

As everything desirable in life, the next question is cost. So a more realistic expression would be: I like it if it is cheap, I hate it if not. :)

If it requires some convoluted bloat to keep pixel position stable in variable length fonts, than I don't think it would be worthwhile. I have no use case for it anyway.

If I am not mistaken, juffed makes use of scintilla library. Possibly owes this behavior to some borrow-ware function there. :)

[tsujan]

@aramazano I didn't understand what you wanted. Please explain it concisely, without referring to other things.

As for the position, it's calculated from each line start and you really can know where you are in a document by knowing it. I don't understand what more you might need for that.

Neither I understood what you meant by a zig-zag movement. FeatherPad's behavior is like other text editors, Kate for example.

[tsujan]

OK, I read you comments again.

The text info should be independent of temporary factors like font size, font type, pixels, window size and wrapping; otherwise, it won't be a real info.

The cursor position is always the position from the line start. Here, "line" means the real or absolute line (sometimes called "block", sometimes "paragraph"). The visible line is relative and depends on temporary factors.

Non-mono fonts are non-mono by definition. If you use them, there will be an obvious cost: characters won't have the same width. Text cursor should (and can) never depend on pixels.

Text tab is a single character in itself. Its visible width in pixels depends on the font type. In FeatherPad, it's 4 spaces but that can be changed. As is explained in Help:

"It is better to use text tabbing only for indentation and never alongside spaces; otherwise, text lines might have different indentations with different text editors."

The same is true with different fonts (I'll replace "text editors" with "fonts" in the above explanation). Text tabs shouldn't be used in the middle of the text for alignment.

In short, forget about pixels ;)

[aramazano]

OK, sorry for bringing up variable length fonts here - it was just an interesting side note and I don't use non-mono fonts anyway.

Text tabs shouldn't be used in the middle of the text for alignment.

This is the critical part. I do use tabs for "tab"ulation a lot in ASCII-art tables etc. It is true that with different TAB lengths text gets distorted, but I always use 8 char tabs everywhere and it is OK for me as long as I don't exchange docs with others (even then it's usually OK because ordinary people mostly use 8 char tabs by default).

I am simply suggesting to count TAB characters as 8 spaces (or whatever length it is set to) in cursor positionings and in the "Position:" value at the status bar.

To reproduce the zig-zag movement I was talking about:

0) Set TAB length to e.g. 8 spaces (anything will do) 1) Prepare a test content, alternatively one line comprised of TABs, and one line of spaces. 2) Put the cursor on e.g. 5th TAB (cursor position:5) 3) Jump to the neighboring line by Up or Down key and note where the cursor is now.

At the "TABs" line, cursor position is reported as 5, while the cursor is at 40th character position and while it is correct from character count point of view, it is not so from positioning point of view.

Other text editors, including vi, behaves the way I suggest.

[tsujan]

I am simply suggesting to count TAB characters as 8 spaces (or whatever length it is set to) in cursor positionings and in the "Position:" value at the status bar.

That's wrong because the text tab is just one character (\t) and doesn't consist of a number of ordinary spaces. If you want it to be 8 characters, you should use 8 spaces instead of an 8-space wide tab.

FeatherPad has shortcuts for 2 and 4 spaces but more than that would be bloating/misusing shortcuts. You could press Ctrl+Tab twice for 8 spaces.

At the "TABs" line, cursor position is reported as 5, while the cursor is at 40th character position

That's both correct and expected. Use either real text tabs or spaces for indentation/making distance.

Other text editors, including vi, behaves the way I suggest.

Because they don't use real text tabs but just spaces and, in this way, hide the meaning of a real tab. As mentioned above, FeatherPad uses real tabs and has shortcuts for 2/4 spaces.

To summarize: text tab ≠ set of ordinary spaces

[tsujan]

On a side note, I can make Ctrl+Tab obey the setting for the real tab width. If you wanted that in this report, I wouldn't close it. Actually, it's a good idea and I will do so. But tab is tab ;)

[aramazano]

If you want it to be 8 characters, you should use 8 spaces instead of an 8-space wide tab.

I can make Ctrl+Tab obey the setting for the real tab width.

But if you mean by that, putting N spaces for a tab char, then it wouldn't work the same as tabs. There is a reason why I use tabs instead of spaces in text formatting. Consider this table:

Name Address

---

Lorem Some address Sit Another address Amet Yet another address

With space formatting, whenever a name field is re-edited for a shorter or longer one, corresponding address field gets misaligned. OTOH with tab formatting, chenging the length of a name doesn't affect corresponding address alignment (as long as name length didn't exceed that of tab).

Because they don't use real text tabs but just spaces and, in this way, hide the meaning of a real tab. As mentioned above, FeatherPad uses real tabs

I am not sure if I understood this correctly, but all the other editors ı referred to use a single real \t (0x09) character in the file, like FeatherPad. As for presentation, they jump from one tab-stop to another, so they use tabs as "real tabs" in presentation too. Possibly I am missing something here?

[aramazano]

I hope it renders better now.

Name    Address
----    -------
Lorem   Some address
Sit     Another address
Amet    Yet another address

[tsujan]

There is a reason why I use tabs instead of spaces

Of course, there is, and that's my point. Check this with FeatherPad but with a non-mono font like DejaVu Sans or Arial (replace <TAB> with a real tab):

aaa<TAB>b
a<TAB><TAB>b

Then check it with Kate (which uses "false" tabs):

aaa b
a       b

With FP, b's are aligned vertically. With Kate, you could do nothing to align them.

[tsujan]

A screenshot with Arial (in case you don't have it):

[tsujan]

Oh, I forgot to say that you should use the default tab in the above test.

[tsujan]

In simple words:

A real tab is a beast that changes its length to work with both mono and non-mono fonts. However, if mono is changed to non-mono or conversely, the alignment will be lost.

On the other hand, "false tabs" may not work with non-mono fonts (for alignment).

[tsujan]

To be super thorough:

You may have been misled by this (Kate's default Config):

With that setting, the user couldn't do alignment with non-mono fonts. With the option above it, alignment will be possible for mono and non-mono fonts (separately).

[aramazano]

I don't have kate due to its KDE dependency, and mousepad advertises but won't do variable length fonts, so I just tried it with juffed. Yes, with variable length fonts juffed misses the alignment (like kate). But with mono fonts (where a plain text editor will be used most, if not always) they do tabs OK.

On a side note, I don't know if TAB concept means much in variable legth fonts. Because TAB is -by definition- for tabulation, and it inherently requires monospace. TAB concept is a legacy of old monospace-only domain, so it looses its meaning for variable length fonts. So, I think that a TAB should mainly cater for monospace. For variable fonts, I would accept whatever functionality a TAB happens to offer. :)

[tsujan]

Because TAB is -by definition- for tabulation, and it inherently requires monospace.

Wrong! Real tab is for both mono and non-mono -- as I emphasized above. I don't know about old times or legacy.

If I added such an option to FeatherPad, I'd get a "bug" report, saying, "I can't align text with DejaVu Sans..."

EDIT: Or worse: "Text can't be aligned."

[tsujan]

The interesting thing is that, when Kate is used outside KDE, it gets the default font of the active DE, which is usually non-mono. Advanced users may know what's wrong but we can't expect that.

[tsujan]

There is a compromise: Adding an option, like "Spaces instead of text tabs", always disabling it for non-mono fonts, and adding a tooltip about that to it.

[aramazano]

I am not sure such an option would worth the clutter, as Ctrl+Tab is already doing that fine. And I have just checked, it is also following "Tab width" setting as well. My tabs are 8 characters long and Ctrl+Tab inserts 8 spaces.

Unfortunately "spaces for tabs" is not what I was looking for. :)

[tsujan]

And I have just checked, it is also following "Tab width" setting as well. My tabs are 8 characters long and Ctrl+Tab inserts 8 spaces.

Oh, thanks! I'd forgotten that.

Unfortunately "spaces for tabs" is not what I was looking for

I'm sure that's exactly what you tried to describe and Kate has it :) Its difference from a mere 4/8-space Ctrl+Tab is that, it might insert less spaces in order to create a vertical alignment if possible -- but only for fixed-pitched fonts.

Anyhow, this feature seems both interesting and useful to me. As far as I know myself, I'm sure I couldn't help implementing it sooner or later ;)

[aramazano]

Its difference from a mere 4/8-space Ctrl+Tab is that, it might insert less spaces in order to create a vertical alignment if possible

However, it would fill up the area with spaces instead of a \t character, making further edits prone to misalignments, re: https://github.com/tsujan/FeatherPad/issues/130#issuecomment-385197864 and this is precisely why I use tabs instead of spaces.

I need the "vacuum zone" of a tab for recurrent edits to not misalign the following text.

[tsujan]

The second good thing that I can extract from this discussion is changing the behavior of Up/Down, so that they see a real tab as 4 spaces, instead of a single character (what it really is). Again, Kate has it and I'll add it to FP soon.

[tsujan]

I opened https://github.com/tsujan/FeatherPad/issues/132

[aramazano]

Its difference from a mere 4/8-space Ctrl+Tab is that, it might insert less spaces in order to create a vertical alignment if possible

It just occured to me that this can very well be the default (hard coded) behavior of Ctrl+Tab. That would result in one less option (tidiness) in settings. Since a TAB jumps to next tab-stop by a \t character, it follows naturally that a Ctrl+TAB would jump to next tab-stop by spaces. Really, current Ctrl+TAB behavior of placing a fixed number of N spaces was a bit out of context (though acceptable). Therefore, assigning the behavior you mentioned to Ctrl+Tab fits in nicely (I think).

[tsujan]

I made Up/Down vertical as far as possible with tabs in https://github.com/tsujan/FeatherPad/commit/42356b1261ba632990866ab9b56c15cc3fd00c44. Now, their behavior is exactly that of Kate + tabulators (= real tabs).

We'll discuss "Spaces instead of text tabs" or, perhaps, a new behavior for Ctrl+Tab later.

In the last 24 hours, I broke my record for coding and committing; really need some rest ;)

[aramazano]

That's amazing! Thank you very much for your hard work. :)

[tsujan]

Thanks for your support and reports!

[tsujan]

Fixed Ctrl+Tab in https://github.com/tsujan/FeatherPad/commit/1af4179ed8f9743e583a1229f25ae1dedc6f16db

Now, you could use Ctrl+Tab for vertical alignment (with mono fonts, of course -- for non-mono fonts, only real tabs work).

The bug was about inserting spaces without considering the cursor position. It's fixed now. Many thanks for finding and reporting such issues!

I also apologize for closing this report before first extracting its info. Please describe problems concisely, so that I (or any developer) can see them quickly.

[aramazano]

No need to apologize, such things happen, and it was my floppy style (again) to mix main issue with subtly relevant side notes, blurring the focus and meaning of the report.

All the hard work is yours, so all the thanks go to you. :)

[tsujan]

Thanks for the kind words!

I completed it a few minutes ago. Waiting for you to test it (after the deb package is updated).

[aramazano]

Works like a charm. :)

[tsujan]

Happy to know that :) Are you sure you have the latest version? The deb package is updated so soon?! I made 2 other commits too.

[agaida]

tstststs

featherpad:
  Installed: 0.9~45-g82fafe6-1
  Candidate: 0.9~45-g82fafe6-1
  Version table:
 *** 0.9~45-g82fafe6-1 500
        500 http://packages.4sid.eu/debian experimental-snapshots/main amd64 Packages
        500 https://lxqt.debian.net/debian experimental-snapshots/main amd64 Packages

The very advantages of jenkins, an own buildserver and a self hosted repository - and a guy how is tinkering with some web stuff deep at night ...

[tsujan]

Soooo fast! And nice.

a guy how is tinkering with some web stuff deep at night

Like me ;)

[aramazano]

Just installed the latest version (0.9~45-g82fafe6-1) tonight. :)

[agaida]

and again - building the packages is easy:

git clone https://salsa.debian.org/lxqt-team/featherpad -b experimental-snapshots 
cd featherpad
git snapshot
dch -r
debuild -j$N
$SUDO apt install ../*deb

done :P ok, for me it is debuild -S; dput snapshot ../*changes

[aramazano]

Hmm I have just stumbled upon git-buildpackage (makes use of git and devscripts)

This package contains the following tools:

• gbp buildpackage: build a package out of a git repository, check for local modifications and tag appropriately
• gbp import-orig: import a new upstream version into the git repository
• gbp export-orig: export an upstream tarball from the git repository
• gbp import-{dsc,dscs}: import existing Debian source packages into a git repository
• gbp dch: generate Debian changelog entries from Git commit messages
• gbp {pull,clone}: clone and pull from remote repos
• gbp pq: manage debian/patches easily
• gbp create-remote-repo: create remote repositories
• gbp push: push content to remote repositories
• gbp tag: tag a Debian package in git
• gbp pristine-tar: create pristine-tar commits

Maybe I should fiddle with it later. Seems good for a lazy *** like me. :)

[agaida]

Your current problem is - you don't read and listen and have no plan about packaging :P - sorry if i'm saying this so direct. git buildpackage is fine if the workflow is made for git buildpackage - we don't use it for LXQt packaging in Debian right now. All one need for the experimental snapshots is lxqt-build-package - and the included scripts.

And for the experimental snapshots the workflow is as described above - ok, i leaved out pushing the changes back to the repo. This make sure that the official packages work with the snapshots to an extend, aka possible upgrade pathes etc.

[tsujan]

Going off topic, to make both of you angry ;) When it comes to making an installable package, nothing compares to Arch's makepkg. Don't say, "no"!

[agaida]

why should i be angry - i started with arch :P

[aramazano]

@agaida being direct is better, no problem. And you were correct too, currently I have other things to do, so I am not really into packaging for the time being. I am already getting the packages fairly soon with experimental-snapshots, but of course you can push me into packaging, by stopping experimental-snapshot updates. ;) Anyway, I plan to tinker with it in due time.

@tsujan I never used an Arch based system so I can't know. Have experience only with Slackware, various RPM and DEB based system, and finally settled down on Debian. I surmise you would recommend Arch? ;)

[tsujan]

I surmise you would recommend Arch?

No I don't. Debian is excellent. You might ask why I migrated from Debian to an Arch-based system. The answer: only because I wanted more speed with package management. I recommend Debian ;)

BTW, Ctrl+Tab has still a hidden problem. I'll try to fix it.

[tsujan]

Made the fix -- hopefully, the last one for text (de-)tabulation.