www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - single-line string?

reply spir <denis.spir gmail.com> writes:
Hello,

This may be a feature request for a single-line string syntactic form --if ever 
others are annoyed as well, see below. One possible form may be:
     str = s"abc";
I have myself long found it stupid to separate single- and multi-line string, 
since there is no formal reason for that. But there are practical consequences 
on code edition I did not imagine until I started coding in a language not 
making this distinction... namely D.

Problem:

In my editor, Geany, each time I press '"', the whole code (actually the rest 
of the code from the current cursor position) is re-scanned, re-interpreted, 
re-displayed. This is fully logical and in itself is not a major issue in Geany 
because it is very light & fast. I wonder how this goes with heavier editors or 
real IDEs.
But the real point is that this causes a big usability problem, namely that all 
(the rest of) code suddenly gets unfolded! If I want to go on editing 
comfortably, I then need to refold all and manually re-unfold the part(s) I'm 
currently working on. Very annoying. Imagine a debugging session requiring 
debug prints here & there...

This is a bug of the editor, indeed, but since Geany is based on Scintilla's 
editon component, I guess this bug may be widely shared. A solution may be that 
opening of a (possibly multi-line) string should limit the reinterpretation 
scope to the current logical line, or simply suspend it, until either the 
string is closed, or said line is quit (via arrows or mouse). Also, the bug 
happens even if I use Geany's feature of auto-closing delimiters, meaning when 
I press '"' '""' is written out (a feature I hate anyway for code edition). I 
would like to know how & how well other editors deal with all of that 
(especially but not only emacs and vim).

Compare with multi-line comments: the difference is double: (1) there is syntax 
for single-line comment (2) the closing delimiter is different ('/*' vs '*/'). 
This means that (1) use of multi-line syntax is limited to actual need for 
multi-line (2) one can avoid the bug by writing the closing delimiter first, 
hehe! (what I constantly do when writing docs docs)

Any comment ot hint welcome.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Apr 2011 10:49:58 -0400, spir <denis.spir gmail.com> wrote:


 Hello,

 This may be a feature request for a single-line string syntactic form  
 --if ever others are annoyed as well, see below. One possible form may  
 be:
      str = s"abc";
 I have myself long found it stupid to separate single- and multi-line  
 string, since there is no formal reason for that. But there are  
 practical consequences on code edition I did not imagine until I started  
 coding in a language not making this distinction... namely D.

 Problem:

 In my editor, Geany, each time I press '"', the whole code (actually the  
 rest of the code from the current cursor position) is re-scanned,  
 re-interpreted, re-displayed. This is fully logical and in itself is not  
 a major issue in Geany because it is very light & fast. I wonder how  
 this goes with heavier editors or real IDEs.
 But the real point is that this causes a big usability problem, namely  
 that all (the rest of) code suddenly gets unfolded! If I want to go on  
 editing comfortably, I then need to refold all and manually re-unfold  
 the part(s) I'm currently working on. Very annoying. Imagine a debugging  
 session requiring debug prints here & there...

 This is a bug of the editor, indeed, but since Geany is based on  
 Scintilla's editon component, I guess this bug may be widely shared. A  
 solution may be that opening of a (possibly multi-line) string should  
 limit the reinterpretation scope to the current logical line, or simply  
 suspend it, until either the string is closed, or said line is quit (via  
 arrows or mouse). Also, the bug happens even if I use Geany's feature of  
 auto-closing delimiters, meaning when I press '"' '""' is written out (a  
 feature I hate anyway for code edition). I would like to know how & how  
 well other editors deal with all of that (especially but not only emacs  
 and vim).


Not sure about folding in vim, since I generally do not use vim's folding  
features, but it does temporarily syntax highlight the rest of the file as  
if it were a string.  However, vim does not re-interpret/display the  
entire file, it generally only cares about the visible portion.

In NetBeans, you can set it up to insert two quotes when you type one  
(i.e. auto-closing delimiters).  However, I use that to edit PHP and HTML,  
so I'm not sure how that compares.

I'd say your best bet is to get the bug fixed in your editor.  Changing  
the language is wholly inappropriate to address an editor bug, especially  
when it's only one editor, and one person's preference that is being  
affected.

-Steve
Apr 14 2011
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
spir Wrote:


  I 
 would like to know how & how well other editors deal with all of that 
 (especially but not only emacs and vim).


