[ELPA] New package: shift-select

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[ELPA] New package: shift-select

Jen-Chieh Shen
Shift select text like how other text editor does.  

I notice there is `shift-select-mode` built-in to Emacs, but this does not work the same as other text editor. And somehow act weird and mess up the select region. This package should have the user use the shift select text the same way as other text editor. 

Virus-free. www.avg.com

shift-select.el (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ELPA] New package: shift-select

Clément Pit-Claudel
On 2019-04-16 03:51, Jen-Chieh Shen wrote:
> I notice there is `shift-select-mode` built-in to Emacs, but this does not work the same as other text editor.

What's the problem with the way shift-selection works in Emacs?

Reply | Threaded
Open this post in threaded view
|

Re: [ELPA] New package: shift-select

Stefan Monnier
In reply to this post by Jen-Chieh Shen
> (defun shift-select-pre-command-hook ()
>   "Shift select pre command hook."
>   (setq-local shift-select-shift-pressed

You already declared the var with `defvar-local` so you don't need
`setq-local` here (or alternatively, you can use plain `defvar` at
top-level and `setq-local` here).

>               (ignore-errors
>                 (and (stringp (symbol-name last-command-event))
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This either errors or returns t but never returns nil, sop you can just
remove it.  Tho I think what you meant to write was (symbolp
last-command-event), after which you should remove the `ignore-errors`
which would otherwise just hide programming errors.

>                      (string-match-p "S-" (symbol-name last-command-event)))))
>   (when (or this-command-keys-shift-translated
>             shift-select-shift-pressed)

When is this shift-select-shift-pressed needed?  It seems like this
might be working around a bug somewhere in the sense that
this-command-keys-shift-translated should have been non-nil already.

> (defun shift-select-post-command-hook ()
>   "Shift select post command hook."
>   (if (or this-command-keys-shift-translated
>           shift-select-shift-pressed)
>       (let ((cur-pt (point)))
>         ;; User moves the cursor when holding shift key.
>         (unless (= cur-pt shift-select-start-pt)

IIUC this is trying to notice when the command was a motion command.
Those should call `handle-shift-selection` (e.g. via the `^` char in
their interactive spec string) to announce that they're motion commands.
So IIUC this code tries to compensate for commands which fail to call
`handle-shift-selection`.

It's probably a good heuristic, but it would be good to report those
commands so we can fix them.  Using a heuristic like this one is OK for
an optional package, but for the core functionality we want something
that doesn't occasionally misfire (e.g. cur-pt can be different from
shift-select-start-pt because we switched to a different buffer, or
because text was inserted/deleted before point).

I don't see anything in this code which handles shift-selection
differently from the default code, so I'm not sure what is meant by
"Shift select text like how other text editor does".

Instead it seems to try and work around bugs in code which was (still)
not (yet) adjusted to cooperate with the "new" shift-selection
introduced in Emacs-23.  Maybe you could change the Commentary
accordingly (or otherwise clarifies in which way the behavior is
supposed to differ from the default shift-select-mode)?


        Stefan