xah-expand-region doesn't work in lisp

[spiderbit]

No matter if I use lisp mode or emacs-lisp mode it does not expand the normal lisp tree structure, instead it seems to expand to word then line and then +1 line forward each time:

Just found in the description:

when there’s a selection, the selection extension behavior is still experimental. But when cursor is on a any type of bracket (parenthesis, quote), it extends selection to outer bracket.

So thats a regression? I noticed that it works if you expand on the bracked correctly if you have the curson on the closing bracket at least.

Well to describe the problem I still post my example code:

(defun test (args)
  (print (+| 1 2)))

curser at |

1. expand it selects the "+"
2. expand it selects the line
3. expand nothing happens cause its the last line

if there are more (empty) lines it expands each time one more line.

[xahlee]

yes that command is experiment. pretty much alpha. but 2 reliable use are:

1. it selects current word on first press.

2. in lisp modes, if it is on the left paren, it'll select sexp, press again selects outer sexp.

[spiderbit]

But it used to work better, so you did rewrite it recently?

[xahlee]

last rewrite is some months ago. I think the version you refer to is like 1 or more years ago?

if so, that version does not do anything other than the 2 reliable items i listed. And sometimes it work incorrectly too.

[spiderbit]

Well its possible that it was 1 year old I did not update it very often cause I fear something breaks (for my usecase) even learning some different keybindings can be challenging, and maybe I did not notice that it was broken when I updated it last time, somethimes I dont code for 1 2 months or at least not much. So its possible.

But it really worked well, it may have not worked in special cases but generaly speaking it expanded from word to () to (()) to block perfectly most of the time.

Can't even remember it not working right at all, maybe if the parens were out of balance but otherwise it worked pretty perfectly.

has it outside dependency? Else I eval this old version from here for a tryout, and then make some testcases or something.

[xahlee]

if you revert your local copy to say 2 years ago, you can get back the code.

but i thought the current is better. I'd be interested in examples.

[spiderbit]

Well just tested it with the last version from 2015:

https://github.com/xahlee/xah-fly-keys/tree/668895c2f6014174b0e42539b9d2963ed71b401c had to evaluate xah-extend-selection and xah-semnav-up

same example:

(defun test (args)
  (print (+| 1 2)))

1. press [+]
2. press [(+ 1 2)]
3. press [(print (+ 1 2))]
4. press: [(defun test (args) (print (+ 1 2)))]

didn't test since when it changed but this version worked as I am used to it :D and which makes much sense for elisp I think.

[spiderbit]

In C-syntax langs its a mixed bag:

example:

Python:

print("te|st")

Java:

System.println("te|st")

ruby:

puts "te|st"

with the current version it has 2 extensions:

1. [test]
2. the line

with the old you have 3:

1. [test]
2. ["test"]
3. [("test")]

sadly the 4. doesn't expand to the line/expression.

so the old version does the first 3 steps the right way (imho) but misses the 4. step. with the new version it hits the 1. and 4. expansion but skips 2 and 3.

But even for C langs the new expansion is not very good:

void myfunc (){
  printf ("test");
}

old version:

1. [test]
2. ["test"]
3. [("test")]

new version:

1. [test]
2. line

print ("test") }

So to sum it up, the old version had perfect (e)lisp support (as far as I know). The new version has some some advantages and some disadvantages for C languages.

The ideal solution would be to write a better version that or modify the old that it can expand to the line.

2. best solution would be to use the old version for elisp mode and the new version for other things.

if I had to choose I give a shit about the line expansion in c langs, cause for what do you need a line based extension, you have already the copy / cut / paste functions that do line-based operations without a selection.

So its redundandet feature, you dont need line based expansion if your operation without a selection work linebased anyway?

So I see clearly the old version as the better version the regressions are way bigger then the advancements.

I even nearly forgot with: xah-select-current-line - bound on to 7 you already have the current line, so the new version is just worse in any case, if you disagree I am happy to see examples where you think its better, cause I can't think any?

[xahlee]

that's what am saying, this function is currently just experimental, alpha stage. Lots to do but i just haven't get around it.

it's trivial to change it to become the old version. Because it began as rewrite of the old version, so that it makes more sense when it's outside of lisp code too. But i haven't had much time, and one of the first experiment is just to expand lines.

as i mentioned, there 2 solid use right now.

1, select current work. 2, when cursor is on bracket, pressing it will expand to outer ones.

these 2 are reliable.

On Thu, Aug 10, 2017 at 5:22 PM, Stefan Huchler notifications@github.com wrote:

In C-syntax langs its a mixed bag:

example:

Python:

print("te|st")

Java:

System.println("te|st")

ruby:

puts "te|st"

with the current version it has 2 extensions:

1. [test]
2. the line

with the old you have 3:

1. [test]
2. ["test"]
3. [("test")]

sadly the 4. doesn't expand to the line/expression.

so the old version does the first 3 steps the right way (imho) but misses the 4. step. with the new version it hits the 1. and 4. expansion but skips 2 and 3.

But even for C langs the new expansion is not very good:

void myfunc (){ printf ("test"); }

old version:

1. [test]
2. ["test"]
3. [("test")]

new version:

1. [test]
2. line

print ("test") }

So to sum it up, the old version had perfect (e)lisp support (as far as I know). The new version has some some advantages and some disadvantages for C languages.

The ideal solution would be to write a better version that or modify the old that it can expand to the line.

2. best solution would be to use the old version for elisp mode and the new version for other things.

if I had to choose I give a shit about the line expansion in c langs, cause for what do you need a line based extension, you have already the copy / cut / paste functions that do line-based orientation without a selection.

So its redundandet feature, you dont need line based expansion if your operation without a selection work linebased anyway?

So I see clearly the old version as the better version the regressions are way bigger then the advancements.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xahlee/xah-fly-keys/issues/26#issuecomment-321707210, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYsxoDXvKsnSyVPIUS5kE_cK7nZVEpjks5sW565gaJpZM4OtPoL .

[spiderbit]

select current work? what does that mean?

 print ("test | 1111")

when I expand here it expands to the 3 spaces, so it does not even expand to word or sentence... I did put the old stuff in my emacs config now.

I just don't see really how thats better.

2. line by line expansion:

I can easily do that with: xah-select-current-line next-line

all easily with the default keybindings, 7 t t t t... for (e)lisp its a huge regression, even for C not beeing able to select the string with the ["] is a regression, I can think of copying a string in a c source, having to manuelly select the chars of the string + ["] would be a pain in the ass.

I suggest you bring back the old code till the new is working (better)... I think this functions is a very important one basicly a killer feature of fly keys, over the modularity itself.

But I can load the old code manualy of course. If you at least could get real advantages in C langs it would maybe depending on your priority worth to use it even if it does not work for elisp good anymore, but so you gain basicly nothing, but have huge regressions.

btw it also expands to "[]"

var cars = ["Saab", "Volvo", "BMW"];

so you can select also the [] block here in typical vector/array blocks in different languages here js. and I am pretty shure it would be easy to expand it very easy to "{}" and then you could expand to if or for or other code blocks in languages that use {} for that.