Vim's heritage is line based editing. For this reason operations are performed
by line and it does processing by line. However as it is visual its buffer
consists of more than the line being edited.

Highlighting is done once again on a per line basis and only of the visible
area (give but never take a few). To handle multiple lines Vim uses
synchronization. It makes use of specific structures which it can use to
'anchor' how the lines below will be highlighted, and again it only needs to
process till the end of the visible area (it will continue processing as you
scroll down).

You can specify how many lines back Vim will look for an anchor before it gives
up. Right now I think comments are the only anchor for D and it looks back like
300 lines. This does mean that highlighting can be incorrect. If you jump from
the top to the bottom (not scrolling) and there was an open quote/comment that
was never closed you will end up with code which highlights as though it wasn't
in a quote/comment.
Apr 14 2011
parent spir <denis.spir gmail.com> writes:
On 04/14/2011 07:58 PM, Jesse Phillips wrote:

 spir Wrote:


   I
 would like to know how&  how well other editors deal with all of that
 (especially but not only emacs and vim).


 Vim's heritage is line based editing. For this reason operations are performed
by line and it does processing by line. However as it is visual its buffer
consists of more than the line being edited.

 Highlighting is done once again on a per line basis and only of the visible
area (give but never take a few). To handle multiple lines Vim uses
synchronization. It makes use of specific structures which it can use to
'anchor' how the lines below will be highlighted, and again it only needs to
process till the end of the visible area (it will continue processing as you
scroll down).

 You can specify how many lines back Vim will look for an anchor before it
gives up. Right now I think comments are the only anchor for D and it looks
back like 300 lines. This does mean that highlighting can be incorrect. If you
jump from the top to the bottom (not scrolling) and there was an open
quote/comment that was never closed you will end up with code which highlights
as though it wasn't in a quote/comment.


Thanks for this precision.
I prefere the possibility of erroneous highlighting you describe here than 
current Geany's behaviour.

[I have stopped exchanging on Geany's mailing list about features/issues/bugs 
because, it beeing based on scintlla, they seem to constantly forward people to 
request or remark there... except for points they feel concerned with. This is 
understandable, indeed, and rather a fact than a critique; i would probably 
behave the same way in their position. They also are truely blocked by 
scintilla on some points, i guess like when Geany did not properly cope with d 
multiline comments.]

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 14 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.3500.1302792612.4748.digitalmars-d puremagic.com...

 This is a bug of the editor, indeed, but since Geany is based on 
 Scintilla's editon component, I guess this bug may be widely shared.


FWIW, I use Programmer's Notepad 2 which is also based on Scintilla. The 
somewhat older version I've been using (I need to update, just haven't 
gotten around to it yet) doesn't have that problem *because* it doesn't 
recognize D's comments as being multi-line. But I just checked the latest 
version, and it's just like you describe: multi-line strings are highlighted 
correctly, but typing it in unfolds the code that comes after. So it 
probably is a Scintilla issue.

Personally, I don't mind, since I don't use code folding frequently. But I 
can see how that could be annoying. Especially since, just like you, I find 
those "auto-closing" features to just get in my way and I normally turn them 
off.

It's unfortunate, too, since Scintilla does have a lot of good things going 
for it. But then once in a while I'll come across some little thing I wish 
it did differently (for instance, I wish they were receptive to having an 
option for elastic tabstops, and also there's this code folding issue: 
http://code.google.com/p/pnotepad/issues/detail?id=476 ). Heh, Scintilla's 
another one of the 1,000,000 things I'd love to do a D fork of if I had the 
time.
Apr 14 2011
prev sibling parent Kagamin <spam here.lot> writes:
spir Wrote:


 I press '"' '""' is written out (a feature I hate anyway for code edition). I 
 would like to know how & how well other editors deal with all of that 
 (especially but not only emacs and vim).


Visual studio rehighlights instantly and has a timeout of 2 sec for refold.


 Compare with multi-line comments: the difference is double: (1) there is
syntax 
 for single-line comment (2) the closing delimiter is different ('/*' vs '*/'). 
 This means that (1) use of multi-line syntax is limited to actual need for 
 multi-line (2) one can avoid the bug by writing the closing delimiter first, 
 hehe! (what I constantly do when writing docs docs)


And how do you type/delete curly braces?
Apr 15 2011